Most of us here are already shipping AI-assisted code, and the review side of that has not caught up. This is a write-up of what changes when you stop treating AI review as a single yes-or-no gate and start treating it as a pipeline.
The Volume Problem Nobody Planned For
GitHub's Octoverse 2025 numbers put roughly 41% of new code as AI-assisted, and that share keeps climbing. The awkward part is what comes with it: AI-assisted pull requests carry about 1.7 times more issues per PR than human-written ones, logic errors show up roughly 75% more often, and security vulnerabilities appear 1.5 to 2 times more frequently.
Meanwhile review capacity is flat. Senior engineers already spend 20 to 30 percent of their week reading other people's code. Accelerating the writing phase does not create reviewers, it just moves the bottleneck downstream and makes it worse. PRs pile up, reviewers skim, and defects reach production.
Why A Second And Third Pass Pay For Themselves
A single review pass is like one read of a dense paper. You catch the surface errors and the obvious structural problems, and you miss the things that only appear on closer inspection.
The measured curve is consistent across teams running both approaches. The first pass catches roughly 60% of the issues the system can detect at all. The second pass adds another 25%, largely because some findings only resolve once cross-file context is available. Three passes reach about 95%, which makes four the practical ceiling for most codebases.
A workable pipeline has four stages. Planning estimates the scope of the change and groups related files, so a database migration gets different scrutiny than a front-end component. The initial pass runs broad and fast on obvious bugs, style and basic security patterns. The deep pass takes those findings, adds cross-file context, and traces data flow across function boundaries, checks error handling consistency along a call chain, validates transaction scoping and looks for race conditions. It costs 3 to 5 times more compute than the first pass and it catches the bugs that cause incidents.
The fourth stage is the one people leave out: fix verification. After developers address the earlier findings, re-review only the modified areas to confirm the fixes are correct and did not introduce anything new. That is what prevents the classic case of a fix creating a second bug.
A Model Reviewing Itself Retraces Its Own Reasoning
This is the part with the biggest payoff per unit of effort. When a model reviews code it wrote, it tends to walk back through its original reasoning and confirm its original conclusions. Prompting it to be critical does not fix that, because the problem is structural rather than motivational.
Models from the same family share training distributions, architectures and optimization objectives, and those shared foundations produce correlated blind spots. Where one model misses an integer overflow, another flags it immediately because its training made it more sensitive to numeric boundaries. Teams running cross-model review report 40 to 60 percent better defect detection than same-model review, with the largest gains on logic errors and edge case handling.
Running the review in a separate session matters as much as changing the model. The reviewer should see the code and the requirements, not the reasoning that produced the code. That structural separation is what creates real independence.
There is a fuller writeup of the pipeline stages and the cross-model architecture in our guide to multi-pass AI code review if you want the details.
Where It Still Falls Short
Worth being honest about the ceiling. AI review is strong on exhaustive path tracing, so off-by-one errors, null dereferences, resource leaks and concurrency races get caught reliably. It is strong on vulnerability patterns and on consistency enforcement, which humans apply unevenly under deadline pressure.
It is weak on whether the code should exist. It will confirm a function implements its logic correctly and say nothing about whether that logic fits the business problem. Code that is technically correct and architecturally wrong passes without comment. It is also weak on algorithmic complexity, where a cleanly written quadratic solution often gets approved, and on novel vulnerability classes that are thin in training data.
The Takeaway
If you already run AI review, the cheapest upgrade available is not a better model. It is a second pass, a different model family doing the reviewing, and a fix verification stage at the end.
Reserve the expensive multi-pass configuration for the code that deserves it: authentication, payments, data access and infrastructure config. Let UI and docs changes ride on a single pass. Cost then scales with risk instead of with repository size.
