Measuring Quality

A team ships fast with an agent in the loop: a feature branch opens, three commits land within the hour, the PR merges before lunch. Two weeks later the same file is open again — not because product changed its mind, but because the code from two weeks ago no longer looks right to the person editing it now. Multiply that pattern across a thousand files and a few months, and a plain question emerges that velocity dashboards were never built to answer: how much of what shipped this month is going to get rewritten before it ships anything else?

The honest answer, for most teams running agents at scale in 2026, is a number nobody is tracking — because DORA’s four keys measure how fast and how safely code moves, and SPACE measures how developers experience the work, and neither one looks at what the code itself is doing after it lands. The metric built to fill that gap is older than agentic coding and considerably less glamorous: code churn, the share of newly written lines revised again within a short window of being authored, conventionally two weeks. A high churn rate has one plain reading: this code did not survive contact with reality on the first attempt.

What GitClear measured

The most-cited empirical case linking AI-assisted coding to rising churn comes from GitClear, a code-analytics vendor that has tracked this metric across customer and open-source repositories since 2020. Its February 2025 report, covering 211 million changed lines of code authored between January 2020 and December 2024, found churn nearly doubling: from 3.1% of new lines revised within two weeks in 2020 to 5.7% in 2024, a rise concentrated almost entirely in the two years following widespread Copilot and agent adoption. The same dataset showed the share of changed lines attributable to genuine refactoring — GitClear’s “moved” category, code relocated or consolidated into reusable structure — falling from roughly 25% in 2021 to 9.5% in 2024, while copy-pasted lines rose from 8.3% to 12.3% and the frequency of code blocks with five or more duplicated lines climbed eightfold in 2024 alone. 2024 was, by GitClear’s count, the first year on record in which copy-pasted lines outnumbered moved ones.

A direct contradiction

That finding did not go unanswered, and the pushback is substantive enough to earn the label this chapter gives it: contested. A 2025 study by Xiao and colleagues took a different empirical path — rather than inferring AI involvement from the calendar, it identified 151 open-source repositories where developers explicitly acknowledged using generative AI, in commit messages, code comments, or documentation, and tracked churn in those specific repositories over time. Its finding was blunt: no general increase in churn following self-admitted GenAI adoption, directly contradicting the narrative GitClear’s numbers had popularized. The two studies are not measuring quite the same thing — GitClear’s dataset spans repositories where AI involvement is inferred from timing and adoption curves, while Xiao’s sample is repositories where a developer said out loud that they used AI on a given change — and that methodological gap is itself part of what keeps the underlying causal claim genuinely unsettled rather than simply wrong on one side.

Two credible studies, two different samples, two opposite headlines. Both numbers are real. Neither one, alone, tells a team what to do Monday morning.

On the GitClear / Xiao et al. churn dispute

What churn alone can’t see

There is a structural reason two credible research efforts can look at overlapping evidence and land in different places, and it has little to do with which side ran the better regression. Code churn counts every revision inside its window identically, whether the revision represents an agent stuck rewriting the same broken shape or an agent legitimately refining an approach because a test just told it something the first attempt did not know. An agent that writes a function, runs the suite, discovers an edge case, and rewrites the function in the same sitting has technically produced churn — the exact kind every engineer would recognize as the loop working as intended. A team’s fast edit-test-edit cadence, the workflow agentic tooling exists to enable, shows up in a churn report identical to a team stuck rewriting the same misunderstood requirement four times. Worth naming honestly, too: the years GitClear’s report covers were not only the AI-adoption years — the same period saw substantial industry layoffs and reorganization, and churn has correlates besides tooling. None of this makes the churn rise GitClear measured fictional. It means the raw number, on its own, cannot tell a team which of these stories it is living inside.

Churn plus context

A more honest read treats churn as a first pass rather than a verdict, and asks a second question of every spike the first question surfaces: does this file’s churn resolve, or does it persist? Code rewritten twice in its first two weeks and then quiet for the next six months is the edit-test-edit loop working — expensive in the moment, invisible afterward. Code that keeps getting rewritten past that window, that shows up again in next month’s churn report and the month after that, is the actual signal worth escalating: a shape that never stabilized, most often because the requirement was never actually understood on the first attempt, agent or human. The distinction is checkable with the same version-control history that produces the raw churn number in the first place — it just requires looking at a file’s trajectory across a longer window than the two weeks the metric itself uses, instead of stopping at the first spike.

Duplication is the more legible half of the same GitClear-class family, and less prone to the ambiguity churn carries, because a duplicated block does not have the good-iteration excuse available to it. This volume’s companion discussion in Volume IX’s chapter on reusable thinking documented the mechanism from a different angle: a 2025 study of code-generation models found they routinely fail to recognize a codebase’s existing patterns and generate code that conflicts with them, and 2026 trade coverage of production AI-assisted repositories describes the resulting code as tending to “over-allocate, over-abstract, duplicate logic, and miss subtle optimization opportunities” relative to the task in front of it. An agent with no durable memory of the function it wrote three files ago has no equivalent of a human’s felt sense that this looks familiar, so it writes the logic again — GitClear’s eightfold rise in duplicated blocks during 2024 is one dataset’s view of that same structural gap. Where churn needs a follow-up question, duplication mostly answers for itself: a block that matches logic already sitting in the codebase almost never had a legitimate reason to be written twice.

Reading churn honestly

None of the numbers behind that table are Operon’s own — they are GitClear’s, cited because they are the real, dated, verifiable data this chapter’s central claim rests on. What a team would need to check the same claim against its own history is a narrower, session-grained fact that a git log alone cannot see: whether a given piece of churn was a same-session revision or a different session, days or weeks later, coming back to fix what the first one got wrong.

The gap DORA and SPACE leave open

This volume opened with DORA’s four keys, SPACE, and DX Core 4 — three frameworks built, across three different eras, to answer how fast software moves and how sustainable that pace is for the people producing it. None of the three scores the code itself. A team can post a clean DORA scorecard — fast deploys, low change-failure rate, quick recovery — while quietly accumulating exactly the pattern GitClear’s numbers describe, because deploy frequency and change-failure rate are both blind to whether the code that shipped was any good, only to whether it broke something loudly enough to notice on the way out the door. Churn and duplication metrics exist to answer the question those frameworks leave open: not did we ship, but was what we shipped worth keeping. DORA’s own 2025 research makes a version of the same point from the other direction — AI amplifies whatever organizational strengths and dysfunctions were already present — and a churn number climbing while a team’s DORA metrics look fine is one of the more legible ways that amplification shows up before it becomes an incident.

None of this earns churn and duplication a free pass to become the new scorecard. The same lesson this Library keeps repeating about every metric it introduces applies here without modification: a number optimized in isolation gets gamed. A team told to lower its churn rate can do so by making fewer, larger commits — the same rewriting, counted differently, with the underlying rework untouched — exactly the commit-granularity blind spot any git-log-based method has to correct for. The only version of this measurement that resists gaming is the one this chapter has been building toward: churn and duplication read alongside outcome data — defect rates, incident correlation, what actually happened to the code after the report was generated — rather than trusted as a verdict standing on their own. A session that gets rewritten inside two weeks failed by the same test this Library’s Session ROI already named: it did not produce durable value, whatever the commit log said on the day it merged.