parallel-work
Parallel work
Parallelism buys fresh context per unit and speed. It costs coordination: a fan-in that must wait, a merge that must not collide, a judge that must not be the maker. Use it where the units are genuinely independent, and pay the coordination cost explicitly.
Preconditions
- The units are independent: none needs another's result to start.
- You know what the units are. Unknown cause → one investigation dispatch first.
- Writes are isolated: each unit writes different files, or each unit runs in its own worktree and commits only the files that unit touched (mechanics: delegate/references/harness-notes/claude-code.md's Isolation section).
Missing any one → serialize, or investigate first.
Shapes
Fan-out, fan-in. N dispatches of the same phase, one per unit, sent together. A single consolidating dispatch waits for all of them — that wait is the barrier — and merges their delivery files into one. Keep each unit's output in a file; the consolidator reads paths, not your context.
Mechanical fan-out. One process dispatch decides the exact change once. N generic dispatches apply it verbatim, each to its own targets. One review dispatch checks the whole set. The orchestrator never applies the edit itself, however small the set.
Maker/checker. Whoever produced a result never judges it. Route review to a different agent — a reviewer-typed agent for the domain where one exists, otherwise a specialist in a different role — with the success criteria and the artifact path, and nothing from the maker's reasoning.