Will Agentic Coding Replace Engineers? A Pragmatic Take

It is the question I am asked more than any other at the moment, usually with a slightly nervous edge: will agentic coding replace engineers? The first thing I say is that the question is framed wrongly. It invites a yes-or-no answer, and that framing is what stops people thinking clearly about what is actually happening to their work.

This is an opinion piece, so let me be plain about mine. I do not think "replace" is the right word. But I also do not think the comfortable reassurance ("nothing really changes, it's just autocomplete with ambitions") survives contact with what these tools can now do. Both extremes are wrong, and both appeal for the same reason: they let you stop paying attention. The more useful question is narrower and harder: which parts of the engineering job are about to get cheaper, and which parts are about to get more valuable?

Reframing the question

An engineer's job is not one thing. It is a bundle of activities that happen to be performed by the same person: understanding a problem, deciding what to build, specifying it precisely, writing the code, integrating it, verifying it works, and being accountable when it does not. Agentic coding does not act uniformly across that bundle. It compresses some parts to nearly free and leaves others almost untouched. So rather than "engineer: yes or no", the useful thing to look at is where the value moves.

In my view the pattern is already fairly clear. The commodity work gets cheap. The judgement work gets dearer.

WHAT GETS CHEAPER                  WHAT GETS SCARCER / MORE VALUABLE
-----------------                  --------------------------------
boilerplate & scaffolding          system design & architecture
typing out known patterns          specifying intent precisely
rote translation between           verification & deciding what
  languages / frameworks             "correct" actually means
first-draft glue code              security & trust boundaries
look-up of unfamiliar APIs         accountability for outcomes
mechanical refactors               taste & judgement under ambiguity

None of the items on the right are new. Good engineers have always been paid for them. What is new is that they are becoming the whole job rather than a fraction of it, because the left-hand column is being absorbed. If most of your day is spent on the left, that is worth knowing now rather than later. If most of it is spent on the right, your leverage is about to increase.

This is the abstraction ladder again, with a twist

We have been here before, and it is worth remembering how it went. Assembly gave way to higher-level languages, compilers took over register allocation, IDEs absorbed the tedium of navigation and refactoring. Each step raised the level of abstraction at which engineers worked. And each step, contrary to the anxiety of its day, increased demand for engineers rather than eliminating it. Making software cheaper to build did not shrink the market; it expanded the range of things worth building until the appetite outran the supply of people who could build them.

I think agentic coding is, in large part, another rung on that same ladder. It raises the abstraction level again: you increasingly describe intent and review outcomes rather than hand-assembling every line. The historical pattern suggests this expands rather than contracts the work.

The parallel does weaken at one point, though, and I would rather say so than pretend it is exact. A compiler is deterministic. Given the same input it produces the same output, and once you trust it you can largely stop checking. An agent is not deterministic. It is fluent, plausible, and occasionally confidently wrong in ways that look exactly like being right. That difference matters. It changes what "raising the abstraction level" costs you, because the new layer cannot simply be trusted and forgotten the way a compiler can.

A compiler you can trust and stop reading. An agent you can delegate to, but you can never stop reading its output. Most of the real risk, and most of the remaining value, sits in that difference.

The last-mile problem

This is how it looks to me day to day. On well-specified, well-bounded work, an agent will get you a long way, frequently most of the way, quickly and competently. The trouble is that the remaining stretch is not a smooth continuation of the first. The last mile is where correctness, integration with the messy reality of an existing system, edge cases nobody wrote down, and genuine judgement all live. And that stretch remains stubbornly human.

The dangerous move is to mistake the cheap, fast majority for the whole job. When something arrives ninety per cent finished and looks polished, the temptation is to assume the last ten per cent is a formality. It is usually the opposite: the last ten per cent is where the difficulty was concentrated all along, which is exactly why it is the part the agent struggled with. Teams that get hurt are not the ones using these tools. They are the ones over-trusting the part that was easy and under-investing in the part that was always hard.

Risks worth naming honestly

I am optimistic about the tools, but optimism is not the same as denial. There are real risks here, and I think they are under-discussed because they are less exciting than either the utopian or the apocalyptic stories.

• Junior deskilling and a broken apprenticeship pipeline. Engineers have traditionally earned their judgement by doing the commodity work (the boilerplate, the debugging, the unglamorous slog) and slowly internalising why things break. If agents absorb that tier, where do the next generation's instincts come from? You cannot review work well if you never learned by doing it badly first. This worries me more than any other item on the list, because its costs arrive late and are hard to reverse.
• Over-reliance and automation complacency. The literature on automation in aviation and elsewhere is unambiguous: when a system is right most of the time, humans stop checking it, and their skill at catching the rare failure atrophies. The better the agent, the stronger this effect, and the more it matters that someone is still genuinely paying attention.
• Accountability gaps. When a generated system fails at three in the morning and nobody on the team fully understands how it works, who is accountable? "The agent wrote it" is not an answer a regulator, a customer, or a post-incident review will accept. Accountability does not transfer to a tool, however capable.
• Quality and security erosion under delivery pressure. The same pressure that makes "ship it, the agent says it's fine" tempting is the pressure that has always degraded engineering quality. Agents do not create that pressure, but they make it far easier to act on, and far easier to generate plausible-looking code whose security properties nobody has actually reasoned about.

I name these not to argue against the tools but because pretending they do not exist is how organisations walk into them.

What I think engineers should actually do

My advice is not "learn to prompt." It is to move up the stack deliberately. The work that is becoming more valuable is the work of directing, reviewing, and architecting systems that now include agents as components. That is a real skill set, and it is not the same as writing code faster.

Concretely, the posture I would recommend is this. Treat the agent as a capable, fast, tireless junior whose output you are nonetheless fully accountable for. You would not merge a junior's pull request unread because it looked confident; the same discipline applies here, and the agent's fluency makes that discipline harder to maintain, not easier. Own the verification. Own the trust boundaries: decide explicitly what the system must guarantee and check that it does, rather than assuming the generated code shares your assumptions. Own the system design, because that is the part the agent cannot do for you and the part that determines whether the cheap, fast code adds up to something coherent or to a pile of plausible fragments.

The engineers who thrive, I suspect, will be the ones who stop thinking of themselves primarily as people who write code and start thinking of themselves as people who are responsible for systems being correct, safe, and worth building, with agents as one of the ways that gets done.

An honest close

I will not pretend to certainty I do not have. The non-determinism, the pace of change, and the second-order effects on hiring and training make confident prediction foolish, and anyone selling you certainty in either direction is selling something. What I will commit to is that the role changes substantially. It changes more than the reassuring camp admits, and differently from how the alarmist camp imagines. "Replace" is the wrong word, because the human work at the top of the ladder is becoming more valuable, not less. But the comfortable conclusion that nothing of consequence is happening is, in my view, the real mistake. The job is moving. The sensible response is to move with it, eyes open, rather than to argue about whether it is moving at all.