Deterministic review gate

Compiling the checkable part of a team's review guidelines into deterministic checks — linters, formatters, pre-commit hooks — so that model-based review is spent only on what genuinely needs judgement. The model appears once, at compile time, turning prose rules into code; it does not run on every commit.

Named here from stop-burning-tokens-on-code-review, which reports the economics that force the question.

The shape of the argument

Three properties do the work, and none of them is "the linter is smarter":

• Latency. Seconds against tens of minutes (27s for a full sweep, against a 10–30 minute model review). A check that returns while the author is still in the file is a different tool from one that returns after the context has been swapped out.
• Determinism. The same diff produces the same comment every time, so a reviewer learns to dismiss a known rule instantly. A model's review has to be read each time, because it might be saying something new. This is why noise from a model review costs more than noise from a linter.
• Position in the loop. A deterministic check runs in the editor and on pre-commit, which for an agentic team means it fires before the agent opens a pull request. Model review is structurally after-the-fact.

Why it is an agent question, not a lint question

Linters are old. What is new is that the volume of code under review is now set by agents rather than by typing speed — 2,900 pull requests in a quarter in the reported case — and that per-review model cost scales with it while per-review linter cost does not. At that volume, "have the model check the model" is a per-commit expense on the hot path, and the cheap move is to spend a model once to generate the rule and never again.

It also inverts the usual direction of the spoke's guideline artifacts. claude-md and agents-md hold project rules as prose for the agent to read and, hopefully, follow; a deterministic review gate takes the same prose and makes following it not optional. The two are complements: what can be compiled should be, and what cannot stays in the instruction file.

Where it sits against the rest of the verification thread

• agent-loops-verification argues verification is the binding constraint once loops replace prompts, and proposes better environments to verify in. This is the opposite economy: remove the model from the check rather than give it a better place to run.
• shipping-without-human-verification proposes automating the human out of review entirely. A deterministic gate is the conservative version — automate the mechanical half and leave the judgement half where it is.
• agent-guardrails bounds what an agent may do; this bounds what an agent may land.
• constraint-evading-behavior is the standing caveat. Agents satisfy a check's letter while defeating its purpose, and a deterministic rule is easier to game than a reviewer's reading of it. No source here measures how often a compiled rule gets evaded.

What nobody has measured

Whether the compiled rules catch what the model review caught. The reported case measures cost and latency on both sides and defect detection on neither, so the trade — cheaper and faster against possibly blinder — is asserted rather than shown.

Related

stop-burning-tokens-on-code-review · jev-code-reviewer · agent-loops-verification · shipping-without-human-verification · agent-guardrails · constraint-evading-behavior · claude-md · agents-md · agentic-coding-harness · synthesis