Adversarial Verification

A team wires an LLM judge into its agent pipeline: every finished pull request gets one inference call, a score from zero to one, and a short verdict before a human opens the diff. A retry-and-backoff change for a flaky downstream service comes back at 0.94 — clean, well-commented, structurally sound — and merges on the strength of that score alone. Nine days later, under real production load, the retry path leaks a connection on one specific error branch the judge had no reason to think about, because nothing in the diff read as wrong. The code was not badly written. It was persuasively written, and persuasive was the only thing anyone had actually asked the judge to detect.

This Library’s chapter on judge panels, in the volume on multi-agent systems, already established the mechanism behind that gap: language padded with confident, consistency-signaling phrasing measurably inflates the score a passive LLM judge assigns to an answer, and the inflation survives switching to a larger judge model or warning it explicitly not to be fooled. A judge asked "how good is this, from zero to one" is answering a question about how the artifact reads. That is a different question from "does this actually work," and the gap between the two questions is exactly where the retry-path leak lived.

What passive scoring can’t see

The scale at which that gap matters stopped being small some time in the last year. By GitHub’s own count, more than one in five code reviews on its platform now involve an agent, and its Copilot review feature alone has processed over sixty million reviews — a roughly tenfold increase in under a year. Reporting drawing on a January 2026 study on AI-authored code, titled "More Code, Less Reuse," found a specific pattern sitting underneath that volume: AI-generated changes carry more redundancy and more technical debt per change than the human-authored code beside them, while the humans reviewing that code report feeling more confident approving it, not less.

Call the pattern hallucinated correctness: code that compiles, passes the tests it was asked to pass, and reads as the work of a careful engineer, while quietly doing the wrong thing on a branch nobody happened to exercise. A passive score cannot catch it, structurally, because a passive score is a read of the artifact as presented — and a well-formatted, well-commented, plausible-sounding diff is exactly what a passive read is built to reward. The failure is not that judges are careless. It is that being asked to rate something and being asked to disprove it are different jobs, and most review pipelines, human and automated alike, only ever assign the first one.

Ask it to break it, not to grade it

Adversarial verification is the alternative assignment: instead of asking a reviewer — human or model — to rate an artifact, ask it to try to disprove a specific claim about that artifact. This function handles the empty-list case. This migration is reversible. This retry logic cannot leak a connection on any error path. The reviewer’s job changes from forming an impression to running an investigation, and the two produce structurally different failure modes. A passive judge that skims a diff and finds nothing objectionable has completed its assigned task — nothing looked wrong. An adversarial reviewer that skims the same diff and finds nothing has failed its assigned task, because the assignment was to find something, and a cursory look is not evidence that nothing is there.

That asymmetry is the whole mechanism. Agreement under an adversarial framing requires actively trying and failing to find a problem, not merely failing to notice one. That is a meaningfully harder bar for a persuasively-written-but-wrong artifact to clear, because persuasive phrasing helps a skim-reader relax — it does essentially nothing for a reviewer actively probing a claim’s specific failure modes one at a time. The reframing also costs more: a genuine adversarial pass usually means another round of tool calls, test executions, or traced code paths rather than one inference, which is exactly why this chapter treats the two techniques as complementary rather than interchangeable — a cheap passive score to triage volume, an adversarial pass reserved for what an actual decision rides on.

The empirical case for training a reviewer to hunt specifically rather than to grade generally comes from OpenAI’s published work on critic models. Contractors deliberately planted subtle, hard-to-spot bugs into otherwise-working code, and a critic model trained against that adversarial signal — explicitly rewarded for finding the planted defect rather than for producing a plausible-sounding review — was preferred over unassisted human critique in 63% of cases, and caught more real bugs than the paid human reviewers it was benchmarked against. The gain did not come from a smarter model reading the same diff more carefully. It came from changing what the reviewer was being asked to do.

Failing to find a problem, on purpose

The distinction has a name outside software. Karl Popper’s account of scientific method held that a theory earns provisional trust not by being confirmed but by surviving genuine, repeated attempts at falsification — a conjecture nobody seriously tried to refute has not actually been tested, no matter how well it reads. Verification borrowed that logic long before anyone applied it to a pull request, and it is worth stating plainly: a review process built to confirm is structurally different from one built to refute, even when the two produce a verdict that looks the same on the surface.

The idea has a research lineage inside AI as well, and it predates the current generation of coding agents. Irving, Christiano, and Amodei’s 2018 proposal for AI safety via debate argued that a judge unable to evaluate a complex claim directly can still reach a better verdict by watching two agents argue opposing sides of it, on the theory that a false claim is harder to defend under sustained, adversarial pressure than it is to state persuasively once and walk away from. Refuter panels, developed later in this chapter, are a narrower and more practical descendant of the same intuition, built for a code review queue rather than a thought experiment about long-horizon oversight: instead of two agents debating each other, several independent reviewers each try, alone, to break the same claim.

A conjecture nobody seriously tried to refute has not actually been tested, no matter how well it reads.

The logic adversarial verification borrows from the philosophy of science

Refuter panels and the kill-if-majority-refutes rule

A refuter panel is nothing more exotic than running an adversarial pass more than once, independently, and comparing verdicts. Spawn N reviewers — three or five is a practical range for most teams — give each the same artifact and the same claim, and do not let any of them see another’s output while working; a refuter that reads a peer’s verdict first is no longer independent, and independence is the entire source of the panel’s value over a single reviewer. Each refuter has exactly one job: find a concrete, specific, falsifiable reason the claim is false. Not a stylistic quibble, not a preference about how the code is organized — a reason that would change the verdict if it turned out to be true.

The decision rule that makes the panel useful rather than merely expensive is kill-if-majority-refutes: a claim survives only if a strict majority of the panel’s refuters try and fail to find a real problem with it. A single dissent does not kill a claim. One reviewer — human or model — can be distracted, wrong, or chasing a plausible-sounding objection that does not actually hold up under a second look, and treating any single refutation as final would make the panel less reliable than one careful reviewer, not more. A majority is a different and stronger signal: it means most of the independent attempts to break the claim came back empty. When the panel does kill a claim, the artifact should go back for revision carrying the specific objections that were raised, not a lowered score — the entire point of asking for a reason to reject is that the reason is something someone can act on.

The case for independence over a single reviewer echoes findings from elsewhere. A panel of several smaller, differently-sourced judge models was found to reduce the bias any one model’s blind spots introduce into scoring, at a fraction of the cost of running one large judge repeatedly — evidence, in a passive-scoring context, that independence across reviewers buys something a single reviewer structurally cannot. A related but distinct precedent comes from a different corner of the field entirely: sampling several independent chain-of-thought reasoning paths for the same problem and taking the answer most of them converge on outperforms trusting any single path, because errors in independent attempts tend not to correlate while a genuinely correct answer does. Neither result is about adversarial refutation specifically — one is about passive scoring, the other about generation, not verification — but both rest on the same underlying fact a refuter panel exploits directly: independent attempts at the same problem fail in different, uncorrelated ways, and majority agreement filters that noise in a way no single attempt ever can.

Multi-lens review: correctness, security, performance

A refuter panel built from otherwise-identical reviewers, each given the same generic instruction to find a problem, will still miss things — not because the technique is wrong, but because "find a problem" is too broad an assignment for any one pass to hold well. A reviewer trying to keep correctness, security, and performance in mind simultaneously tends to under-weight at least one of them, which is the same failure mode human code review worked around long before AI entered the picture, by making security review its own discipline rather than a checkbox inside a general pass.

An empirical study of how developers actually behave during code review found that most do not spontaneously raise security concerns while reviewing for correctness — not because they consider security unimportant (asked directly, they call it a priority) but because a correctness-focused pass structurally does not surface it. Security review asks a different question than correctness review: not "does this do what it claims to do" but "how could this be made to do something else," which requires actively reasoning about hostile inputs and trust boundaries rather than checking a stated behavior against an implementation. Performance review asks a third, equally distinct question that neither of the other two lenses is built to catch: what does this cost under real load, at scale, or in the worst case.

Some 2026 practice already runs on close to this shape, though it should be read as an early, individually-reported pattern rather than settled methodology. One practitioner’s public account of an autonomous build pipeline describes a three-reviewer gate — separate agents assigned correctness, convention, and security — followed by a second, independent model given specifically an adversarial pass over the combined result, with findings recorded as structured, machine-checkable output rather than prose comments. GitHub’s own guidance for reviewing agent-authored pull requests, drawing on the same hallucinated-correctness pattern this chapter opened with, recommends a related move for the human layer sitting above any automated pass: rather than attempting comprehensive review of an AI-sized diff, trace one critical execution path end to end under an explicitly adversarial question — what would have to be true for this to be wrong.

Where adversarial passes earn their cost

None of this is free, and running it everywhere would trade one kind of waste for another. A few rules keep the cost proportional to what is actually at stake:

1. Reserve adversarial passes for what a decision rides on. A cheap passive score still does the job of triaging the bulk of a fleet or a queue; spend the extra tool calls on the finalists, not on everything.
2. Enforce real independence. A refuter that has seen another refuter’s verdict, or the original author’s reasoning, is not running the assignment — it is confirming a prior.
3. Require a falsifiable reason, not a vibe. A refutation that would not change if the claim turned out to be true was never really an attempt to break it.
4. Split lenses before you split reviewers. Adding more refuters to the same generic instruction buys less than giving fewer refuters a narrower, sharper one.
5. Track the reversal rate, and how often the reversal was right. A panel that overturns passive verdicts constantly but is usually wrong is adding latency, not safety.