Two engineers picked up similar tasks with the same AI assistant. The one six months into the job flew — the tool filled gaps in her knowledge, suggested the idiom she did not yet know, turned a day of searching into an hour. The principal engineer beside her, working in a service he had built and maintained for three years, found himself oddly slower. He knew exactly what he wanted to write. Now he was reading what the model wrote instead, checking it, correcting its confident near-misses, and explaining in a prompt what he could simply have typed. Same tool, opposite effect. Neither result was a mistake.
The finding, stated plainly
Across the better studies of AI coding assistance, the benefit is unevenly distributed: it is largest for less-experienced developers and for anyone working in unfamiliar territory, and smallest — occasionally negative — for experienced engineers working on code they know well. The most-cited example is a controlled trial by METR, which found experienced open-source developers were measurably slower with early-2025 AI tools on their own familiar projects, even though they believed they had been sped up. Other analyses of broad developer populations show the same gradient: the biggest gains accrue to juniors and recent hires.
This is not a claim that senior engineers are bad at using AI, nor that the tools are useless at the top end. It is a claim about where the tool’s value lands — and it follows directly from what made someone senior in the first place.
Why expertise inverts the benefit
AI coding tools are, in essence, a very fast way to turn intent into plausible code and to surface knowledge you do not already hold. That is enormously valuable when the constraint is knowledge — when you do not know the API, the idiom, the pattern. It is worth much less when you already do.
- For a newcomer, writing the code is the hard part. AI removes the search, the half-remembered syntax, the unfamiliar framework — and the speed-up is real.
- For an expert on familiar code, writing was never the bottleneck; deciding what to write was, and that decision is already internalised. AI accelerates a step that was cheap for them, and adds a new one: reviewing generated output for the confident near-misses that are the hardest kind to catch.
- The expert also carries the burden of knowing what good looks like. They notice the subtle wrongness a newcomer would accept, so they spend time correcting and re-prompting where a junior would simply move on — slower, but also safer.
So the paradox resolves: AI substitutes for knowledge the newcomer lacks and the expert already has. It is a leveller, and levellers help whoever is furthest from the level.
| Newcomer / unfamiliar code | Expert / familiar code | |
|---|---|---|
| The bottleneck | Knowing what to write | Already internalised |
| What AI does | Supplies missing knowledge | Speeds an already-cheap step |
| New cost AI adds | Small — gains dominate | Reviewing output they could have written |
| Net effect | Faster | Flat — sometimes slower, usually safer |
The mistake is telling your most experienced people that AI will make them faster at the thing they are already fastest at. It will not. Aim it at the edges of what they know, and protect the centre — the judgement and review the rest of the system now leans on harder than ever.
What to do with the gradient
The finding is an allocation signal, not a verdict on anyone’s skill. Use it to point AI where it pays and to protect the work it cannot do.
- Aim AI at unfamiliar territory: new languages, unowned services, breadth work, boilerplate — where the constraint is knowledge the tool can supply.
- Stop measuring seniors by generated volume: their value was never typing speed, and it is even less so now that review and judgement are the scarce work.
- Reinvest the senior hours AI frees at the edges into the centre: architecture, acceptance, mentoring, and reviewing the flood of generated code — the tasks the whole system now depends on more.
- Mind the apprenticeship: the same tool that speeds juniors can also rob them of the struggle that built senior judgement in the first place — a risk we treat in our piece on the missing rung.
The headline that AI makes everyone more productive is too coarse to plan with. It makes the inexperienced faster and frees the experienced from the wrong tasks — but only if you let it. Aim it at what people do not know, and guard the judgement they do.
Frequently asked
- Does AI make senior developers slower?
- Sometimes, on code they know well. A controlled METR trial found experienced developers were slower with early-2025 tools on their own familiar projects, even while feeling faster. It is not that seniors are bad with AI — writing was never their bottleneck, so the tool speeds a cheap step and adds the cost of reviewing generated output. On unfamiliar work, seniors benefit like anyone else.
- Why does AI help junior developers more than seniors?
- Because AI substitutes for knowledge. A newcomer’s bottleneck is knowing what to write; AI supplies the missing API, idiom or pattern, so the gain is large. An expert has already internalised that knowledge, so the tool accelerates a step that was already cheap and adds a new reviewing cost — leaving the net benefit small.
- Should senior engineers stop using AI?
- No — they should aim it differently. AI pays off for experts in unfamiliar territory, breadth work and boilerplate, where the constraint is knowledge. On code they know deeply, the gain is marginal, so their time is better spent on architecture, review and judgement — the scarce work the rest of the system now depends on.
- What does this mean for how we measure productivity?
- Stop measuring senior engineers by generated volume. Their value is judgement, architecture and review, not typing speed — and those are now the bottleneck. Measuring AI’s impact by lines or “percent faster” misreads exactly the people whose contribution matters most.