Is AI Making Our Code Worse? How to Actually Check

TL;DR: Industry-scale data says AI-era code duplicates more, churns more, and gets refactored less. Whether that's happening in your repo is a measurable comparison, not a philosophy debate: AI-attributed work vs. everything else, on rework, cycle time, and review latency, with the paths and PRs as receipts. Sometimes the answer is genuinely "no, it's fine." Then you get to stop arguing about vibes and go expand the thing that's working.

What the industry data actually shows

The population-level evidence is not subtle. GitClear's analysis of 623 million code changes from 2023 to 2026 found code-block duplication up 81% against 2023, within-commit copy/paste share rising from 9.4% of changed lines in 2022 to 15.7% in the first half of 2026, and refactoring line-moves down 70% against 2022 levels, with moved code falling from 21% of changed lines in 2022 to 3.8% year to date in 2026. Two-week churn, code rewritten almost immediately after shipping, rose 15%. Their 2025 study of 211 million lines had already caught the same curve earlier: cloned lines up from 8.3% of changed code in 2020 to 12.3% in 2024, with moved (refactored) lines falling 39.9% in 2024 alone. On the defect side, Faros AI measured bugs per developer up 54% where AI adoption ran high, across two years of telemetry from 22,000 developers on 4,000 teams.

So: is AI making our code worse? At industry scale, the honest short answer is "on average, yes, in specific measurable ways: more duplication, more churn, less refactoring, more bugs."

But you don't ship the industry average. You ship your repo. And the spread across orgs is the real story: the same tools land as clean leverage in one org and a debt engine in another. The variable is the org's absorption system, which means the only answer that matters is local. The good news: local is checkable.

Why you can't answer this by asking the team

The tempting shortcut is a pulse survey: "do you feel AI code quality is a problem?" The result will be confidently wrong in an unknowable direction. METR's randomized trial is the cleanest demonstration: experienced open-source developers working on repos they knew well believed AI made them roughly 20% faster; the measured result was 19% slower. If perception can miss the sign of a speed effect on your own work, it can certainly miss a slow quality drift spread across a hundred PRs.

The codebase, unlike the team, keeps receipts. Ask it.

The check: AI cohort vs. baseline, in your own repo

The measurement is one comparison. Split merged work into two cohorts - AI-attributed (commits and PRs carrying explicit AI signals: co-author trailers, bot and agent identities, agent branches, PR-body markers) and baseline (everything unattributed) - over the same window. Then compare:

• Rework share - the headline number. What fraction of each cohort's files gets re-edited within a short window (say, three weeks) of shipping? Read it as a ratio: AI rework versus human rework. The ratio cancels whatever churn is normal for your org (a hot codebase inflates both sides equally), so it isolates the AI effect instead of punishing you for being busy.
• Cycle time p50 - is AI-assisted work actually shipping faster, slower, or the same? This is where the "worse code but faster delivery" trade becomes visible, or evaporates.
• Review latency and PR size - the early-warning pair. AI cohorts tend to run bigger; bigger PRs get slower, shallower review; shallow review is how quality problems get into the repo. If AI PR size is up and review latency is up, the degradation is upstream of the diff.

One prerequisite: the comparison requires attribution to exist. If your agents and tools don't sign their work, start there; it's a ten-minute convention, covered in how to measure AI adoption. One honest limit: git-based attribution sees agentic AI only. Tab-completions leave no trace, so your AI cohort is a floor, not a census.

The three places degradation hides

A cohort average can look fine while the damage concentrates. Three views catch what the average hides:

1. The treadmill. List the specific paths where AI-authored lines keep coming back for re-edits within the rework window. This is AI code churn made concrete: not "churn is up 4 points" but "these eleven files are being regenerated instead of fixed." The treadmill list is also your review-gate shopping list.

2. Hotspot areas. Roll AI churn up by code area and look for concentration. An area with heavy AI-authored lines and repeated regression re-edits is the treadmill; an area with heavy AI lines and quiet regressions is scaffolding working as intended. Same number, opposite verdicts, which is why the area view has to carry the re-edit count and not just the AI share.

3. Review coverage that quietly didn't keep up. Volume is AI's signature move, and review is what volume overwhelms first. If AI cohort volume climbed while review coverage sagged, or reviews compressed into rubber stamps, your quality gate degraded at exactly the moment its load doubled. This is the mechanism behind most "AI made our code worse" stories, and it's fixable without touching the tools.

When the answer is no

Run the check honestly and a real fraction of orgs get good news: AI rework at or below the human baseline, cycle time flat or better, treadmill quiet. That's clean leverage, and it deserves to be said as loudly as the findings. It usually means your review and test gates were strong before the tools arrived (the readiness factors, doing their job), and the rational next move is expansion. At that point the question becomes the commercial one: which tool earns more seats.

The measurement's job is to replace an unfalsifiable argument with a number that can go either way.

Running the check without building it

Everything above is buildable from git history and PR data: attribution parsing, cohort joins, rework windows, area rollups. It's a real project, and it has to stay deterministic or the numbers won't survive their first hostile meeting.

Or connect your repos and read the verdict: Busfactor's AI impact view computes the AI-vs-baseline cohort table (PRs, cycle p50, review latency p50, size p50, rework share), the treadmill list of AI-authored paths being re-edited with the receipts linked, the hotspot areas with regression-episode counts, and a per-tool breakdown so one bad tool can't hide inside a blended average. The headline is an explicit verdict, clean leverage or paying twice, and every number behind it is quoted from the engine, never generated.

Honest limits: rework is a file-grain proxy (a path re-edited within the window rather than line-level diff tracking, so healthy iteration on a hot file inflates it; that's why the verdict reads the AI-to-human ratio). Attribution covers agentic AI that signs its work. And nothing is scored per person; the question is whether the system is absorbing AI, not which developer to blame.

"Is AI making our code worse?" deserves a better answer than a feeling. Your repo already contains it - someone just has to run the comparison.