Lately, it feels like 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 definitely sounds scary. But let’s take a deep 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 actually write it for us? Like, design the architecture, figure out the business logic, and solve the real problems? That’s complete nonsense.

Sure, we’re not going to be furiously mashing our keyboards anymore just to hammer out endless lines of boilerplate. 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.

From Assembly to Prompts: History Repeats Itself

Think back to the shift from assembly to high-level languages. Back in the day, developers were literally writing machine code by hand. Then the first abstractions rolled in. For a while, there was this messy dance between assembly code and early high-level languages. But eventually, the need to tinker down at the “bare metal” level just vanished. We got interpreted languages, massive frameworks, and beastly IDEs.

Did we stop programming because of all that? Nope. Did the number of developers drop? Actually, the exact opposite happened! The higher your level of abstraction, the cheaper and faster it becomes to build software. And when software gets cheaper and faster to build, businesses just demand more of it. Which means we need more code, and a whole lot more developers to architect it all.

Right now, we’re sitting at that exact same crossroads. Except this time, instead of jumping from C to Python, we’re leaping from rigid syntax to plain, natural language.

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 its break neck speed of development is that we’re bulldozing that roadblock. You just 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)

I think this puts the emphasis on fundamentals of computer science back. You can always ask the AI assistant to suggest/explain algorithms, data structures, and design patterns. But you need to understand those concepts yourself to be able to effectively plan ahead and hold the mental model of the system in your head. You need to be able to understand the trade-offs and make informed decisions about which approach to take. But I digress. Perhaps this is a topic for another post.

The age of syntax is coming to an end. The age of logic and architecture is just beginning. And I am excited to see where it takes us and how we can push the boundaries of what’s possible with software.

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.

This is a draft post.

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)