BMAD vs PRP vs SDD: The Complete Decision Framework

Continuing from the past three weeks covering BMAD, PRP, and SDD, this week I'll put it all together with a practical decision framework. This is the culmination of my vibe-planning series. If you've been following along, you now understand three powerful frameworks for structured AI-assisted development. The question is: when do you use which? ## The Core Problem All Three Solve You may wonder, why do we need three frameworks? That is because they all solve the same fundamental problem—vibe-coding collapse—but from different angles. **Vibe-coding fails because:** 1. AI doesn't maintain consistent reasoning across sessions 2. Each new session loses previous architectural decisions 3. No validation that code matches requirements 4. No institutional memory of WHY decisions were made Each framework addresses these failures differently: | Framework | Primary Focus | Core Mechanism | |-----------|---------------|----------------| | **BMAD** | Structure | 21 specialized agents with defined handoffs | | **PRP** | Context | Minimum viable packet for codebase awareness | | **SDD** | Specification | Intent as executable source of truth | ## Quick Reference: The Decision Matrix Before we dive deep, here's the quick decision matrix: | Scenario | Use This | |----------|----------| | Enterprise system from scratch | BMAD | | Feature in existing codebase | PRP | | Greenfield with clear requirements | SDD | | Solo developer, quick iteration | PRP | | Multiple teams, long-term maintenance | BMAD | | Requirements stable, AI owns implementation | SDD | | AI keeps building wrong things | PRP (context issue) | | Implementations drift between sessions | BMAD (structure issue) | | Vague requirements causing hallucinations | SDD (spec issue) | ## Framework Deep Dive ### BMAD: When Structure Is the Answer **Use BMAD when AI lacks structure.** BMAD (Build Measure Analyze Design) provides comprehensive enterprise structure through 21 specialized agents across four phases: 1. **Analysis** — Analyst Agent captures requirements into a one-page PRD 2. **Planning** — Product Manager breaks PRD into scoped user stories 3. **Solutioning** — Architect designs system structure 4. **Implementation** — Development with human oversight **Ideal Scenarios:** - Building a new SaaS platform from scratch - Enterprise system with multiple integration points - Projects requiring regulatory compliance documentation - Teams where multiple developers need shared context - Long-term products requiring maintainability **The BMAD Strength:** Documentation becomes the source of truth. Six months later, any developer (human or AI) can read the PRD and architecture docs to understand WHY decisions were made. **The BMAD Tradeoff:** Steeper learning curve. More upfront investment. Can feel heavy for small features. ### PRP: When Context Is the Answer **Use PRP when AI lacks codebase knowledge.** PRP (Product Requirements Prompt) provides the minimum viable context packet: 1. **PRD** — What you're building and why 2. **Curated Codebase Context** — File paths, library versions, patterns 3. **Validation Commands** — Executable tests AI runs to verify its work Plus the Ralph Loop for autonomous self-correction: implement → validate → fix → repeat. **Ideal Scenarios:** - Adding a feature to an existing codebase - Solo developer or small team - AI keeps generating code that doesn't fit your patterns - You need production-ready on first pass - Existing architecture, just need implementation **The PRP Strength:** Lightweight and focused. You provide context once, AI implements correctly. The Ralph Loop means AI debugs itself. **The PRP Tradeoff:** Less comprehensive documentation. Assumes you already have architectural decisions made. Best for feature work, not system design. ### SDD: When Specification Is the Answer **Use SDD when AI lacks clear requirements.** SDD (Spec-Driven Development) makes specifications executable: 1. **Spec-First** — Write detailed spec before coding 2. **Spec-Anchored** — Keep spec for evolution and maintenance 3. **Spec-as-Source** — Spec IS the main source file; humans never touch code Tools: GitHub Spec-Kit (Specify → Plan → Tasks → Implement) and Amazon Kiro (natural language → user stories → design → tasks). **Ideal Scenarios:** - Greenfield projects starting from scratch - Requirements are clear and relatively stable - You want AI to own implementation entirely - Business stakeholders can define acceptance criteria - You prefer iterating on specs, not code **The SDD Strength:** Intent becomes source of truth. Clear specifications reduce hallucinations. Spec-Kit's 50k+ stars show industry adoption. **The SDD Tradeoff:** Critics call it "Waterfall 2.0." Less agile if requirements change frequently. Works best when you can define requirements upfront. ## The Decision Tree Here's a practical decision tree to guide your choice: ``` START: What type of project? │ ├── New system from scratch │ ├── Enterprise/complex → BMAD │ └── Clear requirements → SDD │ ├── Existing codebase │ └── Adding features → PRP │ └── Not sure └── What does AI lack? ├── Lacks structure → BMAD ├── Lacks codebase knowledge → PRP └── Lacks clear requirements → SDD ``` ## The Quick Test When you're stuck, ask yourself one question: **"What does AI lack right now?"** - **AI builds inconsistently between sessions** → Structure problem → **BMAD** - **AI doesn't know my codebase patterns** → Context problem → **PRP** - **AI hallucinates or builds wrong things** → Specification problem → **SDD** This single question cuts through the complexity. ## The Hybrid Approach You may wonder, can I combine them? That is because these frameworks aren't mutually exclusive—they're complementary layers. Here's a hybrid workflow I've found effective: ### Phase 1: Requirements (BMAD-style) Use BMAD's Analyst Agent approach to create comprehensive requirements. Even without the full 21-agent system, the structured thinking helps. Output: Clear PRD with user stories and acceptance criteria. ### Phase 2: Context (PRP-style) Add codebase-specific context: file paths, library versions, existing patterns, architectural conventions. Output: Context packet AI can reference during implementation. ### Phase 3: Specification (SDD-style) Format requirements as executable specifications. Define validation commands. Output: Spec that AI generates code from. ### Phase 4: Implementation (Choose Your Tool) - **Spec-Kit** for greenfield with Copilot/Claude/Gemini - **Kiro** for full IDE experience - **PRP Ralph Loop** for existing codebase iteration ### Why Hybrid Works Each framework excels at different layers: | Layer | Framework | Contribution | |-------|-----------|--------------| | **Requirements** | BMAD | Comprehensive analysis and structure | | **Context** | PRP | Codebase awareness and patterns | | **Specification** | SDD | Executable intent and validation | | **Execution** | All | Choose based on tooling preference | ## Real-World Scenarios ### Scenario 1: Building a New SaaS Product **Context:** Starting from scratch, 3-person team, needs to scale. **Recommendation:** Start with BMAD → Transition to SDD - Use BMAD's analysis phase for comprehensive requirements - Create architecture documentation for team alignment - Once architecture is stable, use SDD for feature implementation - Spec-Kit for consistent generation across team ### Scenario 2: Adding Auth to Existing App **Context:** Solo developer, React app exists, need to add authentication. **Recommendation:** PRP - Create context packet with existing file structure - Document current auth-related code (if any) - Define validation commands (tests, type checks) - Use Ralph Loop for implementation ### Scenario 3: Greenfield Microservice **Context:** Clear API spec exists, needs implementation. **Recommendation:** SDD with Kiro - Requirements already clear (API spec) - Kiro generates user stories and technical design - Implementation tasks tracked in IDE - Hooks validate continuously ### Scenario 4: Enterprise Platform Rewrite **Context:** Legacy system rewrite, multiple teams, compliance requirements. **Recommendation:** Full BMAD - 21-agent system for comprehensive coverage - Documentation becomes source of truth - Human oversight at each phase gate - Long-term maintainability prioritized ### Scenario 5: Rapid Prototype **Context:** Validate an idea quickly, code quality secondary. **Recommendation:** Lightweight PRP or skip frameworks - Sometimes vibe-coding is fine for throwaway prototypes - If you need some structure, use minimal PRP - Don't over-engineer exploratory work ## Anti-Patterns to Avoid ### Anti-Pattern 1: Framework Overkill Using full BMAD for a small feature addition. Match framework weight to task size. ### Anti-Pattern 2: No Framework for Complex Work Vibe-coding a complex feature and wondering why it fails. Structure prevents chaos. ### Anti-Pattern 3: Wrong Framework for Context Using SDD when the problem is codebase awareness. AI will generate spec-compliant code that doesn't fit your system. ### Anti-Pattern 4: Framework Switching Mid-Task Starting with PRP, switching to BMAD halfway through. Pick one and commit. ### Anti-Pattern 5: Ignoring Validation Using any framework without validation commands. All three work best with executable tests. ## The Evolution Path As your project matures, your framework needs may change: ``` Prototype → Feature Development → System Scale ↓ ↓ ↓ Vibe/PRP PRP/SDD BMAD/SDD ``` **Early stage:** Move fast, PRP for context **Growth stage:** SDD for consistency, PRP for existing features **Scale stage:** BMAD for enterprise structure ## My Recommendation If you're just starting with structured AI development: 1. **Start with PRP** — It's the gentlest learning curve and solves the most common problem (AI doesn't know your codebase) 2. **Add SDD for greenfield** — When starting new projects, use Spec-Kit or Kiro 3. **Graduate to BMAD for enterprise** — When you need comprehensive structure and multi-team coordination The goal isn't to master all three immediately. Pick the one that matches your current pain point and expand from there. ## What's Next This completes my four-part series on vibe-planning frameworks: - Week 1: BMAD Method - Week 2: PRP Framework - Week 3: Spec-Driven Development - Week 4: Decision Framework (this post) If you've been following along, you now have the complete toolkit for structured AI-assisted development. Stay tuned!! Next week I'll start a new series on practical implementation—taking one of these frameworks and building something real, step by step. ## Key Takeaways - **BMAD** = Structure problem → 21 agents, enterprise systems, documentation as source of truth - **PRP** = Context problem → Minimum viable packet, existing codebases, Ralph Loop self-correction - **SDD** = Specification problem → Intent as source of truth, greenfield projects, Spec-Kit/Kiro tooling - **The Quick Test**: "What does AI lack?" → Structure/Context/Specification → BMAD/PRP/SDD - **Hybrid works**: BMAD requirements → PRP context → SDD specification → Choose execution tool - **Match framework to task size**: Don't use BMAD for small features, don't vibe-code enterprise systems - **Start with PRP**: Gentlest learning curve, solves most common problem ## Additional Documents to Read on This - [BMAD Method - GitHub](https://github.com/bmadcode/BMAD-METHOD) - Full 21-agent framework - [PRP Framework - GitHub](https://github.com/Wirasm/PRPs-agentic-eng) - Context engineering approach - [GitHub Spec-Kit](https://github.com/github/spec-kit) - SDD toolkit - [Amazon Kiro](https://kiro.dev/) - Spec-driven IDE - [ThoughtWorks on SDD](https://www.thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices) - Industry perspective --- *This completes my four-part vibe-planning series. Previous posts covered BMAD Method, PRP Framework, and Spec-Driven Development. Next: Practical implementation series.*