Lately, doom-mongering is everywhere you look: “In six months, 90% of code will be written by AI!” or “The software engineering profession is dead!” If you take these claims at face value, it sounds pretty unsettling. But let’s take a breath and separate the hype from reality.

Is it true that AI is going to type 90% (or even 100%) of the code? Oh, absolutely. But does that mean it’s going to write it — design the architecture, figure out the business logic, solve the real problems? That’s complete nonsense.

Sure, we’re not going to be furiously mashing keyboards to hammer out endless boilerplate anymore. But make no mistake — this isn’t the end of programming. It’s just the next step in an evolution we’ve already been through. Several times, actually.

From Assembly to Prompts: History Repeats Itself

Think back to the shift from assembly to high-level languages. Developers were literally writing machine instructions by hand — every address, every register. Then abstractions started rolling in. For a while it was this awkward dance between assembly and early high-level languages, with plenty of people loudly insisting that “real programmers” would always need the bare metal. Spoiler: they were wrong. That need just… faded away. We got interpreted languages, massive frameworks, IDEs with LSPs, code completion and smart refactoring tools. The tools got better, the abstractions got higher, and the amount of software we build also increased dramatically.

“Software Is Eating the World”
— Marc Andreessen

Did we stop programming? Nope. Did the number of developers drop? Actually, pretty much the exact opposite happened. The higher the abstraction, the cheaper and faster it is to build software — and when software gets cheaper, businesses just demand more of it. More code, more developers to build it, more engineers to deploy and maintain it.

We’re at that exact same crossroads right now. Except instead of jumping from assembly to C (or Python), we’re leaping from rigid syntax and having to write a lot of boilerplate to plain natural language. And as of early 2026, the boilerplate can be written by a model you can run locally. i.e. we got to the stage where even very small and not very capable (relative to the biggest frontier models) are able to produce most of the boring boilerplate.

Death of Syntax, Long Live the Logic!

Up until now, the biggest roadblock between the software idea in a someone’s head and an MVP of the actual product was the syntax and the technical implementation and deployment details. You had to memorize exactly where the semicolons went, precisely how to declare every class, and which flavor of brackets to use. You had to be a technician, one that has to be very precise with the implementation details, not just an architect of the solution.

What’s happening right now with LLMs and the break neck speed of development of models and capabilities is that we’re bulldozing that roadblock. You don’t need to memorize syntax anymore. You get to just dictate your thoughts. It is very helpful to have a good understanding of the fundamentals. Sure, right now we still have to jump in and manually massage the generated code every so often. But give it a year, two, or three, and that awkward back-and-forth will be mostly a thing of the past. We’ll literally just be speaking our architecture and logic into existence.

The developer of the future isn’t the person typing 120 words per minute. It’s the thinker, the engineer, the architect—the person who can formulate their ideas with crystal clarity and give precise instructions to the machines. We’re about to have a lot more code, and it’s going to get much more complex.

Many studies have shown that the majority of software developer’s time roughly 90% is spent on reading code, not writing new code. With LLMs taking care of the syntax and boilerplate, developers will be freed up to focus on the higher-level abstractions, logic and design.

In line with the Jevons Paradox, the more efficient and cheaper something becomes, the more we end up using it. So as it becomes easier and faster to generate code, we’re going to see an explosion in the amount of software being created. And with that explosion comes a need for more developers to manage and maintain all that new code.

So as the amount and complexity of software grows, the need for skilled “developers” (we might be calling them “software architects” or “logic engineers”) to manage and maintain that code will only increase. The demand for such people is not going to decrease; it’s going to skyrocket.

This means we’ll need more developers than ever before to manage and maintain all this new code. But what kind of developers? The ones who can think critically, design robust architectures, and solve complex problems. The ones who can communicate their ideas clearly and work effectively with AI tools.

Fundamentals Still Matter (more than ever)

If anything, I think this swings the pendulum back toward fundamentals. Sure, you can ask an AI to suggest an algorithm or explain a design pattern. But you need to understand those concepts yourself — well enough to plan ahead, hold the whole mental model of a system in your head, reason through trade-offs, and make the call on which approach actually fits. That part doesn’t get automated. If you don’t know what good looks like, you won’t know when the AI is handing you something bad.

The age of syntax is over. The age of logic and architecture is just beginning. And honestly — I can’t wait to see where it takes us.

Low, Medium, High, Extra High

What flavor of Codex should you use?

After spending couple of weeks testing the different flavors of Codex, I can say that the performance we very inconsistent between the Medium, High and Extra High flavors.

The Low flavor can only be used for really simple tasks. In my experience I would probably rank it below Gemini 3 Flash though.

The Medium flavor is the most consistent one. It is not the best in terms of performance, but it is the most consistent one.

What surprised me was that the High and Extra High flavors were not consistently better than the Medium flavor. In some cases, they were actually worse than the Medium flavor. Especially the High gave me results that were worse than the Medium provided.

The Extra High flavor, is obviously the slowest one and It usually produced pretty good results, but sometimes it just overthought things. It was going on tangents and doing things that clearly it wasn’t supposed to do.

My conclusion is that the Medium flavor is the best option for most tasks except really hard ones for which one should probably use the Extra High in planning mode and then execute the plan with the Medium.

If you are getting the:

PhaseScriptExecution [CP] Embed Pods Frameworks issue in

the workaround is to update the generated

*-frameworks.sh files

to add the -f flag to the call to readlink.

This is most likely needs to be done only for your main frameworks.sh file

replace

source="$(readlink "${source}")"

with

source="$(readlink -f "${source}")"

Valid strings are any single-character string, or any of the following strings:

f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, 
f13, f14, f15, f16, f17, f18, f19, f20, 

pad., pad*, pad+, pad/, pad-, pad=,
pad0, pad1, pad2, pad3, pad4, pad5, pad6, pad7, pad8, pad9,
padclear, padenter

return, tab, space, delete, escape, help,
home, pageup, forwarddelete, end, pagedown, 

left, right, down, up,

shift, rightshift, cmd, rightcmd, alt, 
rightalt, ctrl, rightctrl, capslock, fn

For example, to bind the left shift key, you would use “shift”. To bind the right shift key, you would use rightshift. To bind the left command key, you would use “cmd”. To bind the right command key, you would use rightcmd etc…

These are pretty self explanatory.

If you like the vertical rulers showing the column limit of the 80, 100, 120, or whatever you like to have, it’s super easy to set up in VSCode, apparently – no extensions needed.

Just an easy setting:

"eslint.codeActionsOnSave.rules": null,
"editor.rulers": [
    80,
    120
],
"workbench.colorCustomizations": {
    "editorRuler.foreground": "#ffffff11"
}

In this case, rulers will be drawn at column 80 and 120, which can be helpful when following specific coding conventions or when trying to prevent lines of code from becoming too long.

Here, the color of the ruler lines is being customized to be a semi-transparent white color (#ffffff) with an opacity of 0.11 (11%). This could be useful to make the ruler lines less distracting or to make them stand out more against a dark background.

What is doctl

Doctl is a command-line interface (CLI) tool for managing and interacting with DigitalOcean resources. There are several benefits to using Doctl, such as its ability to automate complex tasks and streamline workflows. With Doctl, users can easily create, configure, and delete resources such as droplets, volumes, and load balancers. Additionally, Doctl offers a simple and intuitive interface for managing clusters, deploying applications, and monitoring resources. Other benefits of using Doctl include its ability to integrate with popular DevOps tools like Terraform and Ansible, as well as its support for multiple programming languages and platforms. Overall, Doctl provides developers and system administrators with a powerful and flexible tool for managing their DigitalOcean infrastructure.

resourceID='4851361'

function DO-create-snapshot() {
    doctl compute droplet-action snapshot $resourceID --snapshot-name "subdomain.domain.com$(date +%Y-%m-%d-%H-%M-%S)"
}

function DO-delete-last-snapshot() {
    snapshotID=$(doctl compute snapshot list -v --region nyc3 | awk 'NR>1' | sort -k4 | awk 'NR==1{print $1}')
    doctl compute snapshot --interactive=false delete $snapshotID  --force      # non interactive variant suitable for automation
}

# first schedule the creation of the new snapshot and IF successful - delete oldest one
alias DO-rotate-NYC-snapshot="DO-create-snapshot-NYC_DO_COMITIC_COM && DO-delete-last-NYC3-snapshot"

of course, you can do that for many resources and name the methdos accordingly

Hope it helps!

Why delete DerivedData

The DerivedData folder is a directory used by Xcode to store intermediate build outputs, including compiled code, logs, and other temporary files. While it can be helpful in speeding up the build process, over time, the folder can accumulate a large amount of data, which can take up valuable disk space. Additionally, the contents of the DerivedData folder can sometimes become corrupted, leading to build errors and other issues. In such cases, deleting the DerivedData folder can help resolve these issues and free up disk space, allowing Xcode to recreate the necessary files the next time you build your project. Therefore, it may be necessary to delete the DerivedData folder periodically to ensure optimal performance and stability when working with Xcode.

DERIVED_DATA="~/Library/Developer/Xcode/DerivedData/"

alias goto-DerivedData="cd $DERIVED_DATA"

alias derivedData-Delete="XcodeDeleteDerivedData"
alias XcodeDeleteDerivedData="rm -rf $DERIVED_DATA"

This code is defining four aliases in a Bash shell environment that are related to the DerivedData folder used by Xcode.

The first line assigns the path of the DerivedData folder to the DERIVED_DATA variable. The ~ in the path is a shortcut for the user’s home directory.

The second line creates an alias named goto-DerivedData that changes the current working directory to the DerivedData folder. This alias saves the user from having to type the full path to the DerivedData folder every time they need to access it.

The third line creates an alias named derivedData-Delete that calls another alias named XcodeDeleteDerivedData.

The fourth line creates an alias named XcodeDeleteDerivedData that deletes the entire contents of the DerivedData folder using the rm -rf command. The -rf option stands for “recursive force” and tells the command to delete all files and subdirectories within the DerivedData folder, even if they are write-protected or hidden.

Overall, these aliases provide convenient shortcuts for navigating to and deleting the DerivedData folder used by Xcode, which can help free up disk space and resolve build errors.

in 3 words

It is PITA

in 2 words

Huge PITA

:)

#Useful Crontab CheatSheet

Commands

• crontab -e → Edit or create a crontab file if doesn’t already exist. (This is the command you would want most of the times)
•  crontab -l → Display the crontab file.
•  crontab -r → Remove the crontab file.
•  crontab -v → Display the last time you edited your crontab file. → (This option is only available on a few systems.)

Params

* * * * * command to be executed
– – – – –
| | | | |
| | | | +—– day of week (0 – 6) (Sunday=0)
| | | +——- month (1 – 12)
| | +——— day of month (1 – 31)
| +———– hour (0 – 23)
+————- min (0 – 59)

An example script for backing up a database

#!/bin/bash

backupfolder="/backup/mongo/`date +"%Y-%m-%d_%H.%M"`"
db="db_to_backup"

# do the dump
mongodump --uri="mongodb://user:pass@domain:27017/" --db=$db  -v --gzip --out=$backupfolder

# repack with zip - 0 - just basically adding a password...
zip -0 -P alamoAlamo $backupfolder/backup.zip $backupfolder/$db/*.gz 

# cleanup original *.gz files
rm -fR $backupfolder/$db