The Quality Ledger

A team lead pulls up the quarterly retro deck and the velocity chart looks great: more pull requests merged, more features shipped, the AI rollout paying for itself in throughput. Six months later, three engineers are independently complaining that the codebase has gotten harder to work in — more copy-pasted logic, fewer of the small cleanup commits that used to happen along the way, a rising sense that changes ripple further than they should. Nobody filed a ticket for “technical debt increased.” Nobody could have; there is no line item for it. The velocity chart and the complaint are both true, and the org has no system that connects them.

This is the question this chapter takes on directly, as an economics question rather than a taste question: is AI-generated code, in aggregate, accruing technical debt faster than the code it replaced — and how would a team actually know, rather than guess from a feeling in a code review?

What the largest dataset shows

The most-cited large-scale answer comes from GitClear’s analysis of over 211 million lines of code across a broad sample of commercial repositories, tracking quality signals before and after the AI-adoption period began. Three numbers carry the finding. Code duplication — the share of added code that duplicates a block already present elsewhere in the codebase, rather than reusing it — rose roughly fourfold over the study window. Refactoring, measured as the share of code changes that restructure existing code without adding new functionality, fell from roughly a quarter of changes to under a tenth. And code churn — lines rewritten shortly after being written — moved upward alongside both.

Read individually, each number could be noise. Read together, they tell one consistent story: more code is being added, less of the code already there is being cleaned up, and a larger share of what gets written gets rewritten soon after. That is the shape you would expect if code generation accelerated while the discipline of consolidation did not keep pace — new capability racing ahead of the housekeeping that used to happen as a side effect of a human typing every line by hand.

The critiques, taken seriously

A finding this convenient for a “AI is degrading code quality” narrative deserves the same scrutiny this volume has applied to convenient findings in the other direction. Three objections are genuinely substantive, not strawmen raised to be knocked down.

• Causal attribution. The study correlates the timing of quality decline with the timing of AI-tool adoption. But the same calendar window saw codebases growing in raw size for reasons that have nothing to do with AI, teams under pressure to ship faster for market reasons unrelated to tooling, and a broader industry shift toward feature velocity as the dominant metric leaders reward. Correlation with adoption timing is evidence, not proof — a team that adopted AI tools in a quarter when it was also under a product deadline crunch would show the same duplication spike with or without a single AI-generated line.
• What “churn” actually measures. Churn as a metric is sensitive to definition in ways that are easy to gloss over. A revert of a genuine mistake, an iterative refinement where a developer deliberately drafts something rough and tightens it within days, and true rework caused by a misunderstood requirement all show up as the same “lines changed within N days” signal — but they carry opposite implications for whether the underlying process is healthy. AI-assisted workflows may simply produce more of the fast-iterate pattern, which would inflate churn numbers without representing debt at all.
• Selection and survivorship. The repositories large-scale analyses can access — commercial codebases with usable commit history, often skewing toward companies willing to share data or already instrumented for this kind of study — may not represent the median team’s actual usage pattern. A dataset weighted toward early, aggressive AI adopters could show effects that a more typical, more cautious rollout would not reproduce.

A worked example of the churn ambiguity

The churn objection is worth sitting with a moment longer, because it is the easiest of the three to miss in a quick read of the headline number. Picture two engineers, one shipping a hand-written function that turns out wrong and gets reverted a week later, another using an AI tool to draft a rough first pass deliberately, then tightening it across three commits over two days as the requirement clarifies. Both produce identical "lines changed within 30 days" signals in a churn dashboard that counts by timestamp alone. The first is waste; the second is a workflow that looks more like iteration than defect. A churn metric blind to that distinction will read AI-assisted work as messier even in a world where AI is making the drafting-and-refining loop faster and healthier, not worse — which is exactly why the objection cannot be waved away as pedantry.

None of these objections requires believing the finding is wrong. They require believing it is less load-bearing, on its own, than a single headline number implies. DORA’s 2025 framing is useful here for a different reason than its topline number: its central finding is that AI acts as an amplifier of whatever organizational dysfunction or discipline already exists, not an independent force with its own consistent effect. Applied to code quality, that framing predicts exactly what a causal-attribution skeptic would predict — a team with weak refactoring discipline before AI adoption should see that weakness amplified, while a team with strong review and consolidation habits might see little change at all. If that is closer to true, the aggregate finding is really an aggregate of very different team-level stories, and the average obscures more than it reveals.

The honest verdict

Weighing the finding against the critiques lands on a specific, calibrated confidence level, not a shrug and not an alarm. The data is a real amber warning light: three independent quality signals moving in the same direction, at the scale of hundreds of millions of lines, is not a fluke to be dismissed. But it is not proof that AI-generated code is inherently and universally worse-maintained than human-written code, because the causal path from “AI adoption” to “duplication rose” runs through organizational choices — review rigor, refactoring time allocated, whether anyone owns consolidation as a job — that vary team to team and that the aggregate data cannot isolate. “Contested but directionally consistent” is the right label, and it is the same label this volume has already applied to this exact data in earlier chapters — this chapter’s job was to show the work behind that label, not revise it.

The finding survives scrutiny as a warning. It does not survive scrutiny as a verdict.

An amber warning light has a specific, useful meaning in an operations context: it does not tell an engineer to shut the system down, but it does tell them to stop assuming the system is fine and go look. Applied here, that means a team should not read the GitClear finding as license to slow down AI adoption, and should not read the critiques as license to ignore it either. The correct response to a contested-but-consistent signal is the same response an SRE gives a metric trending the wrong direction with an unconfirmed cause: instrument the specific system, watch the trend locally, and decide from local evidence rather than from the industry aggregate in either direction.

Unsecured debt

The economic framing that makes this actionable rather than just interesting is to treat unrefactored, duplicated code as a real ledger entry — debt taken on now, to be repaid later in maintenance cost, in elevated bug rate from logic that drifted out of sync across duplicated copies, and in onboarding difficulty for the next engineer who has to learn which of four near-identical functions is the one actually still in use. A team that runs up a AWS bill knows exactly what it owes and to whom; a team that runs up duplication debt usually does not, because nothing forces the debt onto a balance sheet anyone reviews. Financial debt at least compounds at a disclosed rate; this debt compounds at whatever rate the next unlucky engineer discovers empirically, usually while trying to fix a bug in one copy of duplicated logic and being unaware three other copies exist.

That is the “unsecured” half of the title. A tracked backlog item — a ticket that says “refactor the payment retry logic, three known duplicates” — is secured debt: someone acknowledged it, it competes for prioritization, and eventually either gets paid down or is consciously written off. Duplication that accumulates silently across hundreds of AI-assisted sessions is unsecured: nobody logged it, nobody scheduled the repayment, and by the time it surfaces — as the vague “this codebase feels harder to work in” complaint from the opening of this chapter — it is usually a different team paying the interest than the one that took out the loan.

Signals a team can track without a research grant

A team does not need a 211-million-line dataset to start watching its own ledger. Three signals, all extractable from version control history a team already has, turn the debate from abstract to operational.

The segmentation by author is the piece that turns a contested industry-wide finding into a team-specific answer. A team that runs these three queries against its own history for two consecutive quarters either sees the GitClear pattern reproduce locally — in which case it has actionable, team-specific evidence to bring to a refactoring investment conversation — or it does not, in which case the aggregate finding was, for this team, not the relevant risk. Either answer is more useful than adopting or dismissing the industry number on faith.

The churn number is the one that needs a follow-up question rather than a threshold. A rising churn rate on AI-assisted commits is not, by itself, bad news — the correct next step is reading a sample of the flagged commits and classifying them by hand: genuine defect fixes, deliberate iterative refinement, or true rework from a misunderstood spec. That fifteen-minute classification pass, repeated quarterly on a sample rather than automated across every commit, is what turns the churn-definition critique from a reason to distrust the metric into a reason to read it more carefully.

What this means for a quarterly review

Chapter 5 named the cost iceberg beneath the token invoice; this ledger is one specific layer of that iceberg, made explicit enough to act on. The point is not to conclude that AI-generated code is categorically worse. It is to stop leaving the debt off the books simply because nobody built the ledger.