The BMad Method: A Structured Development Methodology for AI-Assisted Coding

Every developer using AI coding assistants has hit the same wall. You ask for a feature, the AI generates 400 lines of code, and half of it is wrong. You iterate. It generates more code. The files diverge from the architecture. Tests break. Dependencies spiral. Three hours later, you have a working prototype and a codebase that looks like it was written by five different people with no shared vocabulary.

The problem is not the AI. The problem is the process.

AI assistants are fast, articulate, and aggressively agreeable. They will build whatever you ask, in whatever order you ask it, with no regard for long-term structure. Without a methodology that constrains both the human and the machine, AI-assisted development degenerates into what I call "happy path hacking" -- the first thing that works becomes the foundation, and every subsequent change is layered on top like sedimentary rock.

I have been running AI-assisted development on 6 concurrent Laravel projects, a Python desktop app, a Java trading engine, and a Flutter mobile app for the past several months. The methodology that emerged from that crucible is BMad Method (Build More Architect Dreams).

The Four Phases

BMad has four phases that run sequentially per feature or epic. No phase is optional, and the exit gates are enforced by the AI itself.

Phase 1: Analysis

Before a single line of code is written, the AI is instructed to produce a structured analysis of the problem. The output format is fixed:

## Context
[What exists today. Current state. Pain points.]

## Constraints
[Technical boundaries. Database schema implications. Deployment concerns.]

## Questions
[Categorized questions that scope the work.]

The key rule: the AI must generate questions, not assumptions. Every assumption it would normally make silently must be surfaced as a question for the human to answer. This is the single most important behavior to enforce. Left to its own devices, an AI assistant will silently decide on database schema, UI patterns, error handling strategies, and deployment approaches. Each of those decisions can be wrong by 90 degrees and compound into a mess.

An example from the blog API project:

## Questions

### Technical Scope
- Should the API live under a subdomain (api.martinfournier.com) or a prefix (/api)?
- Is Sanctum required, or is a custom middleware sufficient?
- Should the API return full post content or summaries on the list endpoint?

### Data Modeling
- Should slugs be auto-generated from titles or explicitly provided?
- Should drafts have a published_at of null or a future date?
- Should the API support pagination from day one?

### Security
- Is a single bearer token adequate, or do we need scoped tokens?
- Should the preview route use signed URLs or an auth check?

Every question answered by the human produces a documented decision. The AI records the answer and uses it to constrain all subsequent work.

Exit gate: All questions are answered. The analysis document exists and is saved as a reference artifact.

Phase 2: Planning

Phase 2 is a detailed implementation plan. The AI produces a step-by-step sequence with file-level granularity:

## Implementation Plan

### Step 1: Create BlogApiAuth middleware
File: app/Http/Middleware/BlogApiAuth.php
- Hash-compare bearer token against config value
- Return 401 on mismatch, 500 on missing config
- Register as 'auth.blog-api' in bootstrap/app.php

### Step 2: Define API routes
File: routes/api.php
- Single prefix group: /api/blog
- Apply auth.blog-api middleware to all routes
- Define 6 endpoints (GET list, GET show, POST store, PUT update, PUT updateContent, DELETE)

### Step 3: Build BlogPostController
File: app/Http/Controllers/Api/BlogPostController.php
- index: paginated list with selected fields
- show: full post with content
- store: validate, auto-slug, create
- update: validate, update, return
- updateContent: update only content field
- destroy: delete and return confirmation

Each step lists exactly which files to create or modify, what changes to make, and what tests to write. The plan is structured so that a human can review it in under 5 minutes and approve or reject individual steps.

The plan is the review artifact. The human should spend their review effort here, not on diff output. If the plan is wrong, the code will be wrong faster. If the plan is correct, the AI can execute it with minimal supervision.

Exit gate: The implementation plan is reviewed and approved. Every step has a clear definition of done.

Phase 3: Solutioning

This is where code gets written. The AI executes the approved plan step by step. Each step produces a commit. The commits are small, focused, and individually testable.

The critical behavior: the AI must finish each step before starting the next. No jumping ahead. No "while I'm in this file, let me also fix that unrelated thing." Scope creep is forbidden at the code level. If a new concern emerges during solutioning, it becomes a question in Phase 1 of the next cycle.

This is the phase where the AI is most productive. Given a precise plan with file paths, function signatures, and test expectations, it can generate working code in minutes. The constraint is not the AI's speed. The constraint is the plan's completeness.

Exit gate: All steps are implemented. All tests pass. The diff is clean and matches the plan.

Phase 4: Implementation

Phase 4 is deployment, documentation, and cleanup. This is where the human takes over again:

• Deployment (Fly.io, CI/CD)
• Documentation updates
• Commit message written in the project's required format (business context + technical changes)
• Backlog status updates

The AI can assist with deployment scripts, commit message drafting, and changelog updates. But the human validates that the deployed feature works in production.

Exit gate: Feature is live. Documentation is updated. Backlog is current.

Why BMad Works with AI

The methodology is deliberately structured around the weaknesses of current AI assistants:

1. AI does not naturally plan. It optimizes for immediate output quality, not long-term structure. Forcing a planning phase compensates for this.

2. AI does not naturally ask questions. It treats ambiguity as permission to assume. Forcing a question-asking phase surfaces hidden assumptions.

3. AI does not naturally respect scope. It will happily refactor unrelated code while implementing a feature. The step-by-step execution constraint prevents this.

4. AI produces better code from better specifications. The planning phase artifact doubles as a specification. The AI writes better code against a written plan than against a conversation.

5. Commit discipline is better with a plan. Each planned step maps to one commit. The commit history becomes a narrative of the plan's execution, not a stream of consciousness.

Real Results

I have used BMad across 4 major features on martinfournier.com:

• Blog API (US-048): 6 endpoints, middleware, tests, deployment. Three AI coding sessions, ~20 commits, zero rework.
• Weekly meal pipeline integration: Scraper, Gemini vision, menu generator, web dashboard. Two sessions, ~15 commits.
• OCR receipt benchmark: 18 fixtures, 3 model runners, evaluator, report generator. One session, ~12 commits.
• Project page revamp: Status management, real data from Fly.io, hover cards. One session, ~8 commits.

Before BMad, a feature of that size would involve 3-5 AI sessions, significant rework, and at least one "let's undo that and start over" moment. With BMAD, the rework rate dropped to near zero.

When BMad Breaks

The methodology is not universal. It breaks under three conditions:

1. Exploratory work. If you do not know what the solution looks like, you cannot plan it. BMad assumes a known target. Research spikes and proof-of-concept work need a different approach (usually: build a throwaway prototype in Phase 1, scrap it, then apply BMAD on the real build).

2. Tiny changes. A one-line bug fix does not need four phases. BMad scales down to a single conversation turn: "Analysis: the issue is X. Plan: change Y in file Z. Implementation: PR merged." The phases compress but the order stays the same.

3. Urgent production fixes. When the site is down, you fix the site. BMad is for deliberate feature work, not incident response.

The Bottom Line

AI coding assistants are extraordinary at execution and terrible at governance. BMad adds that governance layer. It does not slow down the AI. It focuses the AI on the right work in the right order.

The cost is small: 15 minutes of planning per feature and the discipline to enforce the exit gates. The return is substantial: fewer iterations, cleaner code, auditable decisions, and a development pace that is faster because you spend less time cleaning up messes.

The methodology is the differentiator. The AI is just the accelerator.