Backpressure

When an agent makes a mistake, you don't just ask it to try again. You change its environment so that mistake can't easily happen again: a line in its instructions, a script it can run, a check it has to get past.

Retrying fixes this one mistake, today. A change to the harness fixes that mistake for every future session, including ones you never watch.

Any automated check that refuses an agent's work and tells it why, so that it corrects itself before a person is involved. Types, tests, linters and security scanners can all do this.

Writing code is now cheap. Knowing that the code is right is not. Backpressure moves some of that cost from your attention to a machine that doesn't get tired. It moves only the part someone wrote a check for, and the rest of this chapter is about that line.

A control that acts before the agent does, steering it towards the right thing: an instructions file, a skill, a code template, an example to copy.

A good guide means the agent gets it right first time, which is cheaper than being told it got it wrong. But a guide is only advice. The agent can read it and do something else.

A control that acts after the agent does, observing what it produced so it can correct itself: a test run, a type check, a screenshot, a review.

Sensors are what make a guide trustworthy. Without one, you can't tell whether the agent followed the instruction or only said so.

A check run by ordinary code, so the same input should give the same answer, usually within seconds. Type checkers, linters and tests are computational.

You can rely on the result and run it a thousand times a day, which is why you turn rules into code wherever a rule can be written as code. Reliable doesn't mean relevant, though: it answers the one question it was written to ask, and no other.

A check where a model forms a judgement: an AI code review, a second agent grading the first. It can notice things no rule can express, such as whether a change makes sense.

It catches what computational checks can't. It also costs tokens, takes longer, can change its mind, and answers differently depending on how you ask. Run it after the cheap checks pass, never in place of them, and make it show its evidence.

A program that rewrites your code into one fixed layout: spacing, line breaks, quote marks. It doesn't change what the code does, and running it a second time changes nothing.

The layout of an agent's output can drift from one edit to the next, and a one-line change can arrive looking like a rewrite. You pay to read that noise, and so does the next agent. A formatter removes it without asking anyone to decide anything, so it costs no retry and no review.

A program that reads your code without running it and flags patterns you have decided are wrong. It takes milliseconds and never gets bored.

For an agent, the message is what matters. An error that names the fix is an instruction that arrives at the exact moment it is relevant, and costs nothing until then.

Writing an error message for the agent that will read it: what is wrong, where, and exactly what to do instead. The message goes straight into the agent's next turn, so it works as a prompt.

A person can look up what a terse error means. An agent takes the message as its next piece of context and guesses at whatever it leaves out. And it only costs you tokens when the rule was really broken, unlike a line in an instructions file, which is read every time.

A program that reads your code without running it and checks that each value is used as the kind of thing it is: no adding text to a number, no asking for a field that isn't there. For TypeScript that program is tsc, and tsc --noEmit only checks.

Nobody has to write a rule or a test first, so it covers code the agent wrote a second ago. Its errors come with a file, a line and a reason, which is close to a ready-made prompt. And it has no idea what you meant: a program can be perfectly typed and wrong.

A setting that makes a type checker stop trusting you in the places it otherwise would. The one that matters most: with it off, a value that could be missing is treated as if it were always there, so the crash waits until the program runs.

An agent only knows what the checker tells it. With strict off it is told nothing about a missing value, so it has no reason to handle one. Turning it on costs almost nothing on a new project. On an old one it can raise a flood of errors at once, which is a job for a ratchet.

A test about how the code is arranged and not what it computes: which folder may use which, where the database may be touched. It reads the imports (the lines where one file pulls in another) and fails if a forbidden one appears.

An agent takes the nearest route to a working change, and a forbidden import works perfectly well, so no ordinary test will complain. Once it is in, that shortcut is an example the next session can copy. AGENTS.md can state this rule. Only a test can hold it.

A script git runs when someone makes a commit. If it exits with anything but 0, the commit is refused. The git chapter showed how one works. The question here is what belongs in it: fast checks only, on what is really going in.

An agent commits often and reads the refusal at once, so this is a cheap place to catch things. It has two weaknesses. A slow hook tempts everyone to skip it, and because it lives on the machine doing the work, the agent is able to.

A script the harness runs when the agent tries to end its turn. If the script says no, the agent is told why and has to keep working.

An agent can finish without committing, so git's hooks may never fire. This one fires when it decides it is done, and turns "please run the tests before you finish" from a request into a step the harness takes whether the agent remembers or not. The agent can't end its turn while tests are failing until the hook lets it, or the harness's own limit is reached.

Everyone merges their work into the shared code often, and a server builds and tests each change on a clean copy of the project. That server is called CI too, and its green tick or red cross sits on the pull request.

A clean machine has only what was committed, so it finds what works only on the agent's laptop. A local hook can be skipped, and a required check on a server can't, unless the agent can edit the check itself, so the file that defines the check needs guarding as well. And ten agents get the same gate as one.

Run first the checks most likely to fail for each second they take, so a bad change hears no as early as possible. In practice that mostly means cheapest first: format, lint, types, unit tests, then the slow and costly ones.

An agent sits idle or burns tokens while it waits, and every retry goes through the line again, so a slow first failure is paid for over and over. Good work doesn't get any faster from this. Only the bad news does, and that is where an agent spends its time.

A set of conditions work has to meet before it may go further, where failing any one stops it: types clean, tests pass, no new security findings. It answers yes or no, and nobody gets to argue with it on the day.

A mechanical gate can only refuse what someone thought to check. An agent can pass every one and still have built the wrong thing, because the behaviour that mattered was never asked for, so no check knows it is missing. Someone reading the code and thinking about the job sometimes will. A gate works with a good brief. It can't stand in for one.

What happens when a check says no to good work too often: nobody believes its no any more. Each wrong no is a false positive. So count how often a check's no turned out to be right, and keep it, fix it or demote it on that number.

People get tired and start clicking through. An agent doesn't get tired and does what it is told, so it will rewrite good code to please the check, spending a try and more tokens. Either way, a check that cries wolf costs more than it looks.

When a check can't run or crashes, treat that as a failure and stop, rather than letting the work through. The opposite, fail open, lets the work through when the check breaks.

A check that quietly stops running looks exactly like a check that keeps passing. This is how a project can go months with a security scan that never scanned anything.

The rule that nobody gets past a check by switching it off: skipping the hook, silencing the error, deleting the failing test. An agent may try any of these, so the rule has to be held by something that can see them, and not by asking.

A person knows --no-verify is cheating. An agent told to make the checks pass can see removing the check as a solution, and can then truthfully report that everything is green. A line asking it not to is only a guide. You need something on a machine it can't edit, looking at what changed.

A rule of thumb: when the agent makes a new kind of mistake, add something that catches that kind from then on. On an old codebase, record today's count of a problem and fail only when it goes up. Quality can then rise, and it can't quietly slip back.

Without it you fix the same class of problem again and again. With it, your instructions file becomes a list of real past failures, which is also the best evidence you can show of your own process.