The Developer Persona
Implementation against spec
The Developer persona implements stories one at a time, working strictly from the approved artifact chain. Its output is code and tests that satisfy the acceptance criteria — not an interpretation of them.
The Developer persona is the last in the chain. By the time it is activated, the PRD, user stories, and architecture document exist and have been reviewed. The Developer's job is to implement — not to reopen design questions, not to add features the PM didn't specify, and not to change the architecture because a different approach occurred to it during implementation.
A Developer session has a fixed structure: load the PRD, load the relevant story, load the architecture document or relevant ADRs, implement the story, write tests against the acceptance criteria, stop. The session scope is one story. If implementation reveals a genuine ambiguity or contradiction in the spec, the Developer surfaces it for human review rather than silently resolving it with an assumption.
AI-generated code requires rigorous human review in one specific respect: it tends to satisfy the literal text of acceptance criteria while missing the intent. The Developer persona produces code correct against the spec; the human's job is to verify the spec was complete enough to capture the intent. This division of labour is the core of BMAD's quality model.
Key Concepts
- One story per session — bounded, verifiable scope with a human review at the end
- Tests are written against acceptance criteria, not inferred from the implementation
- Ambiguities are surfaced for human review — never silently resolved
- Developer does not reopen architecture decisions made in prior phases
- Human code review validates spec completeness, not just code correctness