Reviewing AI-Generated Code With More AI Doesn’t Work

From the series: The Industrialization of Software Engineering

The last essay in this series ended with a question. If review confidence is drifting away from actual risk, does testing pick up the slack, or does something else have to replace the review gate entirely?

The industry’s answer, mostly, is to automate the gate. Route low-risk changes through CI (continuous integration) checks. Save human attention for the changes that cross a defined threshold. That’s a real improvement over waiting days for a colleague to find time. It’s also not the whole fix.

A second answer has grown fast alongside it: have AI review the AI. Tools like Sonar’s Gitar, CodeRabbit, and Cursor’s Bugbot now read a pull request with full repo context, flag or fix what they find, validate the fix against CI, and escalate to a human only when something’s genuinely uncertain. It’s one of the fastest growing tool categories in this space, and it’s solving a real problem: automated analysis that used to require a human’s attention can now run in minutes instead of waiting days for one to be free.

However, the numbers say something is still broken. DORA ran a thematic deep-dive into 1,110 open-ended survey responses from Google engineers in Q3 2025, separate from its main annual survey, and found that higher AI adoption correlated with both higher software delivery throughput and higher software delivery instability at the same time. Not a tradeoff. Both climbing together. Checksum’s State of AI Code 2026 report, a survey of 105 engineering leaders, found 61 percent shipped a production incident originating in AI-generated code in the last 90 days, after that code has already passed the reviews and unit tests already in place. In the same survey, just over half of leaders said their review cycles had grown by 25 percent or more since adopting AI coding tools, while adoption of AI-generated unit tests, the layer meant to catch what review misses, sat at under half.

Automating the gate faster doesn’t explain that gap by itself. Neither does AI reviewing AI. One structural explanation, from a researcher who tested Claude reviewing Claude-generated code against a planted-bug corpus, points at something specific: when the model that writes the code and the model that reviews it come from the same family, they can carry the same blind spots into both jobs. The review ends up checking the code against another model’s opinion of itself rather than against the original intent. The author is careful to call this directional evidence, not a controlled demonstration, but it lines up with what the DORA and Checksum numbers already show: a gap opening up between how fast code gets generated and how well it gets checked.

That’s one plausible explanation for the gap, not a proven mechanism. Either way, verification built entirely out of AI, however fast, risks staying circular. It needs something to check against that didn’t come from the same place the code did.

A written specification is one version of that anchor: a description of intended behavior that exists independently of whatever generated the implementation. But a spec still needs a way to be checked against, and that’s where deterministic, non-AI tools do real work. Some of those tools have existed far longer than this problem has. Cyclomatic complexity, a measure Thomas McCabe introduced in 1976, counts the number of linearly independent paths through a function’s control-flow graph. McCabe built it as a practical alternative to counting every possible execution path directly, since that number can be enormous or infinite once loops are involved. The measure doesn’t care who or what wrote the function, and it doesn’t share a training distribution with anything: it applies the same structural calculation regardless of the source. It also doesn’t tell you whether the code does what the spec says. A function can be structurally simple and still be wrong. That’s the point: mechanical checks like this are one layer in a stack, not a stand-in for verifying intent. Tests, contracts, static and security analysis, and build checks each do a different piece of work, all of it running as fixed, deterministic steps rather than another model’s judgement call.

The architecture that emerges from this isn’t “review, but automated.” It’s layers doing distinct jobs: a specification stating intent, a deterministic pipeline checking mechanical properties against something that doesn’t guess, and AI review held back for the judgement calls left over once the deterministic layers have done their work. Even Sonar, a company selling AI code review, describes its own product this way: Gitar’s AI review sits alongside SonarQube’s deterministic analysis, not in place of it. It’s just no longer being asked to be the whole system by itself.

The review gate didn’t need to get faster. It needed something outside the loop to check against, the same thing every checkpoint in the old SDLC used to provide before the phases collapsed into one continuous conversation with a model. Continuous verification, done tight, isn’t a nice version of review. It’s rebuilding the thing review always depended on, using pieces that don’t share the blind spots of whatever they’re checking.

Closing

The teams solving this aren't the ones with the fastest AI reviewer. They're the ones who figured out what a checkpoint actually needs to be checking against, and uilt that first.

Next in the series: once verification stops depending on human judgement for most of what used to require it, what's actually left for engineers to do, and how is that role starting to split.