96% of developers don't fully trust AI-generated code. Only 48% of them verify it before it ships (Sonar, 2026).
That gap is the reason our product exists: you review every AI change as a diff before it touches your project.
Last week I found our review gate was off by default.
The mechanism was never the problem. The agent is intercepted at the tool boundary, before anything reaches disk. You get a real unified diff, and the run waits. There's no timeout, because a user who walked away hasn't approved anything.
There is also an "Approve the rest" button, deliberately. A cold build writes dozens of files, and asking dozens of times produces rubber-stamping — which defeats the entire point of a gate.
All of that shipped and worked. And reviewChanges
defaulted to false
.
So a new user got the same write-without-asking behaviour as every prompt-to-app tool we describe as the problem. We had quietly joined the 52% who do not verify.
I found it the only way this class of bug can be found: by running a real build and watching the agent create a file in the workspace without asking me a single question.
The gate ran on the original tool arguments. Pre-write hooks — which can rewrite file content — were applied after the user answered.
So if a hook rewrote content
, you approved one change and a different one reached disk. On a review feature, that is not a bug, it is a lie.
The order is now: safety hooks → hook modifications → user review of the final arguments → write.
When a user rejects a change, models sometimes re-propose it. We cap that:
const MAX_REPEATS = 2; // repeats allowed before the turn is ended outright
The check read seen + 1 >= MAX_REPEATS
, and seen
is already the count of previous rejections. So the first repeat satisfied it, and the orchestrator turns that into a full run abort.
One innocuous retry killed everything the user was doing.
The existing test asserted that the third request stopped the run. It never asserted the second one did not.
A feature flag defaulting to off is indistinguishable from never having built the feature. Your tests pass either way. Your changelog says you shipped it either way. Nothing in your pipeline knows the difference between "built" and "reachable".
61% of developers say AI produces code that looks correct but is not — silent failures. A review gate that quietly defaults to off is exactly that failure mode, turned on your own product.
The fix was one boolean. Finding it took running the thing like a user and watching what it actually did.
Originally published at nocoder.codes.