Fan out, then refute: reviewing code with a panel of agents

One AI reviewer gives you one opinion and a pile of confident false positives. Split the review across specialists, then make skeptics try to kill each finding before it reaches you.

Ask a single AI to review your diff and you get one fluent opinion, padded with findings that sound serious and turn out to be wrong. The problem is not the model, it is the shape of the request. Two structural changes fix most of it, and neither needs a smarter model: fan the review out, then verify it adversarially.

Fan out across specialists

Instead of one generalist pass, run several reviewers in parallel, each handed exactly one lens. One only hunts correctness bugs. One only looks for swallowed errors and silent failures. One judges the types. One asks whether the change is actually tested. One thinks about performance. Each is blind to the others, so it goes deep on its own axis instead of skimming everything shallowly. Breadth comes from running them together, not from asking one agent to hold everything in its head at once.

Then make skeptics refute each finding

Now the important half. Every raw finding is handed to a fresh agent whose only job is to refute it. Is this bug actually reachable? Is it already handled three lines up? Is it out of scope for this change? The verifier is told to default to 'not a real problem' whenever it is uncertain. Only the findings that survive that scrutiny get reported. This is where the confident nonsense evaporates, because a claim nobody could knock down is usually a claim worth reading.

Why the refute step earns its keep

A single reviewer has no reason to doubt itself, and it will defend a shaky finding as smoothly as a solid one. An adversarial second pass is cheap when the reviewers are agents, and it changes the incentive: a finding now has to withstand an attack before it reaches you. If you want more rigor, run a few skeptics per finding and take a majority vote. The output stops being a wall of maybe-bugs and becomes a short list you can act on.

The same shape maps an unfamiliar codebase

The pattern generalizes well past review. To understand a system I have not touched, I send several agents in parallel, each to map one axis of it, and then one final agent synthesizes their notes into a single annotated map with references back to the code. Fan out for coverage, converge for coherence. It is the same two moves: parallelism for breadth, one focused pass at the end for trust.

• Split the review into single-lens specialists and run them at once.
• Send every finding to a skeptic told to refute it, defaulting to 'not real' when unsure.
• Report only what survives, and vote with several skeptics when you want more confidence.
• Reuse the shape to learn a codebase: many explorers, one synthesizer.

One agent's confidence is not evidence. Make a second one try to prove it wrong, and keep only what it fails to kill.

The lesson that stuck with me is that you get more out of structuring how the agents work than out of chasing a bigger model. Parallelism buys breadth, an adversarial pass buys trust, and the combination turns a firehose of plausible findings into something you would actually put your name on.