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.

Generate and filter. Fan out to produce candidates; one dispatch dedupes and scores them against a written rubric; only survivors continue. Write the rubric before generating.

Tournament. For ranking a set too large to judge in one window: pairwise comparison dispatches, each holding two items, with a bracket held in a file. Comparative judgments are more reliable than absolute scores.