Will AI Replace Programmers? What Three Waves of Automation Taught Me

Will AI replace programmers? Not the profession, and not in the way the question imagines. It is replacing a large share of the tasks programmers were paid for, starting with the typing, and it is changing what the word programmer means. I have watched that exact sequence twice before in thirty years of writing and architecting software. Each time the prediction was extinction, each time the outcome was transformation, and each time the people who lost were not the ones the headlines named.

This is not an argument that nothing changes. Something very large is changing, faster than the previous two waves, and I will get to who is at risk. But the question deserves an answer from someone who was inside the room the last times it was asked.

First wave: the tools that were going to write the code

I started in IBM development labs in the 1990s, writing C and C++ against systems that ran on mainframes. The prediction then was that programmers were a transitional species. CASE tools would generate applications from diagrams. Fourth-generation languages would let analysts describe what they wanted and skip the engineers. Visual builders would make code a detail. A few years later the fear changed shape but kept its conclusion: after Y2K, offshoring would move whatever programming remained to wherever it was cheapest, and the European or American developer would become a project manager or a memory.

What actually happened is that the cost of producing software fell, so organisations wanted far more of it. The diagrams did not replace the programmers; they became one of the things programmers used. The generated code still had to be understood, debugged and integrated with the systems that already existed, which was where most of the money and most of the risk lived. Offshoring did move a great deal of work, and it did hurt people who were doing exactly the work that moved. But the total number of people writing software for a living grew for the whole of the following two decades. This is the pattern economists call the Jevons paradox: when something gets cheaper to produce, demand for it does not shrink to match, it expands to fill the new price.

The same thing had happened before my time, more quietly. Compilers were supposed to make programmers unnecessary, because business people would write in something close to English. What they did was make assembly language a specialism and create a profession several orders of magnitude larger than the one they replaced. The spreadsheet did the same to bookkeeping: the clerks who did arithmetic by hand declined, the accountants and analysts who used the spreadsheet multiplied. Automation of a task has, historically, expanded the role around the task.

Second wave: the cloud was going to make engineers redundant

The second time I heard it I was at Microsoft and then ServiceNow, and the word was cloud. Infrastructure as a service would end the system administrator. Platform as a service would end the need to understand operating systems, networks and databases. Low-code platforms, and I spent years on one of the best, would let business users build their own applications. Developers would be needed only for the hard parts, and the hard parts would get smaller every year.

The system administrator did largely disappear as a job title. The person did not. They became a site reliability engineer, a platform engineer, a cloud architect, with a larger scope and, in most markets, a larger salary. Low-code produced an enormous amount of software, most of it built by people who would never have called themselves developers, and almost all of it eventually needed someone who understood data models, integration and security to make it survive contact with production. The hard parts did not get smaller. They moved up a level of abstraction and multiplied, because there was now so much more software to hold together.

If the first wave taught me that cheaper production means more demand, the second taught me where the demand goes: toward integration, toward data, toward the parts of the system that have to be true rather than merely working. I have spent the years since on data platforms for that reason.

Third wave: the machine that writes the code

This wave is different in one respect that matters and I will not pretend otherwise. The first two automated the mechanics around programming. This one automates the programming itself. A coding agent today takes a ticket, reads a repository, writes the change, runs the tests and opens a pull request, and in my own work the share of code I type by hand has fallen to a small fraction of what it was two years ago. I described the shift in role in From Developer to AI Supervisor, and the organisational consequences in The Great Reorg. Both pieces still hold, and both understate the speed.

So why do I still answer no to the question in the title? Because of what did not get automated. The agent does not know what the system is for. It does not know that the field called status has meant three different things since 2009, or that the regulation changed in March, or that the team in Lyon will refuse the API shape you just proposed for reasons that were decided before you joined. It does not decide what is worth building, what is safe to change, what correct means for this organisation, or who is accountable when the change is wrong. It writes code against a specification, and the specification, the verification and the accountability are the job. They always were. We just used to spend most of our hours on the part in between.

The pattern of the first two waves is already visible. Software is getting cheaper to produce, so more of it is being produced, by more people, and the work of making it coherent, secure, performant and true is growing faster than the work of typing it. I see this every week in the public sector, where the backlog of things that should be software is measured in decades, not months. There is no scenario in which Europe’s administrations run out of software to build because the agents got too fast. There is a very plausible scenario in which they finally start catching up.

Who is actually at risk

Three groups, and the honest essay names them.

The first is anyone whose job was a single, well-specified task done repeatedly: converting a design into markup, writing CRUD endpoints to a pattern, translating one language into another, producing test cases from a specification. That work is what the agents are best at, and it is what the first wave’s offshoring and the second wave’s platforms already squeezed. It will not come back.

The second group is the one I worry about most: the juniors. For forty years the profession trained its seniors by giving juniors the simple tasks and letting them learn the system by doing them. Those tasks are the ones the agent now does, and the entry-level market has tightened accordingly. If the industry does not deliberately rebuild the ladder, with juniors learning by reviewing, specifying and verifying agent output under supervision rather than by typing, it will have no seniors in ten years. That is a decision organisations are making now, mostly by default, and mostly badly.

The third group is the senior engineer who refuses the tool. I met that person in both earlier waves: the one who would not touch the generator, would not learn the cloud console, would not use the low-code platform because real engineers write everything. They were right about the craft and wrong about the market. The engineer who uses the agent is not going to be replaced by the agent. The engineer who does not will be replaced by the one who does, and that was true of the compiler too.

What the programmer becomes

The role that is emerging has four parts, and none of them is new; they were the parts of the job that mattered most and got the least time. Specification: saying precisely what the system must do and must never do, in a form a machine can act on and a human can audit. Verification: deciding whether what came back is correct, safe and consistent with everything else, which requires understanding the system more deeply, not less. Systems thinking: knowing how data flows, where the state lives, what breaks when a change lands, and what the regulation says about it. And judgment about what to build at all, which is the one thing no amount of generated code supplies.

Notice that all four are about truth and consequences rather than syntax. That is why I believe the people best positioned for this decade are the ones who understand data, because data is where the truth of a system lives and where the consequences of a wrong change show up. The agent can write the query. Knowing whether the query means what the business thinks it means is the job.

The practical questions, answered

Will AI replace software engineers by 2030?

It will replace most of the hand-written code and many of the roles built around producing it. It will not replace the engineer who specifies, verifies and takes responsibility for systems, because those tasks are not what the models do; they are what the models need. Expect fewer people typing, more people reviewing, and a profession that looks more like engineering than it has in decades.

Should I still learn to code?

Yes, for the same reason an architect still learns how a building stands up even though nobody expects them to lay bricks. You cannot verify what you cannot read, you cannot specify what you do not understand, and you cannot supervise an agent in a language you have never written. Learn to code, then spend your energy on data, systems and the domain you want to work in.

Which programming jobs are safest from AI?

The ones closest to consequences: systems where a wrong change costs money, safety or legal standing, and where someone must be accountable for it. Data architecture, security, platform engineering, regulated-industry software, legacy modernisation where the knowledge is in people’s heads rather than in the code. The least safe are roles defined by producing a well-specified artefact to a pattern.

What does AI mean for junior developers?

A harder entry and a faster climb for those who get in. The simple tasks that used to be the apprenticeship are gone, so the apprenticeship has to be rebuilt around reviewing and verifying agent output, understanding systems end to end, and learning the domain. Juniors who do that will reach senior judgment years earlier than my generation did. Organisations that stop hiring juniors because the agent does their old work are borrowing from a future they will not be able to repay.

Is this time different?

In speed and in reach, yes. In direction, no. Every previous wave automated a task, made the output cheaper, expanded demand for it and moved the human role toward specification and judgment. This wave does the same thing to a larger slice of the work, in years rather than decades. The risk is not that the pattern breaks. It is that institutions, from universities to hiring managers to public procurement, adapt more slowly than the tools.

What I tell the people who ask me

Use the agents, every day, for everything they can do, because fluency with them is the new literacy and because the hours they free are the hours you need for the parts that matter. Move toward data, toward systems and toward a domain, because that is where the consequences live and consequences are what pay. Insist on verification you can defend, because the next decade’s incidents will be caused by code nobody read. And if you lead a team, hire the juniors anyway and rebuild the ladder, because the profession has never been replaced by its tools, but it has, more than once, been impoverished by people who assumed it would be.