AI-assisted development can compress days of implementation into hours. Review capacity becomes the constraint. A large change may arrive with passing tests and a persuasive explanation before anyone has built a reliable picture of what it affects.
I handle that problem by separating the roles. One agent writes the change. Reviewers inspect it from fresh contexts, without inheriting the author's reasoning. A repair owner addresses confirmed findings, and the revised code returns to verification. Each stage has a different job and produces evidence for the next one.
The reviewers may run as subagents in the same tool or through the Codex and Claude Code CLIs. I care more about independent context and a useful mix of models than the interface itself. The goal is to make the implementation easier to challenge before it becomes the accepted answer.
Multi-review is one stage in a larger workflow for planning, implementing, verifying, and accepting changes. I cover the broader principles in Notes on working with coding agents. The complete workflow, including Genius Loop, deserves a separate article or a future expansion of that post.
Separate authorship from review
An implementation session accumulates history. The agent has seen the experiments, constraints, failed attempts, and decisions that produced the final diff. That context helps it finish the task. It also gives the agent reasons to defend the path it already took.
A reviewer starts from a smaller packet: the requirement, the relevant constraints, the change, and the verification evidence. It can inspect the surrounding code when needed, but it does not receive the author's entire conversation as a premise.
Subagents make this separation inexpensive. I can keep the implementation session intact while fresh reviewers examine the same revision. A separate CLI adds a model family and execution path that may notice different assumptions. My current multi-review setup combines opus-review, codex-review, and a structured code-quality check, then reconciles their findings before any repair begins.
Use different perspectives deliberately
The roster changes with the work. A routine change may need two independent reviews. A change with broad interactions or an uncertain design deserves another pass from a model suited to deeper analysis.
| Responsibility | Example assignment |
|---|---|
| Implement the change | Opus or Sonnet, working from a bounded task and acceptance criteria. |
| Review in a fresh context | opus-review, using Opus to inspect the requirement, diff, and surrounding behavior. |
| Add another model perspective | codex-review, using GPT-5.6 Sol with high reasoning effort. |
| Check overall code quality | Static analysis and a structured review of security, readability, reliability, maintainability, and performance. |
| Examine a more complex change | Fable, added when the design or interactions justify the extra review. |
A fresh Opus reviewer is still useful when Opus wrote the code because it starts without the implementation history. Sol contributes a different model perspective. The code-quality leg adds repeatable analysis that does not depend on agreement between the model reviewers. Fable is reserved for changes where another careful design review can justify its additional cost.
Model variety helps, but the number of reviewers is not the measure of quality. Reviewers must receive the same revision and enough context to test the same requirement. They work independently and do not see one another's conclusions until their reports are complete.
Review one stable revision
Every reviewer examines the same source state. If repairs begin while a review is still running, the reports can describe different implementations and become difficult to reconcile.
I collect the reports first, combine findings that share a cause, and validate each concern against the code and requirement. Agreement is useful evidence, although a single reviewer may find the most serious issue. I look at the failure it describes, the behavior affected, and the evidence supporting it. This is analysis, not a vote.
A failed review run remains visible. If a model cannot access the change or complete its report, that review leg is missing. I do not count silence as approval.
I learned that part through iteration. An earlier version of the workflow included Antigravity. It stopped working as expected in my setup for several days, so I removed it. A smaller roster that completes consistently is more useful than a larger one with an unreliable leg.
Example: a file import that passes its tests
Consider a feature that imports records from a file. The implementation parses the input, saves each record, and returns a summary. Its tests cover a valid file and pass.
An Opus reviewer may trace the request lifecycle and ask what happens when the same file is submitted twice. Sol may follow the write path and find that a failure halfway through leaves part of the import committed. Fable may question whether the account boundary is defined clearly enough for either behavior to be judged.
Those observations overlap, but they lead to different work. The duplicate submission needs an idempotency decision. The partial write needs a transaction or an explicit recovery rule. The account question may require clarification before anyone changes the code.
I do not assign security to one model and correctness to another. Each reviewer can inspect the whole change. Different models and contexts simply give the same requirement more than one chance to be challenged.
Give repairs one owner
After validating the findings, I send the consolidated set to one implementation owner. GPT-5.6 Sol at high reasoning effort is one option for a difficult repair: it can trace the reported issue, make the scoped change, and run the affected checks without splitting ownership across several concurrent writers.
The repair author does not approve its own work. Tests run again, followed by an independent review of the revised source. A fix may close one finding while changing another behavior, so the next review uses the complete updated change rather than a narrow patch.
Multi-review is the point where independent assessments are brought together. A larger workflow can connect that stage to planning, implementation, verification, repairs, and final signoff while keeping the roles separate.
The final check returns to the original request. Closing every review finding is useful, but the finished change still has to deliver the intended behavior and satisfy its constraints.
When a pull request touches a critical path, I review the final change myself after multi-review passes. I read the complete revised diff against the requirement and check the evidence behind the automated reviews. The models help me find and investigate risks; they do not make the final acceptance decision for that change.
Match the process to the risk
A small presentation change may need a focused review and a few direct checks. Stored data, permissions, shared interfaces, and changes across several components justify a larger roster and a deeper final pass.
Additional reviewers consume time and token capacity. I add them when another perspective can improve the decision, then keep the repair scope narrow. Tests, static analysis, and human judgment stay in the process. Model agreement is evidence to examine, not proof of correctness.
Before accepting the change, I want a clear record of what changed, which assumptions were challenged, what was repaired, and which checks support the final result.