- In short
- The per-file and cross-file pass pattern is a two-phase multi pass code review technique. Phase one runs a focused analysis pass per file for consistent local depth; phase two runs a separate cross-file integration pass to catch data-flow and dependency issues that span files.
What a multi pass code review pattern looks like
The per-file and cross-file pass pattern is the concrete implementation you reach for once you understand the attention dilution problem. Where that knowledge point teaches you to recognise uneven depth across many files, this one teaches you to build the fix. It is an apply-level skill: given a review or audit over many files, structure it as two deliberate phases so that quality is both consistent and complete.
A multi pass code review splits into phase one, the per-file local analysis, and phase two, the cross-file integration analysis. The two phases answer two different questions. Phase one asks, "is each individual file correct on its own terms?" Phase two asks, "do the files behave correctly together?" Neither phase can answer the other's question, which is exactly why you need both.
- Per-file and cross-file pass pattern
- A two-phase implementation for analysing many files. Phase one: a focused per-file pass that gives each file consistent local depth. Phase two: a single cross-file integration pass that inspects only the relationships between files. Together they restore uniform quality and catch issues no single overloaded pass could find.
Phase one: per-file local analysis
In phase one you run a separate, focused pass for each file rather than dumping all of them into one prompt. Because each pass sees a single file, the model can apply the same checks at the same depth every time. There is no large input across which attention can thin out. The output of phase one is a per-file set of findings: the local bugs, style issues, and validation gaps that live entirely inside one file.
A clean way to run these passes is to delegate each to a subagent that works in its own context window and returns only its findings. Anthropic's Claude Code subagents are built for exactly this kind of focused, isolated work, and Anthropic's parallelization workflow describes the same sectioning idea, breaking a task into independent subtasks so each gets full focus. The key property to preserve is isolation: file A's pass should not be competing for attention with files B through Z.
Phase two: the cross-file integration pass
Phase one deliberately blinds itself to everything outside the current file, which means it cannot see problems that only exist between files. That is the job of phase two. The cross-file integration pass takes the structural relationships, call graphs, shared data structures, module boundaries, and looks specifically for issues that span them: a function whose contract one caller violates, a data-flow path that loses validation as it crosses a boundary, a dependency cycle, a helper defined once and misused elsewhere.
Phase two is not a repeat of phase one at larger scale; it is a different analysis with a different target. You feed it the interfaces and relationships, often summarised from phase one's findings, rather than re-reading every line of every file. Skipping this phase is the single most common implementation error for the pattern, and it is the exam trap for this knowledge point: a review that only does per-file analysis will confidently pass code that is locally fine but globally broken.
Choosing the granularity of a pass
The pattern says "per-file," but the deeper principle is "per unit small enough for consistent depth," and choosing that unit is part of applying it well. For most code reviews a file is the right grain, small enough that one pass attends to all of it, large enough to be a meaningful unit. But the grain is a decision, not a law. A four-thousand-line file may itself be too large for a single consistent pass, in which case phase one chunks it further, per class or per function, before the cross-file phase runs. Conversely, a directory of tiny related files might be grouped into one pass without diluting anything. The test is always the same: is each pass small enough that the model can treat all of it with uniform depth?
Granularity also governs the integration phase, which needs the right unit of relationship to reason about. Feed it raw source and you recreate dilution; feed it nothing but a list of filenames and it has too little to find anything. The sweet spot is the aggregated interface summary from phase one, each unit's exported surface, the data it consumes and produces, the shared state it touches. That summary is dense enough to expose mismatched contracts and broken data flows, yet small enough that the integration pass keeps consistent depth across the whole relationship map.
Because the per-file passes are independent of one another, they parallelise naturally. There is no ordering dependency among them, so they can run concurrently, and only the integration phase has to wait for all of them to finish. This is the same sectioning idea Anthropic describes under parallelization: break a task into independent subtasks, run them simultaneously, then combine. The two-phase pattern is therefore not only a quality technique but a throughput one, and on a large review the gap between sequential and parallel per-file passes can be substantial. The discipline that keeps it safe is genuine isolation, so concurrency never lets one file's context bleed into another's.
Wiring the two phases together
Implementing the pattern is mostly about what flows between the phases. Each per-file pass emits two things: its local findings and a compact description of that file's outward-facing interface, the functions it exposes, the shapes it consumes and returns, the globals it touches. Your code aggregates those interface summaries and hands them to the cross-file pass, which now has a map of how the files connect without having to re-ingest all of their source.
This is why the pattern composes naturally with a fixed sequential pipeline: the phases run in a known order, phase two depends on phase one's output, and you can place a checkpoint between them. It is a structured, predictable shape, which is appropriate, because the decision to use a multi-pass split in the first place comes from choosing a decomposition strategy when input volume threatens consistency.
A small but important property of the seam is idempotence. Because phase two consumes a derived artifact, the aggregated interfaces, rather than live source, you can re-run the integration pass without re-running every per-file pass, which matters when you are tuning what the integration phase looks for. Equally, if one file changes, you re-run only that file's per-file pass and refresh its interface entry before re-running integration, rather than redoing the whole review. Treating the interface aggregate as a cached intermediate is what makes the pattern cheap to iterate on, and it is only possible because the two phases are cleanly separated.
Consolidating findings into one report
Splitting a review into many passes leaves you holding many separate result sets: one batch of local findings per file, plus the cross-file findings from phase two. A multi pass review is not finished until those are merged into a single, de-duplicated, prioritised report, and the merge is where the pattern either delivers signal or buries it. The same issue can surface in more than one pass, so consolidation has to collapse duplicates rather than report one bug three times, and it has to rank what remains by severity so the reader meets the load-bearing problems first.
The merge is also where you manage false positives, the natural cost of running many independent passes. Because each pass sees only its own slice, a few flagged issues turn out to be harmless once the wider context is known, so a robust implementation has each pass attach a confidence level to its findings and uses the consolidation step to filter or down-rank the low-confidence noise. The goal is a report a human will actually trust: high-signal, ordered by severity, with every finding traceable back to the pass that raised it. Skipping consolidation, or letting it collapse into a raw concatenation of every pass, gives back much of the quality the split was meant to buy.
Worked example
An architect must build an agent that reviews a 20-file service where a previous single-pass reviewer kept missing issues in the middle of the batch.
The architect implements the per-file and cross-file pass pattern directly.
Phase one runs twenty isolated passes, one per file. Each pass applies the same review rubric, input validation, error handling, naming, dead code, to exactly one file, so file 11 gets the same scrutiny as file 1. Each pass returns its local findings plus a short interface summary: for auth.py, that it exposes verify_token(token) -> User and reads the SESSION_SECRET global. Running these as subagents keeps each pass in its own context, so none of the twenty dilutes the others.
One file forced a granularity decision. ledger.py ran past three thousand lines, large enough that a single pass over it risked the very dilution the pattern exists to prevent, so the architect chunked phase one further for that file, one pass per major class, and merged their findings before recording its interface. Every other file stayed at file grain. That judgement, picking a unit small enough for consistent depth, is the part of applying the pattern that a rote "one pass per file" rule would have missed.
The code aggregates the interface summaries into a single relationship map and starts phase two. The cross-file integration pass is given that map, not the raw 20 files, and asked one question: where do these files interact incorrectly? It finds that billing.py calls verify_token but treats the returned User as a plain dictionary, a contract mismatch invisible to either file's local pass. It also spots that SESSION_SECRET is read in auth.py but written nowhere, a cross-file gap.
Had the architect stopped after phase one, the tempting shortcut, the review would have reported twenty clean files and shipped a broken integration. The cross-file pass is what turns consistent local analysis into a complete review, and building both phases is the apply-level skill being tested.
Common misconceptions
Misconception
Once every file has had its own thorough per-file pass, the review is complete.
What's actually true
Misconception
The cross-file pass should just re-read all the files together to find the remaining issues.
What's actually true
How this shows up on the exam
This knowledge point is apply-level, so questions describe a multi-file review or audit and ask you to structure it, or they describe a partial implementation and ask what is missing. The most frequent correct answer is some form of "run focused per-file passes, then a separate cross-file integration pass," and the most frequent trap is an option that does only the per-file half and calls the review complete. Watch for stems where local analysis is thorough but a cross-file bug, a mismatched interface, a broken data-flow contract, slips through; the fix is always to add the integration pass, never to make the per-file passes larger. Recognising that the two phases answer two different questions is what lets you both build the pattern and spot when half of it is missing.
An agent reviews a 15-file module by giving each file its own focused pass and aggregating the findings. In production it still ships a bug where one module returns a timestamp in seconds while a caller in another file expects milliseconds. What is the correct fix?
People also ask
What is the per-file and cross-file pass pattern?
Why do you need a separate cross-file pass?
What happens if you skip the cross-file integration pass?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
9 Parallel AI Agents That Review My Code (Claude Code Setup)
Why watch: Demonstrates splitting a code review across multiple focused passes (each agent covering a specific aspect/slice) and merging findings, the practical embodiment of the per-file local analysis plus integration pass pattern that defeats attention dilution.
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.