Can your verify gate actually fail?

Andréas, a full-stack developer and CTO, discovered that his automated verify gate, designed to lint, typecheck, build, and run tests before merging AI-generated code, was failing to catch broken code in three out of four repositories. The gate returned a green status without running any tests due to a configuration fallback that treated missing gate steps as success. He fixed the structural flaw by making empty gate configurations fail explicitly and added missing build steps to the affected repos.

I let Claude Code commit directly to my repositories. I don't review the diffs. I didn't think I needed to, because I built a deterministic verify gate — a script that lints, typechecks, builds, and runs tests. If the gate goes green, the PR merges automatically. I trusted that gate implicitly. Until I actually sat down and asked the one question that matters: If an agent pushes completely broken code right now, will this gate actually go red? Not "is the script configured?" Not "does the file exist?" Will it actually fail? Turns out, for three out of my four repos, the answer was an emphatic no . The gate was returning GREEN without running a single line of code. My gate script is repo-agnostic. It looks up the repository name in a policy JSON file gates.<repoName and falls back to a default if it doesn't find one. Here is the PowerShell logic driving the whole operation: php $steps = $policy.gates.$RepoName if $null -eq $steps { $steps = $policy.gates.default } if -not $steps -or $steps.Count -eq 0 { Write-Log "GREEN no gate steps configured for '$RepoName' " exit 0 <-- Unconditional green } And here is my config file: "gates": { "app": "npm run lint", "npm run test", "<design-gate script " , "default": } Look at that exit code. If a repo doesn't have an explicit entry in the JSON file, it falls through to default: . The script sees zero steps, prints GREEN , and exits with 0 . The runner sees exit code 0 and instantly merges the code. I built a system where having no tests configured is structurally identical to passing all tests. When I audited all four repos the runner is allowed to touch, the reality was pretty grim: app The Runner itself : npm run lint runs, but tsconfig explicitly excludes the runner/ directory — meaning build isn't in the gate at all, so client/server boundary breaks ship freely. Vitest runs 28 test files, but the glob pattern completely misses .test.tsx files. product Next.js app : tsc --noEmit , vitest 10 suites , and next build ready to go in package.json . None of them were wired into the gate config. It had 0% coverage purely because of lazy config debt. notes Markdown vault : portfolio Vite site :The real bug here isn't missing npm scripts. The structural flaw is that an empty gate defaults to success . To fix this properly: $steps.Count -eq 0 , the script must exit non-zero or return an explicit UNGATED status. A missing key should break the build, not bypass it. product repo was fixed with a single line in policy.json . npm run build to the gate costs execution time, but it's the only way to catch real deployment breakers. tsconfig and fix the Vitest globs before someone writes a .tsx test that never actually gets executed.If you run AI agents against your codebase without reading the diffs, go break a file on purpose and run your gate. If it doesn't yell at you, you don't have a safety gate — you just have a script that automatically approves bad code. I'm Andréas — full-stack dev, CTO at a B2B SaaS, building my own agent tooling. Portfolio: https://andreas-bodin.vercel.app