Why We Treat Claude Code Multi-Agent as a Prototype — Not a Production Workflow

TL;DR: Tested Claude Code’s multi-agent mode for 3 weeks on real features. Great for parallel greenfield scaffolding (API + tests + docs simultaneously). Fails on refactors needing shared context — agents overwrite each other, lose DB connections, hallucinate each other’s changes. Full comparison →

The Context

Three-dev team, 70% agent-assisted. Tried Claude Code (claude CLI) multi-agent via --agent flag: 1 planner + 3 executors (backend, frontend, QA). Tested on: (1) new billing API endpoint, (2) auth refactor across 14 files, (3) dashboard rewrite. Baseline: single-agent Cline (VS Code) and Continue.dev (Zed) for same tasks.

What We Tested

Scenario	Tool	Verdict	Why
New billing endpoint (greenfield)	Claude Code multi-agent (1 planner + 3 executors)	✅	Planner decomposed well; backend/frontend/QA agents worked in parallel; 45 min vs 2.5 hr single-agent
Auth refactor (14 files, shared DB)	Claude Code multi-agent	❌	Backend agent changed schema; frontend agent didn’t see it; QA agent tested old schema; 3 hrs debugging conflicts
Dashboard rewrite (React, 20 components)	Claude Code multi-agent	⚠️	Parallel component generation worked; integration failed — agents didn’t share design tokens, created duplicate utils
Same tasks	Cline (single agent, VS Code)	✅	Slower on greenfield (sequential), but reliable on refactors — single context, terminal state persisted
Same tasks	Continue.dev (single agent, Zed)	✅	Best on long refactors — persistent terminal, DB connections, file context across 4+ hour sessions

The Pivot Point

Week 2: Auth refactor. Planner assigned: “Backend: update User model + migration. Frontend: update forms. QA: write integration tests.” Backend agent ran migration, pushed schema change. Frontend agent (separate context) generated forms against old schema from cached files. QA agent tested against old schema. Merge conflict storm. 3 hours to untangle. Same task in Continue.dev (single agent): agent read current schema, updated model, updated forms, ran migration, updated tests — 1.5 hours, zero conflicts. Multi-agent wins on embarrassingly parallel greenfield; single-agent wins on anything with shared state.

What We Use Now

Claude Code multi-agent → spike branches only

• Use for: new feature scaffolding (API + tests + docs + types in parallel), prototype exploration, throwaway experiments
• Never for: refactors, migrations, anything touching shared DB/schema/design system
• Config: claude --agent planner --agent backend --agent frontend --agent qa --max-turns 50
• Output goes to spikes/<feature>-multiagent/ — human reviews, cherry-picks, rewrites integration layer

Production: Zed + Continue.dev (single agent, persistent context)

• Continue.dev config: qwen2.5-coder:32b planner + deepseek-coder:33b executor
• Project instructions: “Maintain terminal state. Never assume server restarted. Read current schema before changes.”

When You’d Choose Differently

• Claude Code multi-agent if: truly independent parallel workstreams (micro-frontends, separate services), team has strong human integration layer, throwaway spikes acceptable
• Aider multi-repo if: git-native, works across repos, terminal-only workflow preferred
• Cursor Background Agents (beta) if: IDE-integrated, but same shared-state limitations apply

Tool Crucible Rating

Dimension	Rating (1–5)	Notes
Overall	2	Prototype-grade; viral demos don’t reflect shared-state reality
Greenfield Speed	5	3-5× faster for parallel scaffolding
Refactor Reliability	1	Shared-state failures are structural, not prompt-fixable
Context Management	2	No built-in shared memory; agents hallucinate each other’s work
Integration Effort	2	Human becomes merge conflict resolver — defeats purpose

---

This is part of our AI Coding Agent Evaluation series. See full comparison: Claude Code Multi-Agent vs Single-Agent: When Parallel Works (and When It Breaks)