Subagent-Driven Development: Why One Agent Isn't Enough
Role separation in the agentic world: feature-dev, self-review, and an independent external-review with a clean context — a pipeline that catches generation drift.
Subagent-Driven Development: Why One Agent Isn't Enough
Most developers use an AI agent as a single performer: hand it a task, get back code. That's like hiring one person who writes, reviews, and tests their own work. Naturally, the quality is mediocre.
A real team has role separation: developer, reviewer, QA. In the agentic world it's the same — except the roles are played by different agents with different contexts.
The Subagent Pipeline I Use
The first agent is feature-dev. It receives the spec and the skills and writes code through the lifecycle: RED test → GREEN impl → REFACTOR. It has full project context.
The second agent is self-review. It runs right after generation, looking for compile errors, type mismatches, naming inconsistencies. A fast check for "did I break anything obvious?"
The third is external-review. An independent agent with a different context. It never saw how the code was written. It receives the diff and the company's list of skills, and returns findings: Critical, Important, Nit.
Each finding becomes its own fix commit: fix(feature): external review round-1 — I1 wire test + N1 doc. Atomic commits, each revertible on its own.
Why This Beats a Single Agent
A single agent drifts over a long session — it starts to "forget" the rules, simplify, cut corners. This is a known problem. A subagent with a clean context catches exactly that drift, because it sees the code with fresh eyes.
On the 24-module project, 26 review-fix commits went through this pipeline. That's a public audit of discipline right in the git log — open any of them and you'll see the findings were real.
A bonus effect: the pipeline is reproducible. It doesn't depend on mood, fatigue, or rushing. Every feature goes through the same lifecycle. Every one.