AI won’t replace software engineers—but it will expose the ones who can’t think

By: Enitan A. Awosanya

We have been here before. The typewriter, the factory robot, the spreadsheet — each was greeted with the same mixture of panic and dismissal that AI now provokes. History suggests we are asking the wrong question again. The right one is far more uncomfortable.

In 1961, a General Motors plant in New Jersey installed the first industrial robot on a production line. The machine, called Unimate, weighed nearly two tonnes and performed a single task: removing die castings from a moulding machine and welding them onto car bodies. The United Auto Workers union was alarmed. Newspaper columnists warned of mass unemployment. A presidential commission was convened to study the threat of automation to the American workforce.

Six decades later, automobile factories employ more people than they did in 1961 — not because the robots went away, but because the nature of the work changed. The robots took the jobs that were dangerous, repetitive, and physically destructive. The humans kept the jobs that required judgment, adaptation, and the ability to reason about problems that had not been anticipated in advance. The workforce did not disappear. It transformed.

We are living through an almost identical moment in software engineering. And we are, with impressive consistency, making almost identical mistakes in how we think about it.

Every generation believes its automation crisis is uniquely existential. Every generation has been wrong in the same way — and right in ways it did not expect.

A Pattern as Old as the Loom

The fear of technological unemployment is not a modern invention. The Luddites who smashed textile machinery in early nineteenth-century England were not simply reactionaries afraid of change. They were skilled craftsmen watching a specific set of competencies — competencies that had taken years to develop and that commanded genuine market value — become suddenly worthless. Their grievance was real. Their prediction, however, was wrong. The textile industry did not shrink. It expanded by orders of magnitude, and the aggregate demand for labour with it.

The same pattern repeated with the typewriter, which was predicted to eliminate the need for clerks and secretaries — it created millions of them. It repeated with the spreadsheet: when VisiCalc arrived in 1979, accountants feared that the need for human number-crunching would evaporate. Instead, the spreadsheet made financial analysis cheap enough that it was applied everywhere, dramatically increasing demand for people who could interpret and act on financial data. The automation did not destroy the profession. It redefined what the profession was for.

There is a name in economics for the mechanism that explains this pattern: the Jevons paradox, named after the Victorian economist William Stanley Jevons, who observed that as steam engines became more efficient, coal consumption went up rather than down, because the lower cost of steam power made it economical to apply in entirely new contexts. Efficiency gains in technology tend to expand the market for that technology rather than contract it. The history of computing is in large part a continuous demonstration of this principle.

Where We Are on the Curve

Gartner’s Hype Cycle — the research firm’s now-famous framework for tracking the maturity of emerging technologies — describes a pattern that will be familiar to anyone who has watched a technology go from laboratory curiosity to industry standard. A trigger event produces a wave of inflated expectations. Hype builds to a Peak. Then reality intervenes, and the technology slides into what Gartner calls the Trough of Disillusionment, before eventually climbing, more slowly and more soberly, to the Plateau of Productivity.

AI coding tools have followed this arc with almost textbook fidelity. The Peak of Inflated Expectations arrived around 2023, when a succession of impressive demonstrations produced a wave of commentary claiming that software engineers would be obsolete within years. The Trough is arriving now, as organisations that deployed these tools at scale confront the gap between what the tools promised and what they reliably deliver. The code they generate looks correct. In the happy path, it often is. At the edges — under load, at the boundaries of the specification, in the presence of requirements that were never made explicit — it frequently is not.

This does not mean the tools are without value. It means we are in the phase of the cycle where the initial narrative gives way to a more nuanced one — where practitioners start to develop a genuine understanding of what the technology does well, what it does poorly, and how to integrate it into workflows that exploit its strengths while compensating for its limitations. This is where every transformative technology eventually lands. It is where AI coding tools are heading.

We are somewhere between the Trough of Disillusionment and the Slope of Enlightenment. This is not a crisis. It is where the real work begins.

What AI Is Actually Good At

To understand the shift clearly, you have to be honest about what modern AI coding tools genuinely do well. They are remarkably good at pattern completion: given a recognisable context, they can produce syntactically correct, idiomatic code at a speed no human can match. They are good at boilerplate, at standard implementations, at translating a well-specified requirement into working code that follows a known pattern. They can explain unfamiliar codebases, generate test cases for existing functions, and surface common classes of bugs.

None of this is trivial. These are tasks that consumed real engineering time. The engineers most immediately affected are those whose primary value proposition was execution speed within well-understood patterns — the same position that typists occupied when word processors arrived, or that bookkeepers occupied when spreadsheets did. The task has been commoditised. That is not nothing. But it is also not the end of the profession.

What AI Cannot Do

AI coding tools have no model of the problem space. They have a model of the solution space: they know what code looks like, how patterns are typically assembled, what a well-formed response resembles. But they have no understanding of why a particular system needs to exist, which constraints are load-bearing, or what the consequences of an architectural decision will be eighteen months from now when usage patterns have shifted and the team that built the original system has changed entirely.

This is not a limitation that will be trivially engineered away. It reflects something fundamental about what software engineering, at its best, actually is. It is not the production of code. It is the translation of messy, ambiguous human problems into systems that are reliable, maintainable, and capable of evolving. The code is the output. The judgment is the work.

I have seen this distinction play out with particular clarity in the fintech systems I have worked on. The regulatory and business constraints shaping a payments architecture are not legible to an AI that has never sat in a room where a compliance officer explained why a specific edge case could result in a fine, a frozen account, or an uncomfortable conversation with the regulator. That knowledge is not in any training corpus. It is embedded in context, relationships, and hard-won experience. Robots replaced the dangerous, repetitive work on the factory floor. They did not replace the engineers who designed the factory.

The Amplification Problem

There is a subtler risk that receives less attention than the replacement narrative, and it is the more serious one. AI coding tools are powerful amplifiers. They amplify good engineering judgment into extraordinary output. They also amplify poor engineering judgment into extraordinarily confident disasters.

An engineer who understands what she is building can use AI assistance to move faster, explore more solution paths, and prototype ideas she previously would not have had time to test. An engineer who does not understand what she is building will use AI to produce more code, faster, with greater apparent confidence. The code will look correct. It will often run correctly in the simple case. It will fail in the ways that matter — under load, at the boundaries, when assumptions that were never made explicit turn out to have been wrong all along.

And it will fail at scale, because AI-assisted engineers can produce ten times the volume of code in the same time, which means ten times the surface area for the failures to hide in. This is what the Trough of Disillusionment is largely made of: not the tools failing, but the tools succeeding at producing code while the engineering judgment required to make that code trustworthy was never really present.

The Unimate robot did not replace the engineer who designed the production line. AI will not replace the engineer who understands what the system is actually for.

What This Moment Actually Requires

The strategic imperative for engineers is the same one that has emerged from every previous wave of automation: invest relentlessly in the capabilities that the technology cannot replicate. For software engineers today, that means systems thinking — the ability to reason about how components interact, how failure propagates, how a design decision made today creates constraints three years from now. It means domain expertise. It means communication: the irreducibly human work of translating between the language of business problems and the language of technical solutions.

For organisations, the imperative is to resist treating AI-assisted productivity gains as an opportunity to reduce engineering headcount without reducing engineering complexity. The complexity does not go away because the code is generated faster. If anything, it accumulates more rapidly. The companies that will win are not the ones that use AI to replace engineers. They are the ones that use AI to make their best engineers more capable of doing the work that has always mattered most.

Unimate did not end manufacturing. The typewriter did not end the office. The spreadsheet did not end accounting. Each of them changed, irrevocably, what it meant to work in those fields — and in each case, the people who thrived were the ones who understood what the technology could not do, and built their expertise around that understanding.

The engineers asking that question now are not threatened by AI. They are the ones who will define what the profession becomes.

Awosanya is a software engineer and technical co-founder with experience across fintech, startups, and technology consultancy.