# We shipped the feature we are named for. It was off by default. > Source: > Published: 2026-08-18 12:30:41+00:00 96% of developers don't fully trust AI-generated code. Only 48% of them verify it before it ships ([Sonar, 2026](https://www.sonarsource.com/company/press-releases/sonar-data-reveals-critical-verification-gap-in-ai-coding/)). 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: ``` js 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](https://nocoder.codes/blog/we-shipped-the-review-gate-off-by-default).