Multi-Pass Review for Large Multi-File Changes

1.Why one giant review pass underperforms

Anthropic's context-engineering post calls this effect context rot: the more tokens in the context window, the worse the model recalls information from it. The post explains that each token attends to every other token, so as context grows, the model's grip on those relationships gets stretched thin. The result is a performance gradient rather than a cliff. In its words, "Context, therefore, must be treated as a finite resource with diminishing marginal returns."

For review, this means a single pass over a whole multi-file change spreads the model's attention across everything. A subtle issue in file 31 gets less of it than it would in a focused pass. Claude Code's best-practices guide gives the operational version: "Long sessions with irrelevant context can reduce performance." Every other file in the diff is mostly irrelevant context when you're looking for a local bug in one file. That's the case for splitting the review.

The exam objective also ties one giant pass to contradictory findings, not only to missed ones. The sources don't spell out a mechanism for contradictions beyond attention being stretched thin across a large context. What they do document is the remedy: after focused passes, a reconciliation step deduplicates and ranks the findings so the report is coherent. The next section covers that step.

Sources12

2.Per-file passes, then a merge across files

The multi-pass pattern has two stages. First, a focused pass reviews each file for local issues. Second, a separate step combines those per-file results into one coherent report. Claude Code's dynamic workflows document this shape directly. An example request reads: "use a workflow to review every file changed in this PR for correctness issues, then merge the per-file findings into one ranked summary." Each per-file pass works with a small context, and the merge step deals with what no single pass can: duplicates and ranking across the whole change. Code Review's reconciliation does the same, deduplicating findings and ranking them by severity.

When there are too many files to hand out one at a time in a conversation, fan out. The best-practices guide's recipe is to generate a task list, loop through it with a script that calls claude -p once per item, and "Test on a few files, then run on all of them." A workflow does the same inside Claude Code: it lists the files, then runs one agent per file. Each agent is its own session, so files don't share context and none of them dilutes another's attention.

A per-file pass sees one file, so it cannot see how data moves between files. A merge doesn't fix that. It reconciles and ranks findings that already exist; it doesn't trace anything. Cross-file data flow needs its own analysis. Claude Security describes this capability: it "traces data flows across files" and identifies multi-component vulnerability patterns. The exam guide frames it as a separate integration pass that follows the per-file passes. The sources here don't give an input format or prompt for that pass, so the key point is the division of labor. Per-file passes find local issues, an integration pass examines cross-file data flow, and the merge deduplicates and ranks.

const audits = await pipeline(found.files, file =>
  agent(`Audit ${file} for missing authentication checks.`, { label: file }),
)

Sources314

3.Parallel specialist passes plus a verification pass

Passes can be split by concern as well as by file. This is a different axis from the per-file plus cross-file split above: per-file passes divide the change by where the code is, while specialists divide it by what kind of problem they hunt. The Agent SDK notes that during a code review you can run style-checker, security-scanner, and test-coverage subagents simultaneously instead of one after another. Since they run concurrently, the whole review takes as long as the slowest one, not the sum of all of them.

Claude Code's managed Code Review product puts these pieces together with a verification pass at the end. When a review runs, multiple agents analyze the diff and surrounding code in parallel, and each agent looks for a different class of issue. Then a verification step checks results against actual code behavior to filter out false positives. The surviving findings are deduplicated, ranked by severity, and posted as inline comments. That assurance has a cost. Reviews scale in cost with PR size and complexity and take 20 minutes on average, and Code Review usage is billed separately through usage credits. You can build the same thing yourself with a workflow, for example one that audits every route handler for missing authentication checks and "adversarially verify each finding before reporting it."

Sources563

4.Self-reported confidence and review routing: what the sources cover

The exam guide adds one more technique: the model reports its confidence alongside each finding, so findings can be routed by how sure the model is. The prompting guides for Claude Opus 4.8 and Sonnet 5 document the finding-stage prompt for this. It tells the model to report everything, including uncertain items, and to attach a confidence level and an estimated severity to each finding, so that a separate downstream step can filter and rank. The guides add that moving confidence filtering out of the finding step often helps, and that you should tell the model its job at that stage is coverage, not filtering.

The sources don't give numeric confidence thresholds or a routing table, so don't invent any. What they do show is the downstream step. In the vulnerability-detection cookbook, triage is a fresh query that re-reads the code, verifies each finding against the actual lines, and collapses duplicates. It deliberately re-derives severity instead of inheriting the finder's scores, which is "a cheap way to catch overconfidence." Confidence and severity are different signals: severity says how much an issue matters, and confidence says how sure the reviewer is that it is real.

Report every issue you find, including ones you are uncertain about or consider low-severity. Do not filter for importance or confidence at this stage - a separate verification step will do that. Your goal here is coverage: it is better to surface a finding that later gets filtered out than to silently drop a real bug. For each finding, include your confidence level and an estimated severity so a downstream filter can rank them.

Sources678

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.If the whole multi-file diff fits in the context window, one review pass is as good as several focused passes.Why is that wrong?

   Recall and long-range reasoning lose precision as context grows, so focused per-file passes keep each review sharper.

   Covered in Why one giant review pass underperforms

2. 2.Once specialist agents have found an issue, a separate verification pass is redundant.Why is that wrong?

   Code Review runs a verification step after the specialist agents specifically to filter out false positives before findings are posted.

   Covered in Parallel specialist passes plus a verification pass

3. 3.Severity ranking and confidence scoring are the same signal.Why is that wrong?

   Code Review tags findings by severity, which is how much an issue matters. Filtering out unsupported findings is a separate verification job.

   Covered in Self-reported confidence and review routing: what the sources cover