Skip to content

Who Gets Replaced, Who Becomes Irreplaceable#

A person stands on a path splitting toward a fog-shrouded dead end labelled with legacy processes, siloed AI efforts, rising costs and lost relevance, versus a sunlit path labelled with agentic workflows, unified platform, compound impact and market leadership.

Who Gets Replaced vs. Who Becomes Irreplaceable

Skills Career Team design

What agents are actually good at absorbing#

Looking honestly at what coding agents do well today, without overclaiming: they are strong at scoped, well-specified, low-ambiguity tasks with a clear definition of done - updating a dependency and fixing the resulting breakage, writing tests for existing behaviour, refactoring within an established pattern, generating documentation from code, or implementing a well-described bug fix from a reproducible report. These are exactly the tasks that used to consume disproportionate senior engineer time relative to their difficulty.

What doesn't get replaced is judgement under ambiguity: deciding what should be built and why, trading off architectural approaches with incomplete information, negotiating requirements with stakeholders, and - critically - deciding whether a given agent output is actually correct, safe, and worth merging. That last one, reviewing and owning the outcome, is not a shrinking skill. It's the one every other chapter on this site assumes you're getting better at.

The shift in where value concentrates#

Absorbed by agents Becomes more valuable in humans
Writing boilerplate and repetitive scaffolding Framing the problem correctly before any code is written
Mechanical refactors within an established pattern Recognising when a "mechanical" refactor actually hides a design decision
First-draft test coverage Deciding what's worth testing and what the tests should actually assert
Summarising a diff or a log Deciding whether the summary is trustworthy enough to act on
Producing multiple implementation options quickly Choosing between them with organisational and technical context an agent doesn't have

The irreplaceable skill set is less "can you type fast" and more "can you be the accountable adult in the room" - which maps directly back to Rule Zero. Engineers who lean into review rigour, architectural judgement, and clear problem specification become more valuable as agent throughput increases, because they're the multiplier on that throughput. Engineers who only offered typing speed are competing with a tool that types faster than any of us ever could.

A practical reframe for individual contributors#

If you lead a team, the coaching conversation shifts from "how fast can you code this" to:

  • Can you write a specification an agent could act on unambiguously? This is a real skill - vague tickets produce vague (or wrong) agent output just as they produce vague human output, only faster and at more volume.
  • Can you review someone else's (or something else's) work rigorously, quickly, and fairly? This was always valuable; it's now a larger fraction of the job.
  • Can you spot when an agent is confidently wrong? This requires the same domain depth as before - agents don't remove the need to actually understand the system, they raise the cost of not understanding it.

Exercise: audit your last two weeks of tickets#

Split your last ten completed tickets into two piles: "an agent could plausibly have drafted the first pass of this, with a human reviewing," and "this required judgement calls an agent couldn't make on its own." For the second pile, write one sentence per ticket on what specifically required human judgement. That list is a good first draft of the skills to invest in deliberately, rather than leaving to chance.

Further reading#