{"path":"research/bmad-framework-analysis.md","content":"# BMAD Framework: What It Is and What It Would Say to Deliberus\n\n**Date**: March 28, 2026\n**Purpose**: Research survey of the BMAD framework, followed by application of its lens to the Deliberus project at the research-to-build transition.\n\n---\n\n## Part 1: What BMAD Is\n\n### Origin and Creator\n\nBMAD-METHOD — \"Breakthrough Method for Agile AI-Driven Development,\" or retroactively \"Build More Architect Dreams\" — was created by a developer operating under the handle **bmadcode**, first published on GitHub in April 2025. The repository (`github.com/bmad-code-org/BMAD-METHOD`) has accumulated 42,500+ stars and 5,100+ forks as of March 2026, making it the most-starred AI development framework by a wide margin. It reached 130+ contributors and 28 releases in under a year, with a dedicated Discord community and YouTube channel (265K+ views on the flagship masterclass). The framework is MIT-licensed, completely free, with no paid tiers.\n\nThe project describes itself as responding to the \"vibe coding\" era — the pattern where developers engage in ad-hoc LLM conversations that produce fragmented code, work until context degrades, and end up in cycles of hallucination and rework. BMAD's thesis: vibe coding fails not because the AI is weak, but because the structure around it is absent.\n\n### The Core Idea\n\nBMAD's central bet is that **documentation is the source of truth, not code**. Code is a downstream artifact of specifications. In BMAD's framing:\n\n> \"Source code is no longer the sole source of truth — documentation (PRDs, architecture designs, user stories) is. Code becomes merely a downstream derivative of these specifications.\"\n\nThis \"docs-as-code\" philosophy is the spine of the framework. Everything else — the agents, the phases, the sharding — is implementation of this principle.\n\nThe structural innovation is treating an LLM session not as a conversation with one smart assistant, but as a **multi-agent team simulation**. Different roles have different contexts, permissions, and responsibilities. You don't ask a single AI to \"build my app\"; you orchestrate a product manager, an architect, a scrum master, and a developer — each loaded with the appropriate scoped context.\n\n### The Agent Corps\n\nBMAD ships 12+ specialized agent personas as compiled Markdown files:\n\n| Agent | Primary Output | Key Behavior |\n|-------|---------------|--------------|\n| **Analyst** | `product-brief.md` | Deep elicitation — probes intent, market, constraints. Won't accept vague goals. |\n| **Product Manager** | `PRD.md`, `epics.md`, `user_stories.md` | Scope gatekeeper; \"zero tolerance for scope creep\" |\n| **Architect** | `ARCHITECTURE.md`, `db-schema.md`, `api_spec.json` | Conservative, NFR-focused; defines allowed/forbidden libraries |\n| **Scrum Master** | `stories/*.md`, `workflow-status.md` | Context sharding — breaks PRD into atomic story files |\n| **Developer** | Source code, unit tests | \"Obedient craftsman\" — does NOT make architectural decisions; halts and reports conflicts |\n| **QA / Test Architect** | Test strategy, E2E test suites | Risk-based prioritization (P0-P3 coverage) |\n| **UX Designer** | `UX_Design.md`, user journeys | Front-end behavior specs for Developer Agent |\n| **Product Owner** | Validation reports | Story acceptance before Dev Agent begins |\n\nThe constraint architecture is deliberate: the Developer Agent is explicitly blocked from modifying database schemas (that's the Architect's domain). Role boundaries prevent what BMAD calls \"domain contamination.\"\n\n### The Four Phases\n\n**Phase 1 — Analysis & Discovery**: Analyst Agent conducts multi-round interviews. The goal is crystallizing vague intent into a concrete product brief. The Analyst asks about target market, UVP, cold-start strategy, privacy constraints — things founders often skip.\n\n**Phase 2 — Planning**: PM Agent translates the product brief into a full PRD: functional requirements with acceptance criteria, non-functional requirements (latency budgets, security), user personas, epic definitions. MVP scope is negotiated here, not during development.\n\n**Phase 3 — Solution Design**: Architect Agent reads the PRD and produces technical blueprints. Tech stack selection, database modeling, API contracts. The Architect generates `tech-stack.md` that explicitly defines allowed and forbidden libraries — a constraint the Developer Agent is bound by. **No application code is written until this phase completes.**\n\n**Phase 4 — Implementation**: The Scrum Master shards the architecture and PRD into atomic story files. Each story is ~1KB, containing only the context needed for one feature: acceptance criteria, relevant DB table snippets, API definitions, design references. The Developer Agent loads one story at a time. BMAD claims this produces 90% token savings versus loading full project documentation, while dramatically improving instruction-following accuracy.\n\nWithin Phase 4, the micro-loop is: shard → develop → test → validate → mark done → unlock next story. Stories have explicit dependency ordering. The Scrum Master maintains a `workflow-status.md` as the project heartbeat.\n\n### Scale-Adaptive Intelligence\n\nBMAD doesn't apply the full four-phase pipeline to every task. It ships three tracks:\n\n- **Quick Flow (Level 0-1)**: Bug fixes, small UI changes. Developer Agent loads a micro-spec and implements directly. Under 5 minutes.\n- **BMAD Standard Method**: Full-stack features, most greenfield projects.\n- **Enterprise Flow**: Compliance-sensitive domains. Adds Security Auditor Agent, mandatory static analysis gates, audit traceability.\n\nThe Analyst Agent recommends a track based on project complexity during initialization.\n\n### Context Engineering (The \"Sharding\" Innovation)\n\nThe deepest technical innovation in BMAD is its approach to LLM context windows. Rather than feeding the full PRD and architecture docs to the Developer Agent (which causes context degradation and hallucinations as documents grow), the Scrum Master pre-shards all documentation into story files that contain only what's needed for one task. The claim: 90% reduction in tokens consumed per development session, with substantially higher instruction-following accuracy.\n\nBMAD v6 adds a \"Step-File System\" allowing agents to pause mid-task and save state — addressing the problem of long tasks hitting context limits mid-execution.\n\n### Installation and Tooling\n\n```bash\nnpx bmad-method install\n```\n\nThe installer deploys agent definition files, workflow definitions, and IDE skill launchers into the project. Supports Claude Code, Cursor, Windsurf, VS Code, and 20+ other platforms. Project configuration lives in `.bmad/config.yaml`, which specifies project type, available agents, quality gates, and output paths.\n\nBMAD ships five modules: the core BMM framework (34+ workflows), BMad Builder (create custom agents), Test Architect (risk-based test strategy), Game Dev Studio, and Creative Intelligence Suite.\n\n---\n\n## Part 2: How BMAD Differs From Traditional Methodologies\n\n### vs. Agile/Scrum\n\nTraditional Agile puts humans in every role — a human product manager writes stories, a human architect designs systems, a human developer writes code, a human QA tests. BMAD keeps the roles but replaces most human execution with AI agents. The human becomes what the BMAD community calls the \"Vibe CEO\" — the strategic decider who approves artifacts and makes judgment calls between phases.\n\nAgile is iterative by default, tolerating ambiguity and evolving requirements. BMAD is more front-loaded: it invests heavily in specification before writing any code, closer in spirit to the \"spec-first\" approach validated in Fredrik's Case Study 3 (222x multiplier when specs eliminate all decisions before implementation).\n\n### vs. Lean Startup\n\nLean Startup's mantra is \"build-measure-learn\" with minimum viable experiments. BMAD's instinct is almost the opposite: front-load analysis, eliminate ambiguity, then build confidently. A BMAD practitioner would be uncomfortable starting to code before the Architect has produced the schema. This makes BMAD stronger for complex, well-understood product spaces and weaker for hypothesis-driven exploration where you genuinely don't know what to build.\n\n### vs. \"Vibe Coding\"\n\nThe contrast BMAD is most explicitly designed against. Vibe coding: ad-hoc prompts, no persistent artifacts, context degrades over conversation turns, hallucinations accumulate. BMAD: every phase produces durable artifacts, agents hand off work through documents rather than conversation history, context is scoped and fresh for each agent session.\n\n### The Distinctive Bet\n\nBMAD's differentiated bet versus alternatives (SpecKit, OpenSpec, GSD, Superpowers) is **end-to-end team simulation**. Competitors focus on specific phases: SpecKit generates specs, OpenSpec standardizes spec formats, Superpowers enforces TDD discipline. BMAD tries to simulate the entire product development lifecycle as an AI team. As of March 2026, it's the most comprehensive attempt at this, measured by stars, adoption, and feature breadth.\n\n---\n\n## Part 3: Community, Adoption, and Real Limitations\n\n### Adoption\n\n42,500+ GitHub stars in under one year is exceptional for a methodology framework (versus a library or tool). The community includes contributors spanning JavaScript, Python, and TypeScript. Discord is active. YouTube tutorials have hundreds of thousands of views. It has been adopted by practitioners from solo developers to what appears to be small team environments.\n\nThe framework is being used in production across game development (BMGD module), enterprise compliance contexts (TEA module), and standard web application development.\n\n### Real Limitations (From Community Feedback)\n\nThe most valuable signal comes from detailed real-world usage reports in GitHub issues. Key patterns:\n\n**1. The Target Audience Paradox (Issue #2003, March 2026)**: BMAD markets itself as accessible to non-technical users, but the code review workflow (Step 4) requires humans to make architectural decisions about AI-generated code they didn't write and can't trace. As one contributor documented: \"an inexperienced user does not have the skills to read and understand a complex mountain of code, nor to make architectural decisions about how to solve the problems.\" The stable v6 leaves users in a dead end. The same contributor concluded: \"A good CLAUDE.md file, starting prompt documentation, and structured step-by-step plans with checks on control files are definitely more functional\" for complex architectures.\n\n**2. Superficial Fix Patterns**: Without safeguards forcing root-cause understanding, Developer Agents produce fixes that satisfy checklist criteria without solving the underlying problem. Stories get marked \"done\" after renaming an IPC command instead of implementing the required HTTP probe.\n\n**3. Agent Communication Isolation**: Agents operate in complete isolation. The human must relay all information between agents. PO validation is invisible to Dev agents. This creates coordination overhead that BMAD claims to eliminate.\n\n**4. Monolithic Document Assumption**: The standard flow assumes one PRD, one architecture doc, one project-wide brief. This breaks brownfield projects and parallel feature development.\n\n**5. Framework Overhead for Simple Projects**: One experienced practitioner documented that an MVP \"would perhaps require 10 to 15 times the time with BMAD compared to a normal traditional development process using Claude Code or Codex.\" BMAD's own maintainer (@dracic) acknowledged this directly: the current framework is \"an R&D lab: a beautiful, chaotic bowl of brilliant ideas.\"\n\n**Where BMAD genuinely excels**, per the same critics: \"brainstorming, research, deeper analysis, advanced planning, and multi-domain support for a project, provided that it remains purely within the management of ideas.\"\n\n---\n\n## Part 4: BMAD Applied to Deliberus\n\n### The Situation\n\nDeliberus is at a specific inflection point: 29 research documents accumulated over weeks of intensive intake, 8 conceptual threads synthesized, multi-model strategic consensus achieved (consensus-path-forward.md, second-opinion-mvp-strategy.md), but zero code written. The founder has 18 years of domain expertise and a documented pattern of research without shipping. The project's unique challenge is the \"platform graveyard\" — 20+ predecessors that failed because they couldn't solve cold-start and couldn't deliver single-player utility.\n\nWhat would BMAD practitioners do with this situation? What would they validate, challenge, or ignore?\n\n---\n\n### What BMAD Would Validate\n\n**1. The spec-first instinct.** BMAD's core philosophy — documentation as source of truth, code as downstream derivative — directly validates the current research investment. Fredrik's existing docs (vision.md, conceptual-threads.md, object-model.md, technical-direction.md) are exactly the kind of artifacts BMAD's Analyst and PM phases produce. The research phase has been, in BMAD terms, an unusually thorough Analyst phase. This is not wasted time; it's front-loaded clarity that will pay compound returns during implementation.\n\n**2. The combinatorial product thesis.** BMAD's Architect Agent produces `tech-stack.md` listing explicitly allowed and forbidden libraries — a constraints-first approach. Deliberus's combinatorial bet (value emerges from the combination of extraction + correction UX + argument structure + temporal evolution, none of which individually is novel) maps well to BMAD's architectural thinking. The Architect Agent would love this design space: a rich constraint set to reason from.\n\n**3. The single-player MVP priority.** BMAD's scale-adaptive tracks — Quick Flow for simple fixes, Standard for features, Enterprise for complex systems — map directly onto the consensus recommendation from multi-model consultation: build single-player utility first, don't attempt collaborative platform until proven. BMAD would say: start the implementation phase with a Quick Flow story for the core extraction loop before touching the full four-phase pipeline.\n\n**4. The ontology-first concern.** BMAD's Phase 3 (Solution Design) explicitly refuses to write code until the Architect has defined the schema. The CLAUDE.md already says: \"Nothing is set in stone. The ontology, object model, and software architecture require careful, deep design and philosophy work.\" BMAD would fully endorse this caution. A BMAD Architect Agent, given the current docs, would produce multiple competing schema proposals and force an explicit decision before allowing any Developer Agent to proceed.\n\n---\n\n### What BMAD Would Challenge\n\n**1. The research phase has been too long, and BMAD would name it.** BMAD's Analyst Agent is designed to \"probe intent\" and resist scope creep. Given a founder who has been in the Analyst phase for 18 years, a BMAD practitioner would immediately identify this as a pathological pattern. The Analyst is supposed to produce a product brief and hand off to PM. At Deliberus, the brief exists across 29 documents but has never been crystallized into a single, bounded `product-brief.md` that the PM Agent can act on.\n\nBMAD's recommended intervention: **force the artifact**. The Analyst phase is \"done\" when `product-brief.md` exists, not when thinking feels complete. The multi-model consensus (consensus-path-forward.md) has already done this work implicitly — a BMAD practitioner would say: write the one-page product brief TODAY, even if it feels reductive. The act of constraining forces decisions that simmering never forces.\n\n**2. The ontology uncertainty is a blocker, not a virtue.** BMAD's architecture phase cannot proceed without an explicit decision. The current posture — \"nothing is set in stone,\" \"all docs are exploratory\" — is epistemically honest but operationally paralytic. A BMAD Architect Agent would say: pick one ontology proposal, mark it as the current working hypothesis, and proceed. Reversibility is overrated at this stage; building with a wrong ontology and learning from it is faster than continued deliberation. The Meteor prototype proved that working code reveals constraints that documentation cannot.\n\n**3. The absence of acceptance criteria for the intake phase.** Every BMAD story has explicit acceptance criteria: the definition of \"done\" that lets the Scrum Master mark it complete and unlock the next story. The current research phase has no such criteria. This means it cannot end — there's always more to research. A BMAD Scrum Master would ask: what does \"done with intake\" look like? What are the acceptance criteria for moving to Phase 4? Without this, the project is in an infinite loop within Phase 1.\n\n**4. The PRD has not been written.** BMAD's PM Agent exists specifically to bridge vision and implementation. Everything in Deliberus's current docs is either upstream of a PRD (vision, history, academic foundations) or downstream of one (technical-direction, object-model). The middle artifact — a bounded product requirements document with prioritized features, user personas, and explicit success metrics for v1 — does not exist. A BMAD PM Agent given the current docs would produce this in one session, and the act of producing it would force dozens of implicit decisions into explicit ones.\n\n---\n\n### What BMAD Would Miss\n\n**1. The epistemic correctness problem.** BMAD optimizes for shipping correct software. Deliberus needs to ship epistemically correct software — software where the ontology of \"claim,\" \"reason,\" \"objection,\" \"inference\" reflects genuine philosophical rigor, not just engineering convenience. BMAD has no agent for this. The Architect Agent would happily model `Claim { id, text, type }` and generate a working schema without recognizing that this flattens distinctions between propositional content, utterance acts, and normative vs. descriptive claims that matter deeply to Deliberus's thesis. BMAD's framework is optimized for \"does it ship\" not \"is it epistemically sound.\"\n\n**2. The combinatorial value emergence.** BMAD thinks in features and stories. Deliberus's core value is combinatorial — it doesn't exist in any single feature but in the interaction between features. A BMAD Scrum Master sharding the PRD into atomic stories would systematically destroy the interdependencies that make the product interesting. Story 3.2 (\"implement confidence display\") and Story 5.1 (\"implement correction UI\") look independent on the board but are deeply coupled in user experience. BMAD's sharding mechanism is optimized for independence; Deliberus requires managed interdependence.\n\n**3. The adoption problem.** BMAD's framework ends at deployment. It has a Test Architect module, a QA Agent, release gates — but nothing resembling a theory of product adoption. For Deliberus, adoption is the hardest problem. Every predecessor failed not because it shipped broken software but because it couldn't get users to change their epistemic behavior. BMAD would produce a working product and then be silent on the most important question: will anyone use it?\n\n**4. Research as legitimate phase.** BMAD treats anything before `product-brief.md` as pre-work, not real work. The 29 research documents Deliberus has accumulated represent genuine product-defining intellectual work — determining that AIF is a better ontological foundation than McKinsey hypothesis trees, that the cold-start problem requires single-player utility, that normative reasoning is categorically different from factual reasoning. BMAD has no framework for valorizing this. A BMAD Analyst Agent would have rushed to brief within 2 sessions.\n\n---\n\n### Concrete BMAD-Informed Actions for Deliberus\n\nTaking BMAD's lens seriously, without adopting the full framework, suggests three actions:\n\n**1. Write `product-brief.md` now.** One document, one page, maximum two. The Analyst phase is done. The brief should answer: What is being built? For whom (specific persona)? What problem does it solve that alternatives don't? What is the MVP boundary (not the vision, the first shippable slice)? The multi-model consensus already contains this — the action is crystallizing it into a bounded artifact rather than leaving it distributed across 29 files.\n\n**2. Write explicit acceptance criteria for \"done with research.\"** What does leaving the intake phase look like? What decision must be made (ontology? extraction approach? MVP scope?) for the research phase to be complete? Without explicit criteria, the research phase cannot end. The GPT-5.2 second opinion already named this: \"What is the single measurable behavior you want within 8 weeks?\" That question IS the acceptance criteria for Phase 1.\n\n**3. Use BMAD's Analyst Agent for requirements elicitation, not architecture.** The one area where community consensus is unanimous: BMAD's elicitation techniques are exceptional. The Analyst Agent's \"intent-driven discovery\" — probing for cold-start strategy, target market specifics, UVP constraints — is genuinely valuable for surfacing requirements that solo thinking misses. Run the Analyst Agent on the existing product brief as a stress test. It will find gaps.\n\n---\n\n### The Diagnostic Tension\n\nBMAD's deepest lesson for Deliberus is structural, not tactical: **the research phase and the specification phase require different cognitive modes, and conflating them is how projects stay permanently in planning.**\n\nResearch asks: \"What is true?\" Specification asks: \"What will we build?\" These feel continuous but are not. A BMAD practitioner would identify the current Deliberus state as still in the research mode — every document is exploratory, nothing is decided, the ontology is \"all ideas\" — when what's needed is a transition to specification mode: one ontology chosen (as current working hypothesis), one MVP scope bounded, one acceptance criteria defined.\n\nThe 29 research documents are an asset. They become a liability the moment they substitute for a decision rather than informing one.\n\n---\n\n## Sources\n\n- GitHub: [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) (42,500+ stars, v6.2.2, March 2026)\n- [BMAD-METHOD Guide: Breakthrough Agile AI-Driven Development](https://redreamality.com/garden/notes/bmad-method-guide/) — Redreamality, January 2026\n- [BMAD: The Agile Framework That Makes AI Actually Predictable](https://dev.to/extinctsion/bmad-the-agile-framework-that-makes-ai-actually-predictable-5fe7) — DEV Community, January 2026\n- [BMAD Method: Structure That Ships](https://www.signalfromnoise.co.uk/articles/bmad-method) — Signal from Noise, February 2026\n- [DeepWiki: bmadcode/BMAD-METHOD Overview](https://deepwiki.com/bmadcode/BMAD-METHOD/1-bmad-method-overview) — Last indexed March 2026\n- GitHub Issue #2003: [Structural Gaps and Contradictions of BMAD Method V.6 Stable](https://github.com/bmad-code-org/BMAD-METHOD/issues/2003) — MethCDN, March 2026\n- GitHub Issue #446: [Feedback: BMad needs feature-driven approach](https://github.com/bmad-code-org/BMAD-METHOD/issues/446) — screwyprof, August 2025\n- [The Great Framework Showdown: Superpowers vs. BMAD vs. SpecKit vs. GSD](https://ai.plainenglish.io/the-great-framework-showdown-superpowers-vs-bmad-vs-speckit-vs-gsd-360983101c10) — Rick Hightower, March 2026\n- [BMAD Method: Agile AI-Driven Development](https://theonlymittal.medium.com/bmad-method-agile-ai-driven-development-2fcb5864af4f) — Abhishek Mittal, February 2026\n- Internal cross-references: `docs/research/consensus-path-forward.md`, `docs/research/second-opinion-mvp-strategy.md`, `docs/conceptual-threads.md`, `docs/vision.md`\n"}