The volume of AI-generated code is the question every eng manager is asking now, and the common answer is "have an AI review it." But teams keep wiring it up as: the same model that wrote the diff reviews the diff. That is the one setup an AI code review cannot be trusted in, and it's an eval-design issue, not a quality-of-tool issue.
A model reviewing its own output is one blind spot measured twice. It doesn't know what it got wrong in generation because it has no independent read of the code, it has the same priors, the same truncation, the same confidence in the same places. If the generator thought the happy path covered the edge case, the reviewer probably thinks so too, because it's the same weights. Studies on LLM-as-judge (herding, correlated judges) show exactly this: when the judge shares lineage with the thing being judged, N votes is really one opinion counted N times. The self-review loop is the same failure, applied to code.
Three things that actually break the correlated blind spot:
Cross-model review. Have a different model read the diff than the one that wrote it. Different training lineage, different priors, and a genuine chance it catches what the generator assumed. This is cheap to do with agent APIs and it's the single biggest correction you can make.
Independent verification. Tests are the review tool that has no opinion. If the code and its tests come from the same file, they share a blind spot, so look at what the tests never assert and whether anything outside the diff gets touched. A build, a type check, a static-analysis pass that aren't part of the model's output count as signal.
Pin your harness. Review quality is model plus scaffold, so write down what carried context into the review, what tool loop the reviewer ran, and what judge decided "pass." If the score moves, you want to know whether the model changed or the harness did.
The fix for AI code volume isn't a better self-reviewer. It's making sure the thing that reviews the code is not the thing that wrote it.
