Is BMAD faster, or does it spend time differently?

The obvious challenge to BMAD is a fair one:

I could use plan mode, generate the code and finish this in ten minutes. Why should I wait for a longer workflow?

Measured from the moment someone types a request to the moment code appears, a structured workflow is rarely quicker. It asks questions, records decisions and reviews its own output. A plain "plan and code" session does none of that, so it finishes first.

Finishing first is not the same as being done. The honest answer to "is BMAD faster?" is that it spends time differently, and whether that trade is worth it depends on the change. You will not know for your own organisation until you measure it.

Mopane Logistics is fictional, and its systems and figures are illustrative. After six months of 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 in Part 1 was the loudest example, not the only one. When the team adopted BMAD, two engineers raised the ten-minute objection within a week, and the operations director asked the same question in different words. The tech lead promised an answer based on evidence rather than enthusiasm.

What the extra time is buying

BMAD's own documentation answers the ten-minute objection directly. Its guidance on building a change says the plan-and-implement half of bmad-build "usually takes about as long" as plan mode, and "usually needs a couple fewer turns from you." The difference comes afterwards. The workflow "then reviews the result, triages the findings, and automatically fixes the ones worth fixing." Plan mode and code, in the documentation's words, "does none of this."

So the longer run is not a longer plan. It is review and correction that a quick session leaves for later. Someone still has to ask for that review, read the findings, set aside the ones that are noise or belong to some other piece of work, and arrange the fixes. In a quick session, that someone is the developer, one turn at a time.

The same documentation names the resource it is trying to protect: "Human attention is by far the most expensive resource, and the productivity bottleneck in AI-backed software development." A model can keep working while an engineer does something else. The engineer's own attention cannot be run in parallel. That changes the productivity question. Do not ask only how many minutes passed before the agent stopped. Ask how many minutes of skilled human attention it took to reach a change you would trust.

Three clocks

Three clocks matter, and teams usually watch only the first.

A ten-minute implementation followed by forty minutes of review, triage and repair was not a ten-minute delivery. A twenty-five-minute automated run that needs five minutes of focused human review may be the faster delivery system, even though the terminal ran longer.

That is a claim to test, not a promise. Automated review can be noisy, can miss material defects and can spend more inference than a change deserves. The point of the three clocks is to make all of that visible.

Size the work before choosing the process

BMAD's guidance is to use the smallest amount of method that safely fits the change. It describes a typical bmad-build session as one goal: about 500 lines of code added or changed, not counting tests, across a small handful of files.

Treat that as a sizing heuristic, not a quality limit. A forty-line change to how users sign in may deserve far more care than a six-hundred-line internal migration. How far a change reaches, whether it can be undone, and whether important decisions are still open matter as much as how many lines it touches.

If a change will not fit one bounded session, the answer is not a bigger prompt. Plan the larger outcome, split it into coherent units, and build one unit per run. Once the pattern for those units is stable, BMAD's bmad-build-auto can implement and review a single ticket unattended, though it does not orchestrate a set of tickets for you.

How bmad-build chooses its depth

Within a session, bmad-build investigates the request and the codebase, then reports three facts about the design it has settled on:

1. Intent gaps: decisions that are still missing and would be visible in the result.
2. Irreversible actions: choices that are difficult or costly to undo.
3. Footprint: how much code and how many systems the change touches.

A design that is clean on all three takes a light path, with a minimal plan and implementation in the same session. Anything flagged gets a full written plan first, with each intent gap recorded as an open question the developer answers before approving it. This is more useful than treating every feature as either "no process" or "full process". The method adapts to consequence.

Mopane's sizing checklist

Mopane added one layer of its own on top. The three factors work inside a session; the team also wanted a quick way to decide, before anyone opened a session, whether a change needed planning skills, architecture or formal governance at all. It adopted an eight-question checklist, 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?

The score maps to three broad classes of change. Class A (0–1) is small and reversible: brief, build, test and review. Class B (2–3) is a meaningful feature: a specification plus targeted architecture. Class C (4 and above) is high consequence: full discovery, staged delivery and, at the top of the range, formal governance and specialist assurance.

Fixing the date format on the tracking page scored 1. Its only "yes" was that the front-end code was old and poorly understood. It went straight to a single bmad-build run, which flagged nothing, and took an afternoon including review.

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, three ticket-sized build runs 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.

When to skip the process

The guidance is explicit here too: "For a throwaway prototype, or a trivial change you will review yourself, skip the process." You can make the change directly, or tell bmad-build to take its one-shot route and, where appropriate, to skip review.

Good candidates:

• Exploratory code that will never reach production.
• A spelling correction.
• A local development convenience with no shared or production impact.
• A small change protected by obvious deterministic tests and immediate human inspection.

Skipping review is a risk decision, not a speed setting. The person who chooses it owns the review that the workflow no longer performs.

The reviewed path earns its extra time when a defect could escape into production, when the change creates a pattern others will copy, when sign-in, payments, personal information or permissions are involved, when several files must stay consistent, when the codebase hides contracts or has weak tests, or when a reviewer would otherwise coordinate several manual passes. The extra inference is justified only when it removes more expensive human work or production risk.

Where it saves human time, and where it still wastes it

It can save human time because it:

• investigates the repository before asking questions, so the developer is not asked things the code already answers;
• reduces repeated explanation across sessions, because context lives in the repository rather than in chat history;
• runs implementation, review, triage and correction as one workflow;
• fixes findings that belong to the change, rather than handing every observation back to the developer;
• defers unrelated issues that were already in the code, instead of letting the current change grow;
• goes back to the plan when the code is weak, and back to the goal when the plan is weak, rather than patching only the diff.

It can still waste time when a team:

• runs bmad-build on a spelling correction;
• gives one run several independent goals;
• generates documents nobody uses after the next step;
• runs expensive reviewers without a risk-based reason;
• repeats the same information in several artefacts;
• keeps stale project context, so agents act on old decisions;
• treats automated review as proof of correctness;
• lets review loops continue without a stop condition.

None of this is a secret. 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 text is work someone still has to do.

Measure the complete delivery system

Track a pilot against comparable work. A demo of BMAD against a demo of an unstructured assistant on the same toy task tells you almost nothing about real delivery.

Model cost belongs in the table but should not dominate it. Our articles on AI coding costs beyond model prices and session hygiene cover how to measure and control that line.

A fair comparison

Take two groups of similar changes from the same repository. For the baseline group, use ordinary plan mode and implementation, run the team's normal review, and record the time spent triaging and correcting by hand. For the BMAD group, use bmad-build with its normal review path, and record elapsed time, developer turns and every human intervention. Apply the same final acceptance standard to both.

Compare reviewed outcomes, not demonstrations. If BMAD takes longer, costs more and does not reduce human effort or defects for a class of change, use the lighter path for that class.

Mopane's ten-week comparison

Mopane's tech lead compared a ten-week pilot with the previous quarter. To keep it fair, the team counted only changes of similar size, features and integration work rather than one-line fixes: 12 in the baseline quarter and 14 in the pilot. Engineers logged their active minutes on each change in a shared sheet, which was rough but better than guessing.

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.

First code came later, as expected. It is the cost the method charges up front, and the two engineers who raised the ten-minute objection were right about that clock.

Human attention fell more than lead time did. Engineers spent less of their own time steering, reviewing and correcting each change, even where the agent ran longer. That was the clock the team cared most about.

Rework and escaped defects fell. 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, specifications were too long. The team agreed a one-page maximum for anything scoring below four on the checklist, and by the last month reviews were faster than before.

AI cost per change went up. At R540 a change, against an engineering day that costs many times that, the team judged it acceptable, and it is reported in rand every month so that nobody has to guess.

The report to the operations director was careful. Lead time improved modestly; human effort and quality improved more. Part of the gain 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.

A claim you can defend

Do not market BMAD, or any method, as universally faster, and certainly not as "ten times faster" without a defined baseline and workload. Say what the method is optimising:

BMAD may use more elapsed compute time to reduce human coordination, review administration and avoidable rework. It is worthwhile when the value of integrated review and correction exceeds the extra inference and waiting time.

That claim can be tested. It also explains why a throwaway prototype and a production identity change should not go through the same process. Mopane's results fit that sentence. They would not have supported a bigger one.

The short version

Finishing first is not being done. The longer run buys review, triage and correction.

Watch three clocks. Wall-clock time, human-attention time and quality-adjusted time tell different stories.

Protect human attention. It is the scarce resource; inference is not.

Size before you build. One goal per run, about 500 changed lines, and the light path only when nothing is flagged.

Skip deliberately. Skipping review is a risk decision someone owns.

Claim only what you measured. Less human effort and rework are defensible; 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.

Sources

BMAD guidance quoted here was checked against the official documentation on 13 October 2026. Recheck it before you rely on it, because the method changes quickly.

• BMAD Method: build a change (work sizing, integrated review, decision factors and when to skip the process)
• BMAD Method documentation and repository
• Birgitta Böckeler: Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

How CloudNala can help

We help teams find out whether a structured AI delivery method actually saves them time: setting a fair baseline from comparable past changes, measuring human attention as well as elapsed time and AI cost in rand, deciding which kinds of change should take the reviewed path and which should skip it, and reporting results 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