Multi-Instance and Multi-Pass Review

What You Need to Know

Self-review means that a model checks its own output in the same conversation session. An independent instance is a separate Claude invocation without that prior reasoning context. Attention dilution is uneven attention when one pass reviews too much at once. A confidence score is the model's own report of its certainty about a finding.

This lesson uses one made-up example throughout: the development team at an online shop. Claude writes the shop's order-processing code and then reviews it. Each change is a pull request (PR): a set of changed files that the team wants to merge.

The Self-Review Limitation

In self-review, the model retains its original reasoning chain. It already "knows" why it chose each approach, classified each finding at a particular severity, or selected certain values. So the model tends to confirm those decisions rather than challenge them. This is how self-review works in one session. Plan your design for this behaviour. If Claude chose an unsafe pattern in the order code, a same-session review still holds the reason for that choice. So the review is likely to approve the code again.

An independent instance judges the output on what it sees alone, without the bias of "I chose this because...". This lack of bias makes the independent instance much better at finding subtle issues.

// Anti-pattern: self-review in the same session
const generation = await client.messages.create({
  messages: [
    { role: "user", content: "Write a function to process orders" },
    { role: "assistant", content: generatedCode },
    { role: "user", content: "Now review your code for bugs" }
    // Model retains its reasoning — less likely to find its own mistakes
  ]
});

// Correct: independent review instance
const review = await client.messages.create({
  messages: [
    {
      role: "user",
      content: `Review this code for bugs, security issues, and edge cases:\n\n${generatedCode}`
    }
    // Fresh instance — no prior reasoning context
  ]
});

Multi-Pass Review Architecture

In a single pass, large reviews (multi-file PRs, complex extraction pipelines, broad code audits) suffer from attention dilution. These are the symptoms:

• Detailed feedback on some files, superficial comments on others
• Obvious bugs missed in the middle of the review
• Contradictory findings: flagging a pattern as problematic in one file while approving identical code elsewhere

One pass over a large PR might check the first file line by line, skim the middle files, and flag a pattern it approves elsewhere. The fix is to split the review into focused passes.

Pass 1: Per-file local analysis. Each invocation reviews one file with a focused prompt, so that file gets full attention and every file gets consistent depth.

Pass 2: Cross-file integration. After the review of every file is complete, a separate pass receives all the per-file findings. This pass checks data flow between modules, consistent API usage across services, dependency conflicts, and contradictions in the per-file findings themselves. This pass catches cross-file issues that no single-file review would identify. At the shop, the checkout file might send an order total as text while the payment file expects a number. The prompt below also names API contracts. An API contract is the agreed format of the requests and responses between two services. Separate passes stop contradictory findings from appearing in the same output.

// Pass 1: Per-file analysis
const perFileFindings = await Promise.all(
  files.map(file =>
    client.messages.create({
      messages: [{
        role: "user",
        content: `Review this file for local issues (bugs, security, logic errors):\n\n${file.content}`
      }]
    })
  )
);

// Pass 2: Cross-file integration
const integrationReview = await client.messages.create({
  messages: [{
    role: "user",
    content: `Given these per-file findings, identify cross-file issues:\n` +
      `- Data flow inconsistencies between modules\n` +
      `- Contradictory patterns flagged in different files\n` +
      `- API contract violations across service boundaries\n\n` +
      `Findings:\n${JSON.stringify(perFileFindings)}`
  }]
});

Why Larger Context Windows Do Not Fix This

A bigger context window holds the whole PR, but the model still spreads its attention unevenly across files. The problem is attention quality, not context size. Only focused per-file passes give consistent depth.

Confidence-Based Routing

For uncertain findings, the model can self-report confidence alongside each finding. The score is the model's own view of its certainty. It does not measure how often the model is right. The score allows routing, which decides where each finding goes:

• High confidence findings: Report directly to developers
• Low confidence findings: Route to human review for validation
• Threshold calibration: Use labelled validation sets (examples where you already know the answer) to calibrate what confidence score correlates with actual accuracy

A race condition is a bug where the result depends on which of two operations finishes first. The race condition finding below is uncertain, so it goes to human review.

{
  "finding": "Potential race condition in order processing",
  "severity": "major",
  "confidence": 0.65,
  "reasoning": "The lock acquisition pattern appears correct but the unlock timing depends on an async callback whose ordering I cannot fully verify.",
  "route": "human_review"
}

A raw score is uncalibrated, so it is unreliable for automated decisions. Calibrate the score by running labelled examples (where you already know the answer, such as the shop's past PRs) through the system. Measure how closely reported confidence follows actual accuracy. Then adjust the routing thresholds from that data. A threshold that you validated against labelled sets is suitable for routing. Using uncalibrated confidence for automated decisions is an anti-pattern.

Putting It All Together

A production review architecture combines all three concepts:

1. Generation: First instance generates code, extraction, or analysis
2. Per-file review: Independent instances review each output unit individually
3. Integration review: Separate instance checks cross-unit consistency
4. Confidence routing: Low-confidence findings go to human review
5. Calibration loop: Labelled validation sets continuously calibrate confidence thresholds

At the shop, one instance writes the code, independent instances review each file, another checks across files, and a person checks doubtful findings.

In the exam

The exam tests this principle directly. To improve review quality, the correct answer uses a separate model instance. It is wrong to add "please review carefully" instructions to the same session. It is also wrong to depend on extended thinking within the generating session. Both options leave the original reasoning in context.

For large multi-file reviews, one specific wrong option reads "switch to a higher-tier model with a larger context window". The exam also distinguishes raw confidence scores from calibrated confidence thresholds. Raw confidence scores are uncalibrated and unreliable for automated decisions. Calibrated confidence thresholds are validated against labelled sets and are suitable for routing.

When the Cost Is Worth It

This architecture is more expensive than single-pass review. It is worth the cost when review quality directly affects production reliability. Examples are CI/CD pipelines, financial extraction, compliance analysis, and any system where issues that a review misses have downstream consequences.

Exam Traps

Practice Scenario

Build Exercise

Sources

• Claude Certified Architect Foundations Exam Guide — Task Statement 4.6 — Anthropic
• Prompt Engineering Overview — Anthropic
• Introduction to Subagents: Using subagents effectively (Claude Academy) — Anthropic
• Claude Code 101: Code review (Claude Academy) — Anthropic
• CCAR-F Exam Guide v1.0: Task Statement 4.6 — Anthropic