Why "Lines of Code" Died as a Productivity Metric (And What Replaced It)

Ninety percent of developers now use AI daily. Individual output is up — more pull requests, more tasks completed, more code shipped per person.

And according to DORA's own 2025 research, delivery instability is rising right alongside it.

The uncomfortable finding underneath the AI productivity story: more code, faster, is not the same thing as more value delivered.

Counting output was always a flawed proxy for productivity. AI just made the gap between the two impossible to ignore.

What the data actually shows

DORA's 2025 State of AI-assisted Software Development report, based on nearly 5,000 technology professionals, found that AI functions as an amplifier, not a fix.

It strengthens the performance of well-run teams and amplifies the dysfunction of poorly-run ones.

The report's central tension: AI accelerates initial code generation, but the time saved in writing code is frequently reallocated to auditing and verifying it. One developer's description, quoted directly in the report, captures it: they feel more productive, but "at a cost."

The trust gap underneath this is real and persistent. Roughly 30% of developers report little to no trust in AI-generated code, a number that has barely moved year over year despite adoption climbing past 90%.

Teams using AI coding tools have also shown deployment frequency rising and change failure rate rising in parallel — more shipped, more of it breaking.

Separate 2026 telemetry research reinforces the same shape: individual output metrics climb sharply (more pull requests merged, more tasks completed per developer), while organizational delivery metrics, the throughput that actually reaches customers, stay comparatively flat, at least initially.

Why "lines of code" was always the wrong number

Lines of code was never actually a measure of value; it measured typing. AI made this obvious by making typing nearly free. A metric that rewards volume, once volume costs almost nothing to produce, stops measuring anything meaningful.

Worse, it actively rewards the wrong behavior: more code, more surface area for bugs, more to review, more to maintain, none of which is what a business actually wants from its engineering org.

The same logic applies to a subtler modern version of the same mistake: token consumption.

A "new trend has emerged," per DORA's own recent commentary, of organizations tracking and rewarding raw AI token spend through internal leaderboards to encourage adoption.

Treating token spend as a performance indicator repeats the exact mistake lines-of-code made. It's a proxy for activity, not outcomes, and it's just as easy to game.

What replaced it: DORA's own evolution

DORA's own metrics have had to evolve to stay useful. The classic four (deployment frequency, lead time for changes, change failure rate, and mean time to recovery, since reframed as failed deployment recovery time) got a fifth addition in 2025: rework rate — the share of engineering work that's reactive rework rather than planned, forward progress.

This single addition is arguably the most important AI-era metric shift, because it directly captures the thing lines-of-code and raw throughput both miss: how much of the "output" is actually being redone.

Even DORA's own analysis now acknowledges the limits of this framework in the AI era. Deployment frequency and lead time for changes become misleading once AI generates a large share of committed code — they measure how fast code moves, not whether the code was worth moving.

Mean time to recovery holds up best, because recovering from a production incident still depends on human judgment, system architecture, and observability, none of which AI code generation meaningfully changes.

The metric that matters most right now: what happens in code review

DORA's 2026 report on AI ROI makes a specific, actionable point: writing more code and opening more pull requests faster doesn't by itself mean a company is delivering more value.

If the rest of the delivery pipeline doesn't scale to match, especially code review, the speed gained during development shows up as cost later: more changes waiting for review, more rework, more instability reaching production. AI doesn't eliminate the bottleneck in a delivery pipeline. It moves it downstream, usually to review.

This reframes the whole measurement question. The right question isn't "how much code did AI help us produce," it's "did the code that reached production stay in production without creating rework, instability, or hidden cost later."

What elite teams track instead, practically

• Rework rate — how much of this sprint's work is fixing or redoing prior work, rather than new forward progress

• Change failure rate, watched specifically against AI-touched code — tracking whether AI-generated changes fail at a different rate than human-written ones, since this is the earliest warning sign of AI accelerating technical debt rather than genuine output

• Time-to-production for a change, not just time-to-commit — a fast commit that then sits in review for a week isn't actually fast

• A qualitative read on developer trust in AI output — a team where developers don't trust the AI-generated code they're shipping is a team accumulating hidden verification debt, whether or not the dashboards show it yet

What this means for you

If your engineering org is still reporting on lines of code, commits per developer, or raw AI token usage as a productivity signal, you're measuring something that costs nothing to inflate and tells you almost nothing about whether real value is reaching production.

The organizations getting real ROI from AI adoption in 2026 are the ones that shifted the measurement question from "how much did we produce" to "how much of what we produced actually stayed shipped" — and they built their review and delivery pipeline to keep pace with the code AI helps generate, rather than letting the bottleneck quietly move downstream and out of sight.

Rethinking how your team measures delivery in the AI era? Talk to MUST about engineering delivery