OpenSpec is good for 'architectural blueprints'. But BMad goes further — with specialized agents, 4 end-to-end phases, and an intelligent guide that makes AI coding feel like a real engineering team.
"OpenSpec gives AI a blueprint. BMad gives AI a team of virtual architects, PMs, and developers working together."
Two weeks ago I wrote about OpenSpec — a Spec-Driven Development framework that forces AI to work from specifications, not from chat conversations. Its method is solid: propose → apply → archive, specs/ vs changes/ folders, and IETF RFC 2119 for precise language.
But OpenSpec has one fundamental limitation: it only organizes context. No agents. No workflow management. No such thing as a "virtual PM" or "virtual Architect" guiding the process.
Enter BMad Method.
BMad (Build More Architect Dreams) is a far more comprehensive AI-driven development framework than OpenSpec. If OpenSpec is an architecture assistant, BMad is an operating system for AI coding teams.
| Aspect | OpenSpec | BMad |
|---|---|---|
| Focus | Context management | Full-stack AI development workflow |
| Agents | ❌ None | ✅ PM, Architect, SM, DEV |
| Phases | 1 (Spec lifecycle) | 4 (Analysis → Planning → Solutioning → Implementation) |
| Intelligent Guide | ❌ None | ✅ BMad-Help |
| Tracks | 1 flow | 3 tracks (Quick/BMad/Enterprise) |
| Output | Spec documents | PRD + Architecture + Epics + Stories + Code |
BMad is not just a tool — it is a methodology that changes how you work with AI from "one-on-one chat" to "managing a distributed team of specialized agents".
Unlike OpenSpec which only focuses on the specification phase, BMad covers the entire development cycle — from initial idea to working code.
graph LR
subgraph Phase1["🔍 Phase 1: Analysis"]
A1["Brainstorming"] --> A2["Research"]
A2 --> A3["Product Brief"]
end
subgraph Phase2["📋 Phase 2: Planning"]
B1["Create PRD"] --> B2["UX Design"]
end
subgraph Phase3["🏗️ Phase 3: Solutioning"]
C1["Create Architecture"] --> C2["Epics & Stories"]
C2 --> C3["Implementation Readiness Check"]
end
subgraph Phase4["🔨 Phase 4: Implementation"]
D1["Sprint Planning"] --> D2["Story by Story"]
D2 --> D3["Code Review"]
D3 --> D4["Retrospective"]
end
Phase1 --> Phase2 --> Phase3 --> Phase4
style Phase1 fill:#1e3a5f,color:#fff
style Phase2 fill:#2d5016,color:#fff
style Phase3 fill:#5c4033,color:#fff
style Phase4 fill:#4a1f1f,color:#fff| Property | Type | Description |
|---|---|---|
| brainstorming | Workflow | AI facilitator that guides ideation sessions — like having a coaching session with a product strategist |
| research | Workflow | Market research, domain research, technical research — validate assumptions before committing |
| product-brief | Output | Strategic vision document — foundation before entering planning |
This is where BMad starts to differ. For the BMad Method and Enterprise tracks:
For the Quick Flow track? Jump straight to implementation — no need to go through phases 1-3.
| Property | Type | Description |
|---|---|---|
| Create Architecture | Workflow | Architect Agent documents technical decisions + ADRs (Architecture Decision Records) |
| Epics & Stories | Workflow | PM Agent breaks down the PRD into implementable epics and user stories |
| Implementation Readiness Check | Workflow | Architect Agent validates the cohesion between PRD, Architecture, and Stories — a gate check before coding begins |
Story by story, with sprint tracking and retrospective:
sprint-status.yaml to track allepics and stories.
acceptance criteria.
defined specifications.
requested.
This is the heart of BMad. Not one AI handling everything — but four specialized agents with different roles:
Virtual Product Manager. Creates PRD, breaks it down into epics & stories, handles scope changes. Like having a product manager who never forgets a user story.
Virtual Architect. Creates architecture document with ADRs, validates implementation readiness. Like having a tech lead who documents every technical decision.
Virtual Scrum Master. Sprint planning, story creation, track progress, retrospective. Like having an SM who keeps the process on track.
Virtual Developer. Implements story according to spec, code review. An executor who knows exactly what to build and how.
Just like a real engineering team — specialists outperform generalists. An AI focused on being an "architect" will make more consistent architectural decisions compared to an AI that simultaneously acts as architect, PM, and developer in a single chat session.
The most killer feature in BMad: BMad-Help. It's like having a senior engineer who knows the entire workflow sitting next to you.
bmad-helpOr with context:
bmad-help I have a SaaS idea, where do I start?BMad-Help will:
BMad-Help doesn't just answer general questions — it knows your current project state, the phase you're working on, and what needs to be done next. This is what sets it apart from just asking a regular AI.
BMad provides different tracks depending on project complexity:
| Property | Type | Description |
|---|---|---|
| Quick Flow | Track | Bug fixes, simple features, clear scope (1-15 stories). Tech-spec only, straight to implementation. |
| BMad Method | Track | Products, platforms, complex features (10-50+ stories). PRD + Architecture + UX. |
| Enterprise | Track | Compliance, multi-tenant systems (30+ stories). PRD + Architecture + Security + DevOps. |
This is more flexible than OpenSpec which only has one flow. Quick Flow for quick fixes, BMad Method for new products, Enterprise for complex systems with compliance requirements.
your-project/
├── _bmad/
│ ├── agents/ # Agent configurations
│ ├── workflows/ # Workflow definitions
│ ├── tasks/ # Task templates
│ └── config # BMad configuration
│
├── _bmad-output/
│ ├── planning-artifacts/
│ │ ├── PRD.md # Product Requirements Document
│ │ ├── architecture.md # Technical decisions + ADRs
│ │ ├── ux-spec.md # UX specifications
│ │ └── epics/ # Epic + story files
│ │
│ ├── implementation-artifacts/
│ │ └── sprint-status.yaml # Sprint tracking
│ │
│ └── project-context.md # Implementation rulesOpenSpec uses specs/ and changes/. BMad uses _bmad/ for agent
configuration and _bmad-output/ for all planning and implementation
artifacts. A cleaner and more explicit structure.
Similar to project.md in OpenSpec, but with more capabilities:
bmad-generate-project-contextEach document becomes context for the next phase. PRD → constraints for the Architect. Architecture → patterns for the DEV. Story files → focused context per implementation.
New (greenfield) projects that need complete planning. Need specialized agents for role separation. Want an intelligent guide throughout the process. Enterprise scale with compliance requirements.
Brownfield/legacy projects that need context management. Team is comfortable with vibe coding but needs structure. Need delta-based spec management. Want a simpler adoption curve.
BMad excels at:
OpenSpec excels at:
OpenSpec introduced an important concept: Spec-Driven Development. Stop vibe coding, start from clear specifications.
But BMad goes further. It doesn't just organize specifications — it organizes an entire virtual development team with specialized agents, clear workflows, and an intelligent guide that leads from idea to code.
BMad represents the natural evolution of AI coding tools. From CLI chatbot → context management (OpenSpec) → multi-agent team (BMad). The more mature our understanding of working with AI becomes, the more sophisticated the tools we need.
OpenSpec = a good architecture assistant BMad = an operating system for AI-driven development teams
If you've tried vibe coding and are starting to feel its limitations, OpenSpec is a good first step. But if you're serious about turning AI into a force multiplier for engineering, BMad is the next step.
