Our Agent Gate Blocked Every Bad Change. So Everyone Started Rubber-Stamping It.
We built a gate for agent work. It blocked bad changes beautifully. That was the problem. Nobody read it anymore.
This is the story of how a perfect control trained the whole team to approve on reflex, and what the fix actually was. Spoiler: it wasn't a better gate.
How a gate dies
The sequence is boring and inevitable.
First, the gate catches real problems. Blocked changes save real weekends. Trust in the gate grows.
Then, agents start producing most of your diff volume. Review queues fill up. Every approval is the same ritual: open diff, it's long, the gate is green, the tests passed, approve. Nobody says they're not reading. Everyone is speed-reading the summary, the checks passed, that's the entire review.
The gate didn't fail. It succeeded itself into ceremonial status. A control people trust blindly is a control that no longer exercises judgment, it just adds latency before the same yes.
The moment it gets noticed is always the same one. Three hundred lines of agent diff, the summary says tests passed, the finger is already moving toward approve. Then something feels wrong, a second look happens, and the second look finds it: a test the agent wrote for its own change, asserting the wrong thing, passing, because it was testing its own behavior. The gate was green. The gate was right, technically. The review was about to be wrong, and the review was a tired human.
The shape shows up in real release work: a green pipeline that lied, a check that silently did nothing while reporting success. The failure isn't in the tools. It's in the relationship between the tools and the tired human at the end of the chain.
The gate is a product surface
Once you accept that the human is part of the gate, the design problem changes completely. A gate isn't a checkpoint, it's an interface, and interfaces have UX whether you design it or not. So design it:
Choices, not proofreading. Instead of a wall of diff, the gate presents decisions: this changed files outside its scope, allow or reject? Each one is a real question a human can answer while tired.
Blast radius first. The gate leads with what the change touches: credentials, migrations, API surface. You judge danger before you judge elegance. Elegant agent code is cheap. An agent touching auth is the thing to slow down for.
Per-change, not per-batch. Four agent PRs in one approval is four chances to say yes when you meant to say no to one. One at a time, no matter how much the queue begs.
Force the failure into view. If a check is green, show me what it ran and what it covered. The summary saying "tests pass" is a claim. The artifact is the evidence, and the gate should surface the evidence by default.
Why this actually matters now
Agent volume makes this urgent, because the review bottleneck is the one everyone's feeling. Harness's 2026 survey put it at 81% more time spent on review work than a year ago, and it's the top tax on all this speed. The tool response to that has been more AI review, more automation, more gates.
But every automated layer you add without touching the human loop just accelerates the rubber stamp. The bottleneck was never the checking. It was the judgment, and judgment can't be outsourced to a system whose output you trust enough to stop reading.
There's an uncomfortable symmetry with the agents themselves. We ask if we can trust the model, tune its guardrails, gate its tools. Then a human skims its output at 11 p.m. and approves in nine seconds. Which one of those two is actually unguarded?
What I can't claim
Better gate UX is not a security control. It's an attention allocator. It raises the floor on tired mornings, it doesn't raise the ceiling of what a good reviewer catches. And I'll be honest about the failure mode I still don't have a fix for: the moment people learn the gate is good, they trust it, and trust is the thing you needed to keep them skeptical. Every fix for that is cultural, slow, and fragile.
We didn't need a smarter gate. We needed a gate a human could disagree with at 8 a.m. That's a UX problem, and it was ours, not the agent's.
How many seconds do you actually spend on an agent PR before approving? Don't estimate. Time it.
Top comments (7)
A review gets faster to trust when it shows only what changed and why, in a few plain lines, instead of the whole diff. One habit that helps: ask the agent to end every change with "what could this break?" in one sentence. If that sentence is vague or empty, that is the signal to slow down, and it gives the human something specific to disagree with.
Agreed on the second half. One way to make the disagreement a habit: the reviewer writes one line back, either "agree" or "this could also break X". Even a one-word "agree" counts as an answer, and it makes silent rubber-stamping visible in the history.
"Succeeded itself into ceremonial status" is the best description of a green checkmark I've read. The agent writing a test for its own change that asserts the wrong thing is the part that scares me most, because it looks like extra safety. Blast radius first makes a lot of sense to me. I'd much rather answer "this touched a migration, okay?" than scroll 300 lines hoping my eyes catch it.
The detail that stuck with me is the agent writing the test for its own change. I'd make that its own blast-radius line in the gate: if the same run touched the code and the assertion, say so up front and let the green check count for less. A test the agent wrote against its own behavior proves the change is consistent with itself, not that it's right.
I'd push a little on per-change review too. One PR at a time helps, but the reflex comes back by the third one in a row. Making the reviewer answer one question in their own words before approve is clickable, something like "what breaks if this is wrong," does more than any layout change. Nine seconds gets hard when you have to type a sentence.