861% Code Churn: Did What You Shipped Last Quarter Survive?

Code churn rose 861% between low and high AI adoption in Faros AI’s 2026 telemetry, which covers 22,000 developers across more than 4,000 teams. The metric is the ratio of lines deleted to lines added in merged code per quarter, and it now runs at 9.6 times its prior rate. Faros’s own caption is blunt: “Code churn is the asterisk on every output number in this section.” Task throughput per developer is up 33.7% in the same dataset. Epic completion is up 66.2%. The asterisk hangs over all of it, because a growing share of what merges gets deleted soon after.

We covered the quality side of this report, the defect rates and the review load, in the acceleration whiplash and the verification job. This piece stays on the churn number, because it raises a question that velocity dashboards never answer and that most engineering organizations cannot currently answer either: did the code you shipped last quarter survive?

A Metric That Is Ambiguous by Construction

Understand how the number is built before deciding what it means. Faros computes churn as deletions over additions, for merged code, per quarter, from repository metadata across thousands of customer organizations. That construction has a blind spot baked in: it counts deleted lines without knowing how old they were.

A quarter is a wide window. A line deleted in March could have been written in February by an agent, or in 2019 by an engineer who has since left. The metric treats both deletions identically. Faros is explicit that cross-customer observational research at this level cannot resolve the ambiguity, and credits itself only with detecting that something large is moving.

Something large is moving. A 9.6x increase in the deletion ratio means the shape of engineering work has changed under AI adoption. What changed is the open question, and there are three candidate answers.

Three Stories, One Number

Faros names three explanations, and states that all three are consistent with the data.

The first is accept-then-replace rework. Developers accept AI-generated code quickly, ship it, and return to replace it when it proves insufficient in practice. The deletion happens inside the same measurement window as the addition. This is real waste: the throughput numbers counted code that did not last a quarter, and the acceleration everyone is celebrating is partly a treadmill.

The second is the optimistic story. AI has made large refactoring projects cheap enough to staff. Legacy systems that accumulated for years are finally being replaced, and the deletion volume reflects productive architectural work. Under this story, the 861% is the best number in the report: the industry is paying down a decade of deferred maintenance.

The third sits between them. AI accelerates the pace at which engineers return to improve code they were never fully satisfied with. Neither waste nor a refactoring wave, just faster iteration on known-mediocre code.

The stakes of telling these apart are budgetary, not academic. If your organization is in story one, your velocity gains are overstated and your AI harness needs work upstream of merge. If you are in story two, you should be funding more refactoring while the window is open. The same dashboard number recommends opposite investments depending on which story is true, and the metric as shipped cannot tell you.

The Corroborating Trend Points One Way

GitClear analyzed 211 million changed lines from 2020 through 2024 and published the results in February 2025. The share of new code revised within two weeks of being written grew from 3.1% in 2020 to 5.7% in 2024. Code revised within two weeks is too young to be legacy refactoring; that fraction is rework by construction. The same study found duplicated code blocks of five or more lines rose 8x during 2024, and copy/pasted code grew from 8.3% to 12.3% of changed lines while “moved” lines, the signature of refactoring and reuse, fell 39.9%. 2024 was the first year in the dataset where copy/pasted code exceeded moved code.

GitClear’s January 2024 study, on an earlier 153-million-line corpus, had already projected that churn would double in 2024 against the 2021 pre-AI baseline. The projection was directionally right before the Faros telemetry made it look conservative.

One disclosure belongs here: GitClear builds a code-analysis product and Faros sells engineering intelligence tooling, so both firms benefit when the data reveals problems their products address. Read the exact percentages with that in mind. The direction, however, shows up in two independent datasets with different methodologies, and the two-week revision window in GitClear’s data specifically weakens the pure-refactoring story. It does not settle the question for your organization. Only your own Git history can do that.

The Method: Provenance, Windows, Durability

Resolving the ambiguity locally is a few days of engineering, and Faros points at the mechanism itself: Git-level line provenance. Here is the concrete version.

Narrow the window. Compute the deletion-to-addition ratio per repository at monthly intervals, not quarterly. A month-wide window constrains where deleted code could have originated and turns a vague quarterly average into a signal you can align with specific projects, migrations, and incidents. Run it across the last 12 months so you have a baseline before AI adoption ramped, if your history reaches that far.

Date the deleted lines. For the highest-churn months, take the deleted lines and ask when they were written. git blame on the parent commit of each deleting commit gives you the birth date of every line that died. Bucket the ages: lines under 60 days old at deletion are rework; lines older than a year are legacy refactoring; the middle band is your iteration-on-mediocre-code story. This single histogram is the analysis Faros says would resolve its own headline ambiguity, and almost nobody runs it.

Add a durability metric. Churn measures deletions looking backward. Durability looks forward: of the lines you merged N days ago, what percentage is still alive in HEAD? Pick N at 90 days and compute it per repo, per team, and if you tag AI-assisted pull requests, per authorship mode. This is the survival rate of your shipped code, and it belongs next to every velocity number you report. A team merging 30% more code with 90-day survival falling from 92% to 70% has not accelerated.

Interpretation follows from the shape. Rework concentrated in specific repos or teams points at a harness problem: prompts, context, review depth, or task selection in those areas. Deletions dominated by old lines across many repos is a refactoring wave, and the right response is to fund it. A rising middle band suggests iteration is genuinely cheaper now, which is fine as long as the durability number holds.

The connection to comprehension is direct. Code that engineers did not fully understand at merge time is exactly the code that gets replaced when it meets production, a dynamic we examined in comprehension is the bottleneck. And the volume feeding this pipeline keeps growing, as the code tsunami reaching production shows. Churn is where those two pressures become measurable in your own history.

Do This Now

Pick your three highest-merge-volume repositories. For each one, run the monthly deletion-to-addition ratio over the past year and flag the top two churn months. For those months, date the deleted lines with git blame against parent commits and bucket them: under 60 days, 60 days to a year, over a year. You now know which of the three stories you are in, per repo, with evidence.

Then make durability a standing metric. Report 90-day line survival alongside throughput in whatever review your team already runs. When someone presents a velocity gain, the survival number is the asterisk, made visible.

Teams that cannot answer “did what we shipped survive?” are reporting velocity, not progress. The answer costs one engineer a few days. The ambiguity costs you every planning cycle it goes unresolved.

This analysis synthesizes AI Engineering Report 2026: The Acceleration Whiplash (Faros AI, April 2026), AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones (GitClear, February 2025), Coding on Copilot (GitClear, January 2024).

Victorino Group helps engineering teams instrument line provenance and code durability around AI-assisted delivery. Let’s talk.