Model AI Nggak Ada yang Ngomongin Ini (Padahal Kelihatan Banget Lebih Bagus)

OpenSpec bagus untuk 'denah arsitektur'. Tapi BMad melangkah lebih jauh — dengan specialized agents, 4 fase end-to-end, dan intelligent guide yang membuat AI coding terasa seperti tim engineering sungguhan.
"OpenSpec memberi AI satu denah. BMad memberi AI satu tim arsitek, PM, dan developer virtual yang bekerja sama."
Dua minggu lalu saya menulis tentang OpenSpec — framework Spec-Driven Development yang memaksa AI bekerja dari spesifikasi, bukan dari obrolan chat. metodenya solid: propose → apply → archive, folder specs/ vs changes/, dan IETF RFC 2119 untuk bahasa yang tegas.
Tapi OpenSpec punya satu limitasi fundamental: ia hanya mengorganisir konteks. Tidak ada agents. Tidak ada workflow management. Tidak ada yang namanya "PM virtual" atau "Arsitek virtual" yang menuntun proses.
Masuklah BMad Method.
BMad (Build More Architect Dreams) adalah framework AI-driven development yang jauh lebih komprehensif dari OpenSpec. Kalau OpenSpec itu asisten arsitektur, BMad adalah sistem operasi untuk AI coding teams.
| Aspek | OpenSpec | BMad |
|---|---|---|
| Fokus | Context management | Full-stack AI development workflow |
| Agents | ❌ Tidak ada | ✅ PM, Architect, SM, DEV |
| Fase | 1 (Spec lifecycle) | 4 (Analysis → Planning → Solutioning → Implementation) |
| Intelligent Guide | ❌ Tidak ada | ✅ BMad-Help |
| Tracks | 1 alur | 3 tracks (Quick/BMad/Enterprise) |
| Output | Spec documents | PRD + Architecture + Epics + Stories + Code |
BMad bukan sekadar tools — ia adalah metodologi yang mengubah cara Anda bekerja dengan AI dari "obrolan satu-satu" menjadi "managing a distributed team of specialized agents".
Berbeda dengan OpenSpec yang fokus di fase spesifikasi saja, BMad mencakup seluruh siklus pengembangan — dari ide awal sampai 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 | Facilitator AI yang menuntun sesi ideasi — seperti punya coaching session dengan product strategist |
| research | Workflow | Market research, domain research, technical research — validasi asumsi sebelum komitmen |
| product-brief | Output | Dokumen visi strategis — foundation sebelum masuk planning |
Di sinilah BMad mulai beda. Untuk track BMad Method dan Enterprise:
Untuk track Quick Flow? Langsung lompat ke implementation — tidak perlu lewat fase 1-3.
| Property | Type | Description |
|---|---|---|
| Create Architecture | Workflow | Architect Agent mendokumentasikan technical decisions + ADRs (Architecture Decision Records) |
| Epics & Stories | Workflow | PM Agent memecah PRD menjadi epics dan user stories yang bisa di-implementasi |
| Implementation Readiness Check | Workflow | Architect Agent memvalidasi cohesion antara PRD, Architecture, dan Stories — gate check sebelum coding dimulai |
Story by story, dengan sprint tracking dan retrospective:
sprint-status.yaml untuk trackingsemua epics dan stories.
criteria yang jelas.
sudah didefinisikan.
requested.
Ini jantungnya BMad. Bukan satu AI yang menangani semuanya — tapi empat specialized agents dengan role berbeda:
Product Manager virtual. Buat PRD, pecah jadi epics & stories, tangani scope changes. Seperti punya product manager yang tidak pernah lupa user story.
Arsitek virtual. Buat architecture document dengan ADRs, validasi implementation readiness. Seperti punya tech lead yang mendokumentasikan setiap keputusan teknis.
Scrum Master virtual. Sprint planning, story creation, track progress, retrospective. Seperti punya SM yang menjaga proses tetap on-track.
Developer virtual. Implement story sesuai spec, code review. Eksekutor yang tahu persis apa yang harus dibangun dan bagaimana.
Sama seperti tim engineering sungguhan — specialist outperform generalis. AI yang fokus jadi "arsitek" akan membuat keputusan arsitektural yang lebih konsisten dibanding AI yang sekaligus jadi arsitek, PM, dan developer dalam satu sesi chat.
Fitur paling killer di BMad: BMad-Help. Ini seperti having a senior engineer who knows the entire workflow sitting next to you.
bmad-helpAtau dengan konteks:
bmad-help I have a SaaS idea, where do I start?BMad-Help akan:
BMad-Help tidak cuma menjawab pertanyaan umum — ia tahu state project Anda saat ini, fase yang sedang dikerjakan, dan apa yang perlu dilakukan selanjutnya. Ini yang membedakan dari sekadar bertanya ke AI biasa.
BMad menyediakan track berbeda tergantung kompleksitas proyek:
| Property | Type | Description |
|---|---|---|
| Quick Flow | Track | Bug fixes, simple features, clear scope (1-15 stories). Tech-spec only, langsung ke 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. |
Ini lebih fleksibel dari OpenSpec yang hanya punya satu alur. Quick Flow untuk perbaikan kilat, BMad Method untuk produk baru, Enterprise untuk sistem kompleks dengan kebutuhan compliance.
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 pakai specs/ dan changes/. BMad pakai _bmad/ untuk konfigurasi
agent dan _bmad-output/ untuk semua artefak planning dan implementasi.
Struktur yang lebih bersih dan explicit.
Mirip dengan project.md di OpenSpec, tapi dengan kapabilitas lebih:
bmad-generate-project-contextSetiap dokumen menjadi context untuk fase berikutnya. PRD → constraints untuk Architect. Architecture → patterns untuk DEV. Story files → focused context per implementation.
Proyek baru (greenfield) yang butuh planning lengkap. Butuh specialized agents untuk role separation. Mau ada intelligent guide sepanjang proses. Skala enterprise dengan compliance requirements.
Proyek brownfield/legacy yang butuh context management. Tim sudah nyaman dengan vibe coding tapi butuh struktur. Butuh delta-based spec management. Inginsimpler adoption curve.
BMad menang di:
OpenSpec menang di:
OpenSpec memperkenalkan konsep penting: Spec-Driven Development. Berhenti vibe coding, mulai dari spesifikasi yang jelas.
Tapi BMad melangkah lebih jauh. Ia tidak hanya mengorganisir spesifikasi — ia mengorganisir seluruh tim pengembangan virtual dengan specialized agents, workflow yang jelas, dan intelligent guide yang menuntun dari ide sampai kode.
BMad mewakili evolusi natural dari AI coding tools. Dari CLI chatbot → context management (OpenSpec) → multi-agent team (BMad). Semakin mature pemahaman kita tentang cara bekerja dengan AI, semakin sophisticated pula tools yang kita butuhkan.
OpenSpec = asisten arsitektur yang baik BMad = sistem operasi untuk AI-driven development teams
Kalau Anda sudah mencoba vibe coding dan mulai merasa batasannya, OpenSpec adalah langkah pertama yang bagus. Tapi kalau Anda serius ingin mengubah AI jadi force multiplier untuk engineering, BMad adalah langkah berikutnya.
