AI Reviewing AI: The Asymmetric Architecture of Code-Review Agents

A review pipeline where the author and the reviewer are both language models trained on overlapping corpora is not a quality gate. It is a confidence amplifier. The author writes code that looks plausible to a transformer, the reviewer reads code through the same plausibility lens, both agents converge on "looks fine," and the diff merges with a green checkmark that means nothing about whether the change is actually correct. Recent industry data shows the asymmetry plainly: PRs co-authored with AI produce roughly 40% more critical issues and 70% more major issues than human-written PRs at the same volume, with logic and correctness bugs accounting for most of the gap. The reviewer agents shipped to catch those bugs are, by construction, the ones least equipped to find them.

The teams getting real signal from AI code review have stopped treating "review" as a slightly different shape of "generation" and started designing review as a fundamentally different cognitive task. Generation prompting asks the model to produce something coherent. Review prompting has to ask the model to find what is missing — to inhabit the negative space of the diff rather than the positive one — and that inversion is much harder to elicit than a one-line system prompt suggests.

Why Review Prompting Is Not Generation Prompting in Reverse

Code generation lives in a generative loop: the model proposes tokens, the next-token distribution rewards plausibility, and the output looks like the training distribution because that is what the loss function asked for. Code review needs the opposite stance. The reviewer has to read finished text and ask "what should be here that isn't" — missing null check, absent error path, unhandled state transition, untested edge case, a precondition the function assumes but never validates. None of those failures show up as something to read. They show up as something to not read, and a model trained to predict the next plausible token has weak machinery for noticing absences.

Two practical consequences follow. First, naive review prompts ("review this diff and find bugs") underperform because they leave the model to decide what review even means, and the default behavior is to summarize and praise rather than to interrogate. Second, the obvious fix — long, detailed review prompts that enumerate every check — overcorrects in the other direction: the review agent starts manufacturing concerns to prove it read the diff, and the false-positive rate climbs to the point where engineers ignore the bot. Research on LLM code editing has documented the same pattern: detailed prompts can introduce a bias toward excessive fault-finding, where the model flags non-existent errors in correct code because the prompt rewarded the appearance of thorough review.

The teams that escape this trade-off treat review as a structured analysis task with explicit anchors. Meta's recent work on semi-formal reasoning templates pushed code-review accuracy substantially higher by forcing the model to state premises, trace execution paths against specific test cases, and derive a conclusion from named evidence rather than vibes. The mechanism is simple: when the prompt requires a chain of "if X then Y because Z," hallucinated concerns are visibly weaker than grounded ones, and the model self-suppresses the kind of generic style nits that make AI review feel like noise.

Multi-Pass Architectures: Specification, Invariants, Adversaries

Single-pass review — one model, one prompt, one response — composes badly with the asymmetry above. The pass-rate ceiling is set by what a generation-trained model can notice in one read of changed lines, which is exactly the set of issues least correlated with what bites in production. The architectures that work at scale decompose review into multiple specialized passes, each with a different question and a different context shape.

A specification check runs first and asks only one thing: does the diff implement what the spec or ticket says it should implement? The reviewer is given the issue description, the user-facing requirement, and the diff — and is forbidden from commenting on style, performance, or polish. The pass succeeds or fails on intent fidelity. SpecRover-style approaches that treat tests and specs as executable contracts catch a category of bug — the patch passed CI but didn't actually fix the customer's problem — that no per-line review will ever surface.

An invariant check runs second and asks whether the change preserves the system's existing properties. The context is not just the diff but the surrounding module, the called functions, and the implicit contracts (this function returns non-null, this list is sorted, this state machine never goes from archived to active). Most subtle production bugs are invariant violations the original author considered obvious; the review agent has to be told what they are.

An adversarial probe runs last and asks the most useful question of all: how would an attacker, a malicious input, or a chaos test break this code? Adversarial code-review patterns separate a Builder Agent (optimized for speed and synthesis) from a Critic Agent (optimized for hostile reasoning) and require the Critic to attempt to falsify the Builder's claim that the change is correct. The pattern works because the Critic's success metric is rejection, not approval — its prompt rewards finding a counterexample, not signing off.

When multiple critics run in parallel, a Moderator role becomes structural rather than optional. Three independent passes will produce overlapping concerns, and dumping all of them into the PR thread is exactly the failure mode that trains engineers to ignore the bot. Game-theoretic multi-agent designs handle this by separating analysis (read-only critics) from synthesis (a single moderator that deduplicates, prioritizes by severity, and writes the final review). The moderator is also the natural place to enforce a precision floor: if a finding cannot be linked to a specific line, a specific consequence, and a specific test that would catch the regression, it does not ship.

The Reviewer-Is-Not-the-Author Constraint

The most underrated architectural decision in AI code review is which model reviews which code. When the reviewer agent and the author agent share a base model, they inherit the same blind spots — the same training data, the same alignment quirks, the same things they were never penalized for missing during pretraining. A Claude-authored function reviewed by Claude is a single point of failure dressed up as two.

Cross-family review breaks this. Three models from different families, each given the same diff with deliberately different context framing, reduces the chance that one model's interpretation poisons another's. The mechanism is not that one model is smarter; it is that their failure modes are uncorrelated. The Critic-Verifier architectures that perform well on vulnerability detection benchmarks lean on this directly: cloud-based expert agents analyze the code from complementary angles (structure, security, control flow), while a separate local verifier — explicitly trained against the experts' false-positive distribution — adjudicates.

For most teams, this looks like one practical rule: do not let the model that wrote the code be the model that reviews it. If your IDE assistant and your CI reviewer are the same provider on the same model version, you have wired together a closed loop whose only failure signal is the human who eventually reads the merged commit.

Diff-Aware Context: Changed Semantics, Not Changed Lines

The other context decision that quietly destroys review quality is how the diff is presented to the model. Most early review bots dumped the unified diff into the prompt and called it context. The result is review comments that obsess over the lines that changed and miss the semantic neighborhood the change lives in — the caller that now passes the wrong type, the test that no longer exercises the renamed branch, the migration that assumes the old column name.

Practitioners have converged on a few patterns that move the needle. Unified diffs (rather than file-rewrite responses) reduce model laziness substantially — Aider's published numbers showed roughly 3x fewer "lazy" responses when the prompt format was unified diffs. Hunk-aware context windows that include the function the changed lines live inside, plus the call sites of any modified signature, give the reviewer enough surface to reason about ripple effects. Symbol-level retrieval — fetching the definitions of every type and function the diff references — is now standard in serious review pipelines because without it, the reviewer is reasoning about an AccountState it has never seen.

The constraint that kills naive approaches is the context budget. A single dependency upgrade can balloon a diff to fifty thousand lines, and stuffing it all into the model's window past a certain point degrades output quality, not just cost. Effective diff-aware review pipelines invest in which lines deserve context expansion — flagging the high-blast-radius hunks (changes to security-sensitive files, public API signatures, schema migrations, concurrency primitives) for full context inclusion and giving the boilerplate hunks a cursory pass. The signal-to-noise math wins or loses on this triage.

Evaluation: Planted Bugs and Regression Suites

The hardest part of running a code-review agent is knowing whether it is actually working. Acceptance rate — the share of bot comments that result in a code change — is the most cited metric and the most misleading one in isolation. A bot that flags only style issues will have a high acceptance rate (engineers will fix the nits) and zero correlation with bug prevention. A bot that flags real concurrency issues will have a low acceptance rate (engineers will argue, then fix, then sometimes wave it off) and high correlation with downstream incident reduction. The metric you actually want is whether hotfixes go down quarter over quarter; the metric you can measure today is acceptance rate; the gap between the two is where review-agent ROI claims live.

Two evaluation patterns separate teams that know if their reviewer works from teams that hope it does. Planted-bug benchmarks inject known-bad changes into a stream of normal PRs and measure whether the reviewer catches them — null dereferences in the obvious places, missing auth checks on new endpoints, off-by-one errors in pagination, forgotten cleanup in error paths. The benchmark has to be refreshed; once a reviewer is tuned against a static planted set, it overfits and the recall numbers stop predicting production behavior.

Historical regression suites are even more useful: take the last twelve months of production bugs that human review caught (or failed to catch and shipped), reconstruct the diff that introduced them, and replay it through the reviewer agent. The bot's recall on this set tells you which classes of real bugs your reviewer is structurally blind to — and "structurally blind" is the operative phrase, because a reviewer that misses a class of bug once will miss it again, and discovering the gap from a planted benchmark is much cheaper than discovering it from a P0.

The newer behavioral evaluation patterns — observing whether developers fixed code after a review comment versus ignoring it — are honest in a way precision/recall labels are not. They sidestep the question of "was this comment correct" and replace it with "did the engineer treat this comment as signal." That latter question is what review tools are actually optimizing for, and the data is generated for free as a byproduct of running the tool.

The Org Failure Mode

The technical patterns above are necessary and not sufficient. Most AI code review programs that fail do so for organizational reasons that no architecture can route around. The reviewer agent goes live, posts a hundred comments per PR for the first week, engineers learn to scroll past them, and within a month the bot is wallpaper. The fix is not a better prompt; it is a precision floor enforced upstream. If the team is not willing to ship a reviewer that comments on fewer than half the PRs it reads — because the threshold for posting is "I have a specific, falsifiable concern" rather than "I noticed this diff exists" — the bot will be ignored and the question of whether it actually catches bugs becomes academic.

The deeper failure is the one the asymmetry argument predicts: organizations that ship AI code into AI-reviewed pipelines are running an experiment whose null hypothesis ("this catches what matters") was never tested against the hardest case ("the author and the reviewer share blind spots"). The teams that get this right do three things in sequence — they cross-family the reviewer, they instrument it with planted bugs and historical replays, and they enforce a precision discipline that treats every false positive as a bug in the reviewer rather than a cost of doing business. The teams that don't will discover, eventually, that the green checkmark on their PRs has been provided by a system optimized to produce green checkmarks, and the bug count that was supposed to fall has been falling into a different column of the dashboard.

The shape of code review is changing. The cognitive labor that used to be done by the senior engineer reading the diff at 4pm is being decomposed into specification checks, invariant probes, and adversarial passes — each running cheaper, faster, and more consistently than a human reviewer could. None of that decomposition fixes the fundamental constraint: a review pipeline whose author and reviewer are statistically identical is a confidence machine, not a quality gate. The architecture has to be asymmetric on purpose, or it is not really review at all.