BMAD in Practice
AI coding tools produce code quickly. That is not the same as producing the right system. This eight-part series explains the BMAD Method as a context and decision system for AI-assisted delivery rather than a magic developer: the loop from intent to verified change, a first pilot that does not drown in process, greenfield and brownfield paths, why agent perspectives do not replace your team, how it compares with Spec Kit and lighter conventions, whether it is actually faster, and how South African enterprises can adopt it with governance and trust. One fictional Durban logistics company and its seven-person software team carry the examples.
8 articles
- Part 1What BMAD actually isAI coding tools produce code quickly. That is not the same as producing the right system. Part 1 explains what the BMAD Method is and is not, the four things it coordinates, the hidden-context problem it is trying to solve, where it helps and what it leaves for people to own.9 min read
- Part 2From idea to working changeSmall and large changes do not need different delivery philosophies. They enter the same loop at different points and with different depth. Part 2 walks through BMAD's planning sizes and six practical stages, from framing intent to review and learning, using one WhatsApp delivery-update change from start to finish.9 min read
- Part 3Getting started without drowning in processDo not start with a company-wide BMAD transformation. Start with one repository, a small group and a change that is valuable but recoverable. Part 3 covers choosing a version, the five things to settle before installing, a safe first run, a one-page pilot charter, a starter change brief and the questions for the first retrospective.9 min read
- Part 4Greenfield and brownfield are different gamesA greenfield product starts with few technical constraints and many product unknowns. A brownfield system starts with code, data, integrations and history, much of it undocumented. Part 4 covers how a structured method should treat each, recovering project context from an existing codebase, the facade instead of the rewrite, and the questions that must never be answered by guessing.9 min read
- Part 5The BMAD team is not a replacement for your teamBMAD's named agents bring an analyst's, an architect's and a product manager's questions into the work. They do not bring authority, accountability or the knowledge nobody gave them. Part 5 covers how to map perspectives to people, the small-team, enterprise and consultancy patterns, and why marking facts and assumptions matters more than polished output.10 min read
- Part 6Supporting tools, alternatives and hybridsBMAD supplies structure, but authority and proof come from the toolchain around it. Part 6 covers what BMAD needs from source control, CI, tests and security tooling, how it compares with GitHub Spec Kit, harness-driven development and plain repository conventions, a selection matrix by change type, and the hybrid we recommend.9 min read
- Part 7Is BMAD faster?BMAD can make typing slower and delivery faster, or it can just make everything slower. Part 7 covers where structured AI delivery saves time and where it wastes it, what to measure in a pilot, an illustrative ten-week comparison, a change-sizing checklist, three change classes, and the claim a responsible team can actually make.9 min read
- Part 8Adopting BMAD in South African enterprisesStructured AI delivery can help scarce South African teams carry more context, or it can flood them with plausible, unverified material. The final part covers a four-stage adoption path, the questions leadership should answer first, what to demand from suppliers selling 'autonomous delivery', and where BMAD's value really lies.9 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala