The AI Code Went In Fast. It's Coming Back Just as Fast.

TL;DR: AI-assisted code merges faster, and in the industry data it comes back for repair faster too. The metric that settles whether that's happening to you is the AI code rework rate: how much AI-assisted work gets rewritten within weeks, measured against the same number for human-authored work. You can build a first version from git this month, for free. If the delta is ugly, the fix is intake discipline, not canceling seats.

Merge velocity is up. You can see it in the graphs and feel it in standup - features that used to take a week land in two days, and the agent PRs read cleaner than half the team's.

Then you start recognizing the file names.

The service that shipped in a day is back in review. The helper module from three weeks ago is being rewritten by someone who swears it never worked in the edge cases. Your throughput chart went up and your progress didn't, and you're starting to suspect the two lines have quietly decoupled.

The comeback rate is the number that matters

You're not imagining it, and you're not alone. GitClear's analysis of 623M code changes found short-term churn - code rewritten within two weeks of landing - up 15%, code-block duplication up 81%, copy/paste rising from 9.4% to 15.7% of commit content, and refactoring line-moves down 70%. Their 2025 research found the effect concentrates hard: the heaviest AI users showed roughly nine times the churn. Faros's 2026 AI Engineering Report measured bugs per developer up 54% at high AI adoption. And the 2024 DORA report estimated a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability - faster hands, slower system.

None of that proves it's happening in your repos. That's the trap on both sides: the enthusiasts wave the authoring speed, the skeptics wave the industry churn data, and nobody in the room has your number. Meanwhile the felt sense is unreliable in the worst way. In the METR randomized trial, experienced developers were 19% slower with AI on mature codebases while believing, afterward, that they'd been sped up by 20%.

So get your number. The AI code rework rate is the share of AI-assisted merged code that gets rewritten or reverted within a fixed window, measured side by side with the same rate for human-authored code. It's the honest successor to raw churn: the absolute value is noisy, but the delta between cohorts under one definition is hard to argue with. It's what turns "the AI code is fine" and "the AI code is a debt machine" from opinions into findings.

One fairness rule before you measure anything: churn is not automatically bad. A refactor that lands and then gets polished is churn; punishing it teaches the team to stop improving code. The naive metric can't tell polish from repair, which is exactly why you compare cohorts under the same rule instead of moralizing about a single number.

Do this first - free, this month

1. Fix the window and the rule. Pick a rework window (21 days is a reasonable start), define rework as lines rewritten or reverted within it, and apply the rule identically to all merged work. Changing definitions mid-argument is how these debates die.
2. Establish a deterministic AI floor. Agent bot accounts and commit trailers (Co-Authored-By and friends) are facts in your git history. Count those. Git cannot see tab-completions or pasted chat output, so treat this as a floor, not a census. Say so on the slide; the labeled floor beats an impressive guess.
3. Cohort at area grain, never person grain. The question is "where does AI-assisted work hold up, and where does it come back?", asked per module and per service. The moment this becomes a per-person score, you've built a surveillance tool and poisoned your own data.
4. Read the delta with two interpretations. High AI rework in an area can mean the tool is wrong for that codebase - or that the area's review net is too thin to catch what the tool gets wrong. The receipts (which PRs came back, what the fix commits say) decide, and the agent guardrails address the second reading directly.
5. Tighten intake, then re-measure. Smaller PRs, a human approver who can explain the change, tests where the comebacks cluster. If the delta doesn't move, now you have an evidence-backed tooling conversation instead of a vibes one.

How you'd actually see it in Busfactor

Everything above is a scripting weekend if you want to own it. What Busfactor's AI view does is run it continuously: AI-versus-human rework cohorts side by side, built on deterministic attribution (commit trailers and bot accounts, the measured floor, never a tunable confidence slider), plus the areas where AI churn concentrates and a judged readiness verdict for the org.

The honest limits, because they're load-bearing: the floor is a floor. Invisible completions stay invisible, and anything beyond the deterministic floor is a disclosed estimate, labeled as one, never quoted as fact. Cohorts stay at tool and area grain, never a per-person verdict. And we don't see your seat invoices. You bring the bill, the cohorts bring the outcomes, and the ROI method joins them.

The door

Nobody here is telling you to turn the agents off. The authoring gains are real, and the research says the repair bill is where they leak. So stop arguing about vibes: fix a window, get your floor, compare your cohorts. If the AI work holds up, scale it with confidence and receipts. If it comes back fast, you've found the rework eating your speedup while it's still cheap to fix. And if nobody can even say who owns the AI-heavy areas, that's its own emergency. Either way, you'll be the one person in the AI debate holding a number instead of a feeling.