Verify gates: catching agent mistakes before you do

The fastest way to waste your own time reviewing AI-generated code is to spend it catching things a computer could catch. A verify gate is the fix: an automated build-and-test pass that runs before you look, so your attention goes to the parts only a human can judge.

What a verify gate is

A verify gate is a check that runs automatically on an agent's finished work — usually your build and your test suite. It's a binary: pass or fail. Pass, and the work is eligible to merge (after your review). Fail, and it never reaches you in that state.

Catch it before you do

Agents produce code that looks done but doesn't compile, or that quietly breaks a test elsewhere. Those are exactly the failures a machine should catch. Running the gate first means you never open a diff that doesn't build — the embarrassing, mechanical mistakes are filtered out before they cost you a single minute.

What to put in the gate

Start with the essentials and add as needed:

• Build — the project compiles or bundles cleanly.
• Tests — your unit and integration suite passes.
• Lint & types — style and type checks, if you run them.

Auto-retry on failure

A failing gate shouldn't dump the problem straight on you. The task is retried automatically a set number of times — often a transient issue or a small miss the agent can fix on its own. Only if it still can't pass does it stop and route to your review queue, history attached. No infinite spinning, no silent failures.

Gate first, then review

The gate and your eyes are a team, not substitutes. The gate proves the change works; your review judges whether it's the right change — correct scope, sensible approach, no edge cases missed. Let the machine handle the mechanical layer so your judgment isn't spent on typos.

Don't review code that doesn't build. Make passing the build the price of admission to your attention.

What to put in your verify gate

A verify gate should mechanically catch everything a machine can, so build it from your existing checks. Start with the two essentials: the project builds (compiles or bundles cleanly) and the tests pass. Layer on what you already run — lint for style, type checks for type safety, and a quick smoke test if you have one. The gate is essentially your CI, run earlier: at the moment an agent finishes a task rather than after you've already reviewed it. Keep it fast enough that it doesn't become its own bottleneck — a gate that takes twenty minutes will slow your whole loop — and scope it to what actually predicts a good change. The point isn't to run every possible check; it's to make "passes the basics" the price of admission to your attention.

Handling flaky tests and slow gates

Two things undermine a verify gate in practice: flakiness and slowness. A flaky test that fails randomly will bounce good agent work back to review for no reason and erode your trust in the gate — so quarantine or fix flaky tests rather than letting them gate every run. Slowness compounds because the gate runs on every task across every parallel agent; if it's slow, your throughput drops. The fixes are ordinary good engineering: parallelize the test suite, cache dependencies so a fresh worktree doesn't rebuild the world, and split a giant suite so the fast checks fail early. An auto-retry on the gate helps with genuinely transient failures, but it's not a substitute for a suite you can trust. A fast, reliable gate is what makes running many AI coding agents at once actually pleasant.

The gate and review: who checks what

The verify gate and your human review aren't redundant; they're a division of labor. The gate answers a binary, mechanical question: does this change work — build, tests, types? Your review answers the judgment questions a machine can't: is this the right change, is the scope correct, are the edge cases handled, does it read like the surrounding code, is there a security or secrets smell? By letting the gate handle the mechanical layer automatically, you guarantee you never waste a minute reviewing code that doesn't compile, and your attention goes entirely to the parts that need a human. In Command Fleet the gate runs on every task and auto-retries failures before anything reaches your review queue — so the queue only ever holds changes that already passed the basics and are ready for your judgment.

Setting up your first verify gate

You almost certainly already have the pieces of a verify gate — you just need to point them at agent output and run them earlier. Start with the single command that proves your project is healthy: usually a build followed by your test suite, the same thing you'd run before pushing. Wire that as the gate so it executes automatically when an agent finishes a task, before the change reaches your review queue. If it passes, the work is eligible to merge after your review; if it fails, it auto-retries a few times and then routes back to you with its history. Once the basic gate is reliable, layer on lint and type checks. Keep it fast — cache dependencies, parallelize tests — so it accelerates your loop rather than throttling it. In Command Fleet the verify gate is a setting per project: define the command once, and every task across every agent is held to it automatically, so your review queue only ever holds changes that already build and pass.

Frequently asked questions