Guide
How to run several coding agents in parallel without chaos
Parallel agents do not fail because the models are slow. They fail because two agents were given work that touched the same file, or because nobody could read the diffs as fast as they were produced.
Split by file, not by ambition
The rule that matters: two tasks may run at the same time if they cannot touch the same paths. A migration and its test fixture are one task. A new endpoint and a new page that consumes it are two.
When you cannot find a clean split, that is information about the codebase rather than about the agents — the coupling you just found is real, and an agent will find it too, at merge time, with a worse outcome.
Write the exit condition first
An agent with no definition of done will stop when it feels finished. A concrete condition — this test passes, this command exits zero, this route returns 200 — turns a session into something you can leave alone and come back to.
That condition is also the thing you re-run when you ask for another pass, which is why it belongs in the task description rather than in your head.
Questions
- How many agents should run at once?
- As many as you can review. Three is a common ceiling for one person reading diffs properly; beyond that sessions finish faster than they can be checked, and the queue becomes the bottleneck.
- What if two agents need to change the same file?
- Then it was one task. Sequence them — finish and merge the first, then start the second in a fresh worktree from the updated branch.
- Do parallel agents need more machine resources?
- They need what the CLIs need. Each session is a process, plus whatever it runs — test suites and builds are usually the actual load, so the honest answer is that the build is the limit, not the agent.