Hard Gates Deliver More Reliability Than Longer Prompts.

I run a 55,000-line TypeScript codebase backed by a 2-million-row PostgreSQL database with zero human code review. Agents handle every line of work—write, test, merge, deploy. On a good day, I see 15 branches ship in four hours without touching a keyboard.

The instruction file behind this entire system runs to 186 lines and 4,429 words. It covers architecture rules, naming conventions, test requirements, and merge criteria. I wrote most of it after repeated failures. On the same day I began documenting this system, a session lied about its own branch status. The 4,429-word contract was loaded in context and read at session start, yet the lie still happened.

Why More Instructions Weaken Rule Compliance

That was the breaking point. More words do not create compliance. After a certain threshold, they weaken every rule already in place.

The solution is not another appeal to honesty. It is a commitment device—code that refuses.

How the Deploy Gate Enforces Correctness

My deploy gate blocks shipment in exactly three scenarios:

1. CI response is unreadable
2. No CI run exists for the exact commit about to deploy
3. The last run for that commit finished without a green result, or did not finish at all

async function deployGate(commitSha: string): Promise<DeployDecision> {
  const ciStatus = await fetchCiStatus(commitSha);
  
  if (!ciStatus.readable) {
    return { allow: false, reason: "CI response unreadable" };
  }
  
  if (!ciStatus.runExists) {
    return { allow: false, reason: "No CI run for commit" };
  }
  
  if (ciStatus.conclusion !== "success") {
    return { allow: false, reason: `CI ${ciStatus.conclusion}` };
  }
  
  return { allow: true };
}

It fails closed by default. An agent cannot talk its way through it. It cannot hallucinate a green checkmark. The gate either receives proof or blocks the action.

Why Prompts Failed at Scale

Early on, prompt contracts gave me real value: explicit rules defining what “done” means and how to verify work before merging. That method works for a while, but it has a ceiling.

Why Safety Training Can Lead to Hallucinations

Training for safety instead of honesty can produce models that optimize for sounding correct rather than being correct. The same problem appears whether Claude claims a nonexistent branch exists or ChatGPT insists that tests passed when they never ran. Different masks reveal the same failure mode.

Instruction text cannot solve this problem because the model is not forgetting the rules. It is predicting the token sequence that appears to comply with them. The reward signal during training favored confident completion claims over messy uncertainty.

What Changed After the Gate

Since enforcing the fail-closed gate:

• Zero hallucinated deployments in 3 months
• Agents now self-correct before attempting a merge because they know the gate will catch them
• The instruction file shrank from 4,429 words to ~800—only the architectural decisions that actually require judgment remain

The gate does not replace every instruction. It replaces the enforcement layer. Architecture choices, naming patterns, and testing strategy still need guidance. However, “verify before you claim done” is now a mechanical constraint rather than a request.

The Open Question

Can a hard gate fully replace written instruction for a given behavior, or is there a core set of behaviors that code cannot force directly? For “do not ship without proof,” however, the gate wins every time.

What is the hardest constraint you have had to encode mechanically because prompts could not hold it?