Two-Model Code Review
Run code reviews with two different LLMs — one finds issues, one verifies fixes — to catch blind spots and reduce false positives before merge.
Why one model is not enough
Every LLM has blind spots shaped by training data, safety tuning, and architecture. A model that misses a race condition might catch an auth flaw. Running two models in opposition — reviewer A finds issues, reviewer B validates or rejects them — mirrors how human senior/junior pairs work and cuts noise before it hits your PR.
This is a workflow guide, not a product pitch. Works with Claude, GPT, Gemini, or any pair you choose.
The two roles
| Role | Model choice | Job |
|---|---|---|
| Reviewer | Strong reasoning model (e.g., Claude Opus, GPT-4o) | Find bugs, security issues, design smells |
| Auditor | Different family (e.g., Gemini, o3, DeepSeek) | Confirm findings, drop false positives, rank severity |
Use models from different providers when possible. Same-family "second opinion" helps less.
When to run it
- PRs touching auth, payments, or data deletion
- Refactors over 200 lines
- New dependencies or config changes
- Junior dev submissions before senior human review
- Pre-release hardening sprints
Skip for typo fixes and pure content changes.
Step-by-step workflow
1. Prepare context bundle
Give both models the same inputs:
- PR diff (or git diff)
- Relevant file paths for surrounding context
- Project constraints (framework, test command, style rules)
- Threat model one-liner if security-sensitive
Keep diffs focused. If the PR is huge, split review by module.
2. Reviewer pass (find issues)
You are a senior code reviewer.
Review this diff for:
1. Correctness bugs
2. Security vulnerabilities
3. Performance regressions
4. Missing tests
5. API / breaking changes
Output format:
- [SEVERITY: critical|high|medium|low] File:line — Issue — Suggested fix
Be specific. Cite lines. Do not praise the code.
If no issues, say "No issues found" and list what you checked.
DIFF:
[paste diff]
3. Auditor pass (verify findings)
Feed the same diff plus the reviewer's output:
You are an independent auditor. Another model reviewed this diff.
Your job:
1. For each finding, mark VALID or FALSE POSITIVE with one-sentence rationale
2. Add any issues the first reviewer missed (max 3)
3. Output a final prioritized list: must-fix before merge vs. nice-to-have
Do not agree by default. Challenge vague claims.
DIFF:
[paste diff]
FIRST REVIEW:
[paste reviewer output]
4. Human triage (5 minutes)
Merge the auditor's must-fix list into your PR checklist. Ignore low-severity noise unless pattern repeats across PRs.
5. Fix and re-run (optional)
After fixes, run only the auditor on the new diff with:
Previous must-fix items: [list]
Confirm each is resolved or explain what remains.
Severity rubric (shared across models)
| Level | Definition | Merge rule |
|---|---|---|
| Critical | Exploit, data loss, auth bypass | Block merge |
| High | Logic bug affecting users | Block merge |
| Medium | Edge case, missing test | Fix or ticket |
| Low | Style, naming, nit | Optional |
Paste this rubric into both prompts so severity labels align.
Model pairs + CI hook
| Reviewer | Auditor |
|---|---|
| Claude Sonnet / Opus | GPT-4o |
| GPT-4o | Gemini 2.5 Pro |
| Claude | DeepSeek R1 |
Swap pairs monthly. In CI: git diff → reviewer script → auditor script → PR comment. Block merge on validated critical/high only.
Human final pass
- Auditor validated all critical/high items
- Tests added for fixed bugs; no secrets in diff
- Prompts versioned in
prompts/code-review/(reviewer.md, auditor.md, severity-rubric.md)
Never auto-merge on AI output alone. Two models, human triage — that is the system.