Design multi-instance and multi-pass review architectures

When one Claude session generates code and is then asked to review that same code, it still holds the full reasoning context from generation. It already worked out why each choice was correct, so rather than questioning those decisions it tends to rationalize them. This is generator context bias.

Instructions like "now carefully review your own work" or enabling extended thinking do not remove the bias, because the biasing material (the assumptions and justifications) is still sitting in the context window. The model reviews through the same lens it wrote with, and extended thinking often just deepens that same line of reasoning.

The exam states this precisely: a model retains reasoning context from generation, making it less likely to question its own decisions in the same session. The correct response is architectural, not a stronger prompt.

An independent review instance is a fresh Claude invocation that receives only the artifact to review (the diff, the file, the extracted JSON) and none of the generation transcript. With no prior reasoning to anchor on, it evaluates the work on its merits and catches subtle issues that self-review misses.

In the Claude Agent SDK this is a separate session or agent; in Claude Code CI it is a separate claude -p invocation from the one that produced the change. The generation job writes code, and a distinct review job reads only the resulting diff. This is the same idea as session context isolation from task 3.6: the session that generated the code is less effective at reviewing its own changes than an independent instance.

Key testable ranking: an independent instance beats both self-review instructions and extended thinking for catching subtle problems, because those two operate inside the biased context while the independent instance starts clean.

Reviewing many changed files in one prompt dilutes attention. The symptoms are distinctive and heavily tested: detailed feedback on some files but superficial comments on others, obvious bugs missed, and contradictory findings where the model flags a pattern as a bug in one file while approving identical code elsewhere in the same review.

The remedy is prompt chaining into focused passes. Run a per-file local pass on each file for issues contained within that file (null handling, off-by-one errors, local error handling, in-file logic). Then run a separate cross-file integration pass that examines data flow across files: changed function signatures, interface and contract mismatches, shared state, and ordering assumptions.

Because each local pass sees only one file, depth stays consistent and findings stop contradicting each other. The integration pass is where genuinely cross-cutting bugs surface, which is why you cannot simply split the change into smaller reviews and stop there. This is the review-stage application of the decomposition principle in task 1.6.

A verification pass re-examines the artifact, often with an independent instance, and attaches a confidence level to each finding. Those confidences drive calibrated routing: high-confidence findings can be auto-posted as PR comments, while low-confidence or ambiguous ones are routed to a human or a deeper second look.

Calibrate the thresholds against a labeled validation set rather than trusting the raw numbers, and keep the scope narrow. Per-finding confidence is a prioritization signal for reviewer attention. It is not a reliable proxy for overall case complexity or an escalation trigger, because model self-reported confidence is poorly calibrated when used that way (see tasks 5.2 and 5.5).

So use confidence to rank and route the findings coming out of a review, not to decide whether the whole task needs a human.

Put the pieces together for a scenario-5 style automated review. Generation and review run as separate jobs, which gives you the independent instance for free. The review job runs claude -p in non-interactive mode and emits machine-parseable findings with --output-format json and --json-schema, so results can be posted as inline PR comments.

For a large PR the review job fans out: one local pass per changed file plus one integration pass over the full diff, then it aggregates the findings. On re-runs after new commits, include the prior findings in context and instruct Claude to report only new or still-unaddressed issues, which avoids duplicate comments.

# review job, independent from the generator
claude -p "Review src/orders.ts for local issues" \
  --output-format json --json-schema findings.schema.json

This mirrors the prompt-chaining decomposition from task 1.6, applied to the review stage itself rather than to the original implementation task.