Why 3 Adversarial Reviewers Beat a 5-Agent Team

A new study found a 3-agent adversarial review setup beat a 5-agent cooperative team on LiveCodeBench, using fewer agents.

A study posted to arXiv in mid-August 2026 tested whether a small, structured disagreement between AI agents beats a bigger team of cooperative reviewers on a coding benchmark. The result: a 3-agent adversarial review setup outperformed a 5-agent cooperative baseline on LiveCodeBench, reaching an 87% pass rate against the larger team's 82%, using two fewer agents to get there.

Sources: arXiv: Adversarial Review (2608.18167)

The question behind the study is a practical one for anyone building automated code review with LLM agents. When review quality is not good enough, is the fix to add more reviewers, or to change how the reviewers interact with each other? The paper argues for the second answer, and backs it with three separate benchmarks rather than one.

What the researchers actually built

The paper, titled 'Adversarial Review: Structured Disagreement for Grounded Agentic Code Review' (arXiv 2608.18167), comes from researchers at Cornell and Stanford and was accepted to the DL4C workshop at ICML 2026. It does not use a proposer, challenger, and arbiter format. It studies three roles instead: a main agent that writes or edits the artifact, meaning code or a plan, a reviewer subagent that critiques that artifact, and a critic subagent whose only job is to audit the reviewer's critique before the main agent is allowed to act on it.

Sources: arXiv: Adversarial Review (2608.18167)

The paper treats coding performance and review quality as two different claims that often get blurred together. LiveCodeBench tests whether a method produces correct code on competitive-programming-style problems. SWE-PRBench tests something else: whether an agent's review comments match what a human reviewer actually flagged on a real pull request, scored by an LLM judge that the authors report agrees with human annotators at a Cohen's kappa of 0.75. SWE-bench Verified tests a third thing again, whether a generated patch passes hidden tests on a real repository. A method that wins on one is not guaranteed to win on another, and that is close to what happened here.

Sources: arXiv: Adversarial Review (2608.18167)

The authors call the protocol Adversarial Review, or AR. It freezes the artifact during the reviewer-critic exchange: the reviewer writes a critique, the critic evaluates it and can revise or challenge it, and the two go back and forth until they reach a consistent judgment or hit a five-round cap. Only after that inner loop settles does the main agent edit the artifact, and the cycle repeats. Despite the paper's title, the authors describe AR itself as 'a minimal cooperative code-review protocol': communication is restricted to one channel, and disagreement has to take one of three explicit forms.

Sources: arXiv: Adversarial Review (2608.18167)

• AGREE: the critic accepts the reviewer flag as written.
• DISAGREE_EVIDENCE: the critic cites specific code that contradicts the flag, and the reviewer must revise based on that citation.
• DISAGREE_CONCERN: the critic raises an objection that cannot yet point to contradicting code, and the reviewer must either cite supporting code for the flag or drop it.

The head-to-head: three agents against five

The paper builds up to AR step by step rather than testing it in isolation. It first tries zero-shot generation, then self-refine, where the same agent critiques its own code, then a single external reviewer, then two independent reviewers. None of those separated meaningfully from doing no review at all: self-refine matched zero-shot at 77% because the same model that wrote the bug tends to make the same reasoning mistake when checking its own work, a single reviewer helped only slightly on the harder tasks, and two independent reviewers, merged without a critic auditing them, actually scored a little below the single-reviewer setup.

Sources: arXiv: Adversarial Review (2608.18167)

The strongest cooperative baseline in the paper is MARS, a five-agent system: one author agent, three reviewers working in parallel without talking to each other, and a separate meta-reviewer that reads all three critiques and issues one final verdict. If the meta-reviewer rejects the solution, the author revises and a new round of independent review runs, up to two rounds. MARS is the paper's stand-in for a larger cooperative review team, and it is the method AR has to beat.

Sources: arXiv: Adversarial Review (2608.18167)

On both the full 105-task set and the 57-task hard subset, the three-agent adversarial setup scored highest of every method the paper tested. It beat MARS's five agents by about 5 percentage points overall, while running one main agent, one reviewer, and one critic instead of one author, three reviewers, and a meta-reviewer. The gain did not come from adding more reviewers. It came from adding one specific interaction: a critic whose only job is to challenge the reviewer before the main agent acts.

Sources: arXiv: Adversarial Review (2608.18167)

Where it did not hold up, and why that matters more

The same structure did not transfer automatically to a second benchmark. On SWE-PRBench, which scores how closely an agent's review comments match real GitHub pull-request feedback, the naive version of AR produced the lowest F1 score of the four review methods tested there: 0.457, behind a single reviewer at 0.495, two independent reviewers at 0.503, and MARS at 0.501. The authors trace this to a false-consensus failure: two agents asked to converge on a shared judgment tend to agree with each other even when the agreement is not backed by evidence. One case study shows a reviewer padding a review with hedged, speculative flags that a critic rubber-stamped. Another shows a critic raising a real bug, then abandoning it after the reviewer pushed back without citing any code.

Sources: arXiv: Adversarial Review (2608.18167)

Adding an explicit text constraint fixed it. Once the critic had to choose between the three named response types above, accept the flag, cite contradicting code, or raise a concern that still needs code evidence, rather than a free-form agree or disagree, AR's F1 score rose to 0.533, the best result among the methods tested on that benchmark. The authors treat this as the paper's central lesson: the value is not in agents interacting, it is in forcing that interaction to stay evidence-grounded instead of drifting into polite agreement.

Sources: arXiv: Adversarial Review (2608.18167)

On SWE-bench Verified, a 500-task benchmark built from real GitHub issues that requires an agent to locate a bug in an existing repository and patch it, AR reached a 75.2% pass rate against 71.6% for zero-shot and 72.6% for MARS. The paper is direct about the cost: AR used roughly 4.5 times the tokens of zero-shot generation to get there.

Sources: arXiv: Adversarial Review (2608.18167)

Two case studies from that benchmark show both sides of the trade-off. On a matplotlib bug where resetting a plot axis silently dropped tick-visibility settings, zero-shot and MARS both patched the symptom in the public-facing reset function, while AR's critic caught the same mistake early and pushed the agent one layer deeper to the actual source of the bug, producing a shorter patch that was the only one of the three to pass the hidden tests. On an astropy issue that asked for one new constructor argument, AR instead expanded a clean 24-line fix into a 32-line patch that added an unrequested feature and failed the hidden tests, because the reviewer raised a speculative question during review that the critic failed to reject as out of scope.

Sources: arXiv: Adversarial Review (2608.18167)

The result held without a rigid harness, too

AR still outperformed zero-shot and MARS even without a rigid harness enforcing the protocol. The LiveCodeBench and SWE-PRBench experiments run under a Python orchestrator that enforces each step, which keeps the comparison across methods strict and controlled. SWE-bench Verified used a looser execution mode instead: the paper expressed the entire AR protocol as a single SKILL.md text file and handed it to Claude Code running with full tool access, letting the agent itself decide when to invoke the reviewer and critic and when to edit. The authors read this as evidence that a lightweight cooperative protocol like AR can travel across agentic systems as a portable instruction set, not only as logic baked into a benchmark harness.

Sources: arXiv: Adversarial Review (2608.18167)

The finding that outlasts the benchmark numbers

Set the specific scores aside and the more durable claim is about design, not scale. Adding independent agents to a review process, by itself, produced small or inconsistent gains across every configuration the paper tested, from one extra reviewer up to a five-agent cooperative team. The configuration that won replaced independent, parallel opinions with a narrow, structured channel for disagreement between two agents holding different mandates: one producing a critique, one auditing that critique for evidence. The paper's own stated conclusion is that designing structured, evidence-grounded disagreement, rather than scaling how many reviewers look at the code, is what improved both code generation and review quality.

Sources: arXiv: Adversarial Review (2608.18167)

That is independent academic research, not a study of any commercial product, and it should not be read as an endorsement of one. It does line up with a design choice TLM Forge makes for Claude Code: its review agents run with different mandates instead of piling on more copies of a general reviewer, a threat-modeler auditing the design before code is written and a red-team auditing the diff afterward, and a merge stays blocked until every critical finding from that review is resolved rather than waved through on a single 'looks good.' The paper does not test TLM Forge and makes no claim about it. It does add outside evidence for a narrower point: review quality tracks how a review is structured, not how many agents show up to run it.