AI Cuts the Easy 80% of Coding in Half. The Hard 20% Barely Moves.

AI saves up to half the time on documentation, a bit over a third on writing routine code, a quarter to a third on refactoring. On high-complexity tasks, under 10%.

That gradient is the most useful thing in McKinsey's research on AI and developer productivity, and almost nobody quotes the last number. The tools deliver real, large savings on the routine work – 45 to 50% on documentation, 35 to 45% on writing code, 20 to 30% on refactoring. And on the genuinely hard tasks, the ones McKinsey's developers rated high in complexity, the savings collapse to less than 10%. For junior developers on complex work, the fuller writeup found some tasks actually took 7 to 10% longer with the tools than without.

So AI is spectacular at the easy 80% of coding and barely moves the hard 20%. That sounds like a minor caveat, but it's actually the whole ballgame, because your delivery date almost never lives in the easy 80%.

A quick, honest note on the number you've probably seen

There's a figure circulating that a McKinsey study of 4,500 developers found a 46% cut in routine coding. Go looking for that study and you hit a wall: the "4,500 developers, 46%" framing lives in aggregator posts citing each other, not in McKinsey's own published research. What McKinsey actually published is the gradient above – routine work cut by roughly a third to a half, high-complexity work under 10%. That's the version worth standing behind, because you can open the source and read it.

I'm flagging this on purpose. The specific, round, confident statistic is usually the one that got laundered through three blogs until it lost its parentage. The messier published version is the one that's true. If a stat can't survive you clicking through to its source, it shouldn't survive into your planning.

The bottleneck was never the boilerplate

Here's why the gradient matters more than the headline. Software teams don't miss deadlines because writing CRUD endpoints was slow. They miss them on the hard parts: the architecture decision nobody wants to own, the integration with a system whose docs are a lie, the subtle bug that only shows up under load, the unfamiliar framework someone has to actually learn. That's the 20% where projects go sideways. And it's exactly the 20% where AI's contribution rounds to noise.

This is a theory-of-constraints problem wearing an AI costume. If a factory's bottleneck is the paint station, buying a faster cutting machine upstream doesn't ship one more unit – it just grows the pile of parts waiting for paint. Adding capacity anywhere except the constraint is motion without progress. AI coding tools are a very fast cutting machine. If your constraint is the paint station – the hard, complex, judgment-heavy work – making the easy part faster produces more code waiting on the same hard decisions, not more shipped software.

In software the paint station has a hundred faces, and none of them are typing. It's the one senior engineer who really understands the payments system, so everything that touches payments waits on her calendar. It's the staging environment that only mostly works, so every release burns a day proving it's safe. It's the requirements nobody pinned down, so a third of what got built fast gets rebuilt slowly once someone finally asks what it was for. Point AI at the code around those constraints and you generate more work that piles up in front of the same bottleneck. The pile gets bigger and it arrives faster. The date doesn't move, because the date was never a function of how quickly the unblocked work went.

The aggregate data has been quietly telling this story. DX's longitudinal study of 400-plus organizations found that as AI usage jumped about 65%, median pull-request throughput rose just under 8%. That's the signature of a tool hammering a non-bottleneck: enormous local speedup, tiny system-level result. Stanford's research across roughly 100,000 developers puts the mechanism underneath it, finding AI's effectiveness swings hard with task complexity and codebase maturity – strongest on simple, greenfield work, weakest on complex work in mature systems. Which is to say: weakest exactly where mature companies spend most of their hard hours.

Why smart teams still get fooled

The trap is that the easy 80% is where all the visible, satisfying metrics live. Lines of code, commits, pull requests, tickets closed – those all light up when you accelerate routine work. The dashboard looks incredible. Meanwhile the release date doesn't move, because the release date was always hostage to the hard 20% that no dashboard cleanly measures. You get faster at the measurable thing and stay stuck on the thing that matters, and the gap between those feels mysterious right up until you name it.

There's a comfort story that says this is temporary, that the next model will crack the hard 20%. Maybe. But the current data describes the tools as they are now, and planning a delivery date on a capability that doesn't exist yet is how you end up explaining a slip to the board. Plan for the gradient you can measure, not the one you're hoping for.

Find the constraint before you buy more throughput

The move isn't to abandon AI coding tools. On the easy 80% they're genuinely excellent, and capturing 40% off your routine work is real money and real relief for your team. The move is to stop expecting throughput on the routine to fix a bottleneck that lives somewhere else.

This is why "how do we boost developer productivity" is the wrong opening question and "where does our delivery actually stall" is the right one. They sound similar and lead to opposite places. The first sends you shopping for tools that speed up coding, which your own numbers will then show barely moved the outcome. The second sends you to find the single step that governs everything downstream of it – and once you've named that step, you often find it isn't a coding problem at all. It's a decision nobody's made, an ownership gap, a system only one person understands. AI can't fix those, and buying more of it just lengthens the queue in front of them.

So before the next round of AI spend aimed at "developer productivity," answer a prior question: where is your delivery actually stuck? If it's stuck in boilerplate and glue code, wonderful – AI is aimed straight at it. If it's stuck in architecture, integration, unfamiliar systems, and complex debugging, more code generation will grow the pile at the paint station and call it progress. That diagnosis – finding the one constraint that actually governs the outcome, before spending against it – is the difference between AI making you feel busy and AI making you ship.

None of this is an argument against the tools. It's an argument for aiming them. The easy 80% getting cut in half is a real gift – it frees a team from the drudgery that never should have eaten their week in the first place. It's just not the part of the job that was ever in the way of shipping, and mistaking it for the part that was is how you spend a budget and miss a date in the same quarter.