WorkWritingAboutContactGet in touch
All writing
4 min read

Every commit gets reviewed by a fleet I don't manage

Hundreds of "review this for security" sessions in my logs looked like noise. They were a review gate I hadn't bothered to trust. So I wired them as one.

Every change I push gets a full review before a human looks at it. Security, correctness, the obvious dumb mistakes. Not by me, and not by a teammate. By a fleet of agents that runs on every commit, posts what it finds, and never asks me to babysit it.

I don't manage that fleet. I built the wiring once and now it runs whether I'm watching or not. That distinction is the whole post.

This is not "AI writes my code," and it is not "which model is best" (that's a different post). It's about the unglamorous thing that actually decides whether software is any good: review. And what happens when you stop treating it as a person's job.

Before: Me reviewing my own diff, then Merge - one tired reviewer approving themselves. After: Commit flows into a Fleet Gate that reviews, verifies, and blocks, then to Me for judgment only - every commit, no babysitting.Before: Me reviewing my own diff, then Merge - one tired reviewer approving themselves. After: Commit flows into a Fleet Gate that reviews, verifies, and blocks, then to Me for judgment only - every commit, no babysitting.
The shift - from one tired reviewer approving their own diff to a gate that runs on every commit.

The bottleneck it killed

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. That is not review. That is theater with one actor.

The honest tell was in my logs: page after page of sessions named some variant of review this for security. I treated them as noise. Background chatter.

That was the mistake. That many review sessions firing on every change isn't clutter. It's a review system you're refusing to trust. The day I actually read one and saw it had caught a real bug I'd have shipped, the framing flipped. The noise was the gate. I just hadn't wired it as one.

How the fleet runs

A commit or PR fans out to three independent model families - one owning security, one correctness, one types and tests. All three feed an adversarial check that tries to refute each finding. Findings that survive go to the Gate, which posts inline, blocks the merge, and auto-fixes where it can. Findings that fail are dropped. The Gate hands off to a human for the 'is this wise?' judgment call.A commit or PR fans out to three independent model families - one owning security, one correctness, one types and tests. All three feed an adversarial check that tries to refute each finding. Findings that survive go to the Gate, which posts inline, blocks the merge, and auto-fixes where it can. Findings that fail are dropped. The Gate hands off to a human for the 'is this wise?' judgment call.
Three independent reviewers, adversarially checked, gating the merge. The human only makes the call a machine can't.

Three independent model families, each owning a domain, running in parallel on the event. No "remember to run the reviewer" step, because the day you rely on remembering is the day the risky change slips through. The trigger is the architecture.

The step that turns noise into a gate is the adversarial check. An unverified finding is noise: a model that flags forty issues, thirty-five of them nonsense, hasn't reviewed anything, it's generated work for me. So before a finding posts, another agent tries to refute it. Can it reproduce the bug? Is the security concern real or theoretical? Survivors post and can block the merge. The rest die quietly. Skip this layer and you retrain yourself to ignore the gate inside a week, which is worse than no gate at all.

What's left for me is a posture shift. 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," and I overrule it when it's wrong. That isn't rubber-stamping. Rubber-stamping is one tired human approving their own diff. This is several independent reviewers, adversarially checked, gating the merge.

The fleet owns "is this correct and safe." I own "is this wise." Those are different jobs, and only one of them needs me awake.

What this is not

Not a pitch to go build a review platform. The pieces already exist and already fire on your changes. The work is wiring, not inventing.

And 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 opens with their consent, not your enthusiasm.

The bottom line

If you work solo or on a small team, you almost certainly have the pieces for this already, firing on every change, and you're probably filing them under noise. Wire the trigger to the event, put a verification step between the findings and your attention, and let it run.

The bar for "every change gets a real review" used to be "hire enough good engineers." It isn't anymore. That's the part worth sitting with.

Back to all writing