The fleet owns "is it correct." I own "is it wise."
Hundreds of "review this for security" sessions sat in my logs as noise. Then one caught a bug I was about to ship. So I wired the noise into a gate and changed jobs: the fleet reviews, I edit the reviewers.
I was about to ship a real bug. A review session I had dismissed as noise caught it.
Now every change I push gets a full review before any human sees it: security, correctness, the dumb mistakes. Not by me. By a fleet of agents that fires on every commit and posts what it finds.
I built the wiring once. It runs whether I'm watching or not.
This is not "AI writes my code." The fleet's anatomy, rosters and dedup code and receipts, has its own post. This one is about what changes when review stops being a person's job.
Review theater with one actor
I work across a sprawl of repos, mostly alone. For a long time, the "review" on my own changes was me reading my own diff, nodding, and merging.
The author's blind spots reviewing the author's blind spots. Everyone approves.
The noise was the gate
The honest tell was sitting in my logs. Page after page of sessions named some variant of review this for security.
Hundreds of them.
I treated them as background chatter. I scrolled past.
Then I read one. It had caught the real bug I would have shipped.
That many review sessions firing on every change is a review system you're refusing to trust. The framing flipped on the spot. The noise was the gate. I just hadn't wired it as one.
A trigger plus a filter
Findings alone are not a gate. A gate is a trigger plus a filter.
The trigger is the architecture. The reviewers run on the event: every commit, in parallel, no invitation. There is no "remember to run the reviewer" step, because the day you rely on remembering is the day the risky change slips through.
The filter is adversarial. An unverified finding is noise. A model that flags 40 issues, 35 of them nonsense, hasn't reviewed anything. It has generated work for me.
So before a finding posts, another agent tries to refute it. Can it reproduce the bug? Is the security hole real or theoretical? Survivors post inline, can block the merge, and, where the fix is mechanical, get fixed on the spot. The rest die quietly.
Skip the filter and you retrain yourself to ignore the gate inside a week. That's worse than no gate at all.
Google measured the same failure at fleet scale (Sadowski et al., CACM 2018): cross a roughly 10% effective false-positive rate and developers dismiss the analyzer outright. Any false positive hands them, in the paper's words, "a justification for inaction". Tricorder enforces that threshold per check and holds the whole system under 5%.
The number that decides whether your gate lives isn't recall. It's the false-positive rate.
Don't bet the gate on one model
The reflex with LLM tooling is to pick one model and standardize. For review, that leaves coverage on the table.
One model is one distribution of misses. Standardize and you inherit all of it.
My gate runs three model families, one per vendor, each owning a domain. One takes security. One takes correctness. One takes types and tests.
Across 10 models on the Defects4J benchmark, the ensemble's union repaired 205 bugs against the best single model's 112. An 83% ceiling over the best soloist ("Wisdom and Delusion of LLM Ensembles"). Even a two-model ensemble, picked for diversity, beat either model alone.
On security review specifically, the DVDR-LLM ensemble work reports 10 to 12% higher detection accuracy than the average single model and 18% better recall on vulnerabilities spanning multiple files, with the gains growing as code complexity grows.
But I published the clean version of this claim once, and it's too clean.
Blind spots do not "rarely overlap". Model misses are correlated. Goel et al. measured it at ICML 2025 ("Great Models Think Alike and this Undermines AI Oversight"): mistakes across model families overlap, and the overlap grows as models get stronger. A model judging findings also favors models that resemble itself.
Naive consensus has its own trap. The ensemble paper found voting collapses into a popularity trap, with models converging confidently on the same wrong answer.
The version I stand behind is narrower: what slips past three vendors is smaller than what slips past one. It is not nothing. Measure the overlap. Don't assume it away.
Two house rules keep the fan-out sane.
Cost tracks value. Orchestration stays on the strongest model because coordination is where reasoning matters most. Deterministic, judgment-light work routes down to cheaper or local models. The top tier is a per-task decision, not an inherited default.
Collapse discipline. Fan-out means more latency, orchestration, and tokens. Reserve it for work where a miss costs more than the extra spend. Keep the routine path on one model.
Then measure what the extra models actually catch. If a seat isn't catching what the others miss, collapse it. A roster spot is not tenure. That rule eventually fired an entire three-model jury on another pipeline.
The editor of the reviewers
I'm not the reviewer anymore. I'm the editor of the reviewers.
The fleet owns "is this correct and safe." I own "is this wise."
Wise is everything the fleet can't see. Should this change exist at all? Is today the day to take this risk? No reviewer in the fleet holds that context. Only one of those jobs needs me awake.
The editor's other job is killing findings.
The fleet's scariest category, prompt injection, once went 68 for 68 false positives across 201 runs. Every finding flagged the artifact's own authored prompt text. I killed all of them and rewired the check. The anatomy post has the receipts.
An editor who can't kill bad findings is a rubber stamp pointed the other way.
Rubber-stamping is one tired human approving his own diff. This is several reviewers from different vendors, adversarially checked, gating the merge, while I decide whether the change should exist at all.
What this is not
This is not a pitch to build a review platform. The pieces already exist. They already fire on your changes. The work is wiring.
It is also not a license to point this at your team. I gate my own commits, on my own repos, by choice. Aiming an automated reviewer at other people's work starts with their consent.
The bar moved
DORA surveyed about 5,000 technology professionals for its 2025 report on AI-assisted development. 90% use AI at work. 30% report little or no trust in AI-generated code.
Both numbers are rational. AI adoption still correlated with worse delivery stability, unless paired with what DORA calls robust control systems: strong automated testing and fast feedback loops.
Nearly everyone has AI volume firing on their changes. A third don't trust what comes out. What turns that volume from instability into safety is the control system: the trigger and the filter.
The bar for "every change gets a real review" used to be "hire enough good engineers." It isn't anymore. Most teams are still staffing for the old bar.
The lesson is plain: automated review earns trust only when it fires without being invited and distrusts its own findings before asking anyone else to act.
Then the last question stays with a person: should this change exist at all?
That one still needs me awake.