Summary
At the end of "The Living Specification" I wrote that structured methods for AI-driven development deserved their own article, and that BMAD was one of them. This is it. I ran BMAD with the Superpowers plugin for Claude Code on a real feature, a revenue and expense dashboard with trends and period comparisons, spread across two repositories: a Java backend and an Angular frontend.
The opening question was simple: what does BMAD add when a specification is already the source of truth? My answer: not more specification, but the layer above the story. A frozen API contract, which makes it legitimate to split a feature into one backend story and two frontend stories run in parallel without integrating on trust. The order of the work. And a reader of the result who did not write it: the compliance audit that checks, once the code is merged, that it still honours the contract.
It all falls into three stages: BMAD to frame and freeze the contract, Superpowers to implement in TDD inside a Git worktree, BMAD again to audit. Three weeks of work for this feature. The two methods collided once, when the brainstorming step reopened a question the contract had already settled; I drew a rule from it: during implementation the agent may discuss how, never what the contract says. And when the audit finds a gap, fix the upstream artifact first, never the code.
What I would tell a team on a Monday morning: adopt the frozen contract and the session boundary, which cost almost nothing; adapt the artifacts, keeping one durable source of truth and disposable scaffolding; skip the full method for small changes, because a method applied to everything ends up bypassed. AI writes the code, a method decides what gets built; neither decides whether it is right.
Key ideas
- BMAD does not add a specification: it adds the layer above the story, the contract, the order of work and a reader of the result who did not write it.
- A frozen API contract makes parallelism possible; left soft, every story becomes a negotiation. But a wrong contract held firmly yields two well-tested halves of a mistake.
- Epic, story and plan are three objects with different lifetimes: the story is the input, the plan is the state.
- Acceptance criteria are checked once, invariants forever: they must migrate into the durable specification.
- A gap found at audit is fixed first in the upstream artefact, the story, the architecture or the contract, never in the code first.
Why I wrote this
I had promised it at the end of "The Living Specification": structured methods deserved their own article, and BMAD was one of the notable approaches I had come across. I wanted to share my reasoning on where BMAD helps and where it must absolutely be avoided, after two months of AI-assisted work in which the most expensive habit to lose had been letting the specification live in several places at once.