What AI Changes About Measurement

Part 13 closed with a warning that one force is reshaping the graveyard faster than any before it. This final part faces that force directly: what does AI-assisted code generation actually change about measuring software work? Not what the vendor decks claim, and not what the doom threads claim — what the evidence says, with every figure dated and attributed, because if this series has had one discipline throughout, it is that a number without a source and a year attached is a rumour. That discipline matters more in this part than in any other, since nothing in measurement is moving faster than this, and everything quantitative below is a snapshot that will age.

What the review queue found

The most direct evidence on AI code quality comes from looking at real pull requests. CodeRabbit''s December 2025 State of AI vs Human Code Generation report examined 470 open-source PRs — 320 AI-co-authored, 150 human-only — and found the AI-co-authored ones carried roughly 1.7x more issues per PR (10.83 versus 6.45). Breaking that down: code quality and maintainability problems ran 1.64x higher, logic and correctness issues were 75 per cent more common, and security findings ran 1.57x higher overall.

Hold the figures with appropriate care. This is one vendor''s analysis of one sample, published at one moment in a fast-moving field — and the vendor sells code review, which does not falsify the numbers but does deserve mention alongside them. What makes the study worth citing anyway is its shape: it measured artefacts, not opinions, and its finding lands exactly where this series has been pointing. The machine does not write worse code so much as it writes unreviewed-feeling code at a rate that overwhelms the practices built for human output — and every one of those multipliers is an argument for the automated gates this series has been assembling.

What the diffs say

The second body of evidence looks not at individual PRs but at the aggregate shape of change. GitClear''s research on AI-era code quality, built on 211 million changed lines of code spanning January 2020 to December 2024, tracked what kinds of changes developers make — and found the mix shifting. The share of changed lines classified as copy/pasted rose from 8.3 per cent to 12.3 per cent across that window, while the share of changed lines associated with refactoring sank from 25 per cent in 2021 to under 10 per cent in 2024.

The framing matters, so let me be precise: these are percentages of changed lines — the composition of what changed, not a codebase-wide duplication ratio. Read correctly, the finding is about behaviour: assistants make producing a fresh near-copy easier than finding and reusing the existing abstraction, and they make adding easier than restructuring. Duplication rising while refactoring falls is compounding debt in its purest form — more copies being minted, less consolidation paying them down. This is why part 3''s debt ratio and the duplication instruments moved up my priority list: the trend they watch is the trend that moved.

Trust, measured

A statistic I will conspicuously not use here: a widely circulated claim that 71 per cent of developers do not merge AI code without review. I went looking for its primary source while writing this series and could not find one — it does not appear in the Stack Overflow survey it is usually pinned to, only on aggregator sites citing each other. It sounds plausible; that is not the same as being sourced, and part 1 committed this series to knowing the difference.

What the verifiable numbers say instead is interesting enough. Qodo''s State of AI Code Quality 2025 survey found that even among developers reporting low hallucination rates from their tools, 75 per cent still hesitate to merge AI-generated code without manual checks. And the Stack Overflow 2025 developer survey found 84 per cent of respondents using or planning to use AI tools while only around 29 per cent trust the accuracy of the output. Adoption near-universal, trust nowhere close — that gap is the measurement story, because a workflow where most output is machine-drafted and most drafters distrust it is a workflow that runs on verification, and verification is precisely what quality metrics instrument. Meanwhile the volume claim should be carried exactly as hedged in part 1: as of early 2026, surveys — Sonar''s State of Code among them — put AI-assisted code at roughly 40 per cent of committed code, with vendors projecting majority share. A projection, time-stamped, not a fact.

The productivity paradox, in one dated paragraph

Then there is the delivery question, where the evidence initially looks contradictory and resolves into something coherent once every finding is pinned to its source and year. Faros AI''s July 2025 analysis of telemetry from more than 10,000 developers found individuals completing about 21 per cent more tasks and merging about 98 per cent more PRs — while organisation-level delivery metrics stayed largely flat, and PR review time rose about 91 per cent. The 2024 DORA report found that a 25 per cent increase in AI adoption was associated with an estimated 1.5 per cent decrease in delivery throughput and a 7.2 per cent decrease in delivery stability. And the 2025 DORA report found the throughput association had flipped positive, while the instability signal persisted.

Individually faster, organisationally flat-to-worse, improving as practices catch up: that is not a contradiction, it is a queue. If individuals produce twice the PRs and review time nearly doubles, the constraint has simply moved — from writing code to verifying it — and organisation-level metrics stay flat because the system''s bottleneck, not its busiest worker, sets its throughput, exactly as part 9"s mathematics said it would. My reading of the 2024-to-2025 shift is cautious optimism: the throughput penalty easing while instability persists looks like organisations learning to feed the verification queue, without yet having learned to keep quality steady at the new pace.

The standard grew a ninth characteristic

Even the standards bodies re-cut their instruments for this era. ISO/IEC 25010 — the product quality model from ISO/IEC JTC 1/SC 7 — was revised in 2023, and the revision changed the map most references still reproduce: the model now has nine quality characteristics, not eight. Safety was added as a characteristic in its own right; usability was renamed interaction capability; portability was renamed flexibility. The nine, by name: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility, and safety.

I list the names and stop there deliberately — the standard''s definition text is ISO''s to publish, not mine. The point for this series is the vintage lesson from part 8 applied to a standard rather than a benchmark: a great many quality frameworks in circulation, including one of my own reference documents until I checked, still present the 2011 eight-characteristic model under a 2023 label. Date your instruments — even the ones with ISO numbers on them.

What I gate differently now

Creator voice for this section: these are my adjustments, made across estates I work on, offered as tested defaults rather than findings. The cognitive-complexity gate from part 2 stays blocking and unchanged — machine-written code shows no instinct for its own readability, so the gate simply fires more often and earns its keep more visibly. Coverage alone I now trust less than ever: generated tests are fluent at executing code while asserting little, so on AI-heavy modules I pull part 5"s mutation score forward from quarterly to per-change on critical paths. Duplication monitoring moved from periodic cleanup to a per-PR watch, for exactly the reason GitClear''s trend suggests. Churn and hotspot tracking from part 6 get special attention on files with heavy assistant involvement, because rework churn is where “faster to write” quietly becomes “written twice”. And the review-response heuristic from part 12 hardened from courtesy to policy — if review is the new constraint, then the review queue is the first queue to instrument.

Closing the ledger

An honest retrospective to end the series, in the spirit it opened with. This series grew out of two metric catalogues in my own working notes — one for code quality, one for delivery — and both were marked as drafts when I began, which turned out to be the honest label: writing these fourteen parts was their maturing pass. Chasing every claim to a primary source corrected real errors along the way — figures I had pinned to the wrong organisation, benchmark tiers quoted without their vintage, a standard cited in its superseded shape. If your own metrics notes have never had that pass, they contain the same class of drift; mine did.

Second: every threshold in this series that arrived without a citation — the WIP limit, the churn trigger, the review-response window, the sprint-completion line — is a working number from my practice, not a law. They are where I would start, not where you should end.

Third: the AI-era figures in this part have the shortest shelf life of anything in the series. The studies are early, the tools change quarterly, and the 2024-to-2025 DORA reversal shows findings in this space can invert year over year. Measurement of AI-assisted work is a moving target, and I have dated every figure precisely so that you can tell, later, which have expired.

What will not expire is the rule the series opened with, and it holds harder in the AI era than when Goodhart and Strathern earned their citation in part 1: a metric can inform a decision or judge a person — never both. Machines now write much of the code, but the theatre was always a human production. Decline the starring role, keep the instruments honest, and the numbers will go on meaning something.