- In short
- A multi pass code review architecture replaces one sweep over a whole change set with several focused passes: a per-file local pass that analyses each file at consistent depth, and a separate cross-file integration pass that checks data flow and contracts between files. Splitting the work this way keeps each pass within the model's effective attention and prevents the uneven quality of a single pass.
What a multi pass code review actually is
A multi pass code review is a way of organising automated review so that quality does not collapse as the amount of code grows. Instead of handing the model an entire pull request and asking for one verdict, you run several deliberately narrow passes. The first kind is a per-file local pass: each file is analysed on its own, with the same depth of scrutiny applied to every file regardless of how many there are. The second kind is a cross-file integration pass that ignores within-file detail and instead asks how the files interact, where data flows between them, and whether the contracts they share still hold. This knowledge point lives in Domain 4, and it is fundamentally about applying structure to beat a limitation, so the exam tests it at the apply level rather than as recall.
The reason a multi pass code review beats a single sweep is mechanical. A model has a finite budget of effective attention, and when one prompt asks it to hold twenty files in mind at once, that budget is spread thin. The work degrades unevenly: the files it considers early often receive careful analysis, while the files it reaches later receive a cursory glance. By the time it summarises, its judgement is an average of deep and shallow looks, and the shallow ones are where defects hide.
- Multi pass code review architecture
- A review design that replaces one sweep over a whole change set with multiple focused passes: per-file local passes that analyse each file at consistent depth, plus a separate cross-file integration pass that checks data flow and shared contracts between files.
Attention dilution is the problem this design solves
The failure mode that justifies the whole architecture is attention dilution. When a review prompt is overloaded with files, the model cannot give each one its full consideration, so the effective quality per file drops as the count rises. This is not the model being lazy or random; it is a predictable consequence of asking one inference to do too much at once. You can observe it directly: ask for a review of three files and the analysis is thorough; ask for the same review across thirty and the later files are summarised rather than examined.
Anthropic's own prompt-engineering guidance recommends chaining prompts precisely to counter this, decomposing a task into a sequence of smaller steps so that each call processes a more manageable input and gets full attention. A multi pass review is that principle applied to code: the per-file pass is the decomposition, turning one impossible request into many tractable ones. Because each file becomes its own focused task, the per-file pass delivers consistent depth no matter how large the change set is, which is the property a single pass can never guarantee.
The per-file local pass
The per-file local pass treats each file as an independent unit of work. For every file in the change, the model receives that file (and just enough surrounding context to make sense of it) and a fixed set of review criteria, then reports issues found within that file. Because the input is small and the task is the same every time, the depth is uniform: the hundredth file is examined as carefully as the first. This pass is excellent at local defects such as a function that mishandles an edge case, a null that is never checked, an off-by-one error, or a violation of a coding standard. What it cannot do, by construction, is see beyond the file in front of it.
That boundary is a feature, not a gap. By refusing to think about other files, the local pass stays focused and cheap, and it produces findings that are easy to attribute because each one is tied to a specific file. The exam likes this clarity: it wants you to know that the per-file pass owns within-file correctness and consistent depth, and that asking it to also reason about system-wide interactions would reintroduce the very dilution you split the work to avoid.
The cross-file integration pass
The cross-file integration pass is the deliberate complement. It does not re-examine the internals of each file; it looks at the seams. Its job is to catch the defects that only exist in the relationship between files: a function whose signature changed in one file but whose callers in other files were not updated, a data shape produced in one module and consumed incompatibly in another, a renamed configuration key referenced by an old name elsewhere, or an assumption about ordering that two files disagree about. None of these are visible when you read a single file in isolation, which is exactly why the per-file pass will never find them.
By giving integration its own pass, you let the model adopt a different and narrower lens: contracts and data flow rather than line-by-line logic. The input is the set of interfaces and the way values move between files, not the full body of every function, so this pass also stays within a manageable attention budget. Together the two passes cover the space completely: local correctness from the per-file pass, and system coherence from the cross-file pass, with neither asked to do the other's job.
Designing the passes in practice
Applying this architecture means making a few concrete decisions. You decide the unit of the local pass (usually one file, sometimes one function for very large files), the fixed criteria each local pass enforces, and how surrounding context is supplied without bloating the input. For the cross-file pass you decide what counts as an interface worth checking: exported functions, shared types, configuration keys, database schemas, and message formats are common choices. You then merge the findings from both passes into a single report, deduplicating where a local and a cross-file finding point at the same root cause.
The order matters less than the separation. Some pipelines run the local passes first and feed a summary of each file into the cross-file pass; others run them independently and merge at the end. What the exam cares about is that the two concerns are not collapsed back into one prompt. The moment you ask a single pass to review every file deeply and reason about all their interactions, you have rebuilt the diluted single-sweep review you were trying to escape, and the uneven quality returns.
Decomposing passes by concern, not only by file
Splitting by file is the most common axis, but it is not the only one. The same attention-dilution logic says that asking a single pass to judge security, performance, maintainability, and edge cases all at once spreads the model thin across unlike concerns, so a focused pass per concern can raise signal the way a focused pass per file does. A security pass looks only for injection, authentication gaps, and unsafe data handling; a performance pass looks only for needless work, repeated queries, and allocation in hot paths; a maintainability pass weighs naming, duplication, and structure; an edge-case pass probes nulls, empty inputs, and boundary values. Each pass carries a narrow rubric and gives that rubric its full attention.
The two axes compose. A large change can be reviewed per file for local depth and then by concern across the whole change for issues a file-by-file lens flattens together. However you slice it, the passes have to be consolidated into one ranked report, and a common practice is to tier findings by severity: critical issues that must be fixed before merge, then high, medium, and low, so a developer reads the most important problems first. The discipline is identical to the per-file and cross-file split, namely one focused task per pass and then a deliberate merge, rather than one overloaded sweep trying to do everything at once.
How this is tested on the Claude Certified Architect exam
Task statement 4.6 asks you to design multi-instance and multi-pass review architectures, and this knowledge point is the multi-pass half. It appears in Scenario 5, Claude Code for Continuous Integration, where a review job is expected to give every changed file the same scrutiny. Expect a scenario where reviews of small pull requests are excellent but reviews of large ones miss defects in the files that were changed last, and you are asked to explain the cause and propose a structure. The cause is attention dilution; the structure is a per-file local pass plus a separate cross-file integration pass.
Distractors usually offer to fix the single sweep by adding stern instructions, raising a token limit, or retrying. Those do not address the underlying spread of attention across too many files. The right answer applies the decomposition: give each file its own focused pass for consistent depth, and add a dedicated pass for the interactions that no single-file view can reveal.
Worked example
A CI review job for a refactor that touches twelve files passes review, but two files changed late in the set ship a bug, and a renamed function breaks a caller in a file that was not flagged at all.
The original job sent all twelve files to one Claude call and asked for a complete review. The first few files were analysed carefully, but by the eleventh and twelfth the model was summarising rather than examining, so a mishandled edge case in file eleven slipped through. Worse, a function renamed in file three still had a caller using the old name in file nine, and because no single file contained both ends of that mismatch, the single sweep never surfaced it.
Redesign it as a multi pass code review. First, a per-file local pass runs once per file with identical criteria, so file twelve gets the same depth as file one and the edge case in file eleven is caught. Then a cross-file integration pass receives only the changed signatures and the places they are used, notices that the renamed function in file three is still called by the old name in file nine, and flags the broken caller.
The same model and the same criteria now find both defects, because neither pass was asked to do more than its attention could support. The per-file pass guaranteed uniform local depth, and the cross-file pass gave the rename mismatch a place to be seen. That division of labour, not a stronger prompt, is what made the review reliable.
The cost of running multiple passes
Splitting review into many passes is not free, and a complete answer acknowledges the trade-off. Running a separate per-file pass for every file means more model calls than a single sweep, which costs more tokens and adds latency, and the cross-file pass is an additional call on top of those. For a small change the overhead can outweigh the benefit, so a pragmatic pipeline applies the full multi-pass structure only above a threshold of files or lines and falls back to a single focused pass for trivial diffs.
The point is that multi-pass review buys consistent depth and interaction coverage at the price of more inference, and you choose to pay that price when the change is large enough for attention dilution to bite. Recognising when the structure earns its cost, rather than applying it blindly to every review, is part of designing it well, and it is precisely the kind of judgement the apply-level questions in this task statement reward. An architect who can say not just how the passes work but when they are worth running has understood the knowledge point fully.
Misconceptions to avoid
Misconception
A single thorough prompt over all the files gives uniform quality if you just tell the model to be careful with every file.
What's actually true
Misconception
The per-file pass and the cross-file pass are redundant, so one of them can be dropped.
What's actually true
An automated review gives small pull requests excellent feedback but consistently misses defects in the files changed last on large pull requests. Which architectural change best fixes this?
People also ask
What is a multi pass code review?
Why split review into per-file and cross-file passes?
What is attention dilution in code review?
Is a single pass over all files reliable?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Anthropic's NEW Claude Code Review Agent (Full Open Source Workflow)
Why watch: Walks through Anthropic's code review agent workflow where the diff is analysed in distinct passes, illustrating how separating analysis stages prevents shallow single-pass review.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.