From Prompt to Platform: Why Modern AI Code Review Needs an Architecture¶
When most people imagine an AI code reviewer, they picture a single prompt: hand the model a pull request, ask for a review, read what comes back. For small changes, that works surprisingly well — which is what makes the failure on larger ones interesting. As a pull request grows, the model starts losing context. Behavioral defects become harder to find. Security, correctness, architecture, and testing all compete for the same limited attention, and the review quietly becomes shallower even though the model hasn't changed.
I wrote recently about the correctness problem in AI code review, and ended with a suspicion: that the next generation of reviewers would be defined less by larger models than by harnesses built around them. This article is my attempt to describe what I think that harness looks like. Because the limitation I keep running into isn't model intelligence.
It's architecture.
Rather than treating code review as a single LLM call, I've started thinking of it as a pipeline of narrow responsibilities — something closer to a distributed system than a prompt.
Figure 1. A multi-agent architecture for AI-assisted code review. Each stage has a single responsibility: discover context, perform specialized analysis, verify findings, score results, and present evidence-backed recommendations.
What one prompt is being asked to do¶
The first generation of AI code reviewers looked something like this:
It's elegant, it's simple, and for many changes it's genuinely sufficient. But look at what that single call is being asked to do. The model must understand the system while simultaneously judging the change to it. Every concern — security, correctness, architecture, testing, maintainability — competes for the same limited reasoning capacity. Context discovered while investigating one finding is discarded rather than shared with the next. And every review begins from zero.
None of those are failures of intelligence. They are consequences of putting an entire review inside one call. The architecture in Figure 1 separates the review into stages so that no single call has to solve every problem at once.
Discovery: context before judgment¶
Before asking whether the code is correct, the pipeline first asks a different question: what changed, and what parts of the system does it affect? The Discovery Agent doesn't review code at all. It traces dependencies, follows data flow, maps inputs and outputs, and identifies the execution paths the change actually touches. Its output is a shared context package handed to every downstream reviewer.
That has an obvious efficiency benefit — no specialist repeats the same exploratory work — but the more important effect is that judgment starts from an understanding of the system rather than being formed alongside it.
Specialists: one concern at a time¶
Once discovery is complete, multiple specialist reviewers analyze the pull request independently, each focused on a single engineering concern: correctness, security, architecture, maintainability, testing. Rather than asking one prompt to balance every engineering discipline simultaneously, each specialist reasons deeply within its own domain.
In my experience this produces more consistent findings, and it has a quieter architectural benefit: each reviewer can evolve independently. The correctness reviewer can get better without disturbing the security reviewer, in exactly the way separately owned services can.
The challenger: findings are hypotheses¶
The most important principle in the whole design is that AI findings are hypotheses until verified. Instead of publishing what the specialists report, a challenger stage attempts to invalidate it. Is the execution path actually reachable? Does the evidence support the claim? Is the behavior genuinely incorrect, and is the severity proportionate? Could an independent reviewer reproduce the finding from the source?
This stage exists because of a lesson from the benchmarking that prompted the previous article: the models were remarkably confident, and confidence was only weakly correlated with whether a finding was real. Verification is the stage that acts on that lesson. What survives the challenger is closer to evidence than prediction.
Scoring: quality and readiness are different numbers¶
I've already written about why collapsing a review into one score fails: a pull request can be beautifully designed, thoroughly tested, highly readable — and contain a verified bug that should block deployment. A weighted average lets the quality dimensions outvote the defect. Engineering quality and release readiness are different measurements, so the scoring stage keeps them apart: rubric-based quality assessment on one axis, verification evidence combined with a deterministic review policy on the other. The published review can then say both how well the software is built and whether it appears safe to ship, without either answer hiding the other.
The published review¶
Only at the end does anything reach the developer, and by then it is no longer a list of observations. The report contains verified findings with their supporting evidence, remediation guidance, rubric scores, and enough audit information to reconstruct how each conclusion was reached. The objective isn't to generate comments.
It's to produce findings a developer can trust — and check.
What a pipeline doesn't solve¶
I should be honest about the limits of this design. A pipeline is slower and more expensive than a prompt, and every additional stage is another place for the system to fail. More fundamentally, the challenger can only test findings that exist: it filters out false positives, but it recovers no false negatives. Five specialists can still collectively miss the defect none of them was asked to look for, and no amount of verification will surface it afterwards.
And none of this removes the human decision. The pipeline explores, analyzes, and verifies — engineers still decide whether software ships. The architecture isn't intended to replace reviewers. It's intended to hand them better evidence than a single confident prediction.
The part we get to design¶
Early AI code reviewers were essentially prompts. The ones I'm learning to trust are becoming systems: systems that discover context before reasoning, verify their own conclusions, and keep evidence separate from confidence. What I like most about this shift is the question it changes. "Which model is best?" was never a question engineers could do much with — the answer changes every few months, and none of us controls it.
"How should we architect AI systems that engineers can trust?" is different.
Models will keep improving on their own schedule. The architecture is the part we get to design.