Anyone can start twenty coding agents. Twenty worktrees, twenty branches, one terminal each, and a laptop that barely notices. The interesting number is not how many you can start. It is how many you can still be responsible for.
That number is set by review throughput, not by hardware, and for most people it lands somewhere between three and six. The arithmetic is short enough to check.
The arithmetic
Careful code review runs in the low hundreds of lines an hour. Call it 300, which is generous for unfamiliar code and stingy for a small tidy diff. Say you give review two hours in a working day before meetings and your own work take the rest. That is about 600 lines a day you can read properly rather than skim.
Now the other side. A scoped agent task lands somewhere near 150 to 400 lines, depending on how tightly you wrote the prompt. Take 250 as a middle value. Six hundred lines of reading budget divided by 250 lines a changeset is between two and three changesets a day, read properly.
Agents produce more than one changeset each if you keep them running. So the ceiling on agents you can supervise is the ceiling on changesets you can read, divided by how many turns you let each agent take.
- lines read properly per day
- ~600
- lines in a scoped changeset
- ~250
- agents one person can hold
- 3-6
Run it with your own numbers. The conclusion survives every substitution, because the only quantity that scales with agent count is the one on the writing side.
Three things that move the number, and one that does not
Prompt scope moves it most. Ask for one thing, name the command that has to pass, and you get a changeset you can hold in your head. Ask for five and you get a diff you skim, and skimming is not a faster read, it is a different activity with a worse error rate. Halve the changeset and you double the ceiling, for free.
Familiarity moves it too. An agent's change in code you wrote last week reads several times faster than the same change in a subsystem you have never opened. So the ceiling is personal, and it moves around the repository with you.
Having compile, tests, and branch state already settled moves it. A reviewer who establishes those by hand for six changesets has spent the budget before reading a line of anything.
Hardware does not move it, and this is the part people get wrong. A faster machine, a bigger token budget, a better model: all of them raise how much gets written. None of them raises how much you can read. The constraint was never on the writing side.
What hitting the ceiling looks like
You do not get an error message. You get symptoms, and they arrive in a fairly predictable order.
Approvals speed up while changesets get bigger. Green checks start standing in for reading. You lose track of which worktree holds which task, and catch yourself hunting for a window instead of looking at code. Then one afternoon you fix an agent's mistake by hand, because writing the correction as a prompt felt slower. That is the moment you became the bottleneck, and it does not announce itself.
What to do at the ceiling
- 1
Run fewer agents on tighter prompts
Three well-scoped agents beat eight vague ones, because the ceiling is measured in lines rather than in processes.
- 2
Stagger the starts
Agents that all finish at 16:00 hand you a queue. Agents started across the day hand you a stream, and a stream is readable.
- 3
Make the correction a prompt, not an edit
The note on the diff line costs a sentence. The hand fix costs your afternoon and teaches the agent nothing.
- 4
Put the whole fleet on one surface
Much of what people file under running out of attention is really navigation: finding the run, working out its state, remembering what it was asked.
Where Cohalen fits
Cohalen is built for the reading half of this. Every agent's changeset arrives on one surface with the mechanical checks resolved, an outline of what changed, and a note on a diff line that goes back to the agent as its next prompt. The worktree lifecycle is handled, so the navigation cost does not grow with the count. Token spend is metered per workspace, so the agent you are not currently reading cannot quietly run all night.
If your limit is how much you can read rather than how much you can run, Cohalen is the tool built for that limit. Two things it does not do: it does not raise your reading rate, and no tool does. And per-member budgets are the Organization tier, in build rather than shipped.
Questions people ask
How many AI coding agents can one developer run at once? As many as the machine allows, which is not the useful question. The number you can supervise is set by how many changesets you can read properly in a day, which for most people is a few.
Does a faster machine let me run more agents? It lets you run more. It does not let you review more, and review is the constraint.
How do I raise my ceiling? Tighten prompt scope so changesets are smaller, review in code you know, and have the mechanical checks answered before you open a diff.
What happens if I ignore the ceiling? The unread changesets do not disappear. They merge, and the errors they carry surface later, when the context that would have caught them is gone.