subagent-driven-development

Read the plan once, extract all tasks with full text into a todo list, then dispatch a fresh implementer subagent per task with the complete task text and context. After each task, run a spec compliance review followed by a code quality review before marking it complete.

Subagent-driven development stays in the current session with fresh subagents per task and no human-in-loop between tasks, enabling faster iteration. Executing plans uses a separate parallel session, which involves a context switch and handoff.

Avoid it when tasks are tightly coupled and cannot be implemented independently, when there is no written implementation plan, or when you have not yet brainstormed the approach. Tightly coupled work is better done manually or in a single continuous session.

Assess the blocker: provide more context and re-dispatch if it is a context problem, use a more capable model if the task needs more reasoning, break the task into smaller pieces if it is too large, or escalate to the human if the plan itself is wrong. Never force the same model to retry unchanged.

Spec compliance verifies the implementer built exactly what was requested, nothing more or less, by reading the actual code rather than trusting the report. Reviewing code quality first wastes effort on code that may need to change to meet the spec.

No. Dispatching multiple implementation subagents in parallel causes conflicts between their changes. Tasks are executed sequentially, with each task completing both review stages before the next implementer is dispatched.