Parallel Claude workflow
Parallel Claude workflow
One-line summary: Running 5–10 Claude sessions concurrently across terminal, web, and mobile surfaces — shifting the human's job from "going deep on one task" to "tending a fleet of agents."
The insight
Once individual agent sessions are reliable enough to run unattended for minutes at a time, single-session thinking becomes a bottleneck. The throughput-maximizing workflow is to keep several agents in flight, each in its own isolated context (separate git checkout), and cycle through them as they need attention.
The human is no longer writing code; they are queueing plans, reviewing plans, unblocking agents, and fielding questions — a dispatcher role.
Evidence
- From 2026-04-21-boris-claude-techniques (Boris Cherny):
- "My job now isn't to go super deep on one task. It's to do a bunch of tasks in parallel."
- "I also run 5 to 10 Claudes in parallel with my local Claudes."
- "This morning I kicked off, I think like three Claudes as soon as I woke up … checking Twitter and someone had a bug report. So I just opened my phone …"
- "The way I code now is like probably half of it is just on my phone, and it sort of just works."
- "My work now is just jumping between tabs, kind of tending to the Claudes, make sure they're unblocked, answering their questions."
- Reply commenter @PangestuAden in the same thread: "running multiple instances simultaneously changes the whole workflow — it's less about one perfect output and more about parallel exploration."
- Reply commenter @MGMurray1: "The Plan then Execute with multiple parallel Claudes pattern using master files for memory is exactly our architecture." — evidence that this pattern is not just a Boris idiosyncrasy; other teams report the same structure.
How Boris operationalizes it
- One separate git checkout per terminal tab. Explicitly does not use worktrees — "I just keep it pretty simple."
- Overflow to web when out of terminal tabs.
- Overflow to mobile for sessions kicked off away from the desk (e.g., first thing in the morning, in response to a bug report seen while scrolling X).
Surface split: terminal + mobile are his primary surfaces; web is the overflow queue.
Design implications
- Tab count is a real constraint. Managing 5–10 parallel git checkouts is operationally expensive; Boris's choice of "separate checkouts, no worktrees" is worth examining — it trades disk + tab clutter for simplicity.
- Mobile is a first-class coding surface for this workflow, not a curiosity. Session initiation from the phone is load-bearing.
- Session sync gaps become painful. A commenter in the same thread flagged that iOS ↔ Mac mini sync is one-directional — a papercut that becomes significant at fleet scale.
Contradictions / tensions
- Boris's rejection of worktrees is a judgment call, not a universal principle. Worktrees give you shared history with no duplicated clones; separate checkouts give you full isolation at the cost of N× disk. Readers in large-repo contexts may find the trade-off flips.
Open questions
- At what scale does the parallel workflow stop scaling? Is there a natural cap (5–10 as Boris does), or is it bottlenecked by plan-review bandwidth?
- Does this pattern assume well-factored work (many independent tasks) or does it still help on a single sequential refactor?
How this relates to multi-tool stacking
The wider market (see ai-coding-tool-stacking) stacks across tiers — IDE tool + terminal agent + occasional background agent — with 70% of developers running 2–4 distinct tools simultaneously. Boris's pattern is different: he stacks within claude-code by running 5–10 parallel sessions of the same tool. Both are forms of parallelism; the axis differs. Per 2026-04-21-autoresearch-best-ai-coding-tools, the cross-tier pattern is more common in 2026 surveys, while Boris-style intra-tool parallelism is a workflow extreme validated by one highly-credible source (boris-cherny) plus indirect corroboration from reply commenters.