Review is the gate

Nothing an agent produces reaches production or publication except through a gate: a machine checks it first, a human judges it second. What makes it a gate rather than a good intention is that it cannot be skipped. Not for a deadline. Not by the person who owns the repo. A gate you can route around is a norm, and norms go first under pressure.

Every company says it reviews things. What separates the ones that actually do is what happens at six on a Friday, when the person who has to approve the change is the person who wrote it and it has to go out today.

Decision rights

The question is not who reviews. It is who can skip the review, and the answer has to be nobody, including whoever set the rule up. A gate with an exception for the founder is a gate with an exception for the busiest, most senior, least interruptible person in the building, which is exactly the exception that will get used.

That is only enforceable by the platform. "We always open a pull request" is a sentence in a rules file. Branch protection with no bypass actors is a server refusing a push. The two feel identical right up until the week they differ. If you have not checked which one you have, assume it is the sentence.

Memory and context

Review the diff, not the artefact. A rendered page tells you it looks fine. The diff tells you what changed, which is the only question a reviewer can actually answer. Teams that review the artefact re-read work they already approved and miss the two lines that moved.

The gate also has to remember its own history. A check that goes red for a reason nobody wrote down gets re-explained every time it fires, and the third time somebody explains it they suggest turning it off. Every check carries a one-line answer to "what broke that made us add this", kept next to the check.

Execution

The machine leg is not fixed in size. It grows, and growing it is the actual work of this principle: every review comment that could have been a check becomes a check. Left alone, a human reviewer degrades into a linter with opinions, reliably catching the mechanical things, expensively, while the actual argument goes unread.

What the human is left with is the part no check reaches: whether the change is the one the spec asked for, and whether the claim it makes is true. Both are judgment and neither survives being rushed.

Governance

Gates have a cost and the cost decides whether they survive. A gate slower than the mistake it prevents gets routed around, and the routing is invisible because it does not look like a bypass. It looks like people batching changes to spread the cost of the wait, and a big batch is exactly what defeats review. Gate latency is a governance number, not an engineering detail.

Adding a gate is easy and popular after an incident. Removing one is political, because whoever proposes it is arguing for less safety. So every gate carries a stated failure it exists to prevent, and a gate whose failure no longer happens is a candidate for deletion. Otherwise the pipeline silts up and the routing starts.

Small teams hit a real limit here. When one person is the only human, the human leg is self-review, and self-review catches less. The machine leg covering everything mechanical helps, and a public record means the review that did not happen is at least discoverable. Neither is a substitute for a second person.

Observability

The only way to know a gate is real is to try to break it. Push a deliberately bad change, a schema violation, a dead reference, and see whether anything stops it. A gate nobody has tested is a gate you are assuming, and the assumption is usually a year old.

The number that says whether the gate holds is the bypass count: changes that reached production without passing through it. If your platform can report that, it is the honest measure. If it cannot, you do not have a gate. You have a habit.