The Nature of Programming Is Changing Again

Programming is changing its nature again.

If we look at the history of programming, we have continually created new layers of abstraction and tools that hide more and more implementation details.

• First came machine code and punch cards.
• Then assembly.
• Then compilers and high-level languages.
• After that came libraries, frameworks, and ready-made components.
• Later, Stack Overflow made an enormous collection of existing solutions accessible to everyone.

Now we have the next layer: LLMs.

Every such transition was met with roughly the same reaction:

"Now programmers will stop understanding what is going on."

— The Internet

But something else happened.

More and more people gained the ability to build increasingly complex systems, while programming became more accessible. It was not just the tools that changed, but also the level at which a developer had to think.

• Machine code made us think in processor instructions.
• Assembly — in registers and memory.
• C — in algorithms and resource management.
• Java and C# — in objects and models.
• Elm and Haskell — in pure functions, immutable data, and effect management.
• React — in components and UI state.
• Kubernetes — in infrastructure and distributed systems.
• LLMs seem to be freeing us from some of the work at the level of individual lines of code, shifting our attention to the structure of the system as a whole.

Each new layer of abstraction did more than simply hide the one before it. It reframed the question:

"At what level should an engineer think now?""

— A New Layer of Abstraction

Meditating on the Problem

But LLMs \ AI are bringing about another important change.

Writing code used to be part of the thinking process — a kind of meditation on the problem 🧘.

When you spent several hours implementing a new feature, you gradually immersed yourself in the domain, found suitable abstractions, noticed contradictions, discarded unsuccessful approaches, and wrote tests.

Code was not just the result of your thinking. It was a tool you used to think.

Now the workflow increasingly looks different:

You define a task, send it to an LLM \ Agent, and a few minutes later receive hundreds of lines of finished code. Instead of gradually immersing yourself in the problem, you move almost immediately to review.

The meditation of programming turns into the rather tedious review of code that is yours, yet was written by someone else.

That is why Amelia Wattenberger's essay Code Is a Medium for Thought resonated with me. It is also beautifully designed.

Perhaps code is valuable not only because it makes a computer do something. It also helps people formulate their own thoughts.

When a model increasingly does this work for us, a question arises:

"As we stop writing code by hand, are we also losing part of the process of understanding the problem?"

On the other hand, perhaps we are not ceasing to think. Perhaps we are simply moving our thinking to a higher level.

Instead of asking:

"How do I write this function?""

— A Programmer

we are increasingly asking a different question:

"What should this system be in the first place?""

— An Engineer

From Programmer Back to Engineer

When I was studying to become an automotive electrical systems engineer, we were taught to understand how every element of a system worked: power sources, wiring, relays, sensors, actuators, and electronic control units.

But a modern car can no longer be designed one light bulb at a time.

First, an engineer defines the requirements for the vehicle and its functions. Then they design the interactions between its subsystems. Only after that do the specific electronic control units, data buses, wiring harnesses, sensors, and the code that controls them appear.

Software development seems to be moving in the same direction.

We start less and less often with individual functions, and more often with requirements, system boundaries, data flows, component interactions, and acceptable trade-offs.

Perhaps the profession of the programmer is gradually turning back into the profession of the engineer.

Implementation Is Getting Cheaper, but Design Is Not

In the past, a significant amount of time went into figuring out implementation details: language syntax, API behavior, libraries, and tools.

Today, an AI Agent can do much of this work almost instantly.

But if you have not thought through the architecture, modeled the domain incorrectly, or drawn the boundaries between services in the wrong places, a model is unlikely to save the project.

More likely, it will simply implement a bad idea very quickly 🧞‍♂️.

This leads to an important conclusion:

"LLMs make implementation cheaper, but they do not make design cheaper."

— The Key Takeaway

That is why the following skills may become especially valuable in the coming years:

• system design
• architectural thinking
• domain modeling
• the ability to formulate requirements
• an understanding of technical and product trade-offs

Knowing the syntax of a particular language will become roughly equivalent to an automotive engineer knowing the pinout of a particular electronic control unit.

It is useful. Sometimes you cannot solve a problem without it. But by itself, it no longer defines someone's level of expertise.

Programming as Magic

If natural language really is becoming the next layer of abstraction, then over time programming may come to be perceived much like electricity or the internet is today.

People will build products, automate work, and launch businesses with almost no idea of what is happening under the hood.

In a sense, programming will become magic.

As Arthur C. Clarke wrote:

Any sufficiently advanced technology is indistinguishable from magic.

— Arthur C. Clarke

But that is precisely why an understanding of fundamental principles may become even more valuable.

For most people, programming may indeed become magic. An engineer, however, will have to understand why that magic works, where its limits lie, and when it begins to break down.

Perhaps in ten years, the best programmer will not be the person who remembers TypeScript or Go syntax perfectly, but the one who can design systems, formulate requirements precisely, and find the right trade-offs.

Code will become an intermediate artifact.

Engineering thinking will become the main product.