Review with independent instances and multiple passes

Claude Code generates a fix and, in the same session, you ask it to review it. It says it is fine. The bug shows up in production. It is not bad luck: the reviewer had all the reasoning that led to that solution in its context.

Why self-review fails

In self-review, the model keeps the reasoning context from when it generated the code. The justifications that convinced it are still there, so it is unlikely to question its own decisions. Asking it to “review critically” or giving it more extended thinking does not change that: it is still looking with the same assumptions.

The independent instance

An independent review instance is another Claude call, without the generator’s history. It receives:

• the output (the diff or the code);
• the requirements;
• explicit review criteria.

It does not receive the generator’s reasoning or earlier verdicts. That way it judges the evidence and does not inherit the conclusion. In CI, the reviewer is a separate run from the one that wrote the code.

Focused passes

A 40-file PR reviewed in a single pass ends up with deep findings in the first files and shallow ones in the last, and sometimes contradictory ones. That is attention dilution. Multi-pass review avoids it:

1. One pass per file for local issues.
2. One integration pass for data flow across files, fed compact summaries of interfaces and calls, not all the raw code. This is the pass that catches a change to a public API that breaks another package.

(The reasoning behind splitting it this way is in the task decomposition lesson.) Another way to focus is by category: if a single pass has to cover security, performance and style, attention spreads and the hardest category slips through.

Verify each finding

A reviewer instance reports 12 findings and 5 are false. Instead of hiding everything or posting everything, add a verification pass:

• one instance per finding receives the finding, the code and the criteria, and confirms or rejects it;
• only confirmed findings are posted and rejected ones are logged, so you can audit what was discarded without losing security coverage;
• the verifier needs explicit criteria, not “is this a real bug?”: that way two similar findings get the same verdict on every run.

The guide adds a variant: have the model report its confidence alongside each finding to route the review (doubtful ones to a person, clear ones straight through). That confidence is for routing, not for deciding what a finding is; the criteria decide that.

If two instances report the same bug in different words, deduplicate in code by location and issue type. If two instances with different criteria disagree, the disagreement goes to the verifier and is logged.

The typical traps

• “Review your own code carefully” in the same session.
• Giving the reviewer the generator’s reasoning “so it has context”.
• One giant pass over the whole PR, or a bigger context window as the fix.
• Per-file passes with no integration pass, which miss cross-file failures.

On the exam

If reviewer and generator share a session, the answer is a separate instance without that context. If quality drops in the last files, per-file passes plus integration. If the problem is false positives without losing recall, per-finding verification with explicit criteria.