AI Reviewing AI: A Filtered Pipeline of Specialists Is a Quality Gate, Not a Governance Model

Two companies run AI code review at production scale, and both converged on the same design: not one model reading a diff, but a pipeline of specialist sub-agents with aggressive filtering behind them. At Intercom, over 19% of PRs are auto-approved with no human in the loop. At Uber, uReview processes over 10,000 commits a week and engineers mark 75% of its comments useful.

One reviewer becomes a dozen specialists

Neither system treats review as a single task, because no single reviewer, human or model, covers every dimension of a PR under time pressure. Intercom decomposes review into independent sub-agents: one assesses the quality of the problem description, one checks whether the diff matches the stated intent, others cover safety concerns, logical correctness, and best practices against known anti-patterns. The effect, in their words, is that every PR is reviewed "as if a dozen of our most tenured and knowledgeable engineers were all looking at it simultaneously."

Uber built the same shape as a pluggable assistant framework. Three assistants run today: a Standard Assistant for bugs, incorrect exception handling, and logic flaws; a Best Practices Assistant that enforces Uber conventions against a shared registry of style rules; and an AppSec Assistant for application-level security vulnerabilities. Each assistant has its own prompts, its own context, and its own evaluation, so each lens improves independently. That is the mechanism: decomposition turns "review quality" from one untunable blob into a set of components you can measure and fix one at a time.

The agent reads the codebase, not the diff

A human reviewer reads the changed lines. The agent traces where the change goes. Intercom's reviewer "traces execution paths, following the implications of a change through the codebase," which humans "rarely had time to do, even when they wanted to." Their canonical example: the agent flagged a one-line text copy change as incorrect because the new copy contradicted a validation mechanism elsewhere in the codebase. Their claim is not that no human could ever catch it. It is that the system makes this kind of tracing routine instead of exceptional. It performs the part of review humans systematically skip.

Raw model output is unusable; the filter pipeline is the product

Uber's blunt lesson: single-shot prompting was not enough, even with strong models. Unfiltered output produced hallucinated issues, duplicate suggestions, and inconsistent quality, and a high false-positive rate trains engineers to tune the tool out. So uReview chains four stages: comment generation, a secondary grading prompt that scores each comment's confidence (thresholds set per assistant, per language, per category), a semantic similarity filter that merges overlapping suggestions, and a category classifier that suppresses comment types with historically low developer value. Their benchmark found the best configuration paired Claude-4-Sonnet as the generator with OpenAI o4-mini-high as the grader, beating GPT-4.1, o3, o1, Llama-4, and DeepSeek R1 setups on F1.

The suppression data is specific. Readability nits, minor logging tweaks, and stylistic comments consistently received poor ratings; correctness bugs, missing error handling, and best-practice violations with links to internal docs scored well.

Feedback makes the reviewer company-specific

Both systems are grounded in guidance the company's own engineers wrote, and both feed ratings back into it. Intercom's reviews encode Intercom-specific standards; engineers flag whether each review comment helped, and that feedback sharpens the guidance. Uber embeds Useful / Not Useful links in every comment, streams all comment metadata to Hive via Kafka, and automatically checks whether a comment was addressed by re-running uReview five times on the final commit. The loop pays for itself: uReview returns feedback within a median of 4 minutes of a commit being posted, across all six of Uber's monorepos, saving roughly 1,500 reviewer hours weekly, about 39 developer years annually. One fence on the volume figure: Uber's post states the diff count as roughly 65,000 weekly in one place and 65,000 monthly in another; the unambiguous number is the 10,000+ commits per week uReview processes after excluding config files.

A better reviewer raises the bar at the gate; it does not decide who is accountable

Three boundaries, all stated by the companies themselves:

And one gap the field is silent on: whether the reviewing model should be deliberately independent of the authoring model. Uber's grader differs from its generator because that combination won on F1, not as an independence policy; Intercom has Claude writing code that an AI pipeline then approves. The segregation-of-duties question lives at the gate, not in the reviewer. The other decision-gate controls in this act pick up where this page stops: review as a gate for what a gate must guarantee, accountability stays human for who owns the outcome after approval, and auto-approval by risk for which changes the reviewer may approve alone. The full Intercom write-up is at AI PR review.