AI coding tools can produce code quickly. That is not the same as producing the right system.
The hard work still sits before and around the code. What problem are we solving? Who decides what "right" means? Which assumptions are safe? Which architecture constraints already exist? How does a requirement survive the journey from a conversation to a pull request? And how does a reviewer know whether the change matches the intent, rather than only whether it compiles?
The BMAD Method is one answer to that gap. Its repository expands the name as Breakthrough Method for Agile AI Driven Development, and its documentation describes a set of named commands, called skills, that a team adds to its AI coding tool. Some help the team explore, research and specify. Others help it design, build, review and test. A handful are named agents that bring a specialist perspective to the work. The aim throughout is to keep important decisions explicit and to carry useful context forward into the work that follows.
In plain language:
BMAD gives an AI-assisted delivery team a structured way to think before it types, while people stay responsible for the decisions.
This eight-part series explains BMAD without treating it as magic. It shows the method as a configurable delivery system, compares it with lighter and heavier alternatives, and places it in the reality of South African delivery teams: mixed skills, legacy estates, procurement gates, regulation and limited specialist capacity. If you want the short comparison first, our overview of the SDD flavours sets BMAD beside GitHub Spec Kit, Kiro, OpenSpec and the rest.
The team that brought us here
Mopane Logistics is fictional, and its systems and figures are illustrative. Mopane is a Durban freight and courier company with about 650 staff and depots in Durban, Pietermaritzburg, City Deep in Johannesburg and Gqeberha. Its customers are mostly retailers and wholesalers. Its software team is seven people: a product owner, a tech lead who also carries the architecture, four engineers and one tester. Security and risk review come part-time from the group's IT function.
The team's core system is Dispatch, a twelve-year-old .NET application on SQL Server that holds every waybill and consignment. Around it sit a customer portal for tracking and invoices, a WhatsApp messaging integration through a third-party provider, and a finance system that belongs to the finance team.
For six months the engineers used AI coding assistants, a mix of Claude Code and Cursor seats. Typing got faster. Rework went up. Then one change made the cost visible. An engineer asked the assistant to rename a confusingly named Dispatch field, consignment_ref, to something clearer. The assistant did exactly that, cleanly, with tests updated. That night the batch export to finance, which read the field by its old name, failed. Nobody had told the assistant the export existed, because nobody had written it down.
The tech lead's conclusion was not that the assistant was bad. It was that the team had no reliable way to get its own knowledge into the work. That is the problem BMAD is designed for, and why Mopane looked at it as a context and decision system rather than as more AI.
Four things people confuse
Conversations about BMAD often mix up four separate things:
- The method: a way of moving from intent to verified software, with decisions made explicit along the way.
- The perspectives: product, architecture, UX, development and other specialist viewpoints applied to the work. In the current stable release, five of these are named agents: an analyst, a product manager, an architect, a developer and a UX designer.
- The artefacts: product briefs, specifications, architecture decisions, epics and stories, code and review evidence, kept in the repository where the next piece of work can find them.
- The execution environment: the AI coding tool, the repository, the terminal, the CI pipeline and the engineering controls around them.
BMAD coordinates these elements. It does not make them the same. A perspective is not a person, an artefact is not a decision until someone with authority accepts it, and the AI coding tool is not the pipeline that proves the change is safe.
A layperson's analogy
Imagine renovating a house.
A powerful AI coding assistant is like a very fast building crew. Say "please open this room up" and the crew may start breaking walls immediately. The work may be impressive. It may also remove a load-bearing wall, because the hidden constraint was never stated.
BMAD adds a structured conversation before the hammers come out:
- The analyst asks why the room must change.
- The product perspective defines who benefits and what outcome matters.
- The architect checks the load paths, the services in the walls and the building constraints.
- The planner breaks the work into safe increments.
- The developer carries out each increment.
- The reviewer confirms that it works and that the original need was met.
The named perspectives are useful, but they are not employees with professional accountability. They are structured lenses applied through the AI tool. At Mopane, the architect perspective can ask whether anything else reads consignment_ref. Only the tech lead can know, or find out, that finance does.
The problem BMAD is trying to solve
Most AI coding failures are not syntax failures. They are failures of hidden context:
- The code solves the literal request but not the business problem.
- The assistant picks a library the organisation does not support.
- A small change breaks an unstated integration contract.
- Tests prove the code behaves as written, but nobody proved the requirement was right.
- Decisions disappear into chat history and have to be rediscovered later.
BMAD's response is to turn transient conversation into durable delivery context. Intent is written down before code. Specifications name the constraints and the things that must not break. Decisions are recorded where the next change can see them. Each step leaves something the next step can check against.
None of this is new as engineering practice. Requirements, architecture decision records and definition-of-done checklists are decades old. What changes with an AI coding tool is the cost of skipping them. An assistant that starts typing immediately and confidently will fill every gap in its context with a plausible assumption. Structure is how the team decides which gaps to fill deliberately.
What BMAD is good at
BMAD is most useful when:
- the request is larger than a trivial code edit;
- several perspectives must be reconciled;
- the codebase or business domain contains constraints that matter;
- the team wants its decisions stored in the repository, not in someone's chat history;
- work needs a repeatable handoff from discovery to implementation;
- review must test the change against its intent, not only its style.
It also sizes itself. The documentation sorts work as trivial, one session, epic-sized or project-sized, and a trivial change goes straight to the build step. That sizing is one of the most useful parts of the method, and Part 2 looks at it in detail.
What BMAD does not solve
BMAD does not provide:
- correct business priorities;
- accurate source data;
- production credentials or safe access;
- legal, regulatory or security approval;
- experienced engineering judgement;
- good organisational incentives;
- a reliable deployment pipeline;
- ownership after go-live.
It can make these gaps more visible. It cannot remove the responsibility for closing them. Mopane's broken finance export is a good example. BMAD could prompt the team to list a field's consumers. It could not know about an export nobody had documented. That knowledge had to come from people, and later from deliberately recovering it from the codebase, which Part 4 covers.
A note on versions
As of 13 October 2026, the official repository identifies v6.12 as the stable line, with v6.12.2 the latest release, and v7 as a preview alpha that changes frequently and may break existing setups. The documentation site now describes the v7 preview, while the v6.12 documentation lives alongside the stable code in the repository. The two lines install and run differently.
This series describes the method as it stands on the stable line, and notes where that matters. Before you install anything, check the official repository, choose one line deliberately, and make sure the documentation you are reading matches the version you installed. Part 3 covers that choice for a first pilot.
The CloudNala view
BMAD is best understood as a context and decision system for AI-assisted delivery. Its value is not the number of agent names it offers or the volume of documents it can generate. Its value is the quality of the decisions it makes explicit, the unnecessary work it helps a team avoid, and the evidence it leaves behind for the next person.
Mopane's tech lead put the test more bluntly: after a change ships, can someone who was not in the room find out why it was built that way? If the answer is yes more often than before, the method is doing its job.
BMad and BMAD-METHOD are trademarks of BMad Code, LLC. CloudNala is not affiliated with the project; this series is our independent assessment.
The short version
BMAD is a method, not a magic developer. It adds skills and named agents to your AI coding tool, to help a team think before it types.
It coordinates four different things. Method, perspectives, artefacts and environment work together. None replaces another.
Its target is hidden context. Most AI coding failures come from what nobody told the assistant, not from bad syntax.
Perspectives are lenses, not colleagues. The analyst agent can ask the question; only your team can answer it.
People keep the decisions. BMAD makes gaps in priorities, access, approval and ownership visible. It does not close them.
Next: Part 2, from idea to working change. All parts are on the series page.
How CloudNala can help
We help software teams work out whether a structured method such as BMAD fits the way they deliver. We start from the failures they already have, like the rework, the broken integrations and the decisions lost in chat history, rather than from a tool rollout. We help them decide which context belongs in the repository, who keeps which decisions, and how the method connects to their existing engineering controls, so the first pilot tests the method against real work.
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