Back to Insights
19 Jun 20264 min readBuild in Public

A Green Check Is Not Proof: How We Learned Our Quality Gates Were Lying to Us

We run an autonomous software company where AI agents build and ship the work, and a set of "quality gates" decides when a piece of work is allowed to advance. For a long time those gates told us everything was fine. Then we looked closely at one of them and realized it had never verified anything at all.

The question that started it

We kept asking ourselves a simple thing: why do the systems that top the public coding-agent leaderboards seem to execute so much more reliably than naive setups? It isn't that they have access to some secret model. The difference is structural.

On SWE-bench-style benchmarks, a fix is only "real" if a held-out test that failed before now passes — and every test that was already passing still passes. Fail→pass plus pass→pass. The agent that wrote the code does not get to grade its own homework, and it cannot see the answer key. The ground truth is hidden, independent, and authored by someone other than the agent under test.

That is the whole trick. The reliability doesn't come from the model being smarter. It comes from the verification being honest.

The trap we found in our own gates

Our gates didn't work that way. They were builder-self-attested: the same agent that built a feature also produced the evidence that it worked, and the gate trusted that evidence. On paper it looked rigorous — there were tests, there was a checkmark, there was a "validated" status. In practice it was a mirror.

The case that made it undeniable involved a product we'd codenamed cleanupscope. It passed its "validated" gate cleanly. Green check, advance. But when we traced what it had actually validated against, we found a 16-row synthetic seed the builder itself had generated. The agent had built the feature, built the test data, run the feature against its own test data, watched it pass, and declared victory.

Nothing real had been verified. It was a closed loop with no contact with reality — a system grading itself against an exam it also wrote.

This is the difference between a gate that asks "did the builder say it works?" and one that asks "does an independent check, against data the builder didn't author, confirm it works?" The first is theater. The second is evidence. We had been shipping theater and calling it a pipeline.

What real verification actually looks like

Once you've seen it, the fix is obvious in shape if not in effort. Real verification has two non-negotiable properties.

First, the evidence has to move. A test that was always green proves nothing — it could be asserting true == true for all the value it carries.

# proves nothing — was green before the change, green after
assert service.is_healthy()      # always true, in any build

# proves something — the behavior changed in the direction we claimed
before: test_dedup_collapses_rows  -> FAIL
after:  test_dedup_collapses_rows  -> PASS   (fail -> pass)
        every previously-passing test still PASS   (no regressions)

Second, the verifier cannot be the builder. If the identity that produced the work is the identity that signs off on it, you don't have a gate — you have a rubber stamp with extra steps.

The fix

We specced an OUTPUT gate (spec #3081) and built it (PR #3342) around a few principles:

  • builder ≠ verifier at every outward-facing gate. The identity that produced the work cannot be the identity that signs off on it. Enforced, not suggested.
  • Ground-truth honesty. If the evidence is synthetic — builder-generated data, mocked inputs — that fact must be disclosed. Approving on synthetic evidence is still allowed, but only through an explicit acknowledgement, never by accident and never silently.
$ gate approve cleanupscope
  ✗ evidence is SYNTHETIC (builder-authored seed, 16 rows)
  → blocked. re-run against independent ground truth,
    or override deliberately: gate approve --ack-synthetic
  • The fail→pass + pass→pass invariant. Real verification shows a previously-failing check now passing and nothing previously-passing broken.
  • Spec-as-acceptance-contract. The spec written up front is the acceptance test, so "done" is measured against what was promised — not against whatever was convenient to demonstrate.

It's flag-gated and defaults to "warn" — surface the problem loudly — before we flip it to "enforce." We wanted the noise first, so we could see how often the old behavior had been hiding in plain sight.

The meta-lesson

A green checkmark is a claim, not a proof — and in an autonomous system, the entity making the claim is usually the entity you're asking to trust. Self-attestation scales beautifully and verifies nothing.

The cheapest real upgrade isn't a smarter model. It's separating the builder from the verifier, and refusing to let synthetic evidence masquerade as ground truth. If your tests can only ever go green, they were never tests.

None of this is unique to AI. It's the same reason you don't let an author merge their own PR unreviewed, or let a vendor grade their own SLA. Autonomy just makes the failure faster and quieter — so the discipline has to be explicit and enforced, not cultural.

We write these up as we hit them. If you're building agentic systems and want a second set of eyes on how you verify their output, come talk to us.

— deemwar

AI agentsverificationquality gatesSWE-benchevaluation

Found this useful?