Never Use a Model Where Code Can Decide

One of 53 field notes on AI coding agents. The whole set, and the sources behind every number, is on GitHub.

Written with AI assistance. Figures without a traceable source were cut before publishing.

Writing code got cheap. Checking it did not. That gap is where the CI failures live, and the fix is not a better agent. It is a second program that does not trust the first one.

The Bottleneck Moved and Nobody Moved With It

AI coding agents raised output speed sharply, while the cost of review, tests and lint stayed exactly where it was.

That is the whole problem in one sentence. Production is up, verification is flat, and the queue forms at the narrow end.

Here is the sharper way to say it. As code gets cheaper, the expensive parts of a project stand out more clearly: finding the real problem, defining what the business actually means by a term, handling external systems that misbehave, and being answerable for what happens in production.

None of those got cheaper. So the honest reading of "AI wrote it in four minutes" is that the four minutes moved out of your day and landed somewhere further downstream, usually on a red pipeline at eleven at night.

The Rule That Makes Gates Work

One evaluation framework states the priority as a strict order: deterministic scorer first, rubric scorer second, human scorer last. Never use a model where code can decide, use a model only where it must, and reserve humans for calibration.

I have not seen a cleaner statement of the principle anywhere, though I may simply have missed it. It is also the part everybody skips, because asking a model "is this good?" takes one line and writing a real check takes an afternoon.

The same framework spans 5 dimensions (functional correctness, process quality, efficiency and cost, robustness and safety, and alignment with the intended experience), and it has been run in production on TPerf's performance-analysis agent rather than only argued about.

Five is more than most teams check.

Most check 1: did it compile.

What Code Can Actually Decide

The deterministic half is narrower than it sounds, and knowing its edges is what stops you from over-claiming. It covers 4 kinds of check: whether the specified tool was called and with the right arguments, whether the expected file exists and its contents look the way they should, whether the response contains or conspicuously does not contain a particular string, and whether the number of tool calls and the token spend stayed inside a threshold.

Fast, objective, reproducible.

Those three words are doing real work: a check that gives a different verdict on Tuesday is not a gate, it is a mood. Two out of three does not pass here.

The rubric scorer picks up what is left: the things code cannot judge but you can still describe in a structured way, like answer quality, tone, or how closely a convention was followed.

I would treat every rubric check as a debt rather than a feature. It costs a model call per run, it drifts when the model version changes, and it is the first thing to become quietly wrong without anyone noticing. That last part is what makes it dangerous rather than merely expensive, because a deterministic check that breaks starts failing loudly on the next run, while a rubric check that has drifted keeps returning a number and the number keeps looking fine.

Separate the Thing That Judges From the Thing That Works

Loop engineering describes the minimum viable automation as 5 parts: a goal, an executor, a verifier, a state log, and a stop condition, with the constraint that the evaluator and the executor must be separate. Karpathy is the reference point the source leans on: loop engineering is what fixes automation that keeps falling over.

The stop condition is the part I would install first. An agent with a verifier and no stop condition does not fail. It loops, which is worse, because a failure is loud and a loop is billable.

The same advice appears one level up, in how you organise the agents themselves: split them by responsibility instead of letting one conversation accumulate the requirements, the error output and the entire history, because a single agent playing several roles has nobody checking it.

It is the code review argument, restated for agents. You would not merge your own PR on a team of four, and there is no reason the rule relaxes when the other engineer is a model, especially when that model has already showed it will summarise its own output as a success while the tests are still red.

There is a prerequisite nobody enjoys. Making a workflow automatable means breaking it down to atomic steps and writing out the input, the output and the judgement rule for each. The implicit reasoning has to become explicit, or the agent skips a rung and drifts.

That is a day of writing before a single check runs, which is exactly why most people buy a tool instead. One definition of going AI-native is precisely the opposite: rewrite the workflow, the review, the quality gate and the measurement system, rather than procuring something.

What the Shipped Tools Actually Implement

no-mistakes runs a 9-step quality pipeline on every submission, deliberately does not bind to a single coding agent, and takes the stance that the human decides while the agent works.

It also handles the two things that get a PR bounced for reasons unrelated to the code: it routes fork pushes and PRs correctly, protects against data loss, and writes the PR description itself.

Unglamorous.

I suspect it is the highest-yield item in the whole list, because a rejected PR costs you the same round trip whether the code was wrong or the description was, and only one of those two is interesting work.

Agent Skills takes the other route: engineering discipline encoded as 24 structured workflows covering Define through Ship, with a checkpoint at every stage.

The detail I find genuinely clever is the Common Rationalizations table attached to each of the 24: a list of the excuses an agent reaches for when it wants to skip a step, each one answered in advance.

That is a very specific piece of engineering.

Somebody watched a model talk itself out of running the tests often enough to sit down and write the rebuttals, one by one, which nobody arrives at from first principles. It is a scar.

Agency Agents goes wider still, with 232 structured expert persona files, each carrying an identity, a workflow, delivery criteria and success metrics, compatible with 14 mainstream tools, and claiming an output-quality improvement of over 30%.

I do not believe the 30%. Not because it is implausible, but because "output quality" is undefined in the claim, and an undefined metric that improves by a specific percentage is a marketing number. The 232 files I believe.

Evidence Beats Assertion

The verification loop breaks at the same place on every platform: the agent can write the change but cannot see whether it worked on a real device. One tool closes that by reading the system accessibility tree into a structured page snapshot, then exposing a command line that lets an agent open the app, click, type, swipe and assert — saving screenshots, video, logs and performance traces as it goes. The tool is called agent-device.

Evidence, not a claim of success. I think this is the single distinction that matters. The difference matters because a model reporting on its own work is the least reliable narrator in the pipeline.

OfficeCLI reaches the same instinct through a much smaller decision: every command emits JSON, and the error messages are structured too, so the agent can reason about a failure and adjust instead of guessing at prose.

Structured errors are what turn a retry into a correction, and the gap between those two words is most of the difference between an agent that converges on an answer and one that burns your budget circling it.

Keep the Surface Small

One counterweight runs against all of this, and it comes from a coding agent built on an open base called Pi with only four tools, namely read, write, edit and bash, whose initial system prompt and tool descriptions together came to under 1,000 tokens.

Four tools, and I doubt most setups need a fifth.

A gate is only free if the thing being gated stays comprehensible, and every workflow you encode is surface area you now maintain. The tools in this piece all point the same way, but they point at different amounts of machinery, and the amount is the decision you actually make.

The discipline that keeps that honest is cold-start acceptance: turn the repeating work into a skill template, then verify from a clean start that the agent finds the right entry point and runs it without being nudged.

If it only works while you are watching, you built a demo.

What It Costs

A day of decomposition before the first check runs. A model call per rubric check, forever. A stop condition you will get wrong at least once. And the ongoing tax of maintaining every workflow you wrote down.

What you get back is narrow and worth it: the pipeline stops telling you things are fine.

Read next — more field notes from the same collection:

The $22K-a-Month AI Tool That Never Bought a Single Ad · What a coding-agent model costs, next to how it ranks · AI Model Costs: Beyond Per-Token Pricing · Claude Code and Codex for Office Automation · Your Agent Writes Code Faster Than Anyone Can Review It

Part of llm-api-pricing — field notes on AI coding agents. This one is also on the web, where it links out to the related write-ups. Every figure across the whole collection is also published as JSON and CSV, each row with the sentence it came from.

Want this priced for your own usage? The price table behind these write-ups is also a calculator — one page, nothing to install, no account. It reads the same daily JSON as the table, resolves the peak/off-peak clock for the moment you are asking, applies the long-context cliff to the request you actually send, and lets you put in your own cache-hit share. Did this save you an afternoon? A star on the repository is the whole ask — it is what puts these in front of the next person looking. The data is CC BY and does not require starring. One thing this piece could not settle: does anything in your pipeline right now ask a model to judge something code could have checked instead? Reply with yes or no — and if yes, one word for what it judges: style, naming, docs, tests. "no" is a real answer, and the cleanest one. The reply box is on the thread copy of this piece — one line answers it. No template, no title, nothing to organise first. Want a figure that is not in here yet? Say which metric, which provider, which unit in one line — one required field, and the page you came from is already filled in. Requests get turned into rows. Got a better number? Open an issue — the form already knows which write-up you came from; corrections and counter-data are the point.