Five terminals. Five Claude Code sessions. Same repo, same branch, different jobs. By end of day: 18 commits, 3 bugs caught before production, and one coordination failure that taught me more than all the successes combined.
What You'll See in This Post
- How I split work across five specialized instances
- What actually went well and what broke
- The coordination failure nobody warns you about
- Whether the complexity is worth it
The Setup
Five Claude Code sessions on one Replit workspace, each with its own role:
Instance 1 — Developer. Builds features, writes adapters, produces commits. The busiest one.
Instance 2 — Reviewer. Reviews every commit from the developer. Checks for missing tests, hardcoded values, inconsistent patterns. Doesn't write code.
Instance 3 — Maintainer. Monitors external API changes, runs health checks, keeps documentation current. The quiet one that prevents future problems.
Instance 4 — Quality Controller. Audits memory files, skill definitions, cross-instance consistency. Makes sure the system doesn't accumulate debt.
Instance 5 — Coordinator. Decides priorities, assigns work, resolves conflicts, reflects on process.
Each instance has its own skills directory, its own memory folder, and a shared CLAUDE.md with coordination rules. They communicate through Discord messages and git commits.
What Went Well
The reviewer caught things the developer missed. In one case, the developer hardcoded an API key format into an adapter. The reviewer flagged it within minutes. Without a dedicated review instance, this would've shipped.
Parallel work is genuinely faster. While the developer built three new adapters, the maintainer was simultaneously verifying that existing ones still worked after upstream changes. Sequential with one instance, these would've taken twice as long.
Specialization improves quality. When one instance only does reviews, it develops patterns and catches things a generalist instance wouldn't. Depth beats breadth for repetitive tasks.
The Coordination Failure
The developer committed a fix. At the same time, the maintainer ran a health check on the same file using the old version. The maintainer found a "bug" that was already fixed and filed a report.
The coordinator saw the report and assigned the developer to fix it. The developer saw the code was already fixed and committed a no-op. The reviewer flagged the no-op as suspicious.
Four instances spent 15 minutes on a problem that didn't exist, because of a message timing overlap.
⚠️ When multiple agents work on the same codebase, git commit hashes are the source of truth, not message order. We added a rule: before acting on any report, run
git logto check if the issue was already addressed.
By the Numbers
- 18 commits in one day
- 3 bugs caught by the reviewer before they could cause problems
- 1 false positive from the timing issue
- ~2x token usage compared to a single instance
- Roughly 4 hours of sequential work compressed into parallel execution
What I'd Do Differently
💡 Start with two, not five. Developer + reviewer is the highest-value split. Add more only when you have clear, independent workstreams.
💡 Use git as the coordination layer. Messages arrive out of order. Commits don't. Every important decision should reference a hash.
💡 Give each instance a "don't touch" boundary. The developer doesn't review. The reviewer doesn't write code. Blurred roles create duplicated work.
💡 Write handoff notes. When a session ends, each instance records what it finished, what's blocked, and who's waiting on what.
Is It Worth It?
For most tasks, a single Claude Code instance with good skills and hooks is enough. The parallel setup shines when you have genuinely independent workstreams.
The sweet spot is two to three instances. Five is possible but coordination overhead starts eating into the gain.
❌ Don't do this for a quick bug fix. The setup time isn't worth it.
✅ Consider it for large projects with multiple independent tracks: building new features while maintaining existing ones while monitoring dependencies.
Want to Try It?
- Set up a shared repo with clear directory boundaries
- Give each instance its own
.claude/skills/for role-specific behavior - Use
memory/bot-N/directories for instance-specific notes - Establish a communication channel (Discord, Slack, or git commit messages)
- Write coordination rules in CLAUDE.md that all instances follow
Start with two. Add more when you feel the bottleneck.
The hardest part isn't getting five AIs to work. It's getting five AIs to work together without stepping on each other's toes.