Using four encoding processors seems quite efficient. But who will monitor their productivity?
The October 31st Leaderboard email had a neat trick that allows you to have four coding agents at once and chat with the one that requires your attention. I see the logic here. I found myself wasting time waiting for an answer from one particular agent when I did nothing else but waiting.
However, when I tried my own version of it last weekend – three tabs of the terminal with three different tasks in the budgeting application I'm working on – the speed slowed down somewhere else. Agents were done faster than me. It took me much more time to read three diffs than one; and my concentration is low after some point. I noticed only one duplicate helper function thanks to luck.
It worked much better to assign a different part of the codebase to each of the agents and give each task no longer than five minutes to be reviewed.
The current rule I follow is as simple as not starting any number of agents greater than what I can go through before noon. Quick generation does no good without equally fast review, for I would only be accumulating unreviewed code.
How many agents do you keep going parallel? Also, do you follow any review process such as testing the changes first?
Replies
the review was only half of it for us.. with a few claude code sessions on one repo, one killed another's test run because it matched the process by name. now each agent gets its own worktree and only kills the exact pid it started. do your three tabs share one checkout or one each?
I run several sessions on one repo too, one checkout, and the review cost you describe is real, but the bigger traps for me were about the shared tree. The rules that came out of it: each session stages only the files it changed itself, by name, never everything; it never reverts, stashes or tidies a change it did not make, even inside a file it is editing; and before any deploy that bundles the tree, it checks the status for changes that are not its own and says so instead of shipping someone else's half done work. Your noon rule is a nice human version of the same idea: the limit is not how fast agents write, it is how much unowned change the tree can hold before something ships by accident.
Monitoring productivity across four processors misses the real trap. An encoding run failing or generating broken syntax gets caught fast. The failure that matters is the job returning a clean exit code while silently dropping unhandled types, because that is what slips into prod.