Running 5 AI Coding Agents in Parallel - Setup, Coordination, and Real Tradeoffs
Running 5 AI Coding Agents in Parallel
My current terminal setup runs five Claude Code agents simultaneously. One handles the frontend, one works on the backend API, one writes tests, one manages infrastructure, and one handles documentation updates. Local Whisper transcription lets me address any of them by name without switching focus.
It sounds chaotic. It mostly works. Here is the actual setup, the hard parts, and the practical limits.
The Productivity Case
A single agent working sequentially on a full-stack feature takes roughly an hour. Five agents working in parallel finish in 15-20 minutes when the tasks are properly decomposed. Boris Cherny (Claude Code's creator) reported running 10-20 agents in parallel at any given time. One developer documented watching 12 agents rebuild an entire frontend overnight - 10,000+ lines of coordinated changes in a single pull request.
The key word is "properly decomposed." The parallel speedup only materializes when tasks are genuinely independent. That decomposition work is now a significant part of the actual development task.
File-Level Isolation
File-level isolation is the foundation. Each agent gets a boundary: "You own src/api/. You own src/components/. Do not touch each other's directories." This prevents the most common failure mode - two agents modifying the same file and producing merge conflicts.
The practical implementation uses git worktrees. Each agent gets its own worktree - a separate checked-out directory pointing to the same git history but a different branch:
git worktree add ../project-frontend -b feature/frontend-agent
git worktree add ../project-api -b feature/api-agent
git worktree add ../project-tests -b feature/test-agent
Each agent runs in its own directory with its own branch. No shared working tree, no file conflicts, no accidental overwrites.
The Context Sharing Problem
File isolation is the easy part. The hard part is information flow between agents.
When the frontend agent discovers the API response format needs to change, how does the backend agent find out? Right now, the honest answer is: it usually does not, and the integration breaks.
Cross-agent context sharing is the biggest unsolved problem in multi-agent development. Three approaches that partially work:
Shared types contract. Keep a shared/types.ts (or equivalent) that defines the interface between subsystems. Both the frontend and API agents read from this file. When an interface needs to change, you update the types file and both agents see it on their next file read. This works well for well-defined boundaries.
Coordinator notes file. A AGENTS.md file at the project root that agents are instructed to read and update when they discover cross-cutting concerns. More fragile - requires agents to consistently follow the instruction - but handles issues that the types file cannot express.
Human relay. You as the human coordinator catch integration issues during review and relay them verbally to the affected agents. Not elegant, but the most reliable. Voice commands make this faster.
Voice as the Coordination Layer
Local Whisper running on Apple Silicon transcribes at roughly 2-3x faster than real-time for short utterances, with latency under 500ms. Prefixing commands with an agent name - "backend agent, the user endpoint now returns a list instead of a single object" - is faster than typing and switching terminal focus.
Voice naturally becomes the coordination layer because it is the fastest way to broadcast context changes to specific agents. The overhead of typing a command, switching to the right pane, pasting it, and confirming the agent understood is 30-60 seconds. Voice cuts that to 5 seconds.
Whisper accuracy on technical speech is high when you speak clearly. Model names, function names, and variable names transcribe well. The main failure mode is code syntax - handleUserList works fine; async/await sometimes needs a second take.
Layout That Works
A practical tmux layout for five agents:
+------------------+------------------+
| frontend | backend api |
| agent 1 | agent 2 |
+------------------+------------------+
| test writer | infrastructure |
| agent 3 | agent 4 |
+------------------+------------------+
| docs / coordination / git status |
| agent 5 / your own pane |
+-------------------------------------+
The bottom pane serves double duty: either a fifth agent or your own command pane for git operations and coordination work. Keep one pane for your own use - running builds, checking git status, merging branches.
The Practical Ceiling
Research and practitioner experience converge on 5-7 concurrent agents as the practical ceiling on a laptop before diminishing returns set in. The limits are:
API rate limits. Five active agents hitting the Claude API simultaneously will exhaust rate limits faster than you expect. Build in pauses or use a rate limiter wrapper.
Review bottleneck. You cannot review code faster than you can read code. Five agents producing output simultaneously means your review queue grows faster than you can clear it. This is the actual bottleneck, not compute.
Merge complexity. Five independent branches eventually need merging. The more they ran in parallel, the more divergence has accumulated. Budget time for merge work that grows roughly with the square of agent count.
Starting Point: Two Agents, Not Five
Start with two agents on clearly separated tasks with a well-defined interface between them. Use a shared types file as the contract. Learn the coordination rhythm before adding more.
The jump from one agent to two reveals the actual coordination overhead. The jump from two to five is less surprising once you have the patterns established. Start small and build up.
Fazm is an open source macOS AI agent. Open source on GitHub.