BMAD adds questions, artefacts and reviews. Measured from the moment someone types a request to the moment code appears, that is almost always slower than asking an assistant to implement immediately.
That is the wrong measure. The one that matters is elapsed time from an idea to an outcome the organisation can trust: code that is merged, released, working in production and doing what was actually needed. Raw coding speed affects one segment of that journey. Misunderstood requirements, late security findings, integration failures and disagreements about what "done" means can dominate the rest.
So the honest answer to "is BMAD faster?" is: it depends on the change, and you will not know for your organisation until you measure it.
Mopane Logistics is fictional, and its systems and figures are illustrative. After six months of using AI coding assistants without a method, Mopane's seven-person team had a clear impression: engineers typed faster, and rework went up. The finance-export breakage described in Part 1 was the loudest example, not the only one. When the team adopted BMAD, the operations director asked the obvious question, and the tech lead promised an answer based on evidence rather than enthusiasm.
Where the time goes
Planning moves the first code later. That is visible immediately, and it is what sceptics notice first. Whether the whole journey gets shorter depends on what the planning removes downstream. If it prevents a rework cycle, an architecture reversal or a failed release, it pays for itself many times over. If it produces documents nobody reads, it is pure cost.
Where BMAD can save time
- Fewer repeated explanations across AI sessions, because context lives in the repository rather than in chat history.
- Earlier discovery of conflicting requirements, while they are still cheap to resolve.
- Better-prepared development tasks, with acceptance criteria attached.
- Faster onboarding into an unfamiliar part of the codebase.
- More consistent acceptance criteria across engineers.
- Fewer avoidable architecture reversals.
- Review that traces code back to intent, rather than only checking style.
Where it can waste time
- Generating documents nobody uses after the next step.
- Applying the full planning path to trivial changes.
- Repeating the same information in several artefacts.
- Letting several agent perspectives argue in circles.
- Using large models for work deterministic tools can do.
- Failing to prune stale context, so agents act on old decisions.
- Treating every generated recommendation as needing a meeting.
None of this is a secret. BMAD's own documentation warns against over-planning and the cost of documents nobody reads; its sizing guidance exists so that small changes skip most of the process. Outside the project, Birgitta Böckeler's analysis of spec-driven development tools on martinfowler.com makes a similar point about the category as a whole. Her piece looks at Kiro, Spec Kit and Tessl rather than BMAD, but the warning carries over: verbose specifications can cost more than they save on small changes, and reviewing large volumes of generated markdown is tedious work that someone still has to do.
Measure the system, not the demo
Track a pilot against a comparable baseline. The tempting comparison, a demo of BMAD against a demo of an unstructured assistant on the same toy task, tells you almost nothing about real delivery.
| Metric | What it reveals |
|---|---|
| Lead time to production | The overall delivery effect |
| Time to first reviewed specification | Planning overhead and clarity |
| Rework after code review | Whether implementation matched intent |
| Escaped defects | Delivery quality |
| Security findings late in the cycle | Whether controls are integrated early |
| Reviewer effort | Whether artefacts help or burden review |
| Token and model cost | Direct AI consumption |
| Human intervention points | Operational burden and risk |
| Requirement-to-test traceability | Evidence quality |
| Time for a new engineer to contribute | Whether the context is useful |
Model cost belongs in the table but should not dominate it. A planning step that costs more in tokens and saves an engineer two days of rework is cheap. Our articles on AI coding costs beyond model prices and session hygiene cover how to measure and control the AI line itself.
Mopane's ten-week comparison
The tech lead compared a ten-week BMAD pilot with the previous quarter. To keep the comparison fair, the team only counted changes of similar size: features and integration changes, not one-line fixes. There were 12 such changes in the baseline quarter and 14 in the pilot.
The figures below are illustrative, and the samples are small. They show the shape of a result a team like Mopane's might see, not a benchmark for BMAD.
| Measure | Previous quarter | Ten-week pilot |
|---|---|---|
| Median time from request to first code | Half a day | 1.5 days |
| Changes with significant rework after review | 6 of 12 | 2 of 14 |
| Defects found in production within 30 days | 4 | 1 |
| Median reviewer hours per change, first four weeks | 4 | 5.5 |
| Median reviewer hours per change, last four weeks | 4 | 3 |
| Median lead time to production | 11 working days | 9 working days |
| AI cost per change (tokens and seats, apportioned) | R310 | R540 |
Four things stand out.
First code came later, as expected. Engineers noticed this in week one, and two of them said so loudly. It is the cost the method charges up front.
Rework and escaped defects fell. This is where most of the gain came from. Several of the baseline quarter's rework cycles traced back to the same root cause as the finance-export incident: an assistant met the literal request without knowing a constraint.
Reviewer effort rose before it fell. In the first month, reviewers were reading specifications, stories and code, and the specifications were too long. The team cut them by agreeing a one-page maximum for anything scoring below four on the sizing checklist. By the last month, reviews were faster than before, because reviewers could check code against a short, agreed statement of intent.
AI cost per change went up. Planning consumes tokens. At R540 a change against an engineering day that costs many times that, the team judged it irrelevant, but it is reported in rand every month so that nobody has to guess.
The tech lead's report to the operations director was careful. Lead time improved modestly. Quality improved more. Part of the improvement came from things the method prompted, such as contract tests around the finance export and a maintained AGENTS.md, which the team could in principle have done without it. The team recommended continuing, with sizing enforced, and measuring again after another quarter.
Three change classes
Speed comes from matching process to consequence. Three broad classes cover most work.
Class A: small and reversible. A copy change, a local refactor, a narrow bug with strong tests around it. Use a short brief, build, tests and review. Heavy planning is waste.
Class B: a meaningful feature. A new workflow, an integration or a material data change. Use a specification, architecture where the consequences warrant it, stories, build and review.
Class C: high consequence. Movement of money, identity, regulated data or broad platform changes. Use full discovery, explicit authority, threat and failure analysis, staged implementation and formal evidence gates.
A change-sizing checklist
To stop every conversation about depth becoming a debate, Mopane adopted a simple checklist. Give one point for every "yes":
- Does the change affect money, identity, personal information or safety?
- Does it cross a team or system boundary?
- Are the requirements disputed or incomplete?
- Is rollback difficult?
- Does it introduce a new technology or vendor?
- Is the current code poorly understood?
- Does it affect a regulated or audited process?
- Could failure materially harm customers or operations?
| Score | Suggested depth |
|---|---|
| 0–1 | Brief, build, test and review |
| 2–3 | Specification plus targeted architecture |
| 4–5 | Full discovery, architecture and staged delivery |
| 6–8 | Formal programme governance and specialist assurance |
Two Mopane changes show how it works.
Fixing the date format on the tracking page scored 1. The only "yes" was that the tracking page's front-end code was old and poorly understood. It went straight to build, with a test and a review, and took an afternoon.
Changing how the finance export handles consignment references scored 5. It affects money, crosses into the finance team's system, is hard to roll back once a month-end export has run, sits in poorly understood Dispatch code, and feeds an audited process. It got full discovery, a contract test agreed with the finance team, and a staged release behind a flag. Given the history, nobody argued.
The score is a conversation aid, not a substitute for judgement. A change that scores 2 but would embarrass the company if it went wrong deserves more depth than its score suggests, and the team is free to say so.
A realistic claim
Do not market BMAD, or any method, as "ten times faster" without a defined baseline and workload. Nobody can check the claim, and the first team that tries the method on the wrong kind of change will disprove it.
A responsible claim looks like this:
BMAD can reduce avoidable rework and context loss when its planning depth is matched to the change and its outputs are enforced by a strong engineering harness.
Mopane's results fit that sentence. They would not have supported a bigger one.
The short version
Measure to the trusted outcome. Time to first code is the wrong clock.
Expect first code to arrive later. The gain, if there is one, comes from less rework, fewer escaped defects and faster review.
Watch reviewer effort. It often rises before it falls; keep specifications short for small changes.
Size every change. A short checklist turns depth into a decision instead of a debate.
Claim only what you measured. Rework and context loss are honest claims; multiples are not.
Previous: Part 6, supporting tools, alternatives and hybrids. Next: Part 8, adopting BMAD in South African enterprises. All parts are on the series page.
How CloudNala can help
We help teams find out whether a structured AI delivery method actually works for them: setting a fair baseline from comparable past changes, instrumenting lead time, rework, reviewer effort and AI cost in rand, introducing a change-sizing checklist so planning depth follows consequence, and reporting results that a leadership team can rely on.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Plan an AI Delivery Pilot or write to us at consult@cloudnala.co.za