The adversarial code review approach uses a maker-checker verification pattern in which a fresh-context agent reviews code without inheriting the generator's assumptions and blind spots.
TL;DR
LLMs measurably favor their own output in self-review research. That bias makes the writing agent a weak checker for its own incorrect diff. Adversarial code review splits maker from checker across separate context, instructions, and models, and the checker sees the diff and review criteria before human review.
Reviewers are staring at AI output they trust less. Stack Overflow's developer survey reported developer trust in AI output declining year over year. Within that adoption period, self-review research makes the writing agent the least reliable checker for its own incorrect diff.
Adversarial code review borrows its control model from banking. A second agent with different context, instructions, and often a different model reviews the diff before a human sees it. This guide covers the evidence that self-review fails, how teams configure verifier agents, and how teams route verifier budget before merge.
What Is Adversarial Code Review?
Adversarial code review applies the maker-checker principle to AI coding agents: the agent that writes a change never certifies it. The pattern uses a distinct reviewer role to check code produced by a builder role against the spec before human review. An implementation can add opposing reviewer roles. A primary reviewer proposes findings, a challenger tries to disprove them and hunt for missed issues, and an arbiter weighs both sides and decides what blocks the merge.
Architectural separation matters more than prompt wording. Anthropic's subagent guidance describes specialized agents with separate context windows, system prompts, and tool permissions, so one agent can implement while another performs read-only review. Augment Cosmos, a unified cloud agents platform with shared context and memory across the software development lifecycle, ships this pattern as a Reference Expert: a Deep Code Review agent runs in a fresh Session, isolated from the Session that produced the diff.
| Control dimension | Same-agent self-review | Adversarial code review |
|---|---|---|
| Approver | The writing agent evaluates its own change | A distinct checker reviews the maker's diff |
| Context | Generator assumptions stay in session | Reviewer starts from fresh context |
| Instructions | Implementation goals shape the review | Skeptical review criteria shape the review |
| Model boundary | Same model family can repeat blind spots | A pinned, often different model can review |
| Authority | The reviewer may share write authority | The checker can be read-only before handoff |
| Human handoff | Human review sees the maker's first opinion | Human review receives a separate verifier signal |
The control itself predates AI by decades. In banking, maker-checker controls require at least two individuals to complete a transaction. The Clark-Wilson model gave it formal grounding, and NIST AC-5 codifies separation of duties to reduce the risk of malevolent activity without collusion. Adversarial code review ports the same control to a pipeline where both the doer and the controller are agents.
Why the Model That Wrote the Code Reviews It Too Kindly
Across these self-review studies, LLMs recognized their own output and showed self-preference relative to neutral judging conditions. The self-recognition study by Panickssery, Bowman, and Feng found GPT-4 could distinguish its own text from other LLMs and humans, and fine-tuning made self-recognition stronger for other models. Self-recognition and self-preference show self-preference correlation on output pairs that human annotators judged equal in quality. The mechanism appears to be familiarity: familiarity bias research found that self-preference bias exists because LLMs prefer texts more familiar to them, measured through perplexity.
These reports point to the boundary code review handles: incorrect code. One study found harmful self-preference when stronger models do err, and research on self-attribution bias found the leniency is especially visible on incorrect code. A model reviewing its own buggy diff is at its most generous when the diff is wrong.
The failure modes below map to different studies and different mechanisms, so a team building a review pipeline can see which risks apply to their setup:
| Failure mode | Evidence | Source |
|---|---|---|
| Self-correction blind spot | Models fix identical errors presented as external input but fail on their own output across multiple evaluated models | Tsui et al. |
| Self-verification lowers accuracy | Self-verification produced lower accuracy than external verification in the reported evaluation | arXiv 2604.01993 |
| Blindness to own exploits | Self-critique missed many RL-discovered loopholes in the reported analysis | Anthropic finding |
| Self-preference on equal-quality pairs | The reported bias appeared even when human annotators judged output pairs equal in quality | arXiv 2604.22891 |
| Over-correction of correct code | Requiring explanations and suggested fixes counterintuitively led to higher misjudgment rates | arXiv 2508.12358 |
Prompt engineering does not repair this. Even authorship obfuscation research points the same direction: masking a judge's ability to recognize its own output predictably reduces self-preference, which means recognition drives the bias more than instructions do. Same-session review compounds the problem through context. The assumptions that shaped the implementation carry into the review, so the second pass restates the first opinion when it should produce an independent second look.
What a Second Agent Catches That the First Talked Itself Into
A second verifier agent changes the review boundary by showing the checker only the diff and criteria before the diff reaches a human. A self-correction study reported the relevant maker-versus-checker pattern: the verifier surfaced errors in another model's outputs under that study setup, while self-review showed reduced recall. The same judge also showed lower recall when reviewing itself than when reviewing another model's outputs.
The boundary conditions that matter for a second agent break down into inputs, model choice, and how many independent passes run against the same diff:
| Checker boundary | What changes for the second agent | Reported review effect |
|---|---|---|
| Diff-only input | Implementation history is excluded | Reviewer judges the finished diff |
| External output | The verifier reviews another model's work | The study setup reported better error surfacing than self-review |
| Cross-family pass | Codex and Claude-family reviewers inspect the same codebase | Different model-family failure modes expose missed defects |
| Multiple perspectives | Independent verifier outputs form an aggregate signal | Cross-verification reported pass-rate improvement |
| Benchmark caution | Multi-agent architecture is compared against a simple baseline | SWR-Bench found architecture alone did not guarantee stronger review |
Cross-family review caught defects in the bounded libfuse campaign because a Codex reviewer and Claude-family reviewers brought different model-family failure modes to the same codebase. In the libfuse campaign, a Codex agent found bugs that Claude-family review missed and identified correctness issues in proposed fixes that additional Claude-family agents did not catch. The campaign produced published CVEs. Same-family loops can leak because models from the same family share correlated blind spots and often end up confidently agreeing in the same places.
In the cited experiments, cross-verification reported pass-rate improvement when independent verifier perspectives created an aggregate verification signal. Cross-verification research found that diverse perspectives from multiple smaller models can collectively produce a verification signal strong enough to improve strong generators, and the CVCP protocol reported pass-rate improvement on its hardest task tier.
One caution before treating this pattern as settled: SWR-Bench evaluation found multi-agent approaches underperforming a simple PR-Reviewer baseline in its evaluation. Verifier prompts and scoped context determine what the reviewer catches, so architecture alone does not guarantee stronger review.
Configuring an AI Code Reviewer Agent: How the Checker Differs From the Maker
An effective AI code reviewer agent differs from the maker on five structural dimensions, starting with context. Anthropic's review best practices note that a fresh context improves code review because Claude avoids bias toward code it just wrote. A reviewer running in a fresh subagent context sees only the diff and the criteria, not the reasoning that produced the change. That narrower input makes the review evaluate the result on its own terms.
Each of those dimensions shifts a specific control between the maker and the verifier, from what the agent sees to what it is allowed to do:
| Dimension | Maker agent | Verifier agent |
|---|---|---|
| Context | Full conversation history | Fresh context: only diff plus criteria |
| System prompt | Implementation-focused | Skeptical review checklist |
| Model | Any; often larger for planning | Explicitly pinned, ideally a different family |
| Tools | Write, Edit, Bash, full toolset | Read-only: Read, Grep, Glob |
| Output | Free-form code and artifacts | Structured verdict with issue list |
The read-only tool set for the verifier follows the subagent tool permissions pattern, which restricts a review subagent to Read, Grep, and Glob so it cannot write to the working tree.
The permission boundary matters because the checker should investigate before any fixer receives write access. Augment Code Quick Ask Mode gives checker sessions zero write authority, supporting read-only investigation before any fixer agent gets write access.
A selected review begins with the story requirements, the architecture docs, and the diff. The reviewer approaches that package the way a new developer or systems engineer would on their first day: skeptically. A separate fixer agent applies corrections, a new reviewer takes another pass, and the cycle repeats before escalating to a human.
Fixer handoff keeps that boundary intact. In Augment Code Review, the Fix with Augment button opens an IDE agent session to address review comments, or the team can copy the prompt into another environment such as Auggie CLI. The user then reviews and accepts the proposed changes.
Handoff stages preserve maker-checker separation at each step from initial review through human escalation:
| Handoff stage | Agent boundary | Review-control purpose |
|---|---|---|
| Fresh reviewer | No implementation history enters the review | Prevents the maker's assumptions from becoming review assumptions |
| Read-only exploration | Checker sessions have zero write authority | Keeps the verifier from silently becoming the fixer |
| Fixer loop | A separate fixer agent applies corrections | Preserves maker-checker separation during remediation |
| Repeat review | A new reviewer takes another pass | Rechecks the changed diff before human escalation |
| Human escalation | Humans receive structured findings | Keeps merge judgment at defined checkpoints |
The same boundary generalizes beyond review. AI agent workflow platforms can put a dedicated Verifier role after every implementor output, and the reasoning extends to AI unit test tools: single-agent test generation poses an oracle risk because the same model both writes and certifies the test.
Teams can strengthen the verifier's signal by adding codebase context to the review. Augment Code Review in Thorough Reviews mode provides full coverage and catches 50% more bugs than Precise mode. PR findings use full-codebase context, existing patterns, and configurable review guidelines before human review, a pattern reflected in AI code review tools selection criteria.
Where to Spend the Extra Verifier Review Budget
Verifier-review budget should be routed by blast radius because risk-based routing concentrates the second agent on changes where an escaped defect has the highest cost. Review cost varies by diff size, model choice, and how many independent passes the team runs. Between those poles, these heuristics decide where the checker earns its review budget:
- Rank changes by blast radius. A small permission change can be more dangerous than a large low-risk refactor.
- Always cover security-sensitive paths and low-oversight AI code. Authentication, authorization, secrets handling, and payment paths deserve verifier attention before broad refactors do.
- Skip the trivial. For a tiny diff on a low-risk repository, one agent is enough.
- Use workflows for known repeatable steps. Structured workflows fit deterministic checks better than open-ended adversarial review.
Those four routing rules concentrate verifier spend on permission changes, security-sensitive code, low-oversight AI output, and large changes with high blast radius, while deterministic or trivial work stays cheaper.
Model choice belongs in routing policy because routing the same review task across cheaper or more capable models changes the bill before diff scope changes. In Augment Cosmos, Prism model routing works with the Model Picker, the Auggie /model command, or the CLI --model flag, and it routes requests across a configured pool of model families. Vendor-reported tests on mixed refactor and review prompts matched a 40% hallucination-reduction pattern compared with relying on a single model family. The policy also keeps BYOK model-agnostic across Anthropic, OpenAI, Bedrock, Vertex, and open-source models.
Run your software agents at scale
Cosmos gives your agents the context, tools, and feedback loops they need to get better with every workflow.
Wiring the Checker Into CI and Pull Request Workflows
CI wiring for adversarial code review uses a pull request trigger with a verifier model set independently from the coding agent, so maker-checker separation becomes enforceable before merge. The ai-pr-review pattern uses an environment variable so the review job can pass a different --model flag than the generation job. This workflow runs on GitHub Actions with ubuntu-24.04 and actions/checkout@v4. It installs Claude Code CLI and an npm-based PR review tool such as @diekotto/ai-pull-review-cli, then checks out the pull request and runs the review command.
Each CI control in that workflow maps to a failure mode the team is trying to prevent, from missing triggers to missing credentials:
| CI control | How the workflow enforces it | Failure it prevents |
|---|---|---|
| Pull request trigger | Runs on opened, synchronize, reopened, and ready_for_review events | Prevents verifier review from depending on manual launch |
| Independent model setting | Passes reviewer arguments through REVIEW_CLI_ARGS | Prevents the checker from inheriting the generator's model choice |
| Read permission scope | Sets repository contents to read | Prevents review from requiring broad repository authority |
| Comment permission scope | Allows pull-request comments | Lets findings reach the PR without granting merge authority |
| API secret check | Uses ANTHROPIC_API_KEY from repository secrets | Fails closed when required reviewer credentials are missing |
On each pull_request event, ai-pr-review runs the verifier model and posts review findings as pull-request comments. If no findings pass the threshold, the workflow posts no finding comments but still posts a summary reply to mark the review as completed.
The workflow fails if the job cannot find the reviewer CLI, the model name lacks support, required API secrets are missing, or pull-request permissions do not allow posting comments.
PR-triggered verification works better when the reviewer ignores low-signal files. Augment Code Review uses Smart File Filtering to automatically exclude binary files and generated content from analysis, so those two low-signal classes never enter the verifier's input.
Confidence thresholds control PR noise by filtering findings after parallel reviewer agents score each issue, while checker independence stays intact. Anthropic's open-sourced code-review plugin runs parallel agents and scores each issue for confidence. It surfaces only findings above the configured threshold and auto-skips drafts, closed PRs, and trivial automated changes.
Gating policy decides whether any of it matters. Teams bypass recommended verification when CI does not enforce it under pressure, so every verification layer meant to prevent a merge needs a blocking gate behind it. A rollout can start with advisory mode to calibrate trust. After that, gates should focus on critical findings because blocking on every high-severity finding can push people to route around the system.
Human checkpoints make those gates explicit by defining where approval must happen. Augment Cosmos Human-in-the-Loop policies convert advisory review into gates and reduce 8 software-delivery interruptions to 3 defined human checkpoints, enforcing where human judgment is required before agents continue. Teams comparing gating options can weigh quality gate automation against human checkpoints for the same merge path.
The gate design choices below trade off enforcement strength against developer friction, and each row shows where a team can turn a signal into a blocking rule:
| Gate design choice | CI setting | Human checkpoint impact |
|---|---|---|
| Advisory calibration | Reviewer comments without blocking | Calibrates trust before enforcement |
| Critical-findings gate | Blocks merge on critical findings | Keeps merge judgment at defined checkpoints |
| Human-in-the-loop policy | Requires human approval before agents continue | Reduces 8 software-delivery interruptions to 3 defined human checkpoints |
| Permission-level scope | Reviewer cannot merge or write | Keeps the reviewer as a checker |
| Auditable session | One replayable checker run per session | Preserves review evidence for checkpoints |
Scope the checker's authority at the permission level. Prompt instructions guide behavior, and permission controls define what the reviewer can actually do. A reviewer with merge authority breaks the checker boundary. Permission-level controls and auditable, replayable sessions keep human judgment required at checkpoints the team defines, so humans approve at those checkpoints rather than reading every diff.
Environment controls give that permission boundary an audit trail. Augment Cosmos Environments and Sessions scope reviewer authority to one auditable, replayable session per checker run: Environments define what agents can touch, and Sessions capture each run so the review evidence stays available for the human checkpoint.
A rollout sequence keeps the checker independent before FAQ-level decisions about models, prompts, cost, and merge blocking:
- Route verifier review first to permission changes, authentication flows, and large agent-authored diffs.
- Give the checker only requirements, architecture docs, and the diff.
- Keep checker sessions read-only so a separate fixer agent applies corrections.
- Run advisory comments first to calibrate trust and false positive tolerance.
- Convert critical findings into blocking gates only after the advisory signal is calibrated, leaving human review with a defined verifier signal.
Split Maker From Checker on Your Riskiest Paths First
Adversarial code review rollout should start on riskiest paths because fresh-context checker agents concentrate review effort where self-review is least reliable and escaped defects hurt most. The tension in adversarial code review weighs spend against catch rate, and the evidence points to targeting the highest-risk paths: self-review is least reliable on incorrect code, which is the only code review exists to catch. Start this sprint with permission changes, authentication flows, and large agent-authored diffs. Wire a fresh-context reviewer with read-only tools and a pinned model from a different family. Run it advisory first, then gate on critical findings. Teams that want the maker-checker split without building the harness can use Augment Code for pull-request review with codebase context and 59% F-score quality, running that review before critical changes merge.
FAQ
Related Guides
Written by
Ani Galstian
Ani writes about enterprise-scale AI coding tool evaluation, agentic development security, and the operational patterns that make AI agents reliable in production. His guides cover topics like AGENTS.md context files, spec-as-source-of-truth workflows, and how engineering teams should assess AI coding tools across dimensions like auditability and security compliance