What Will Developers Do?

There has been a lot of talk lately about AI making English the new programming language. This creates the impression that anyone can program. As is often the case with marketing slogans, the reality is more complicated. In this article, I want to look a little deeper into software development and explain how I believe the role of the developer will change in the age of AI.

Today, almost anyone can prompt their way to a simple application. Describe what it should do in natural language, let AI produce the implementation, iterate a few times, and you have working software.

But as many vibe coders have already discovered, the more complex the software becomes, the harder it is to keep the whole thing together. Software always had a canonical model. Sometimes it was written down. Often it lived in developers’ heads. AI can only work from the version that is captured. So the developer’s job moves from writing the code to keeping that model.

The focus of a developer’s work will shift from implementation to system modelling and architecture.

When natural language is no longer enough

Complex systems cannot be described in prose alone over the long term. Not because AI cannot handle it, but primarily because we humans cannot.

As rules, logic, data and their relationships accumulate, we start losing track of the description itself. We pile rules on top of rules, contradictions and ambiguities appear, and eventually we lose sight of what the current desired state of the system actually is.

Natural language is not enough to describe a complex system unambiguously.

AI can ask follow-up questions, but that does not help much if we do not know the answers ourselves. Eventually, it has to fill in the gaps with its own assumptions. This starts a spiral in which the system gradually drifts away from its original intent.

Mathematicians were dealing with this problem long before computers existed. Mathematical notation did not emerge because mathematicians were unable to write sentences, but because beyond a certain level of complexity they needed a more precise way to work with meaning.

Software has the same problem. If we want to manage complexity, we need a description that is more precise and structured than prose.

Back to the roots

Fifteen years ago, we commonly worked in a way where the business expressed a need and an analyst turned it into a consistent, structured description of the system. This captured the data model, rules, algorithms, invariants, permissions and other important elements. It was abstract enough to remain independent of any particular technology, yet precise enough to allow the system to evolve consistently.

The problem was that people did not particularly like this canonical model of the system.

Business stakeholders often found it difficult to read. Developers saw it as unnecessary formality and preferred to start coding. The analyst therefore was not only the author of the model, but also a translator between worlds: helping the business understand it and helping developers turn it into stories, tasks and concrete implementation.

Many teams gradually abandoned this discipline and replaced it with a backlog. But that did not create a description of the system. It created a history of changes to the system.

The backlog describes changes. The canonical model describes the current state of the system.

With human developers, this approach could work surprisingly well for a long time because much of the real system model remained in their heads. They knew why historical decisions had been made, where the sensitive areas were, and what a new change was likely to break.

The problem appeared when the team changed.

Then comes the sentence familiar to almost anyone who has ever inherited someone else’s system:

“We need to rewrite the whole thing.”

Often, this is not evidence that the previous team built bad software. It is evidence that when the people left, part of the system model disappeared with them because it had never been captured anywhere else.

AI changes the economics of development

A canonical model that was often an inconvenient intermediate layer for humans is, on the contrary, a very useful input for AI. Precisely defined data, invariants, states, algorithms and contracts are far more reliable than a history of tickets and knowledge hidden in the heads of a few senior developers.

What a developer often saw as mere documentation can become the actual specification for AI.

AI dramatically reduces the cost of translating the model into implementation. And once implementation becomes cheap, value moves one level higher: to the person who can describe the system correctly and keep its model consistent as it evolves.

So what will developers actually do?

The role of the developer will not disappear, but it will change significantly.

One part of the job will be analytical. Developers will need to understand the business, capture the system’s logic in a canonical model, and keep that model consistent as the system evolves.

Another part will be architectural. Among other things, developers will decide where service boundaries lie and who owns which data, what must be transactional and where temporary data inconsistency can be tolerated. They will design interfaces and deployment models and determine how the system fits into the company’s broader infrastructure.

Developers will, of course, still need to understand the resulting code. But their job will not be to manually read every line generated by AI. More important will be verifying that the resulting software conforms to the canonical model and architectural decisions. An increasing share of that verification can be handled by tests, contracts and other automated mechanisms.

T-shaped is no longer enough

This is uncomfortable news, especially for narrowly focused specialists. It will become increasingly difficult to build your value around being, for example, a frontend developer waiting for a perfectly prepared ticket in the backlog. The traditional T-shaped profile, with one deep specialisation, may no longer be enough.

Future developers will need much broader reach. Their profile may look more like a rake. They will need enough understanding of the domain, data, architecture, security and infrastructure to keep the system as a whole together.

Specialisation will not disappear. But it will no longer be enough.

This may result in one role or two. One may sit closer to the business and the canonical model, the other closer to technology and architecture. What matters is that value is shifting away from writing code and towards managing complexity.

AI will not turn developers into prompters. It will force them back towards software engineering itself.

Code will become cheaper. Good decisions will not.

The developer of the future will not own the code. They will own the complexity of the system.