BMAD is not a delivery system on its own. It is a set of skills and named agents that run inside an AI coding tool and shape how work moves from intent to code. Everything that turns that code into something an organisation can merge, release and trust comes from elsewhere: source control, pipelines, tests, scanners, observability and the people who approve material decisions.
That has two consequences. The first is that a BMAD adoption is only as good as the toolchain around it. The second is that BMAD is one option among several, and the right choice depends far more on the change in front of you than on which method is fashionable.
Mopane Logistics is fictional, and its systems and figures are illustrative. Mopane's seven-person software team runs its code on GitHub with GitHub Actions, and its engineers use a mix of Claude Code and Cursor. By this point it uses BMAD for features and changes near the old Dispatch system, and something much lighter for everything else. A sister team in the group's warehousing business took a different route, and both are fine.
BMAD is one part of a delivery toolchain
| Capability | Typical tool category | Why it matters |
|---|---|---|
| AI coding environment | Claude Code, Cursor, Codex, Windsurf or another supported tool | Runs the skills and works with the repository |
| Source control | GitHub, GitLab, Azure DevOps or equivalent | Preserves history, review and branch protection |
| Work tracking | Issues, boards, Jira or equivalent | Connects delivery to ownership and status |
| CI/CD | A pipeline platform | Repeats build, test, scan and deployment controls every time |
| Testing | Unit, integration, contract, end-to-end and performance tools | Supplies deterministic evidence |
| Security | Secret, dependency, static, dynamic and infrastructure scanning | Stops speed from bypassing controls |
| Observability | Logs, metrics, traces and product analytics | Shows whether behaviour holds after deployment |
| Knowledge | Repository context, decision records, runbooks and a service catalogue | Keeps important context durable |
BMAD officially supports dozens of AI coding tools, and its installer can list them. The choice of tool matters less than people think. What matters is whether the tool's permissions are constrained: which directories it may change, which commands it may run, whether it may reach the network, and whether it can touch production. Our articles on harness engineering and on guides, guards, checks and sensors cover that layer in detail.
At Mopane, the lower band of the diagram already existed before BMAD arrived. The finance-export breakage in Part 1 happened anyway, because no test covered the export and no rule told the assistant the field mattered. Adding BMAD did not fix that. Adding a contract test for the export, and a line in AGENTS.md, did. BMAD made it more likely that someone would think to write them.
Alternatives are different shapes, not one leaderboard
There is no single ranking of AI delivery methods. They put their weight in different places. Our overview of the spec-driven development flavours describes each one; here the question is narrower: when would you reach for each instead of, or alongside, BMAD?
GitHub Spec Kit
Spec Kit is GitHub's open-source toolkit for spec-driven development. As of 13 October 2026 it is actively maintained, MIT-licensed, and at version 1.1.3. Its flow is compact: set the project's principles once in a constitution, then for each feature write a specification, a plan and a task list, implement, and check the result converges with the specification. The commands follow that shape, from /speckit-constitution through /speckit-specify, /speckit-plan, /speckit-tasks and /speckit-implement to /speckit-converge.
Consider it when a team wants a specification-centred flow that fits naturally with GitHub and prefers a focused path over a broad set of perspectives.
Mopane's group has a warehousing business with its own three-person team. That team piloted Spec Kit on a small new service: a stock-count capture API for one warehouse. The scope was clear, the team was experienced, and nobody needed an analyst perspective to decide what to build. Spec Kit's shorter flow suited them, and they kept it. Mopane's team, with an older system and more unknowns, chose BMAD. Both teams were right.
Intent-driven architecture
Useful when an organisation wants architecture to express desired outcomes, constraints and policies, while implementation choices evolve underneath. This is a governing approach rather than one installable workflow: it decides what every team's specifications must respect. See our article on intent architecture.
Harness-driven development
Useful when the agent writes code but fails unpredictably. The fix is often not more planning but a better harness: constrained tools, permissions, fast tests, clear feedback, sandboxes and recovery. Harness work makes any method safer, BMAD included.
Lightweight repository conventions
A team may need only:
- a clear issue template;
- an
AGENTS.mdor equivalent instruction file; - architecture decision records;
- a pull-request checklist;
- strong tests and CI gates.
For routine maintenance this can be better than any full method. It is also what most teams should have in place before they adopt one.
Traditional product and agile practices
Story mapping, example mapping, event storming, architecture decision records, threat modelling and test-driven development all remain valuable. BMAD can prompt for them and store their results. It does not replace them, and a team that already does them well will get more out of BMAD than one that does not.
A selection matrix
| Situation | Recommended starting point |
|---|---|
| Tiny, well-understood change in a healthy repository | Lightweight repository rules, then build and review |
| Product idea that still needs discovery | BMAD's exploration and specification path |
| GitHub-centred team wanting a compact specification workflow | Evaluate Spec Kit |
| Legacy system with weak documentation | Context recovery before any implementation |
| Agent writes code but fails unpredictably | Improve the harness, tests and feedback loop |
| Architecture policy must guide many teams | Intent and policy-based architecture with platform controls |
| Regulated enterprise programme | A hybrid with formal authorities and evidence gates |
Two questions do most of the sorting: how sure are you about what to build, and how bad is it if you get it wrong?
Mopane uses all four quadrants in an ordinary month:
- Clear and recoverable. A label fix on the tracking page, a dependency bump, a report column. Repository rules and the pull-request checklist are enough. Running BMAD's planning path on these would be ceremony.
- Unclear and recoverable. The proof-of-delivery driver app from Part 4. The team needed help working out what to build, and a mistake on one pilot route could be undone. BMAD's planning skills earned their keep here.
- Clear and consequential. Anything that touches the finance export. The team knows what it wants; the risk is in what else depends on it. Here the order is context recovery, a contract test and only then the change.
- Unclear and consequential. Baobab's proposed portal rebuild from Part 5. This needed full discovery, named authorities and evidence gates, whatever tool produced the artefacts.
BMAD's own sizing reflects the same idea. Its planning guidance sizes work from trivial through a single session and epic-sized to project-sized, and trivial changes go straight to its Build skill. The method does not ask to be used at full depth everywhere. Teams that apply it that way are ignoring its own advice.
The hybrid we recommend
Use the smallest method that preserves the decisions that matter:
- Intent and evidence before implementation.
- Durable context kept in the repository.
- Architecture depth proportional to consequence.
- A build harness with constrained tools.
- Deterministic tests and security checks.
- Human approval at product, risk and release boundaries.
- Feedback from production into the next specification.
BMAD can supply much of the orchestration in steps 1 to 3 and help with 7. The existing engineering and governance systems supply the authority and proof in steps 4 to 6.
At Mopane, the hybrid looks like this in practice. Every repository has an AGENTS.md, a decision-record folder and a pull-request checklist. Every change goes through the same GitHub Actions pipeline, with tests and dependency and secret scanning. BMAD's planning skills are used when a change scores two or more on the sizing checklist we cover in Part 7. The tech lead, product owner and tester approve at the same points whether BMAD was used or not.
That last point matters most. If the controls only apply when a particular method is used, people will route around the method to avoid the controls. If the controls apply to every change, the method becomes a way to meet them faster, which is what it should be.
Keep the artefacts portable
One practical rule follows from all of this. Whatever method a team uses, the artefacts should outlive it. Specifications, decision records and project context should be plain markdown in the repository, readable by a person and usable by a different tool.
BMAD makes this easy, because its artefacts are files in the repository. It is still worth checking. Mopane's tech lead tested it by asking a different coding tool, with no BMAD installed, to implement a story from the resend pilot using only the files in the repository. It worked. If it had not, the team would have been building a dependency on a method rather than a body of knowledge about its own system.
The short version
BMAD supplies structure; the toolchain supplies proof. Source control, CI, tests, scanners and approvals were there first and still decide what ships.
Methods are shapes, not ranks. Spec Kit, harness work, intent architecture and plain repository rules each suit different changes.
Sort by uncertainty and consequence. The quadrant tells you how much method a change needs.
Apply the same controls to every change. Otherwise people route around the method to avoid the gates.
Keep artefacts portable. Context in plain repository files outlives any tool.
Previous: Part 5, the BMAD team is not a replacement for your team. Next: Part 7, is BMAD faster? All parts are on the series page.
How CloudNala can help
We help teams choose and combine AI delivery methods for the work they actually do: assessing the toolchain BMAD or Spec Kit will run inside, setting up repository conventions, harness controls and CI gates that apply to every change, and building a selection guide by change type so that planning depth follows consequence rather than habit.
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