When AI reviews AI-written code

Search "best AI code review tools" and the results are a wall of near-identical comparisons, feature grids, pricing tiers, GitHub star counts. They're not wrong about what these tools are good at: pattern detection, style enforcement, known vulnerability signatures, missing test coverage, the mechanical parts of review humans do inconsistently anyway. What none of them say is the thing that actually matters as more code arrives already written by a model.

Same training distribution, same blind spots

An AI code reviewer and an AI code generator are usually trained on overlapping data: the same public repositories, the same common libraries, the same idiomatic patterns for a given language. That overlap is exactly why review tools are good at catching the mistakes a human makes, off-by-ones, forgotten null checks, inconsistent naming, because those are the deviations from the common pattern the model learned. It's also exactly why they're weaker at catching the mistakes a model makes: a subtly wrong assumption that happens to be idiomatic, a plausible-looking abstraction that doesn't fit this specific codebase, an auth check that looks structurally correct and isn't. The reviewer isn't blind to these by accident. It's blind to them because the generator and the reviewer are, in a meaningful sense, drawing from the same well.

Where this actually bites

Business logic errors, authentication flow flaws, and race conditions are already the well-documented weak spot for AI review tools generally. The sharper version of that problem shows up specifically when the code under review was also AI-written: a reviewer trained to flag deviations from common patterns has nothing to flag when the code confidently follows a common pattern that happens to be wrong for this specific business rule. Two systems agreeing with each other is not the same signal as two systems that independently checked something.

What actually closes the gap

Not a better AI reviewer, at least not by itself. The check that catches a plausible-but-wrong pattern is one with a genuinely different source of truth: a human who knows the specific business rule the code is supposed to encode, a property-based test that exercises real edge cases rather than the ones a model would think to write, or a static analysis tool built on explicit rules rather than learned patterns, which fails differently than a model does specifically because it isn't a model. The value of a second opinion comes from it being independent, and two systems trained on overlapping internet-scale code are not independent of each other in the way that matters.

None of this is an argument against using AI to review AI-written code, it still catches a large share of real problems faster than a human alone would. It's an argument for knowing specifically which failure mode it can't see, and making sure something else in the process, a human, a rule-based tool, a test that isn't just plausible, actually can.