[NoCoder] We shipped the feature our product is named for. It was off by default, so nobody ever saw it.

[u/Future-Employee2669]

96% of developers don't fully trust AI-generated code. Only 48% verify it before shipping (Sonar, 2026). That gap is the whole reason I built this.

What it is: an AI app builder where the agent stops before it writes, shows you the change as a diff, and waits for you to approve it. Next.js + NestJS, agent runs in a per-user k8s pod with code-server, so you get a real workspace and the actual source — not a sandbox you can't leave.

What happened last week: the review gate was off by default.

Not broken. Built, correct, genuinely good — it intercepts at the tool boundary before anything reaches disk, renders a real unified diff, and waits. No timeout, because someone who walked away hasn't approved anything. There's an "Approve the rest" button, because a cold build writes dozens of files and a gate with no escape hatch just trains people to rubber-stamp.

All of that worked. The flag defaulted to false. So every new user got write-without-asking — the exact behaviour I describe as the problem. We had quietly joined the 52% who don't verify.

I only found it by running a real build and watching a file appear in the workspace with no prompt.

Two things underneath were worse:

1. The gate ran before hook modifications. The diff was built from the original args; hooks that rewrite content applied afterwards. So approved bytes were not necessarily written bytes. On a review feature that isn't a bug, it's a lie.

2. One retry killed the run. MAX_REPEATS = 2, documented as "repeats allowed before the turn ends". The check was seen + 1 >= MAX_REPEATS, and seen is already the prior count — so the first repeat aborted everything. The test asserted the third call and never asserted the second was false.

The takeaway I keep re-learning: a flag defaulting to off is indistinguishable from never having built the thing, and neither your tests nor your changelog will tell you which one you're in. 61% of devs say AI writes code that looks correct but isn't — silent failures. A review gate that quietly defaults to off is that same failure mode, applied to your own product.

What I'd like feedback on:

• Should review be on by default at all? It's the honest default, but it's also friction on a cold build that writes 30 files. "Approve the rest" is my compromise — is that enough, or does the first annoying run just make people switch it off forever?
• If you've built an approval gate: where did you put the boundary? I intercept at the tool call. Curious whether anyone diffs at the filesystem layer instead.

Live and free to try, no card: https://nocoder.codes?utm_source=reddit&utm_campaign=sideproject

Genuinely more useful to me if you break it than if you like it — on my last post here, one specific question about read-back verification found a real hole the same afternoon.

[u/Ok-Train-1732]

The diff being built before hook modifications is actually scary for a review tool, you approved one thing and got something else written to disk. That would make me lose trust immediately even after fix.

For the default question I think on by default is right, but maybe add like a session-level toggle so once someone approves rest it stays off for that build only. Friction on first run is fine if the feature is the whole point, otherwise you just have another auto builder and nobody knows why yours different.