The bottleneck is me
Six months running three to five coding agents a day, across different projects and on machines I am not sitting at. What breaks is never the model.
Almost everything written about coding agents assumes one developer in front of one agent. And when the subject does move past that, it jumps straight to fleets of hundreds of autonomous agents. Neither describes a working day.
What people around me actually do, and what I do every day, is three or four agents across projects they already have. Not a thousand. Three. And at three, you discover that the hard problems have nothing to do with model quality.
attentionYou cannot read four panes, so you read none of them
This is the first thing to give, and it gives fast. At two agents you keep up. At three you start skimming. At four you have stopped reading without noticing: you watch things scroll, catch a word in passing, and tell yourself you will read it properly later. You never do.
The worst part is not even that. The worst part is that you stay glued to the screen anyway. Not to read, to stand guard. Because at any moment one of the four can ask a question and sit blocked on it until you happen to see it. You delegated execution and kept the watch.
You delegated the work. You kept the leash.
No model improvement touches this. A model twice as good produces twice as much output you are not reading.
notificationsAlerting on everything is the same as alerting on nothing
My first answer was the wrong one: notify on every event. Agent started, agent wrote a file, agent finished a step, agent asked a question. All of it.
I lasted two days. After two days you stop reading notifications, exactly the way you stopped reading panes. You have simply moved the problem from one screen to another, and added noise on the way.
What works is far narrower, and far less satisfying to build: signal only what is actually waiting on a human. An agent that is working is not an event. An agent that has finished barely is. An agent stuck on a question, yes.
compactionThe context compacts, the instruction vanishes, the work carries on
This one cost me the most, because it is silent. When the context window compacts, what survives is what was done recently. What goes is the original request, phrased fifty messages earlier.
So the agent carries on editing code diligently, having forgotten what it was asked to do. It does not stop, it does not warn you, and it has no way of knowing it lost anything. You find out half an hour later, on a change that no longer has any relationship to the subject.
The fix I settled on is not repeating the instruction every turn, which burns precisely the resource you are trying to save. It is storing the instruction outside the context window and having it re-read on demand. The memory of what you want must not live in the same place as the memory of what was done.
the lockA lock released only by a stream that can go quiet is never released
One of my panes stayed flagged "waiting for an answer" through an entire background job. I spent a long time looking at the agent. The bug was mine, and it is instructive.
The lock that marks a pane as blocking was only released by a later transcript line arriving. But a background job writes no transcript lines. So the pane demanded my attention permanently, while nothing was waiting on anything.
The lesson goes well past my case: a lock whose only release comes from a stream that can go quiet is never released. And in a system whose entire job is to say what deserves attention, a permanent false positive is worse than an outright failure. A failure, you can see.
the seamLocal and remote is not an install step, it is a permanent state
The machine doing the work is almost never the one I am sitting at. That is normal and it is desirable: a VPS, a box at the office, a test machine. But the agent writes as though it were talking to someone sitting right in front of it.
It prints a file path, and that path does not exist on my side. It prints a localhost URL, and that URL is dead on my side of the screen. It tells me to open a report, and I cannot open it.
What makes this grating is not the difficulty, it is the frequency. This is not a setup problem you solve once: it recurs on every single agent output, all day, and each time it costs three seconds of mental translation. Three seconds, two hundred times.
dead endsMore context and more agents both made it worse
The two intuitive answers are bad ones, and I tried both.
A bigger context window delays compaction, it does not remove it, and it makes the loss more brutal when it comes because there is more to lose. More agents simply speeds up the saturation of the one resource that did not grow, namely me.
These are ergonomics and state problems, not horsepower problems. They do not get solved by buying more of the thing that already works.
the objectionThe counter-argument I make to myself
A three euro VPS, tmux, one agent: that completely solves the single-project case. Completely. There is nothing to add, and anyone claiming otherwise is selling something.
My belief is that it gives way around five projects, because that is where I watched it give way. But that is a belief, not a measurement, and it is exactly the point on which I would like to be contradicted by someone who works differently. If you hold five projects by hand without losing your attention to it, I want to know how.
I build a tool in this space, a control tower for coding agents. I am saying it here rather than at the end, and I will say nothing more about it: everything above is true independently of what I do with it, and most of these failures are mine, not a competitor's.
I say it all the more readily because I have already got this wrong. On 8 August I posted about my own tool in a French-language free software community, the same day I created my account there. The post was taken down the next morning. In hindsight, rightly so: an account whose only content is the announcement of its own product is indistinguishable from an advert, however good the text. I would rather tell that story than hide it.
What interests me in this piece is not the points of agreement. It is the places where it does not hold: the setup where three agents cause no attention problem at all, the rig where compaction never broke anything, the reason my lock story is a beginner's bug. Write to me, the address is steven@e2pz.app.