AI Code Churn: Why AI-Written Code Gets Rewritten
REWRITTEN IN WEEKS
Code rewritten weeks after shipping isn't velocity, it's a treadmill. What AI code churn is, how to measure it, and how to tell iteration from regression.
Flat and well above the elite reference - a signal, not a verdict.
Illustrative example
TL;DR: AI code churn is generated code that gets rewritten or deleted shortly after shipping. Independent data says it's rising. A raw churn number lies in both directions, though. The honest measurement splits in-flight iteration from delivered-then-broken regression, uses explicit AI attribution only, and judges the trend over months rather than a single hot week.
What is AI code churn?
AI code churn is the fraction of AI-assisted code that gets rewritten, replaced, or deleted within a short window of shipping - usually two weeks. A team can merge more code than ever while the codebase quietly runs on a treadmill, re-shipping last sprint's work with the serial numbers filed off.
Churn is the metric that exposes what AI slop actually costs, because it prices the failure in repeated work. Every churned line was written, reviewed, merged and deployed once already. Paying for all of that twice is velocity theater with a second invoice.
What the data shows
GitClear's 2026 "Maintainability Gap" report analyzed 623 million code changes from 2023 to 2026 and measured two-week churn up 15%, alongside code-block duplication up 81% against 2023 and refactoring line-moves down 70% against 2022 levels.
Worth quoting the same report against the obvious rebuttal ("sure, but look how much more the heavy users ship"). GitClear found heavy AI users out-produce non-users by 4-10x, then said the quiet part: most of that gap pre-dated AI. Measured against their own past selves, heavy AI users gained about 25% velocity. More code going in, more of it bouncing back, and the authorship boom is mostly who those people already were.
The downstream confirmation comes from Faros AI's 2026 AI Engineering Report: bugs per developer up 54% at high AI adoption. Churned code and bug-fix code are close cousins. Both are a second attempt at work that was already marked done.
And if you're wondering whether the extra speed at least pays for the rework, METR's randomized controlled trial found experienced developers were measurably slower with early-2025 AI tools while believing they were faster. The full story of that result is in the AI productivity paradox.
Why AI-written code gets rewritten
Four mechanisms, all mundane, all fixable:
- Plausible is not correct. Generated code optimizes for looking right. It compiles, it demos, and it embeds a wrong assumption that surfaces in production two Tuesdays later.
- Missing context. The model didn't know about the retry semantics in the adjacent module or the invariant that only lives in a senior engineer's head. Code written without context gets corrected by someone who has it.
- Copy-paste beats refactoring under AI. When generating a fresh variant is cheaper than understanding the existing abstraction, duplication wins. GitClear measured within-commit copy/paste rising from 9.4% of changed lines in 2022 to 15.7% in the first half of 2026. Duplicates then drift, and drift becomes rewrites.
- Review didn't scale with output. The volume multiplied; the reviewer hours didn't. Shallow review waves through exactly the code most likely to come back.
"The model is bad" is not on the list. Churn is a system failure: generation speed outrunning the safety nets. That's good news, because you can fix a system.
Iteration or regression: which churn do you have?
This is the fork most churn dashboards ignore, and it decides everything. The same rewritten line can be evidence of two opposite things:
- Iteration (healthy): the rewrite happened while the work was still in flight - drafts converging on an answer before anyone depended on it. High iteration churn with stable delivered code is a team thinking in public. Leave it alone.
- Regression (expensive): the rewrite happened after the work was delivered. Shipped code hauled back for repair costs review cycles, deploy risk, and trust.
A single blended churn percentage will slander a healthy fast-iterating team and flatter a team that ships confidently broken code. Before you judge any number, yours or a vendor's, ask which side of the merge the rewrites landed on.
Measuring it honestly
Four rules keep the number defensible:
- Fix the window and keep it fixed. Two weeks post-merge is the research convention. Changing the window changes the number; pick once, compare trends.
- Attribute explicitly or not at all. AI-vs-human churn comparisons are only honest with explicit attribution: commit trailers, bot and agent accounts. ML fingerprinting guesses, and a guessed denominator poisons the whole ratio. If you have no attribution, track the repo-wide trend. It moves regardless of who typed.
- Separate delivered from in-flight. Per the fork above. If your tooling can't tell them apart, at minimum exclude changes to unreleased branches from the regression count.
- Judge trends, not weeks. One hot week after a big refactor is noise. Three months of climbing two-week churn alongside rising duplication is a diagnosis.
Do this and churn becomes the most decision-ready number in your AI conversation - it tells you whether the assistant is compounding your codebase or eroding it, per directory, with receipts. That's the kind of AI impact evidence worth putting in front of whoever signs the seat renewals.
The fix
The door out of the churn treadmill is not "prompt better":
- Route review attention by churn heat. The directories with the worst short-window churn get senior reviewers and smaller PRs. Boring, effective.
- Refuse the duplication discount. When a change duplicates existing logic, make extending the abstraction the default and duplication the justified exception. Enforce it with a linter rule and a review norm; memos don't survive sprint pressure.
- Put survival on the scoreboard. Report "shipped and still standing after the window" next to throughput. Teams optimize what leadership repeats.
Churn is your codebase telling you the truth about last month's velocity. Listen before the treadmill invoices you again.
Frequently asked
What counts as code churn?
Code that is rewritten, replaced, or deleted within a short window of being shipped, commonly two weeks after merge. Churn on work still in flight is normal drafting; churn on delivered code is the expensive kind, because someone already paid to review, merge, and deploy it once.
Is all churn bad?
No. Fast iteration on unreleased work is healthy; that's the process annealing toward a good answer. The churn worth worrying about is regression: shipped code that comes back for repair. Separating the two is the whole game; a single blended churn number will mislead you in both directions.
How do I measure AI code churn without an expensive tool?
Pick a window, walk merged changes with git log and blame, and compute what fraction of shipped lines were modified or deleted inside the window. Split by explicit AI attribution (commit trailers, bot accounts) if you have it; track the repo-wide trend if you don't. Consistency beats sophistication.