AI Speeds Up Coding, but Productivity Isn't Rising: What DevEx Metrics Explain

The expectation was simple: with AI assistants, a developer ships three to four times more quality code. In practice, almost no team sees a multiple-fold gain in productivity. One of the most cited studies, METR's randomized experiment from 2025, found that experienced open source developers using AI tools solved tasks 19% slower, even though they estimated they were about 20% faster. Habr has published a translation of an analysis whose author suggests adding DevEx metrics to DORA and SPACE to capture what conventional statistics miss. We rely on the announcement of the piece and on commonly known descriptions of these frameworks.

Why the code is faster but the outcome is the same

Writing code takes up only part of a developer's working day. The rest goes to discussions with colleagues, searching for documentation, waiting for reviews and approvals, builds and tests, and switching between tasks. AI speeds up the most visible stage, so the bottleneck simply shifts. This is Amdahl's law at work: if you speed up only one stage of a process, the overall gain is capped by that stage's share.

There is also a counter-effect. More generated code means more diffs to review, more checks, and a higher risk that a bug slips through. Output per person rises, while the team's throughput stays the same. That is why metrics such as lines of code, commits, or the share of accepted suggestions say almost nothing about actual delivery speed.

Three measurement frameworks

Each framework looks at its own part of the system:

• DORA: four delivery metrics: deployment frequency, lead time from commit to production, change failure rate, and time to recover from a failure. It shows the pipeline's results.
• SPACE: five dimensions: satisfaction, performance, activity, communication and collaboration, and efficiency and flow. The framework warns that productivity cannot be described by a single number.
• DevEx: three factors of developer experience: feedback speed, cognitive load, and the ability to enter a flow state. It shows what gets in the way of work.

DevEx is the one that answers where the saved minutes go. Slow CI, an unclear architecture, scattered documentation, and an approval queue eat up the gains from autocomplete, and DORA will capture this only indirectly, through the final delivery time.

How AI changes the measurement itself

AI tools introduce new variables into DevEx. They reduce cognitive load on routine work but add a new burden: verifying someone else's code, even if that someone is a machine. They speed up the search for answers but can lead developers into plausible-looking errors. The gap in METR's data between the actual slowdown and the perceived speedup shows that surveys alone are not enough. You need both subjective assessments and process telemetry.

What to measure in practice

It is worth starting before assistants are rolled out widely: without a baseline, the effect cannot be separated from seasonal fluctuations and changes in team composition. After that, it makes sense to compare three layers of data.

• Wait time: review queue, CI duration, approval delays.
• Quality: change failure rate and recovery time from DORA, as a counterweight to speed.
• Developer experience: regular short surveys about flow, workload, and the quality of feedback.

Check separately whether the load on reviewers has grown. If AI has sped up the authors while senior engineers drown in diffs, the team gains on activity and loses on delivery. And do not turn the number of accepted suggestions or the volume of generated code into a KPI: such figures are easy to inflate, and they are not tied to business results.