We measured the easy part and mistook it for the work

Part 3 of a three-part series on AI, engineering, and what actually changed. Part 1: the code was never the hard part. Part 2: AI relocated the line between engineers and non-engineers, it didn’t erase it.

Here’s the tension boards are living with. The tools demonstrably work – engineers really are generating code faster, non-engineers really are shipping prototypes. The spend is enormous and the vendor decks promise transformation. And yet the productivity dividend, the one that justifies the invoices and the headcount projections, stubbornly refuses to show up at the level of the whole business. What’s going on?

The short version: we sped up the easy part, and then measured the easy part, and mistook that for speeding up the work. To see why that’s not a cynical dodge but a structural fact, you have to look at what we count.

The metric that refuses to die

The clearest symptom is our enduring attachment to lines of code. LoC has been discredited as a productivity measure for decades – not because it’s imprecise, but because it’s actively perverse: it rewards the wrong things (volume, verbosity, the developer who writes 500 lines over the one who deletes 500) and it aims everyone’s attention at code as the output of engineering, when code was never where the difficulty lived. (Bill Gates got there early: measuring programming progress by lines of code is like measuring aircraft-building progress by weight.)

People reach for it anyway, and always for the same reason – it’s easy. It’s a number that moves. Under pressure to show a number that moves, an easy-but-wrong metric beats a hard-but-right one every time; teams then optimise for it, the count goes up, and the value it was meant to stand in for doesn’t.

And the pressure has been ratcheting. First the return-to-office push, where “people are more productive in the office” became received wisdom its own advocates couldn’t quite define. Now AI, where boards and vendors need to show a return on enormous spend – and a metric that reliably moves when you hand everyone a code-generating assistant is exactly the seductive, wrong number to reach for. Of course LoC goes up when the machine writes the code. That was never the question.

“Fine – measure speed instead”

The obvious rejoinder is: fine, LoC is crude – measure speed. But speed of what? Lines shipped is volume, not speed. Story-point velocity is closer, but it’s team-specific, unnormalised, and meaningless across teams – and the moment you make it a target, Goodhart’s Law takes over and it stops measuring anything at all. That’s the deeper lesson, and it generalises past LoC: any metric that sits too close to the code invites gaming, because the code is the easy, countable part.

But there’s a subtler error than picking a gameable metric, which is measuring only one of the two things that matter. Delivery has two axes.

One is throughput – how fast the machine runs. Here the DORA metrics (deployment frequency, lead time for changes, change-failure rate, time to restore) are a real improvement: they track the flow and stability of delivery rather than the volume of output, and they’re harder to game because they hold each other in tension – you can’t juice deployment frequency without change-failure-rate punishing you for it.

The other axis is alignment – whether the machine is pointed at the right target at all. And this is the one that matters more, because a team can be elite on every DORA metric and still be shipping the wrong thing at speed: maximally efficient at going nowhere.

Alignment is where the job actually lives

Alignment is exactly where the rest of the work goes. Study after study, across two decades and wildly different methods, converges on the same uncomfortable shape: developers spend somewhere between a fifth and a third of their time actually writing code. (The oldest estimates – writing new code perhaps 20–25% of the time, the rest spent integrating and fixing – predate the current AI wave entirely.) The remainder goes to design, testing, review, coordination, and meetings. Whatever the exact figure, the direction is settled – and that remainder isn’t overhead wrapped around the real work of coding. It is the work: deciding what to build and keeping everyone pointed the same way.

Which is why AI’s throughput gains hit a ceiling so fast. The tools attack the fifth-to-a-third that is coding – the easy, countable axis – and barely touch the rest. You can make the coding ten times faster and still move the whole system by only a handful of percent, because you sped up the axis that was never the constraint. The constraint was always alignment, and alignment is the hard part precisely because no assistant can do it for you. This is just Amdahl’s Law wearing a lanyard: optimise the small fraction and the whole is barely faster.

That single fact explains the missing dividend. The gain is real but bounded, and it’s bounded by arithmetic, not by how good the models get.

The bitter irony

Here’s where it turns painful. That alignment work – architecture, communication, coordination, translation of fuzzy business need into something buildable – is exactly what gets undervalued when you optimise for code volume. And it maps onto exactly the roles first in the firing line: architects, the “non-coding” senior people, the ones whose calendars are full of meetings that a LoC-shaped mindset reads as not working. The pressure falls on “time spent not coding” precisely when not-coding was the constraint all along.

Meanwhile the promised savings are quietly failing to appear as productivity. Where headcount is being cut and attributed to AI, the numbers often tell a different story on inspection – Uber’s CFO, for one, has described the company’s AI “savings” as tempered engineering hiring rather than any measured productivity gain. A hiring freeze with a narrative attached is not the same thing as a machine doing the work of the people who left.

AI is very good at generating the thing we were already best at producing and worst at valuing. It is not good at the thing that was always scarce: deciding what should exist, and why, and how it fits with everything else.

Where this leaves us

Put it together and the missing productivity gain stops being a mystery. The tools genuinely accelerate coding – the fifth-to-a-third of the work that was never the bottleneck. The bottleneck was alignment: architecture, judgement, coordination, deciding what should exist. We can’t automate that yet, so the system-level speedup is bounded no matter how fast the code flows. And when we go looking for proof that it’s all working, we reach – under pressure, because it’s easy – for the one metric that measures the part that was never hard.

The productivity gain isn’t missing because the AI is disappointing. It’s missing because we pointed it at the fast axis and then measured the fast axis, while the slow axis – the one that was always the job – sat exactly where it always was.

The code was never the hard part. Let’s stop measuring as though it were.

This concludes the series. Part 1 argued the code was never the hard part; Part 2, that AI relocated rather than erased the line between engineers and non-engineers; and Part 3, that this is precisely why the promised productivity gains haven’t materialised.