Attention Is All We Have

The first weeks with an agent are exciting. It writes in an hour what used to take a day, and you catch yourself handing it things you would never have started alone. Then, quickly, the day changes shape. It goes to reviewing its pull requests, one after the other: a thousand green lines, then the next thousand. Nobody wants to review an agent's code, and yet it has become most of the job. We review for one reason: to keep a system we control and understand. I think the harness we put around our agents should be judged on that: on the control it gives back for less attention than review costs, not on what it gets the agent to produce.

The bottleneck moved from writing to review#

We ship more than ever, and that is the problem. Writing used to be expensive, so it capped what reached review. It costs almost nothing now. Review still costs what it always cost: attention.

The paper that introduced the Transformer, the architecture behind today's language models, says it in its title: Attention is all you need. The model attends to every token and never tires. We have a few hours of it a day, and adding GPUs doesn't give us more. Every line the agent writes without our knowing whether it holds is waiting for those hours.

Reviewing harder doesn't hold, so we end up pressing the button#

The obvious answer is to review better. My developer friends all tell me the same thing: agent pull requests getting longer, read faster and faster. One of them was told by his team: "from now on, you don't read the code, you merge." He still answers for what goes to production, with no means left to check it.

That is the ordinary case. Mine is the extreme one. For months, reviewing has taken an attention my energy no longer allows. I didn't review too little, or too fast: I didn't review at all. But I love building, so I kept going: agents wrote every line of my tools, phax among them. When something broke, I could see the error but not go in and fix it. I'd tell the agent "fix this", it did, and another error surfaced somewhere else.

I think my case only shows earlier what is coming for everyone, the day the agent writes faster than you can read.

Each practice moves a judgement to the computational side#

After every error I asked the same question: what would make the agent fix it, and stop this kind of error from coming back? Today I sort the answers on a grid, Birgitta Böckeler's (Harness engineering for coding agent users, martinfowler.com, April 2026). She means the user's harness, what we put around the agent, as opposed to the vendor's harness, the loop and tools the model runs in. It separates guides, which steer the agent before it acts, from sensors, which check after. Each is computational, a program answering true or false, or inferential, a model judging.

Two dimensions. A guide acts before the agent, a sensor after. Each is inferential, judged by a model, or computational, decided by a program. Inferential guides are a skill, CLAUDE.md, a plan the agent reads; a computational guide is a brief computed from the code. Inferential sensors are a review by a model or a person; computational sensors are the type checker, the linter, tests and fitness functions. Each practice moves a judgement toward computation, and the computational sensor is the optimum.

Inferentiala model judges

Computationala program decides

Guidesbefore the agent acts

a skill · CLAUDE.md · a plan the agent reads

toward computation

a brief computed from the code

Sensorsafter the agent acts

a review by a model or a person

toward computation

the optimumtype checker · linter · tests · fitness functions

A type checker at its strictest and a linter are computational sensors. I no longer wonder whether a value can be undefined: the compiler refuses the code, and the agent fixes it. Acceptance tests written by one phase, which the phase writing the code cannot change, make that sensor trustworthy. All that is left to look at is what the tests check. A plan that says, before the code, which files each phase will touch is a guide, and comparing what the phase touched with that plan is a computational sensor. Instead of the diff, you look at the gaps the agent has to justify.

The optimum is always on the same side of the grid: computation, and a computational sensor first. A judgement a program carries holds without our attention. What stays inferential, a model judging or a person reviewing, is what computation cannot carry yet, and that is where our attention should go. With each judgement moved to the computational side, the system stays one we control and understand. The grid, cell by cell and with its examples, is the subject of Guides and Sensors.

A harness is worth what it saves you from looking at next time.