Adversarial Multi-Model Peer Review
Have rival LLMs review each other's code and fight it out until no issues remain
- Difficulty
- Advanced
- Time to result
- ~days to results
- Steps
- 4
- Confidence
- 90%
Because a non-technical builder can't reliably catch code bugs, run the same branch through multiple independent model reviewers (Claude, Codex, Composer), then feed each reviewer's findings back to the lead model as a 'peer review' where it must either defend its code or fix the issues. Use it as the safety net for code you can't personally audit.
Origin
Zevy's biggest challenge as a non-coder is reviewing AI-written code. He built a /peer review command that frames the lead agent as the dev lead whose work other team leads have critiqued — and iterates until the models stop surfacing real issues.
Core principles
- 01Different models have distinct strengths and catch different bugs
- 02The lead model has the most context, so it should adjudicate, not blindly accept criticism
- 03Iterate the fight until no new real issues surface
- 04Never accept findings at face value — force justification or a fix
How to run it
- 1
Self-review first
Run /review so the lead model (Claude) reviews its own branch and lists critical/high/medium bugs.
Watch out Do a manual QA pass before this to catch anything obvious yourself.
- 2
Run independent reviewers
Have Codex and Cursor's Composer separately review all the code in the same GitHub branch (never the live codebase).
Pro tip Composer returns fast; Codex is slower but digs into the hardest problems.
- 3
Feed findings into peer review
Invoke /peer review, paste 'dev lead one' findings from one model and 'dev lead two' from the other; the command tells the lead agent that other team leads reviewed its code and it must defend or fix each item.
Pro tip The lead model is instructed not to take critiques at face value because it has more context and led the project.
- 4
Iterate until convergence
Repeat, letting models argue, until you feel there are no more issues; use a learning command to understand anything you don't grasp.
Pro tip Expect the lead model to get 'sassy' and insist a flagged item is by-design for the third time — that's a signal, not a failure.
In the wild
Zevy runs Claude's self-review, then has Codex review the branch and Composer run /review, then pastes both back into /peer review as competing dev leads to reconcile.
→ Different models catch different bugs; disagreements are resolved by the context-rich lead model until the reviewer feels no issues remain.
Common mistakes
Running one model at the live codebase
A single reviewer misses bugs the others would catch, and reviewing the live codebase instead of a branch risks shipping unverified changes.
Is it for you?
Best for
Non-technical builders who cannot manually audit AI-generated code
Not ideal for
Experienced engineers who can review faster themselves, or trivial low-risk changes
From the transcript
“I have codeex which is chat GBT's competitor to cloud code as well as cursor open and I will have each of them review the…”
“you're the dev lead on this project. Other team leads within the company have looked at your code and reviewed it and found these issues.…”
“sometimes uh cloud code will get really sassy and be like this has been raised for the third time and for the third time I'm…”
From the episode
The non-technical PM’s guide to building with Cursor
Zevi Arnovitz (Meta)