subagent-driven-development

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

The first stage checks spec compliance: does the implementation match the original task requirements exactly, with no scope creep. The second stage checks code quality: conventions, error handling, test coverage, and security. Spec review always runs before quality review.

Fresh subagents prevent context pollution from accumulated state, giving each task clean, focused context without confusion from prior tasks' code or reasoning. The trade-off is more subagent invocations, but issues are caught early instead of compounding.

Each task should represent 2-5 minutes of focused work, such as creating a single model, adding one endpoint, or writing a utility function. Tasks like 'implement the entire authentication system' are too large and should be split during planning.

The implementer subagent (or a new fix subagent) addresses the specific issues, then the reviewer re-reviews the work. This loop repeats until approval, and you never move to the next task while either review has open issues.

Avoid it when you have no written implementation plan, when tasks are tightly coupled and touch the same files, or when you would skip the review stages. Dispatching parallel implementers on shared files and skipping reviews are explicit anti-patterns.