Pressure Driven Development
Coding agents made bad plans cheap to run. A spec earns its keep as a press, not a map: what must stay true, in view at the moment the agent acts, and expensive to ignore. A loop is engineering only when it carries that pressure across attempts.
Spec-driven development, the practice of directing coding agents by written specification, is widely suspected of being waterfall reborn. The suspicion is reasonable, and it is aimed at the wrong feature of the practice. What failed in waterfall was a particular understanding of what a specification is, and that understanding deserves to fail again. What succeeds, where the practice succeeds, is a different understanding that has not yet been named. The purpose of this essay is to separate the two. I shall call the first the Map View and the second the Press View.
What follows rests on my own experience of running coding agents in automated loops, and on the public accounts of others engaged in the same practice.
The Map View and what agents changed
On the Map View, a specification is a description of the finished software, written before the software exists and valuable in proportion to the accuracy of its prediction. Waterfall was the Map View applied with discipline, and it failed for a plain reason: a prediction written before any contact with reality has no source of correction, so that the work of months was routinely spent executing a misunderstanding.
What changed with agents is not the reliability of prediction, which is as poor as it ever was, but the cost of acting on one. Code has become cheap to produce, so a bad plan that formerly consumed months now runs in minutes. An agent given an underspecified task does not stop to ask what kind of feature is intended; it completes the description into a world of its own choosing, and it does so fluently. The failure of the Map View has accordingly become faster, and at the same time cheaper to observe: the failed test, the rejected diff, the benchmark regression now arrive within minutes of the prediction that caused them. A specification that is corrected by these arrivals stops being a prediction and becomes a record of what reality has refused to accept. A specification that is not so corrected is waterfall still, executed faster.
The correction explains why the practice can work at all. It does not explain why writing the document helps in the first place, and here the received explanation is wrong. The value of the specification lies, not in its power to predict the finished software, but in its power to narrow the field of action open to the agent at each moment of its work.
What a press is
I shall use the word press to denote anything that performs this narrowing: whatever stands in the agent’s context when a decision is taken, or pushes back afterward hard enough to return there, making some continuations of the work heavier than others.
The word is taken from football. A pressing team pushes up and removes time and space from the opponent in possession. The rules of the game forbid the opponent nothing new; what has changed is the cost attached to each of his options, and the observable result is that fewer options are taken and more mistakes are made. A coach’s instruction to play one-touch operates on the same object from the other side. It is not a law of the game, and a good player will break it when the situation demands; but it changes where the player stands, how early he scans, and which passes appear natural to him before the ball arrives. Neither the pressing team nor the coach forbids anything. Both operate on the relative weight of moves that have not yet been made.
For a football player the field of options is a manner of speaking. For a language model it is the literal object of computation. The model does one thing, which is to produce a continuation of whatever stands in its context, and an agent is such a model placed in a loop and permitted to act on its own output, one small decision at a time: which file to open, which line to change, whether the task is done. To press an agent is therefore to operate on the decisive object directly: to place material in the context so that some continuations become heavier than others, until the field of likely actions has narrowed. The agent does not experience the press. Its options simply become fewer, as the opponent’s did.
Salience and consequence
Whether an intended constraint presses at all is decided by two properties, which I shall call salience and consequence.
Salience is the share of the agent’s attention a rule holds at the moment of decision. Precision matters here, because the folklore has aged: current models are trained for close instruction following, and a controlled study of repository instruction files found that agents generally do follow them. What defeats a rule is rarely refusal. It is competition and distance. Adherence falls as instructions accumulate: in one benchmark the best frontier models held about 68 percent of 500 simultaneous instructions, and the curve is rediscovered from below by every practitioner who watches a rules file grow past a few hundred lines and the agent begin, in one Cursor user’s words, “just ignoring most of it,” until the always-on portion is cut back to a couple hundred lines and adherence returns. And adherence falls with distance inside the session: a factorial study of 1,650 Claude Code sessions found that where a rule sits within the file makes no detectable difference, while each additional function the agent generates lowers the odds of compliance by roughly six percent. The rule read at session start is not the same rule three hundred edits later. Salience is a property of the moment of decision, not of the file: a constraint stated once at startup competes with everything that has entered the context since, while the same sentence in the failing test the agent is reading right now arrives at the decision instead of before it.
Consequence is the cost of departure. The rule “do not add a dependency” costs nothing to leave while it is only a sentence: the dependency goes in, the build stays green, the task appears finished. Wired to a check that fails the build, the same departure costs a red pipeline the agent must repair before anything can be called finished. The vendors state the principle themselves: Anthropic’s documentation describes Claude Code hooks as deterministic control, ensuring certain actions always happen rather than relying on the model to choose them.
The two combine as a product rather than a sum. A rule that is salient without consequence is departed from at no cost. A rule that has consequence without salience bites only after the diff, when the choice it should have shaped has already been made. At zero on either axis nothing presses, and the two most common remedies fail on exactly these axes: more rules adds text that competes with itself, lowering the salience of every rule already present, and more gates adds enforcement that arrives only after the act. Every complaint of the form “the agent will not follow my specification” resolves, on inspection, into a zero on one of the two axes, and the repair follows from which one.
The rule is, moreover, only one container of pressure. A test, a naming convention, a file boundary, the visible record of a previous failure, and a plainly stated sentence of taste all press, provided they satisfy the same two properties.
What gets pressed
The things worth pressing are for the most part not tasks but invariants, contracts, and boundaries: that existing users can still log in; that an endpoint continues to mean what its consumers rely on it to mean; that authentication code and button copy are not the same kind of surface. Some of these are already present in the code and need only be read: every route passing through the same wrapper, a design system that punishes one-off components, a history in which schema changes always arrive with a migration note. A workflow that reads such regularities before writing acquires its first pressure at no cost. And structure presses from the other side too: a design system that offers the right component is a stronger press than any sentence forbidding the wrong one, because it makes the good continuation the easy one. Statements of this kind are not themselves pressure; they become pressure at the moment they are placed in view of the decision and made expensive to leave.
The loop and backpressure
A loop earns its place in this account because it is the mechanism by which late consequence is converted into early salience. The build failure that arrived too late to shape one attempt is placed in front of the next; the rejected review becomes the first line of the next plan.
Loop engineering is the phrase now attached to this practice, and the accounts traveling under it (Addy Osmani’s is the most complete) are catalogues of machinery: worktrees so parallel agents do not collide, skills so the project need not be re-explained, a second agent to grade the first, a schedule that runs everything overnight. Every part is real, and the catalogue still dodges the only question a loop raises: why the second run should produce anything better than the first. A loop whose iterations are not connected produces nothing that the first iteration could not have produced; it is repetition, not engineering. What improves the second attempt is, not the running again, but the return of the first attempt’s failure as pressure on the second. Geoffrey Huntley’s Ralph, while :; do cat PROMPT.md | claude-code; done, is remembered for its loop and was argued from its backpressure: the capture of what reality pushed back, and the insertion of it into the next attempt’s context. Backpressure is pressure arriving one iteration late, the same salience and the same consequence, and a loop is engineering exactly to the degree that it is built to carry it.
The loops I run myself, loopgen, are built on little more than this: a goal, a loop, and a file of pressure the loop rereads before every pass, amended whenever reality disagrees. “Do not touch the parser” is right until the day the only honest implementation needs one extension point. When that day comes the agent should neither sneak past the rule nor worship it; it should ask for the pressure to change. A press that cannot be amended is superstition with a build step.
Consequences for the practitioner
A loop can carry pressure; it cannot decide what deserves pressing. That part of the arrangement falls mainly on the human side. Some pressure can be read out of the code by anyone, the agent included. But the pressure that matters most can only come from a person: whether this software should be delightful or boring, whether this month rewards speed or polish. The code does not contain it and the model will not supply it. It remains human work, not because humans write the better code, but because a person carries the taste, and the fear, and the accountability for what the software does to the people who depend on it.
If this is right, then the skill to be cultivated in an engineer who directs agents is the placement of pressure: knowing what must remain true, and arranging for it to be present, and expensive to leave, at each moment a machine is about to act. The practice would then also deserve a more accurate name. The specification as document was never the active element, and the proper designation is, not spec-driven development, but pressure-driven development.
Loop prompts for coding agents: /goal and /loop. The pressure is a file the loop rereads.