South African delivery teams often work across a demanding mix:
- modern cloud services alongside long-lived on-premises systems;
- scarce specialist capacity, particularly in architecture, security and testing;
- internal teams, global vendors and local partners working on the same estate;
- regulatory, privacy and audit obligations, POPIA among them;
- public and private procurement gates;
- mobile-first users and uneven connectivity;
- cost sensitivity driven by the rand and by consumption-based services priced in dollars;
- high expectations of service reliability.
Structured AI-assisted delivery can help here. A small team can carry more context and ask specialist questions earlier, even when the specialist is part-time or shared across a group. It can also do real harm: it produces large volumes of plausible material quickly, and a team without the capacity to check that material can end up trusting it by default.
Adoption therefore needs ambition and control in equal measure. This final part of the series describes how to get both.
Mopane Logistics is fictional, and its systems and figures are illustrative. Mopane's seven-person team has, over the course of this series, recovered context in an old dispatch system, run a bounded first pilot, mapped its people to BMAD's perspectives and measured a ten-week comparison against the previous quarter. Mopane belongs to a larger logistics group with a warehousing business and a group IT function. The group's CIO now wants to know whether what worked for one team should become the way the group delivers software.
A four-stage adoption path
Stage 1: Observe
Use BMAD on a non-critical internal change. Do not grant autonomous production access. Compare its artefacts and outcomes with the current process.
Outputs:
- one pilot baseline;
- approved data and tool boundaries;
- an initial project-context template;
- recorded failure and intervention patterns.
Mopane has done this. Its pilot charter from Part 3, its sizing checklist and its ten-week figures from Part 7 are the evidence the group is now working from. Just as useful are the recorded failures: the assistant's invented assumption that invoices could be resent to any email address, and the first month's overlong specifications.
Stage 2: Standardise
Select the useful workflows and remove unnecessary ceremony. Encode local engineering, security and architecture rules. Add CI evidence.
Outputs:
- a version-pinned method;
- approved repository rules;
- a human authority matrix;
- a reusable definition of done;
- a cost and quality dashboard.
The group is here now. Version pinning is not a formality. As of 13 October 2026, BMAD's stable line is v6.12, and the project's next major version is a preview alpha with a different installation model. The project's public documentation already describes that preview, and the stable line's documentation lives on its own branch of the repository. A group with several teams needs one deliberate choice, a named owner for upgrades, and a rule that teams read the documentation matching the version they installed.
The authority matrix is Mopane's perspective-to-person mapping from Part 5, extended to the warehousing team and to group IT. The definition of done applies to internal teams and suppliers alike, whatever method produced the work.
Stage 3: Integrate
Connect specifications, issue tracking, source control, CI/CD, observability and change governance. Keep access least-privileged.
Outputs:
- traceable work items;
- policy-aligned pipelines;
- service ownership records;
- auditable approval evidence;
- a production feedback loop.
This is where most of the long-term value sits, and where most of the effort goes. The group's change-advisory process currently asks for a document that duplicates what is already in the specification and the pull request. Integrating means letting the evidence the delivery system already produces satisfy the governance process, rather than asking people to write it twice. Our article on governing spec-driven development at scale argues the same point: govern decisions and evidence, not document volume.
Stage 4: Scale by change class
Expand only where the evidence supports it. Provide paved paths for small, medium and high-consequence work. Do not force one workflow onto every team.
The warehousing team's choice of GitHub Spec Kit, described in Part 6, is a good test of whether the group has understood this. A group standard that required BMAD everywhere would force a working team to change method for no gain. The group's draft standard instead specifies outcomes, such as durable context in the repository, a sizing step, the same CI gates and the same approval points, and lets teams choose the method that meets them.
Questions for leadership
Before the group's CIO signs off a wider rollout, these ten questions need answers:
- Which business outcomes justify adopting this method?
- What information may the AI tool access?
- Which decisions must remain with named people or forums?
- How will a reviewer tell fact, assumption and generated proposal apart?
- Which evidence must exist before merge, release and production expansion?
- How will model, licence and token costs be measured in rand?
- What happens when the tool or framework changes version?
- Can artefacts and context move to another tool?
- Who maintains the method after the champion leaves?
- Which measure would make us stop or redesign the rollout?
Question 9 caught the group out. Mopane's tech lead is the champion, and most of what makes the method work at Mopane lives in that person's habits. The group is now writing those habits down as a short internal guide and pairing a second engineer with the tech lead for the next quarter. Question 10 turned out to be the easiest to answer: if rework and escaped defects stop improving for two consecutive quarters, the group will pause and look again.
On question 2, POPIA does not stop a team from using AI coding tools, but it does mean knowing what personal information can reach them and where it is processed. Dispatch's test databases contained real consignee names and phone numbers, which the team masked before giving any assistant access. Our AI and POPIA series covers how to reason about this without assuming the data must stay in the country.
A procurement warning
A month after Mopane's pilot results circulated, a vendor approached the group with an offer of "autonomous delivery": a managed service in which the vendor's agents would take tickets from the backlog and return merged code, priced per story point.
Do not buy autonomous delivery as a black box. Ask the supplier to explain:
- the method and version used;
- what data leaves your environment;
- how prompts and context are protected;
- which actions the agents are permitted to take;
- how code provenance is recorded;
- how licences and dependencies are checked;
- which tests and scans are deterministic;
- how humans approve material decisions;
- how the artefacts remain usable if you change supplier.
The vendor answered some of these well. It could not say which of its agents' actions were reviewed by a person before merge, and its artefacts lived in its own platform rather than in the group's repositories. Both were deal-breakers. The first meant the group could not tell who had approved a change. The second meant that leaving the supplier would mean losing the context that made the work maintainable.
None of this means the group should never buy AI-assisted delivery. It means buying it on the same terms as any other delivery: named accountability, inspectable evidence and an exit. Our article on procurement in the agent era looks at the wider buy, build or grow decision.
Where the value really lies
BMAD is not valuable because it gives software delivery more impressive AI characters. It is valuable when it makes intent, context, decisions and evidence harder to lose.
That is what changed at Mopane. The finance export that broke in Part 1 is now protected by a contract test, a line in the repository's agent instructions and a sizing rule that sends any change near it through discovery. None of those is BMAD itself. All of them happened because the method kept asking questions the team had previously left to memory.
The teams most likely to benefit will not be the ones that automate the most conversation. They will be the ones that know which questions deserve depth, which decisions need human authority, and which evidence must survive long after the chat window closes.
The short version
Adopt in stages. Observe, standardise, integrate, then scale by change class, with evidence at every step.
Pin the version and name an owner. The stable line and the preview differ, and teams must read the documentation that matches what they installed.
Standardise outcomes, not tools. Require durable context, sizing and the same gates; let teams choose the method that meets them.
Answer the leadership questions first. Especially who maintains the method when its champion moves on.
Never buy a black box. Demand named approvals, inspectable evidence and artefacts you keep.
This completes the series. It began in Part 1 with a renamed field and a broken export, and the argument has not changed since: BMAD is a context and decision system for AI-assisted delivery, and its worth is measured by the decisions it makes explicit and the rework it prevents, not by the volume of what it generates. For the wider practice it belongs to, see our spec-driven development adoption playbook. Every part of this series is on the series page.
How CloudNala can help
We help organisations adopt structured AI delivery deliberately: running a first pilot with a fair baseline, standardising on a pinned version with an authority matrix and one definition of done, integrating delivery evidence with existing change governance, and assessing suppliers who offer AI-assisted or autonomous delivery. The starting point is not a tool rollout. It is a bounded change, an explicit authority model and a measurable definition of success.
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