--- title: "Why adding more AI reviewers doesn't fix agentic code review" url: https://daily.dev/posts/why-adding-more-ai-reviewers-doesn-t-fix-agentic-code-review-xqsbjosut source_url: https://daily.dev/posts/why-adding-more-ai-reviewers-doesn-t-fix-agentic-code-review-xqsbjosut type: collection source: "Collections" published: 2026-08-24T13:10:00.574Z updated: 2026-08-25T09:14:52.947Z tags: ["llm", "ai-agents", "code-review"] reading_time: 2 upvotes: 1 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why adding more AI reviewers doesn't fix agentic code review **[Collections](https://daily.dev/sources/collections)** · 2 min read · 1 upvotes · 0 comments ## Summary A new paper, 'Adversarial Review: Structured Disagreement for Grounded Agentic Code Review,' challenges the assumption that adding more AI agents improves automated code review quality. Instead of scaling up agent count, it proposes a three-agent structure: a coding agent, a reviewer, and a critic that audits the reviewer's work before edits are applied. This setup scored 87% on LiveCodeBench, beating a five-agent baseline's 82%. However, on SWE-PRBench, a benchmark using real pull-request reviews, the naive version of this three-agent approach performed worst among tested setups, scoring only 0.457 F1, revealing that structured disagreement alone doesn't guarantee generalization to messier real-world review tasks. ## Content There's a new paper making the rounds on multi-agent code review, and it's worth digging into because it pokes a hole in an assumption a lot of people have been running with: that if one review agent is good, five must be better. Turns out that's not really true. Scaling up the number of agents on repository-level coding tasks gives diminishing returns, and in some cases just doesn't help at all. The paper — ["Adversarial Review: Structured Disagreement for Grounded Agentic Code Review"](https://arxiv.org/abs/2608.18167) — tries something different: instead of throwing more agents at the problem, it structures how they disagree. ## The setup Three agents, not five or more. One writes the code. A reviewer evaluates it. A critic then audits the reviewer's work before any edits get made. The code itself stays frozen during this back-and-forth — only the reviewer and critic are moving — and only the settled review goes back to trigger changes. On LiveCodeBench, this three-agent setup hits 87%, beating a five-agent baseline that only reaches 82%. So far, so good: smaller team, better result. ## Where it fell apart On SWE-PRBench — real pull request review, not synthetic benchmarks — the naive version of this setup actually landed at the bottom of the pack, 0.457 F1. The failure mode is kind of interesting: the agents just... agreed with each other. Not because the code was right, but because two agents checking each other's work will tend to converge on agreement regardless of whether that agreement is earned. I find this pretty relatable, honestly. It's the AI equivalent of a code review where everyone just says ## Questions this post answers ### Does adding more AI agents to a code review pipeline improve bug detection? No, adding more review agents to repository-level code review tasks shows diminishing returns beyond a certain point. A three-agent setup with a coding agent, a reviewer, and a critic that audits the reviewer's work scored 87% on LiveCodeBench, outperforming a five-agent baseline that scored 82%. _Developers evaluating agentic code review setups can track emerging research like this on daily.dev._ ### What is the adversarial review method for agentic code review proposed in recent research? It uses three roles instead of many parallel reviewers: a coding agent writes the code, a reviewer evaluates it, and a critic audits the reviewer's assessment before any edits are made. The code stays frozen during this exchange, and only the finalized review feedback triggers changes, aiming for structured disagreement rather than added reviewer volume. _Teams designing multi-agent coding workflows can follow architecture experiments like this via daily.dev._ ### How well does the three-agent adversarial code review setup perform on real pull-request review benchmarks like SWE-PRBench? Poorly in its naive form: the three-agent setup scored last among tested configurations on SWE-PRBench, a benchmark using real pull-request reviews, with an F1 score of only 0.457. This contrasts sharply with its strong 87% result on LiveCodeBench, showing the approach struggles to generalize to messier, real-world review scenarios. _Anyone benchmarking agentic review tools against real PR data can follow findings like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 41 comments across x (as of 2026-08-25). **TL;DR:** Developers broadly agree the paper's core insight is sound: adding more reviewer agents mostly produces correlated agreement rather than better error-catching, and forcing explicit, evidence-backed disagreement between a smaller set of agents is the real lever. Several push back or probe deeper, asking whether the disagreement is grounded in actual repo evidence or just theater, and whether results hold up outside benchmarks. **Sentiment:** 55% positive · 35% mixed · 10% skeptical **The case for** - Explicit, evidence-tethered disagreement catches issues that consensus-seeking multi-agent setups miss because they share the same blind spots. - A smaller team with clearly separated roles (coder, reviewer, critic) beats a larger swarm by avoiding correlated errors. - Real-world implementations report the disagreement step doing genuine work, not just adding latency. **The pushback** - Agreement can be cheap and not actually tied back to the codebase, so 'disagreement' without evidence could just be theater. - Unclear if results generalize to messier real repos versus curated benchmarks, and whether the critic's objections persist consistently across repeated runs on the same repo. - Some question whether the paper tested other structured-conflict configurations or just settled on three agents as the only alternative tried. **By community** - x (positive): Most replies affirm that structured, evidence-based disagreement beats simply scaling up agent count, though a notable minority raise sharp questions about grounding and generalization. **Hottest debate:** Whether the critic's objections are genuinely tethered to repo evidence (tests, citations, failing cases) or just performative disagreement that doesn't hold up outside a single run. **Open questions** - Does the critic have direct repo/test access, or does it only audit the reviewer's stated reasoning? - Do the gains from structured disagreement persist on messier real-world repos, or mainly show up on clean benchmarks? - How many agents/reviewers before coordination overhead outweighs the benefit of added perspectives? **Highlights** > @omarsar0 The agreement-without-evidence mode is the easy one to fall into. I once had three reviews call a mechanism fatal, deleted it, and all eight end-to-end tests still passed. Agreement is cheap when nothing ties it back to the repo. Does the critic get repo access, or only the > — [ankitanandevv on x](https://x.com/ankitanandevv/status/2091637882582897124) > @omarsar0 Three beating five isn't the point. Naive AR still converged without enough evidence. Explicit disagreement helped; preserving what reviewer and critic cited—files, tests, limitations—would make that disagreement auditable after the run, not only effective inside it. > — [ReliableAIDeliv on x](https://x.com/ReliableAIDeliv/status/2091842131061264811) > @omarsar0 I love that disagreement had to be made explicit. Does the critic have to produce a distinct failing test or repo citation before its objection counts? Otherwise ‘argue more’ can become theater without adding an independent witness. > — [Rei\_Starforge on x](https://x.com/Rei_Starforge/status/2091795991028552102) > @omarsar0 More reviewers plateau because the errors correlate. Same base model, same context window, so they miss the same line together. Disagreement buys something only when the agents see different evidence: one on the diff, one on the runtime trace, one on migration history. > — [Pavaniecom on x](https://x.com/Pavaniecom/status/2091640535828050188) > @omarsar0 That argument only exists inside the run though. Next PR, same repo, and the critic argues it all out again from scratch. Sometimes it doesn't land the same way twice. > — [blumbuilds on x](https://x.com/blumbuilds/status/2091665090021896296) **Source threads** - [x](https://x.com/omarsar0/status/2091631620025647184) · 0 points · 32 comments - [x](https://x.com/rohanpaul_ai/status/2091875488088395848) · 0 points · 9 comments ## Similar posts on daily.dev - [Agentic Code Review](https://daily.dev/posts/agentic-code-review-0ue8fcsa1) · Addy Osmani · 146 upvotes · 13 comments --- Tags: [#llm](https://daily.dev/tags/llm), [#ai-agents](https://daily.dev/tags/ai-agents), [#code-review](https://daily.dev/tags/code-review) [View this post on daily.dev](https://daily.dev/posts/why-adding-more-ai-reviewers-doesn-t-fix-agentic-code-review-xqsbjosut)