AI Makes Senior Engineers Slower. That's Not a Paradox.

METR ran a controlled experiment on experienced open-source developers. The result: on complex, novel tasks, senior developers were 19% slower when using AI tools than without them. The developers themselves predicted they'd be 24% faster.

At the same time, McKinsey's 2026 Tech Workforce Report shows demand for software developers up 34% since AI coding assistants became mainstream.

The instinct is to call this a contradiction. It isn't.

What the experiment actually measured

The METR study used experienced developers on tasks that were genuinely complex — meaning no existing solution could be copy-pasted, the scope required building a coherent model of a novel problem, and the developer couldn't proceed without understanding the system at depth.

On that class of task, AI slows you down. The overhead isn't worth it. Switching between your own reasoning and the AI's output, verifying correctness, correcting hallucinated context — all of that interrupts the cognitive work that complex problem-solving requires.

I've hit this directly. When I'm designing something new for Ordia — a new coordination model, a branching detection approach I haven't built before — AI assistance is actively in the way. Not because the output is wrong, but because the process of getting to the output interrupts the process of building the mental model I need. The model doesn't form through prompting. It forms through struggle.

The developers in the METR study overestimated AI's value on the hardest tasks because they were calibrated on AI's performance on the easier ones. It's reliable at the center of the distribution. It's unreliable at the edge — where senior developers actually spend most of their time.

What AI is good at

This is not an argument against AI tools. It's an argument for accurate mental models of what they do.

AI is fast and reliable on tasks with clear specifications and existing patterns. Boilerplate. Implementation of understood abstractions. Translating a well-defined interface spec into working code. For these tasks, the productivity gains are real and compounding.

My practice: I write the skeleton manually. The interfaces, the architecture, the places where the system splits and where it stays flat. Once that model exists in my head and on the page, I hand the interior to the AI. It fills in the parts I've already modeled. I review against the model I already have.

The distinction is: AI works when you already understand the problem. It's a production tool for the work you've already done in your head.

For senior engineers spending most of their time on problems they haven't solved before, that class of work is a minority. The novel, complex, judgment-heavy work — where the real value is generated — is exactly where AI is 19% slower.

Why demand for engineers is up

The 34% demand increase isn't despite AI. It's partly because of it.

AI tooling has lowered the entry cost for software products. More teams are building software. More surface area of software exists that needs to be maintained, extended, and reasoned about. The total amount of engineering work hasn't gone down — it's expanded into corners that previously weren't economical to address.

There's also the review layer. SiliconANGLE reported that enterprises are pushing back on unchecked AI-generated code and instituting more review processes. Someone has to do that review. The more AI-generated code exists, the more senior judgment is needed to assess it.

The value of an engineer hasn't been in producing code for a long time. It's in making decisions about what the code should be, whether the existing code is correct, and where the system will fail under conditions nobody has tested. None of that has been automated. Demand for it went up.

The calibration problem

Where teams get into trouble is applying AI tools uniformly regardless of task complexity.

A team that uses AI heavily on well-understood tasks and manually on novel tasks is getting the benefit without the cost. A team that AI-generates everything and reviews superficially is shipping code at speed with structural debt accumulating underneath.

The 19% slowdown finding is useful not as an argument to abandon AI but as a calibration signal: know which bucket your current task is in before deciding how much AI to involve. Most developers don't make that distinction explicitly. The tool is on or off, not deployed conditionally based on task type.

The developers in the METR study who expected to be 24% faster were presumably not making that distinction either. The tool that helps on 80% of tasks feels like it should help on all of them. That intuition is wrong in a specific, measurable way.

What this means for skill development

If AI reliably handles the easy tasks and slows you down on the hard ones, the implication for skill development is significant.

Junior developers who lean heavily on AI for the work they're supposed to be learning through — implementing patterns, making small architectural decisions, debugging confusing state — are skipping the work that builds the capacity to do the hard tasks later.

The hard tasks don't get easier through AI familiarity. They get easier through accumulated experience doing hard things manually. The developer who uses AI to avoid struggle is deferring the development of exactly the capacity that makes senior engineers valuable.

I started programming at 12. The value wasn't in the code I wrote — it was in the thousands of hours of confusion, debugging, and reconstruction that built the model. AI would have removed most of that friction. The friction was the point.

None of this is a case for artificial difficulty. It's a case for understanding what work is producing judgment versus what work is producing output. Those are different things, and optimizing for one at the expense of the other is a mistake that shows up years later.

The METR result is data. The right response is to update the mental model of what AI is for, not to dismiss the data because it's inconvenient.