There is a strange failure mode that appears only after your tools become powerful enough.
At first, every new gate feels like discipline. A check for dangerous commands. A check for leaked credentials. A check for missing tests. A check for weak specifications. A check for changes that sound risky. A check for work that does not look "ready".
Each one is defensible in isolation. Each one has a story. Each one catches something real, once.
Then, slowly, the system turns into a festival of false positives.
The gate blocks the work it was built to protect. The check meant to improve quality starts preventing the quality improvement from landing. The author learns to route around it. The reviewer learns to ignore it. The alarm becomes background noise — which is worse than no alarm, because now the real signal arrives wearing the same face as the ten false ones before it.
A gate that judges a proxy will eventually block the thing it was built to protect.This is not a tooling bug. It is a category error about what can be decided, and when.Some things are structurally decidable. A secret appeared in output. A command is about to delete a directory. A process is opening a file outside its boundary. A write is targeting a forbidden path.
Those should be prevented at the wall. There is no reason to let the dangerous thing happen and clean it up afterward. The system can know enough, early enough, to stop it cold.
But many of the things we care about most are not like that.
Is this specification good enough? Does this change have the right tests? Is the implementation complete? Is the design coherent? Is the work actually done?
Those questions are real. They matter more than the first list, not less. But they are not structurally decidable at the moment we are most tempted to gate them.
We inspect the prose. We pattern-match the description. We look for phrases, missing filenames, suspicious words, absent sections. The proxy gives us something machine-readable, so we quietly confuse it for the thing itself.
But the proxy lies.
A strong specification can look thin. A weak one can contain all the right headings. A necessary change can use frightening words. A bad change can pass every checklist. The artifact is what matters; the gate sees only the shadow of the artifact, and then rules on the shadow.
The dangerous dream of automation is not that it lets us do reckless things. It is that it lets us build bad restraint very quickly.
That is the part that only shows up at scale. A human reviewer holds the proxy loosely — they read "delete" in a sentence and understand it is describing what the change avoids, not what it does. A pattern does not. Give a capable system the ability to gate on language, and it will gate on language perfectly, including all the times the language was never the point.
The lesson is not "do not build gates." The lesson is to separate two classes of control and stop letting one impersonate the other.
Prevent the dangerous structurally. If a credential leaks, block it. If something tries to read outside its boundary, stop the read. If a command crosses a line that should never be crossed, deny it before it runs. These are decidable, and the cost of being wrong is real, so the wall is the right place.
Reconcile the fuzzy after the fact. If the question is quality, completeness, or intent, do not pretend a cheap proxy can settle it at the boundary. Let the work land into a controlled place. Look at the artifact, not its description. Compare it to the original intent. Decompose what is missing. Open follow-ups. Tighten the system based on what actually happened, not on what the words predicted would happen.
That is slower than a regex. It is much faster than living inside a false-positive machine.
at the wall leaked secret, destructive command,
out-of-bounds write -> prevent, always
in review is it good, complete, intended?
-> accept, then reconcile
The tell that you have confused the two is simple: people start adding effort whose only purpose is to satisfy the gate. They pad the description to clear the checker. They reword a sentence so a word-matcher relaxes. They pass the override flag by reflex. None of that work improves the artifact. All of it exists to appease a proxy. The moment your contributors are writing for the detector instead of for the problem, the detector has become the problem.
When you can build a detector for anything, the temptation is to detect everything, because each detector is easy and each one feels responsible.
The maturity is in restraint: asking which decisions belong at the wall, and which belong in review — and refusing to let the easy, machine-readable proxy stand in for the hard, real judgment just because it compiles.
The wall is for danger. The review is for judgment. Confuse them, and the system becomes an oracle pretending to be a mirror — confidently wrong about the things it was never able to see.