Boring Enough to Ignore

You write gcc main.c, hit enter, and look away. Somewhere in there your source becomes a few thousand lines of x86 you will never read. If I told you to sit and review the assembly the compiler emitted, ready to pounce when it picked the wrong register, you would think I had lost the plot.

Now watch me on a normal Tuesday. Four agents are running. Two are writing tests, one is refactoring a module I half-remember, one is chasing a flaky CI job. The dashboard is green. I have eight tabs and a feeling I would describe, if you asked me in the moment, as leverage. I am doing the work of four engineers. The numbers say so.

My body says something else. I am not absorbed in anything. My eyes go to the terminal that just printed a line, then to the one that went quiet too long, then back. I am not building. I am watching for the moment one of them does something wrong, so I can catch it. That is not flow. That is a night shift in a control room, tired in the specific way you are tired after a long drive in fog: alert the whole time, with nothing to show for the alertness.¹

The thing I am calling leverage is vigilance, and the two feel alike from the inside for about the first hour.

Here is the tell. Flow has a direction: you are moving toward something, and the feedback comes from the thing itself getting closer. Vigilance has no direction. You hold still, waiting for a signal that mostly does not come, and when it does you drop everything and context-switch into a problem something else started. The dashboard sells me the first story. My attention is living the second.

And the closer the agents get to working, the worse this gets. Humans are measurably terrible at watching a source that rarely does anything: sustained attention to a low-event display falls apart after about half an hour, and the rarer the event, the worse you are at catching it.² So a green dashboard is not reassuring, it is the problem. The reward for good agents is a worse watchman.

None of this is new, which is the part that should bother you.

In 1983 Lisanne Bainbridge named the irony of automation. You automate the easy parts because a machine does them well, and what you leave the human is the two things humans are worst at: monitoring a system that is fine, and taking over the instant it is not. The monitoring erodes the very skill the takeover needs, so you are kept on call precisely for the case you are now least equipped to handle.³ Swap "process plant" for "agent fleet" and she described my Tuesday forty years early. We just put a nicer dashboard on it.

And the industry's instinct is to make the dashboard nicer still. More observability, more diff review, a human in every loop. Watch the agents better.

The obvious fix is exactly wrong, because it doubles down on the one task we are bad at. Go back to the compiler to see why.

Nobody watches a compiler, and a compiler took over a far more total job than any agent has. We flow right past it. The reason is the opposite of vigilance: not that we watch it well, but that we stopped watching it at all. And the reason we could stop is not that the compiler earned our trust. Trust is a feeling, and feelings are uncalibrated; blind trust and blanket distrust are both documented failures.⁴ Boring is a property. You do not ignore the compiler because you believe in it. You ignore it because the type checker, the test, the crash will tell you if it lied. The job got boring enough to ignore, and your attention floated up a level to the thing you care about.

That, and not better dashboards, is the real craft of orchestrating agents. Not running more of them. Making more of what they do boring enough to ignore.

And boring is buildable, not a vibe. A diff is boring when a failing test will catch what I did not read. A command is boring when it runs in a sandbox that cannot touch anything I care about, so the worst case is a wasted minute. A change is boring when it is small enough to revert without archaeology, when it crosses a typed contract that refuses to compile if it lies. Each of these is a wall. Inside the wall I do not have to watch, because the wall watches.⁵ The trust is an output of that machinery, not an input. Flow is downstream of the machinery, never of willpower.

The test for whether a piece is boring yet is one line: its failure has to be cheap and loud instead of expensive and silent. A wall you cannot feel break is not a wall.

Here is where I have to stop selling it. A compiler is deterministic. It earned global silence: valid input in, correct output every time, ignore it everywhere, forever. An agent is probabilistic. It can be right a thousand times and wrong the thousand-and-first in a way no rule forbids, so there may be no point at which you can stop watching all of it.

So you stop watching parts of it.

That is the craft, and it is smaller and more concrete than "orchestration." You do not make an agent trustworthy. You wall off one slice of its output until watching that slice earns you nothing, and you do this ruthlessly, slice by slice. You are not certifying the agent. You are fencing the blast radius of one task.

And the leak runs the other way too. When an abstraction leaks, the hidden layer below grabs your attention back.⁶ With a compiler the rare leak is performance. With an agent the leak is intent, taste, context, security, architecture, the question of who is responsible when it is wrong. Those never seal. They are yours. So the work splits cleanly: the part you fenced, which is boring, and the part that leaks, which is the only part worth your flow.

Most people invert this. They watch the diffs, which a test could watch, and skim the architecture, which only they can. They spend their scarcest attention on the work a wall could do and wave through the work that has no wall and never will. That is the tax the dashboard hides: the slice of attention an agent quietly garnishes from you while you admire the throughput, and attention is the only thing you brought to the desk that was ever scarce.

So the leverage question is wrong from the start. Everyone asks how many agents they can run at once. That number is a vanity metric; it measures how thin you spread, which is how much you watch. Ask the other question. How much of this have I made boring enough to ignore? That is the count of slices where failure is caught without you. Drive it up and you do not get a busier operator. You get a quiet one, back in flow on the part that leaks, while the walls hold the rest. Run only as many agents as you have walls for.

Some of it will not wall off. The judgment, the taste, the call on what is worth building: no test catches a wrong intent. That part you watch forever, and you should. That is not a gap in the method. It is the method telling you where you are still the engineer.

So stop counting agents. Walk your pipeline and mark each piece boring or leaky. For every leaky piece, build the wall that makes it boring, or admit it is yours to watch and stop pretending an agent owns it. The walls are the work now.

You will know you have it right when the agents get dull, when you forget they are running, when a thing breaks and a red test, not your tired attention, is what tells you. That is not negligence. That is what flow with a machine has always felt like, the whole time, going back to the first compiler nobody ever watched. The only question left is the one worth sitting with: which parts of this have I made boring enough to stop watching, and which parts have I only managed to stop looking at.