AI writes the code. Who's reading it?

The pitch for AI coding tools is speed, and on that narrow claim they deliver: a developer can produce a 600-line change in the time a 60-line one used to take. The blank page is free now. What almost nobody budgeted for is the obvious consequence — somebody still has to read all that code, and reading didn't get faster.

The bottleneck moved. Most teams didn't.

The data is not subtle

Two of the better datasets tell the same story from different angles.

GitClear analyzed 211 million changed lines of code from 2020 through 2024 — repos from Google, Microsoft, Meta, and a pile of private companies. The trend lines all point the wrong way. Refactoring — the work of consolidating and reusing code — fell from about 25% of changes in 2021 to under 10% in 2024. Duplicated blocks rose roughly eightfold. And for the first time on record, "copy/pasted" lines outnumbered "moved" lines — the signature of teams pasting variations instead of building reusable pieces. Short-term churn (code rewritten within two weeks of being committed) climbed from 5.5% to 7.9%.

Google's 2024 DORA report, with tens of thousands of respondents, corroborates it from the delivery side: a 25% increase in AI adoption was associated with a ~7.2% drop in delivery stability and a small drop in throughput. More AI tracked with worse delivery outcomes — the opposite of the pitch.

Why this happens (and it isn't "AI writes bad code")

The tempting read is "AI code is low quality." That's not quite it, and blaming the tool misses the fix. The mechanism is about batch size and review.

AI makes producing code nearly free, so change sets inflate. A developer accepts a large, plausible-looking diff and ships it as one pull request. The reviewer opens a 600-line PR of confident-looking code, skims it, approves it, and a big, under-understood change lands in production. DORA has shown for fifteen years that large batches are riskier than small ones. AI didn't break that rule — it just made it trivially easy to violate.

AI didn't lower your code quality. It removed the friction that used to keep your changes small and your reviews honest. The quality drop is a review problem wearing a productivity costume.

What I'd actually do

You don't fix this by banning the tools — the productivity is real and your competitors are using them. You fix it by moving your process to where the constraint now lives: review and integration.

1. Cap the batch, not the tooling. Keep pull requests small and single-purpose. If AI helped you generate a 600-line change, your job is to split it into reviewable pieces, not to ship the wall of code as one.
2. Treat AI output as an untrusted first draft. The person who prompted it is the author and owns it — including understanding every line before it goes up for review. "The AI wrote it" is not a code-review answer.
3. Make review a real gate, and staff it. Reviewer time is now your scarce resource. Protect it. A skimmed approval on a huge diff is worse than no review, because it launders risk into "someone looked at it."
4. Lean on the machines that don't get tired. Tests, type checking, linting, and static analysis scale with code volume in a way human eyes don't. If you're going to generate more code, your automated quality gates have to get stronger, not stay flat.
5. Watch for duplication and churn. If the same logic is showing up in five places and recent code keeps getting rewritten, that's the maintainability tax accruing. Refactoring isn't optional overhead — it's the thing AI-heavy teams are quietly skipping.
6. Measure stability, not just velocity. Track change failure rate and how often you're reverting recent work. "We ship more" is not a win if more of it comes back broken.

The bottom line

AI coding tools are a genuine multiplier — of whatever your engineering discipline already was. A team with tight PRs, real review, and strong automated gates gets faster. A team that treated review as a formality now ships its weak spots at scale, and the data shows exactly that: more code, more duplication, more instability.

The question stopped being "can we write this faster." It's "can we still understand what we're shipping." Answer that one, and AI is the best leverage engineering has had in a decade. Ignore it, and you're just accruing technical debt at machine speed.