The shift

AI coding tools changed what it means to ship software. Teams generate more code, faster, across more of the codebase. But the responsibility for what reaches production hasn't changed. It's still yours.

The problem isn't that AI writes bad code. Sometimes it does, sometimes it doesn't. The problem is that nobody on your team wrote it, nobody has a mental model of why it looks the way it does, and the usual review process wasn't built for this volume.

What breaks

Review becomes a bottleneck. Code generation scales with the number of agents you run. Review scales with the number of senior engineers you have. Those curves diverge fast. The result: PRs pile up, reviewers skim, and merge quality drops.

Tests pass, but correctness isn't guaranteed. AI-generated code is often syntactically correct and test-passing. But tests don't encode architectural intent. An agent can remove a null check that protected an upstream contract for years, and every test still passes. You find out in production.

Nobody can explain the code. When a production incident hits, someone needs to explain what the code does and why. If the author is an AI session that no longer exists, you're doing archaeology. Teams that shipped fast with AI spend twice as long debugging code nobody understood in the first place.

Governance gaps appear. Surveys show that over a third of developers access AI tools through personal accounts. That means code is being generated, reviewed, and merged with tools your organization doesn't control, doesn't audit, and may not even know about. For teams with compliance requirements, that's a risk that grows quietly.

The research is clear

Large-scale studies are now quantifying what practitioners have felt: AI coding tools without verification increase risk.

• +60% higher defect risk when AI-generated changes are applied to unhealthy code. The study Code for Machines, Not Just Humans (2026) tested 5,000 real programs across six LLMs. AI consistently performed worse in structurally complex code, and the study only included code scoring 7+ out of 10 in health. For the truly messy codebases most organizations maintain, the real breakage rate is likely much higher.

• 41% more defects from AI adoption, with no measurable increase in throughput. Teams adopting AI coding tools shipped more bugs without shipping more value.

• Developers estimated AI saved them 20% of their time. In reality, they took 19% longer than a control group without AI. The perception gap is striking: AI feels fast while comprehension erodes invisibly.

• Initial AI velocity gains are fully cancelled out after two months, driven by a massive increase in code complexity. The speed you gain in week one becomes the debt you pay in month three.

These findings don't mean AI coding tools are useless. They mean unverified AI output is dangerous. The teams that benefit from AI are the ones that verify before they merge.

What doesn't work

"Just review more carefully." That's the answer nobody has time for. When AI generates 10x the volume, telling reviewers to be more thorough is like telling someone to drink from a fire hose more carefully.

"Let AI review AI." Using one language model to check another sounds efficient. But both models share training data, failure modes, and blind spots. They're more likely to agree on the same mistake than to catch each other's errors. That's consensus, not verification.

"Trust the tests." Tests verify expected behavior against known cases. They don't verify that the implementation is correct in ways the test author didn't anticipate. An AI can generate tests that pass by silently swallowing failures, asserting on wrong values, or testing the happy path while ignoring edge cases.

"The model will get better." Better models produce better code on average. But the verification problem doesn't disappear with better averages. Even a 95% accurate model means 1 in 20 changes has an issue. At scale, that's multiple problems per day. And "better on average" says nothing about your specific codebase, your specific constraints, your specific architectural decisions.

What actually helps

The teams handling this well aren't choosing between "review everything" and "trust the AI." They're building verification into their workflow.

That means objective risk signals on every change. It means knowing when a small diff has a large blast radius. It means separating what factually changed from what might be risky from what can't be verified. It means having an answer when someone asks "how do you know this is safe to merge?"

The question isn't whether your team should review AI-generated code. It's whether your current process gives you confidence that what ships is correct. If the honest answer is "we're not sure," that's the gap that needs closing.