BMAD-METHOD is one of the most popular open frameworks for AI-assisted development: tens of thousands of stars, an active community, a modular ecosystem. We are regularly asked how Use Case Pattern differs from BMAD and whether they solve the same problem. The short answer: they operate on different layers, and comparing them head-to-head is like comparing a scrum board with a type system. Let's take it apart.
What BMAD is
BMAD organizes AI work through a team of agent roles: analyst, product manager, architect, scrum master, developer, QA. Each role is a prompt persona with its own workflows. The process is a delivery loop: clarify the idea → plan (brief, PRD, architecture, epics, stories) → build and verify → learn. The artifacts are markdown documents; the developer agent takes stories one at a time. Version six turns this into a modular platform: the core method, a builder for custom agents, a test-strategy module.
BMAD's strength is the discipline of thinking before code: a vague idea doesn't reach the developer agent until it has passed product and architecture elaboration. For a solo developer with AI, this substitutes for a whole team of perspectives.
What Use Case Pattern is
UCP answers a different question: what the code itself must look like, and how to guarantee it on every change. The core is four pillars:
- the layered pattern Controller → UseCase → Handler → Repository;
- the Use Case specification of a Bounded Context — a long-lived source of truth about the domain: aggregates, invariants, lifecycle, acceptance criteria;
- architecture maturity levels — from MVP to Hexagonal, so a team pays complexity only for what it needs;
- executable standards: every rule has a code (
R-*,JS-*), and every standard has an AI skill that checks it on every PR.
UCP's strength is reproducibility of the engineering result: three agents in three sessions produce code that agrees on layers, names and rules, because the rules are explicit and checked automatically.
Layer by layer
| Layer | BMAD | UCP |
|---|---|---|
| Who thinks, in what order | agent roles, delivery loop | out of scope (any process) |
| Product artifacts | brief, PRD, epics, stories | out of scope |
| Domain model | mentioned within architecture | the core: BC specification, aggregates, invariants |
| Code architecture | up to the architect agent | fixed by the pattern and maturity levels |
| Code standards | none | 18+ standards with rule codes |
| Compliance checking | QA-agent review (general view) | rule-coded review skills on every PR |
| Artifact lifespan | stories are closed and archived | the specification lives and evolves with the system |
The key difference is the last row. BMAD artifacts are disposable: once a story is done, its context is spent. The UCP specification is permanent: the next agent, the next developer, the next team start from it.
Where BMAD is weaker than it looks
- Role ceremony adds no engineering depth. Six personas discuss a story, but none of them will say that an aggregate violates an invariant or that a repository leaks N+1 — that takes domain rules, and BMAD has none.
- Quality rests on the model's general abilities. Without explicit standards, the developer agent applies the "average of the training data" — three sessions, three styles.
- The scale is solo and small teams. With 20+ engineers, consistency takes standards, not characters.
Where UCP does not compete
The product layer: UCP won't tell you which feature to build or how to prioritize a backlog. If you need structure "from idea to backlog," take it from anywhere — including BMAD: the approaches are compatible. A working combination looks like this: product elaboration (BMAD or your own process) → Use Case specification → code generation and review through UCP skills.
In short
- BMAD is a process shell: roles, a delivery loop, product artifacts; UCP is engineering substance: domain, architecture, executable standards.
- BMAD artifacts are disposable (story → archive); the UCP specification is a long-lived source of truth.
- BMAD has no code-level rules and no automatic enforcement — which is exactly what UCP consists of.
- The approaches don't compete: take product elaboration from anywhere; engineering reproducibility comes from UCP.
- The choice is simple: need a thinking process before code — look at BMAD; need equally correct code from any agent — that's UCP.
What to read next
- Use Case Pattern: the methodology — the four pillars.
- The executable standard — why rules must be enforced by an agent, not by team memory.
- UCP vs spec-driven tools — part two: OpenSpec, Spec Kit, Kiro.