Design multi-instance and multi-pass review architectures
What you should be able to do
- Explain why a session reviewing its own output is a weaker check than an independent instance.
- Split a wide review into per-file passes plus a separate cross-file integration pass.
- Have a verification pass report calibrated confidence so findings can be routed.
Exam traps (4)
Ask the model to review its own work critically before returning it.
It still holds the reasoning that produced the code, so it re-derives the same conclusions — self-review instructions do not remove the shared premise.
Review from an instance that never saw the generation.
Turn up the reasoning effort so self-review catches more.
More thinking on the same premises produces a more thorough defence of them; the blind spot is the context, not the depth.
Independence is the mechanism. Effort is not a substitute for it.
Review everything in one pass so findings are consistent.
Attention spreads across the whole change, so per-file depth falls and the same issue can be judged differently in different parts of one reply.
Per-file passes for local issues, a separate pass for what crosses between them.
Treat every finding as equivalent and let reviewers triage.
The high-value findings queue behind the marginal ones, and reviewers ration attention by position rather than by importance.
Have the verification pass self-report confidence per finding so routing can be calibrated.
Primary sources
- Prompt engineering — chain promptschecked 2026-08-15
- Claude Code — GitHub Actionschecked 2026-08-15
Know cold
- Confidence calibration
- Lost in the middle
- Context isolation / progressive disclosure
4 practice questions in the bank are tagged to this task statement.
Practise this task in context: open it inside the interactive study guide, which carries the concept cards, the mock quiz and the practice simulation.