AI Didn't Wreck Your Codebase. Your Review Budget Did

A confession has been making the rounds on dev.to: a team lead who spent six months shipping at AI speed, hit milestones that would've seemed impossible a year earlier, then tried to onboard a new developer and discovered the codebase had become a maze. Their proposed fix — rewrite the core modules "the old way: slower, more deliberate."

The story is thin on specifics, and honestly it reads like a hundred other posts in the genre. That's exactly why it matters. This isn't one team's cautionary tale anymore; it's the median experience, and for the first time we have hard numbers describing it. The interesting question isn't whether AI-accelerated tech debt is real. It's whether "slow back down" is the right response. I don't think it is.

The debt is measured now, not vibes

GitClear's latest research, covering 623 million code changes from 2023 through 2026, puts figures on what that dev.to author felt during onboarding. Refactoring has collapsed from 21% of changed lines in 2022 to 3.8% now. Copy/pasted code climbed from 9.4% to 15.7% over the same window. Cross-file function calls — a decent proxy for "did anyone check whether this helper already exists" — dropped 35%. Developers are now roughly five times more likely to duplicate code than to refactor it; in 2022, the preference ran two-to-one the other way.

That's the shape of a maze codebase, expressed as commit statistics: layers added, nothing consolidated underneath.

DORA's 2025 report supplies the systemic view. With 90% of surveyed developers now using AI at work, AI adoption finally correlates with higher delivery throughput — a reversal from the year before — but it still correlates with worse delivery stability. DORA's diagnosis is blunt: AI increases the rate of code generation faster than review and deployment infrastructure can absorb it. The bottleneck didn't disappear. It moved downstream, where it's more expensive.

And the perception gap is real too. METR's randomized trial had experienced open-source developers work on repositories they knew well; with AI tools they completed tasks 19% slower, while believing they'd been 20% faster. That study measured early-2025 tools on mature codebases, so don't over-extrapolate — but it's the cleanest evidence we have that felt velocity and actual velocity can point in opposite directions. Stack Overflow's 2025 survey rounds it out: the top frustration, at 66%, is AI code that's "almost right, but not quite," and 45% say debugging AI output eats more time than it saves.

What actually changed

Tech debt has always been a loan against future understanding. What AI changed is the economics: the cost of writing code dropped to near zero, while the cost of understanding it stayed exactly where it was. Every AI-assisted team is now running a larger principal on the same fixed interest rate of human comprehension.

Pre-AI, the pain of typing was an accidental quality gate. Duplicating a 200-line module by hand hurt enough that you'd go find the abstraction instead. An agent produces those 200 lines in seconds, and they compile, and the tests pass, and the diff is too long to read carefully at 4pm. GitClear's numbers — duplication up, refactoring down, error-swallowing constructs up 47% — are precisely what you'd predict when the friction that used to force consolidation disappears and nothing replaces it.

The onboarding failure in the dev.to post is the classic tell, and it's worth internalizing why: a new hire is the first person who has to pay the comprehension debt in cash. The existing team was coasting on context they'd built up prompt by prompt — context that lives in chat transcripts, not in the code's structure.

Slowing down is nostalgia, not strategy

Here's where I part ways with the "rewrite it the old way" instinct. It misreads the problem as speed when the problem is unbalanced spend. These teams didn't fail because they generated code quickly; they failed because they kept their 2022-sized review, testing, and refactoring budgets while their code volume tripled. Deliberately hand-writing everything again fixes that ratio by shrinking the numerator — the most expensive possible correction, and one your competitors won't be making.

DORA's data backs the alternative reading: AI acts as an amplifier. Teams with strong control systems — real test suites, fast feedback loops, mature version control practices — converted AI speed into throughput. Teams without them converted the same speed into instability. The tool didn't decide which; the surrounding system did.

Rebalance the budget instead

The practical move is to shift engineering effort from generation to verification and curation, explicitly:

• Hold AI diffs to the same review bar as human ones — which means capping their size. A 1,500-line agent PR doesn't get reviewed; it gets skimmed and approved. Make the agent ship in reviewable increments, same as you'd demand of a junior.
• Put duplication and churn on the dashboard. Tools like jscpd or SonarQube's duplication checks in CI turn GitClear's macro trend into a per-PR signal. If copy/paste share is climbing quarter over quarter, you're accruing the debt whether you feel it or not.
• Budget refactoring as a first-class line item. The industry average fell to 3.8% of changed lines. Pick a floor — 10–15% — and treat dropping below it as a paging-level signal, because it means you've stopped paying interest.
• Prompt for reuse, not just correctness. "Search for an existing helper before writing a new one" belongs in your CLAUDE.md or agent instructions. Agents duplicate by default because duplication is the locally safest completion; they consolidate fine when told to.
• Treat onboarding time as your canary metric. It's the purest measurement of comprehension debt, and it fails loudly months before your incident rate does.

The dev.to author stumbled onto a genuine crisis and reached for the wrong lever. The teams that come out of this era ahead won't be the ones that typed everything themselves, and they won't be the ones that let agents run unsupervised. They'll be the ones that noticed the cost structure of software flipped — writing got cheap, understanding didn't — and rebuilt their process around the expensive part.