Jesse Vincent (obra) / subagent-driven-development
When does splitting work across agents actually help?
When the pieces are genuinely independent, and almost never otherwise.
What to remember
- Independence is the precondition, not an optimisation detail.
- Splitting before planning creates parallel versions of the same misunderstanding.
- Merging is the real cost, and it is paid by you, not the agents.
- Read only fan out, such as research or review, is the safest and most reliable use.
01What it changes in practice
Parallel agents are attractive for the obvious reason and dangerous for a less obvious one: they each make small design decisions, and nothing reconciles those decisions afterwards except you.
The reliable pattern is fan out for reading and gathering, then a single writer for the decisions. Investigations, audits and reviews parallelise cleanly. Interface design does not.
02Where it disappoints
Shared files turn concurrency into conflict resolution, which is why worktree style isolation matters as soon as more than one agent writes.
Coordination cost also grows faster than the speedup. Beyond a handful of concurrent pieces, the merge is the project.
Install and first run
- Install superpowers from obra/superpowers, published under MIT.
- Write the plan first, then split it. Splitting an unplanned task multiplies the confusion.
- Give each agent a boundary in files and a definition of done, and use isolation when they write to the same repository.
Questions people actually ask
- When should I not parallelise?
- When the pieces share state or unmade design decisions. You will get several confident, incompatible answers.
- What is the safest use?
- Read only work such as research, audits and reviews, where nothing has to be merged.
- Do agents need isolated workspaces?
- Once more than one writes to the repository, yes. Otherwise you are managing conflicts by hand.
Sources
Machine readable versions of this page