AI coding agents break most developer KPIs by inflating the exact numbers those KPIs count. Lines shipped, pull requests opened and tickets closed all rise mechanically when a machine writes the first draft, while the real work moves downstream into review and integration. Four measures survive contact with agents: change throughput paired with change failure rate, rework and duplication rate, review load per merged change, and verified time reallocation. Everything else is a vanity number waiting to be gamed.
The measurement problem here is genuinely hard — hard enough that the research organisation running the most rigorous experiment on this question publicly abandoned its own study design in February 2026. If you are being asked to prove the ROI of an agent rollout by quarter end, you should know what you are walking into.
Why the old KPI set breaks when agents write the code
Every classic developer productivity metric is a proxy. Lines of code proxy for effort, pull request count for delivered units of work, story points for complexity. Each held together only because there was a rough, stable relationship between the proxy and the thing you cared about: a human spending human time producing considered work.
Agents sever that relationship. Generating 400 lines is no longer evidence that 400 lines' worth of thinking happened. The proxy inflates while the underlying quantity does not, and the ratio between them is now a function of tool configuration rather than team capability.
GitClear's Maintainability Gap research, published January 2026 across 623 million analysed code changes from 2023 to 2026, tracks what happens to the code itself as AI assistance scales:
- Duplicated code blocks rose from 40.3 per million changed lines in 2023 to 73.0 year-to-date in 2026 — an 81% increase, and the highest level in their record.
- Copy-pasted code went from 9.4% of changed lines in 2022 to 15.7% in the first half of 2026.
- Moved code — the signature of refactoring — collapsed from 21% of changes in 2022 to 13% in 2023 to 3.8% year-to-date in 2026.
- Cross-file function calls, a reuse signal, fell 35% since 2023 (343 to 223 method calls per thousand changed lines).
- Error-masking constructs rose 47%; two-week code churn rose 15%.
Read those together and the pattern is unambiguous: output volume up, structural quality down. A dashboard measuring only the first half will show a triumphant quarter during a period of accumulating debt.
Google's 2025 DORA report, drawn from nearly 5,000 technology professionals, found the same shape at the delivery level. Ninety per cent of respondents use AI at work and more than 80% believe it increased their productivity — but 30% report little or no trust in AI-generated code. DORA observed a positive relationship between AI adoption and both delivery throughput and product performance, and a continued negative relationship with delivery stability. Their explanation is worth writing on a whiteboard: acceleration exposes weaknesses downstream. Without strong automated testing, mature version control and fast feedback, more change volume simply produces more instability.
What the research actually says about AI and developer speed
Here is where most articles on this topic stop being useful: they cite one number and treat it as settled.
In July 2025, METR published a randomised controlled trial of 16 experienced open-source developers across 246 issues in mature repositories. Developers predicted AI would make them 24% faster. They were measured at 19% slower. Afterwards, having lived through the slowdown, they still estimated AI had sped them up by 20%.
That perception gap is the single most useful finding in this literature, and it is the reason self-reported productivity surveys are not a KPI. Your engineers are not lying to you. They cannot tell.
The part almost nobody cites is what happened next. METR ran a follow-up through late 2025 with 57 developers and 800-plus tasks, and in February 2026 published an update saying the design no longer works. Between 30% and 50% of developers told them they were declining to submit tasks because they did not want to do those tasks without AI. An increasing share said they would not accept the study's terms at all. METR describes its own central estimate as likely a bad proxy for the real productivity impact, and calls the data only very weak evidence. They also flag the original 19% figure as historical and no longer reflective of current tools.
So the honest state of the evidence in August 2026: a well-funded research organisation running a randomised trial with paid participants and controlled task assignment cannot produce a reliable point estimate of how much AI changes developer speed. If that is the ceiling, a quarterly survey asking "how much time did AI save you this week?" is not measurement. It is sentiment.
This does not mean nothing can be measured. It means measuring things that do not depend on isolating a counterfactual. DX's AI Measurement Framework, built with the researchers behind DORA and SPACE, splits the problem into utilisation, impact and cost, and reports real deployments in those terms: Booking.com achieved a 16% throughput increase within several months of deploying AI tools to over 3,500 engineers, and even leading organisations reach only around 60% active usage. Both are observable facts about a system rather than inferences about a counterfactual — which is precisely why they are usable.
Where the work actually moves
Output metrics mislead because agents do not remove work from the pipeline — they relocate it. Code generation gets cheap; everything that validates, integrates and operates that code does not.
If your KPI set samples only the "Generate" segment, it will report improvement no matter what happens to the rest of the pipeline. That is the structural reason AI dashboards look better than AI outcomes.
The four KPIs worth keeping
1. Change throughput, never reported without change failure rate
Count merged changes per engineer per week, and publish change failure rate on the same slide, in the same review, every time. DORA's finding — throughput up, stability down — means either number alone is actively misleading. Pairing them makes the trade visible and makes it impossible to claim a win by shipping more broken changes faster. Write the pairing into the reporting template rather than relying on discipline.
2. Rework rate
Measure the share of lines changed that are modified again within two to four weeks of merge — derivable from git log without buying anything. It is the closest available proxy for "code that shipped but was not right," and the metric GitClear's churn data suggests is most affected by agent use. Rising rework alongside rising throughput is the clearest early signal that speed is being purchased with debt.
3. Review load per merged change
Track reviewer time, review latency and review cycles per merged change. This is the segment the work moved into, so it is the segment that fails first. Watch for review latency rising while approval rate stays flat — that pattern means reviewers are under-resourced and starting to rubber-stamp, converting your review gate into a formality precisely when it matters most.
4. Time reallocation, verified against artefacts
Do not ask engineers how much time AI saved them; the METR perception gap makes that answer unusable. Ask a narrower, checkable question: what shipped last quarter that would not have shipped otherwise? If saved hours are real, they resurface as work — migrations completed, on-call load reduced, a deprecation finally finished. If nobody can name the work, the hours went into review and rework, and your throughput gain is circular.
KPIs that get gamed, and what they turn into
| Metric | What it becomes under agent use |
|---|---|
| Lines of code | A measure of tool verbosity and default generation length. |
| Pull request count | A measure of how finely work is sliced, not how much shipped. |
| AI suggestion acceptance rate | A vendor engagement metric. Accepting more suggestions is not a business outcome. |
| "AI adoption %" as a target | Licence activation theatre. Adoption is a diagnostic input, never a goal. |
| Tickets or story points closed | Estimation inflation — points are a human judgement about human effort. |
| Self-reported time saved | Sentiment. Measured against a counterfactual the reporter cannot observe. |
The common failure is treating utilisation as achievement. Usage tells you whether an experiment is running, never whether it worked. Keep adoption on the diagnostic panel — a pilot with 12% active usage is not a failed pilot, it is an unrun one — and off the goals sheet.
Instrumenting this without buying a platform
All of the above comes from systems you already run:
- Throughput and failure rate — CI/CD pipeline history plus incident records. This is the standard DORA four-keys derivation.
- Rework rate —
git logwith line-level blame over a rolling window. No third-party tooling required. - Duplication trend — any static analysis duplication check, run on a schedule and trended rather than gated. The absolute number matters far less than its direction.
- Review load — your forge's API, which exposes review timestamps and cycle counts.
- Reallocation — a single quarterly question tied to named artefacts, not a Likert scale.
Buy a measurement platform when the manual version is working and the bottleneck is genuinely reporting effort. Buying one first tends to produce a well-rendered dashboard of the wrong metrics. Cost per merged change belongs on the same panel — our AI agent cost breakdown and ROI calculator cover the input side of that model.
How we measure it on our own delivery
We build and operate agent systems for clients, so this is not an abstract question for us. On Claude business adoption engagements the structure is deliberately narrow: one pilot before any wider rollout, three workstreams — value, governance and enablement — and success defined on cycle time and throughput before the pilot starts, not after. The metrics we hold ourselves to are cycle-time reduction, time saved on routine tasks, delivery throughput, and the number of workflows moved from manual execution to repeatable automation. That last one is the reallocation test in operational form: a workflow either moved or it did not.
The same discipline applies to engineering-team deployments. Claude Code for companies is organised by department rather than by tool — management, engineering, research, operations, quality assurance, communications and analytics — because the measurement question differs by function, and a single "AI productivity" number across all seven is guaranteed to be meaningless. Across our solutions portfolio the typical first deployment runs 6–12 weeks, roughly the shortest window in which a rework signal becomes readable. Anything shorter measures novelty.
A 90-day sequence that produces a defensible answer
Days 1–30 — baseline before rollout. Capture throughput, change failure rate, rework rate, review latency and duplication trend on the current team, with no agent access changes. Without this you have no comparison and every later number is arguable. This is the step most rollouts skip and later regret.
Days 31–60 — scoped pilot. One team, one codebase, full agent access, all five metrics tracked weekly. Do not expand scope mid-pilot; a moving denominator invalidates the exercise. Expect throughput to move first and quality signals to lag by weeks.
Days 61–90 — decide on the pair, not the number. Review throughput and change failure rate together, rework against its baseline, and the named-artefact reallocation answer. Throughput up with rework flat is a genuine win worth scaling. Throughput up with rework and duplication climbing is a debt transfer, and the correct response is to strengthen the review and test layer before expanding access — the DORA prescription exactly.
For the governance and sequencing side, our Claude enterprise rollout guide covers access boundaries and the pilot-to-scale path. To work through your own baseline, book a strategy call and bring your current metric set — the fastest useful conversation is usually about which existing KPIs to stop reporting.
Frequently asked questions
Do AI coding agents actually make developers faster?
There is no reliable industry-wide number, and anyone quoting one with confidence is overstating the evidence. METR's 2025 randomised trial measured experienced open-source developers as 19% slower with AI; its February 2026 follow-up concluded the design could no longer produce a trustworthy estimate. DORA's 2025 data does show a positive relationship between AI adoption and delivery throughput at the organisational level. Effects are real but highly context-dependent — measure your own team rather than importing someone else's percentage.
Why can't we just ask developers how much time AI saves them?
Because the one controlled experiment that checked found the self-report was wrong in direction, not just magnitude. METR's participants estimated a 20% speedup after a session in which they were measured 19% slower. Self-reports capture how the work felt, which is genuinely valuable for adoption and satisfaction, but it is not a productivity measurement.
Should we track AI tool adoption rate as a KPI?
Track it as a diagnostic, never as a goal. Adoption tells you whether your experiment is actually running — DX reports that even leading organisations reach only around 60% active usage, so low adoption is common and worth investigating. The moment adoption becomes a target, it stops measuring anything, because activating a licence is trivially easy and completely disconnected from outcomes.
What is the single best early-warning metric for agent-driven quality decay?
Rework rate — the share of merged lines modified again within two to four weeks. It moves before incidents do, it is derivable from git history without new tooling, and it captures the specific failure mode agent-generated code tends to produce: plausible code that works well enough to merge and not well enough to leave alone. Pair it with a duplication trend for the structural view.
How long before agent adoption shows up in delivery metrics?
Throughput typically moves first, and quality signals lag it. Our own first deployments run 6–12 weeks, which is roughly the minimum window in which a rework signal becomes readable. Measuring at four weeks mostly captures novelty effects in both directions — the enthusiasm spike and the learning-curve dip.
Does this apply to non-coding agents too?
The structure does. Any agent deployment relocates work from production to verification, so the principle holds: pair a volume metric with a quality metric, measure the stage that got more expensive, and verify claimed time savings against work that shipped. The specific metrics differ by function, which is why we scope measurement per department rather than reporting one organisation-wide AI productivity figure.
Figures cited from GitClear's Maintainability Gap research (January 2026), Google's 2025 DORA report, METR's July 2025 study and February 2026 update, and DX's AI Measurement Framework — each linked above and verified against the primary source on 11 August 2026. This research is moving quickly; check the originals before quoting them.