Everyone argues about which model writes the best code. When I ran 20 coding agents in parallel on one PC, the model was never what slowed things down. The compiler was.
The math nobody does
Parallel agents usually work in separate copies of the repo (git worktrees). Twenty agents means twenty copies, and every one of them wants to build and run the test suite after each change.
That's twenty cold builds at once. On a normal desktop, RAM runs out first, then the CPU, and the agents sit waiting on cargo test while the GPU running the model idles.
Fix 1: cache test results by content
Most of those builds are redundant. Agents working on the same task often land on identical code, and most files are untouched in any given change.
So I hash the inputs (the source tree, the toolchain, the command) and cache the result. Same inputs, same answer, no rebuild. In my runs, 83 to 85% of checks were served from that cache.
Fix 2: agents never grade themselves
"Done" is not the agent saying it's done. Done is a real build and the real tests passing, run by something outside the agent.
Fix 3: lock down what they can touch
Source is writable. Tests and the grader are read-only. Otherwise a stuck agent will eventually "fix" the failing test instead of the code. It's not malicious, it's just the shortest path to green.
Fix 4: put a ceiling on the machine
I cap RAM (21 of 32 GB on my machine) and throttle build jobs. A swarm that crashes your PC finishes nothing.
Fix 5: merge one at a time, re-grade every merge
Agents work in parallel, but changes land one by one. A change only goes in if more tests pass and none newly fail. Parallel work, serial truth.
Result
20 agents, 4 rounds, 1,770 of 1,770 checks green.
The takeaway: adding agents only helps once verification is cheap and impossible to fake. Until then, more agents just means more broken code, faster.
What's the bottleneck in your setup?
Top comments (0)