Pressure Driven Development
|Pressure is the concept I design agent harnesses with, and it came from football.
Everyone is naming machinery right now. Spec-driven development on one side, loop engineering on the other, and the argument between them is about which document or which orchestration deserves to run the agent. Pressure is the concept I reach for underneath both, when I design anything around an agent, the harness, the loop, the rules file, the review. It is not a proposal for a new way to develop software. It is the thing I check every piece of the setup against: what does this make heavier, and for whom.
Where it came from, for me, is games. I spent years in Dota where pressure is the daily texture of the game, constant harassment, aggressive positioning, the enemy carry with less and less space to farm until his choices become predictable enough to punish. And football, where the same thing has a name and a school. Klopp built a whole era on it, and his line is the concept in one sentence: gegenpressing is the best playmaker in the world. The press does not just deny the opponent. It creates your chances. Pressure is where your best moves come from, which is a strange thing to say about a defensive act.
For a player the space that shrinks under pressure is a figure of speech. For an agent it is the literal object. A language model only ever does one thing: it looks at everything in front of it and produces the next piece. Whatever is sitting in that context is what chooses the next token, and an agent is that same machine put in a loop and allowed to act, one small decision at a time, which file to open, which line to touch, whether it is done. So pressing an agent is reaching into that field and making some continuations heavier than others, until the wide range of what it could do next quietly narrows. It never feels the press. The options just get fewer. The agent is your player, reality is the opponent, and you hold the whistle and the training ground.
Earlier coding models had a famous habit: mock everything until the test tests nothing. The suite goes green and nothing was ever run. Say we add a rule to prevent it, mock only what you cannot run, and walk it across the whole pitch, pun intended.
The coach’s instruction
A coach says play one-touch. It is not a law of the game, and any player can break it when the moment asks. But the instruction changes everything before the ball arrives: where he stands, how early he scans, what kind of pass he considers natural.
The rule works only if it is in the agent’s context at the moment of the decision. On line 200 of a config file read once at startup it is not there, however true it is. Sitting beside the code being edited, it is. Same words, what moved is where they sit. Salience is a property of placement, not of wording, and it is why adding more rules so rarely helps: every new rule lowers the odds that any of them is in view when the ball comes.
The instruction is also the pressure that gets revised. At halftime the one-touch call can change, because the first half pushed back. A rule file should be the same kind of document, rewritten by contact, and I will come back to what happens when it isn’t.
The teammate’s run
Thomas Müller invented a name for his own position: Raumdeuter, the space interpreter. He is already where the pass becomes obvious. The option appears in the field and the ball goes there, and nobody had to say a word.
This is the pressure I find most underrated in agent work. A withTestDb() that already exists, spinning up the real database in one line, typed, used by every neighboring test, presses harder than any sentence about mocking. Delete every rule on the subject from the repo and it still presses, because reaching for the helper that is already there and used by every test nearby is simply the most natural continuation. The real database became the cheap path, so the mock stopped being reached for. Design systems, wrappers, one blessed way through the codebase, all of it is Müller making the run. It never looks like enforcement.
The opponent’s press
Now the same rule as a cost. “Don’t mock the database” as a sentence costs nothing to skip, the mocks go in, the suite is green, the task looks finished. Wire a check that fails any spec with no real I/O and skipping the rule now costs a red pipeline the agent has to stop and clean up. That is consequence, a property of wiring, whether the rule is connected to anything that can push back. The failing build, the rejected diff, the benchmark that regressed, these are reality pressing up the pitch, taking away the time and space the agent thought it had.
The two have to meet. Visible but free to ignore usually gets ignored, and a cost that was never in view only bites after the diff, once the choice it should have shaped is already made. Closer to a product than a sum: zero on either side and nothing presses, a note no one reads or a gate no one saw coming. When an agent won’t follow a spec, find the zero first. And there is a third repair, the run: build the utility, so the rule does not have to press alone.
The referee
Offside is a lint. It fires the moment you go early, and the players argue it every week without changing it once. The arguing is free. The flag stands.
Agents rarely delete a failing test outright, but sandboxes exist because nobody wants to keep betting on that, and the softer moves are everywhere: hardcode the expected value, mark the test skipped, or, in the most elegant recorded case, overwrite the equality operator itself so the check comes down to 1 == 1. Every one of those is a legal edit unless something makes it not one. A check the agent can rewrite is a match where the players hold the whistle. The gates that press live out of reach, in CI config the agent cannot touch, in a review it does not control.
The referee is also where the mocking rule gets honest. A check can count mocks, the literal case, and cannot tell a justified mock from a test that no longer tests anything. The semantic version of the rule needs a reviewer that reads meaning, and a second agent reviewing the diff against exactly the stated rules is a referee you can hire for that.
The film session
Bielsa watched more tape than anyone, hours of it for every opponent, and his teams walked out knowing what the first half would look like before it was played. The tape is the part of football that moves pressure through time: what Saturday’s match did to you becomes what Tuesday’s training presses for.
This is what a loop is for, and it is the part the current excitement about loop engineering keeps cataloguing without naming. Worktrees, skills, a second agent grading the first, a schedule that runs while you sleep, Addy Osmani’s writeup has every part, and the persistent state, the verifier, the stopping condition are all backpressure in substance. The principle that makes them one thing: a loop earns its keep only when the failure from one attempt comes back as pressure on the next. Geoffrey Huntley’s Ralph is the loop at its most naked, while :; do cat PROMPT.md | claude-code; done, and his point was the capture: what reality pushed back gets fed into the next attempt. A team that replays its fixtures without ever watching tape is not training. It is just playing more football.
The over-drilled team
Van Gaal’s Manchester United obeyed. The possession numbers went up, the structure held, and the players called the football scripted, because the only behavior that survived the drilling was the pattern. The creative pass died somewhere on the training ground.
Agents fail the same way under overpress. Squeeze the field too hard and the surviving behavior is compliance theater: longer summaries, smaller diffs, greener tests, worse software. Conte drills his teams at least as hard and they stay dangerous, so what separates the two is what the drilling selects for. Every press should have to answer two questions, what bad move does this make harder, and what good move does it preserve.
The manager
Some of the press is already in the code, waiting to be read, every route through the same wrapper, schema changes that always come with a migration note, the standings of a league the agent joined mid-season. A good workflow reads that before it writes a line.
But somebody decides what kind of team this is. Whether the product should be delightful or boring, whether speed beats polish this week, whether the team is quietly shedding abstractions because the architecture got too clever, the code cannot tell you any of that, and neither can the agent. It stays human because we are the ones carrying the taste and the fear.
Manager pressure also expires. “Do not touch the parser” is right up until the only honest implementation needs one extension point, and at that moment the agent should surface the collision instead of sneaking past the rule. Then the human amends the press, or defends it. A press that cannot be amended becomes a superstition with a build step.
Full time
Pressure is how I learned to win games: create it, watch where the opponent’s play breaks, and you know what they were relying on. Agents put me on the other side of it for the first time. The agent plays every match it is given, never tilts, never argues the whistle. The football on display is the press, nothing more.
The loops I run are loopgen. /goal and /loop. The pressure is a file it rereads.