Running a dozen coding agents at once did not turn me into twelve engineers. It turned me into a manager, and the bottleneck moved from typing to judgement.
When I got to the point of running a dozen coding agents at once, across a handful of tasks, I expected the main change to be speed: twelve things happening instead of one, output scaling roughly with headcount. What actually happened was that I stopped being an engineer typing code for most of the day and became something closer to a manager reading other people’s work and deciding what to do about it, except all twelve reports were mine alone and none of them slept. It took a few weeks of running it that way before I noticed the change was in kind, not just in volume.
The parallelism is real at the execution layer and mostly illusory at the layer that matters, which is judgement. Twelve agents can genuinely run at once, each making progress on its own branch of work while I am not looking at it. What cannot run twelve at once is me, deciding whether a given diff is actually correct, whether a given plan solves the actual problem, whether an agent has quietly wandered off into solving a different problem than the one I gave it. That review has to happen serially, one attention span at a time, because it is the part of the work that genuinely requires a single continuous thread of judgement rather than throughput.
This is the same shape of problem any manager of a reasonably sized team runs into, and I did not expect to recognise it this quickly, because coding agents do not come with the social overhead a human report does: no one-to-ones, no morale to manage, no career conversations. Strip all of that away and what is left is the actual hard part of managing people, which was never the social overhead in the first place. It is deciding what each person should work on, catching the moment one of them is going in the wrong direction before it costs a day, and being honest with yourself about which reports you are actually reviewing carefully versus which ones you are waving through because there are eleven others waiting.
The failure I hit first was treating twelve agents running as itself the achievement, and only noticing later that my actual output, the number of things I could review and merge with real confidence in a day, had not gone up by anything like twelve times. It had gone up by some smaller factor bounded by how much careful attention I have in a day, and the gap between agents running and agents producing things I have actually verified is exactly the gap a bad manager ignores and a good one manages directly. I had confused activity for throughput, which is an easy mistake to make when the activity is happening on twelve screens at once instead of one.
What changed the outcome was treating span of control as a real constraint rather than a solved problem because the workers happen to be software. I now cap how many agents I run on anything I intend to review carefully on the same day, not because the agents cannot handle more, but because I cannot. The honest number is smaller than the impressive-sounding one, and building a workflow around the honest number produces work I actually trust, rather than a pile of unreviewed diffs that looks like productivity until the first one turns out to be wrong in a way I did not catch because I was on my ninth review of the day, not my second.
Twelve agents did change what I do all day. It just did not do it by turning me into twelve engineers. It turned me into one manager with twelve reports, doing the oldest job in that category, which is deciding where attention goes when there is more work arriving than one person can look at properly, and the tools changed while that particular constraint did not move an inch.