Skip to lesson

AnthropicClaude Certified Architect – Foundations2026-104.6 Design multi-instance and multi-pass review architectures

Partition large reviews to prevent attention dilution

Completed by the knowledge check

Learning objective

Split large reviews into focused per-file analysis and separate cross-file integration and data-flow checks.

Core idea

A large diff fitting into a context window does not establish that one review will examine every file equally well. Anthropic’s Claude Code best practices warn that performance degrades as context fills. The exam guide’s task statement 4.6 applies that concern to review: split local analysis from cross-file integration so uneven attention does not produce omissions or contradictory findings.

A per-file pass asks whether the implementation in one file has a defect. An integration pass asks whether the changed pieces still work together. The second question requires evidence from both sides of an interface. More per-file reviews cannot replace that evidence, even if each local result is correct.

See 1.6.2 for building the local-to-integration chain; this lesson covers when a large review needs partitioning and how to combine what the passes report.

This is a review design you can implement with focused Claude invocations. It is not a claim that Anthropic’s managed Code Review service partitions work exactly one agent per file. Its documented pipeline specializes agents by issue class, then verifies, deduplicates, and ranks findings.

How it works

Partition the analysis when coverage becomes uneven

Look for uneven review depth rather than choosing a universal file-count threshold. If the first files receive specific path-based analysis while later files receive only a general verdict, the review has not demonstrated comparable coverage. If repeated operations receive contradictory findings, determine whether the input guards differ or the reviewer applied different criteria. These symptoms motivate narrower passes even when every file fits in the window.

Anthropic documents fan-out across files by looping over claude -p invocations for large analyses. Apply that mechanism to a review task list: each invocation receives one changed file, its diff, enough surrounding implementation to interpret that diff, and the shared requirements and defect criteria. Keep these review sessions independent of the authoring history; see 4.6.1.

Ask the local reviewer to check control flow, boundary conditions, local validation, and error handling that the supplied code can establish. A division by a count without handling zero is a local candidate. A missing return after an error branch is another. Require the finding to name the relevant code location and explain the triggering condition; see 4.2.3 for actionable findings.

Use the same defect criteria for equivalent local tasks. Otherwise inconsistent verdicts can reflect different instructions rather than insufficient attention. If two files contain the same operation, compare whether their surrounding guards or reachable inputs differ before treating their findings as contradictory.

Keep the same meaning of a reportable defect across passes. For example, the shared zero-count criterion can require a reachable zero input and no effective guard before the division. One pass should not flag every syntactic division while another flags only reproducible failures. That mismatch creates contradictory reports even if both reviewers have enough context. See 4.1.1 for defining the inclusion criteria.

A per-file task is focused, not forbidden from reading supporting code. If an imported helper determines whether a branch is reachable, give the reviewer that helper or ask it to inspect the relevant definition. Do not expand every local task into a complete repository review. Record unresolved cross-file questions for the pass that owns integration.

Preserve endpoint evidence for integration

See 1.6.2 for the integration assignment and evidence handoff. Keep the endpoint-evidence rule explicit: a reviewer that sees only the producer cannot certify the consumer’s behavior. Supply the other endpoint or keep the question unresolved; local findings alone do not establish the cross-file contract.

For an inventory change, the supplier adapter can return cases while the reorder comparison expects individual items. Both implementations can appear plausible locally. The integration pass needs those endpoints and the intervening representation to check where quantity changes meaning.

Combine candidates without voting away defects

After the local passes complete, use their findings to inform a separate integration invocation. Independent local tasks can run in parallel because one file’s analysis does not require another file’s verdict. An integration pass that consumes those verdicts waits for them; its need for cross-file code remains regardless of scheduling.

Merge candidates by the defect they describe, not merely by a shared line number. Two reviewers can describe the same unit conversion error from different endpoints. Conversely, two separate zero-count failures can require separate fixes even if their wording is identical. Preserve the evidence for each distinct candidate before verification; see 4.6.3.

Candidates from the local passes and the integration pass are merged by defect, and every distinct candidate goes on to verification.

Candidates from every pass are merged by defect, and each distinct candidate goes on to verificationStarts at two independent local tasks, which run in parallel, and the separate integration invocation. The candidates from both are merged by the defect they describe, with no vote between passes, and each distinct candidate goes on to verification.Run in parallelcandidatescandidateseach distinct candidateLocal taskLocal taskIntegrationinvocationMerge by defectVerification

Do not require majority agreement to retain a finding. A cross-file defect might be visible only to the integration pass, and a rare local path might be noticed by only one focused reviewer. Disagreement is a reason to inspect code behavior, rather than count which verdict is more popular.

When merging apparently conflicting reports, preserve their conditions. A local pass might report a possible zero count while the integration pass identifies a caller that guards that count. Send the candidate and the guard to verification rather than reporting two incompatible conclusions. Conversely, a guard in one caller does not establish that all callers enforce it. Reconcile the evidence at the scope of the claimed defect.

Measure the partitioned review against the failures that justified it: did both reachable zero-count paths receive analysis, did the verdicts use the same criterion, and did integration inspect the quantity mismatch? More invocations alone do not establish improvement. The architecture is useful when its focused questions cover the previously uneven or missing analysis.

Key distinctions and trade-offs

Context capacity versus review focus: A larger window can make more code available. It does not prove that a single pass covers each file with consistent depth. Partition the analysis when the observed problem is uneven coverage.

Local validity versus composed validity: A function can correctly implement its own assumptions while a caller violates them. Integration reviews the agreement between those assumptions, including data units and error semantics.

Custom fan-out versus managed Code Review: Your script can assign one claude -p task per file and a separate integration task. Managed Code Review documents parallel agents looking for different issue classes, followed by verification and deduplication. It is in research preview for Team and Enterprise subscriptions. It is unavailable with Zero Data Retention or HIPAA configuration and is not covered by Anthropic’s BAA. Do not equate the two architectures.

Focused calls add invocation and orchestration cost, and shared context may be repeated. They also make missing coverage visible: you can identify which local task ran and which cross-file relationship was checked. Evaluate that trade-off against the review defects you observe rather than choosing an arbitrary file-count cutoff.

Architecture / decision scenario

A developer productivity pipeline reviews a multi-file inventory change in one call. It flags an unguarded average-sales division in one file but misses the same reachable zero-count path in another. It also misses a supplier adapter changing quantity from individual items to cases while the reorder service retains an item-based threshold.

Create separate local review tasks with the same criteria. Supply each affected calculation and its relevant input guards so reviewers can determine whether zero is reachable. That isolates the local defects without forcing either reviewer to judge every inventory interface.

Then run a separate integration review with the adapter output, stored quantity, and reorder comparison. Ask it to trace quantity units through those endpoints. It can identify the case-to-item mismatch even if all local arithmetic is valid. Give it the code as well as the local findings; an empty local report does not mean integration is safe.

Combine the candidates, keeping distinct division defects and reconciling duplicate descriptions of the conversion defect. Send the combined set to finding verification. A bigger window or repeated full-diff votes leaves the original distribution of attention intact; focused local tasks plus explicit data-flow evidence address both observed failures.

Common exam traps

  • Treating “the diff fits” as proof that one pass reviews every file thoroughly.
  • Replacing the integration pass with more isolated per-file passes.
  • Asking for cross-file conclusions without supplying both endpoints.
  • Feeding integration only local summaries instead of the code that carries the values.
  • Assuming identical-looking code has identical reachable inputs.
  • Removing a candidate because only one reviewer reported it.
  • Claiming managed Code Review documents a one-agent-per-file implementation.

What to remember

Partition the questions as well as the inputs. Local passes inspect bounded implementations under shared criteria; integration follows values and contracts across the changed files. Merge by underlying defect and verify candidates against behavior rather than retaining only consensus findings.

Knowledge check

References