Code churn is code that gets rewritten or deleted shortly after it was written, usually within about three weeks of being committed. It has been a useful signal for engineering leaders for over a decade. It became a far more important one in 2026, because AI-assisted development changed both how much code gets written and how much of it survives.
This guide covers what churn is and is not, the four types worth separating, why AI code churn behaves differently from human churn, what PR churn tells you that commit-level churn cannot, and how to respond to a spike without turning the metric into a stick.
The one rule that matters before any of the rest: churn is a diagnostic, never a target. The moment a team learns that low churn is rewarded, you stop getting information and start getting behavior. Everything below assumes you are using it to find friction in the system, not to grade people.
Most churn conversations go wrong because a single number is doing four different jobs. Split it and the metric becomes actionable.
| Type | What it is | Healthy? | Watch for |
|---|---|---|---|
| Exploratory churn | Rewriting while working out the shape of a solution. Prototypes, spikes, proofs of concept. | Yes, expected early in a project | Exploration that never converges |
| Rework churn | Redoing finished work because requirements moved or the problem was misunderstood. | Usually a system problem | Spikes late in a sprint |
| PR churn | Changes made to a pull request after review has started, before it merges. | Some is review working | Many review cycles per PR |
| AI code churn | Generated code that is rewritten, replaced or reverted soon after landing. | Depends entirely on volume | Throughput up, survival down |
Churn is not bad. Testing and rework are natural parts of building software. Levels vary between people, teams, project types and stages. What matters is deviation from that team’s own normal, especially late in a sprint or close to a release.
Churn is not constant across a lifecycle. A healthy project runs high churn early as the solution takes shape and lower churn later as it is refined. Unusually low churn at the start of an unfamiliar project can itself be a warning sign that nobody is exploring.
Churn is not a performance rating. It measures the system a developer is working inside, not their ability. Nine times out of ten a churn spike traces back to unclear requirements, a shifting stakeholder or an oversized change, none of which the developer controls.
Churn was a useful secondary metric for most of its life. AI-assisted development promoted it, for a simple structural reason: when the cost of producing code approaches zero, the cost of producing the wrong code approaches zero too. Volume goes up. The question of how much of that volume survives becomes the interesting one.
Published analyses of large public code corpora, notably the ongoing work by GitClear, have reported a consistent direction of travel since assistants became widespread: more duplicated blocks, less moved or refactored code, and a rising share of code that is rewritten shortly after being added. Treat the specific figures as directional rather than settled, since methodology and corpus choice matter a great deal here. The direction, though, matches what we see in customer data and what most engineering leaders report anecdotally.
Three mechanisms drive it, and they are worth naming because each has a different fix.
Generation is cheaper than deletion is painful
When writing two hundred lines costs a prompt, throwing them away costs nothing emotionally or practically. Healthy in itself. It just means raw churn volume rises without necessarily indicating a problem, which is why churn per merged change is a better lens than churn in absolute terms.
Agents duplicate rather than refactor
Given a choice between reusing an existing abstraction and generating a fresh implementation, an agent without strong repository context will often generate. That produces code which passes review, ships, and then churns weeks later when someone discovers there are now three versions of the same thing. This churn arrives late, which is exactly why it does not show up in a sprint retrospective.
Review capacity did not scale with generation capacity
A team can now produce far more change than it can review at the old standard. Code that was reviewed less carefully churns more later. This is the mechanism behind the pattern engineering leaders keep describing to us: throughput is up, and so is rework, and the two are cancelling out.
The measurement that matters
Do not measure AI code churn in absolute lines. Measure the survival rate of AI-assisted change against your pre-AI baseline. Volume rising is expected. Volume rising while the surviving share falls is the finding, and it is the difference between a productivity gain and an expensive illusion.
This is why we keep AI adoption and AI impact as separate measurements. Adoption tells you the tools are being used. Churn is one of the clearest impact signals available, because it is derived from the codebase rather than self-reported. The wider argument is in DORA metrics in the AI era and cost per accepted change.
Classic code churn is measured after the fact, on merged code. PR churn is measured inside the review window: how much a pull request changes between the moment review begins and the moment it merges, and how many round trips that takes.
The distinction matters because the two have opposite meanings. Some PR churn is the review process doing its job: a reviewer catches something, the author fixes it, the codebase is better for it. That is the system working, and it is one reason we track review thoroughness in merge quality alongside speed. Post-merge churn is the review process having failed to catch something.
What high PR churn usually means:
| Pattern | Likely cause | Where to look first |
|---|---|---|
| Many review cycles, small changes each time | Style and preference disagreements | Linting and formatting automation, not people |
| Few cycles, very large rewrites | Wrong approach agreed too late | Design review before code, not after |
| Churn concentrated in oversized PRs | Batch size, the most common cause | PR size distribution in PR insights |
| Low PR churn, high post-merge churn | Rubber-stamp reviews | Review depth in merge quality |
That last row is the one to watch in an AI-heavy workflow. Approvals arriving faster with less discussion, followed by more rework a few weeks later, is the signature of review capacity failing to keep up with generation volume.
Cause 1
Prototyping
Expected at the top of a project, and productive. The response is to protect the time, not interrupt it: clear an unnecessary meeting off the calendar. Only step in if exploration has run well past what the task warrants, and then ask about the problem rather than the churn.
Cause 2
Unclear requirements
Fuzzy specs force guesses, and some guesses are wrong. This is the highest-yield fix on the list because it is upstream of everything else. Take the rework cost to the product team with numbers attached, and show what clean requirements look like next to messy ones.
Cause 3
Shifting stakeholders
Late requirement changes show up as a sharp rise in rework in the back third of a sprint. Show the stakeholder the share of engineering effort going into rebuilding, in time and money. Also consider that a product owner who keeps changing direction is often stretched too thin rather than careless.
Cause 4
A genuinely hard problem
More exploring and backtracking is the correct response to a hard problem. The judgment call is when it has gone on too long. Pairing with a senior engineer usually beats a manager check-in, and lands better.
Cause 5
Polishing past “good enough”
Repeated refinement that adds little functional value, usually visible sprint over sprint rather than once. Before acting, check whether the rework came from review feedback, because that is the process working and deserves praise rather than correction. If it did not, the fix is a clearer definition of done, ideally set by a senior engineer rather than a manager.
Cause 6
Someone running out of steam
High churn with low throughput over a sustained period, concentrated in the same area of the codebase, alongside disengagement in review, can indicate that an engineer is stalling or losing motivation. Handle this as a human situation, not a metrics one. Git data can surface the pattern; only a conversation, or a developer experience survey, can tell you what is behind it.
Step 1
Establish your own baseline before drawing conclusions. There is no universal healthy churn percentage, and any vendor quoting one is selling something. Your normal depends on your domain, codebase age and project mix.
Step 2
Read churn at team and project level, and pair it with cycle time and change failure rate. Churn alone is ambiguous. Churn plus a stretching review stage plus rising failure rate is a story.
Step 3
Segment by AI-assisted and non-assisted work if you can. That comparison is where the real finding lives, and it needs a pre-AI baseline to be meaningful, which is a window that closes as adoption spreads.
Step 4
Never put churn in a performance review. It measures the system, and the moment it is used to judge people it stops being reliable data. Waydev is built around teams and systems for this reason, and it is what the WAY Framework asks of the metrics inside it.
What is a good code churn rate?
There isn’t a universal number, and anyone who gives you one is guessing. Greenfield work runs higher than mature maintenance, and both can be healthy. Use your own trend as the benchmark.
Is code churn the same as rework?
Closely related. Churn is the measurable footprint in the codebase; rework is the broader business concept, including work redone for reasons that never touch Git. Our rework calculator puts a number on the cost side.
Does AI-generated code churn more than human code?
Published corpus analysis points that way, and it matches what we see, but the honest answer is that it depends on how the code is generated and reviewed. Measure it in your own repositories rather than accepting anyone’s industry figure, including ours.
Should churn be an OKR or a team target?
No. Target the outcomes churn helps you diagnose, such as cycle time or change failure rate. Targeting churn itself teaches people to avoid deleting bad code, which is the opposite of what you want.
See your own churn
Connect your repositories and we will backfill your history, so you can see churn, PR churn and AI-assisted survival rates against your own baseline rather than an industry average.
Related features: PR Insights · Merge Quality · Cycle Time · DORA Metrics · AI Impact · Developer Experience
Further reading: The WAY Framework · More code, fewer releases · When code gets cheap, judgment gets expensive · Measuring developer productivity · Rework calculator · Tech debt calculator
Updated September 2026. Third-party findings on AI-generated code are attributed to their publishers and should be read as directional.
Ready to unlock your SDLC productivity?
