Today I spent an afternoon learning about BMAD, a structured method for AI-assisted software development. What struck me most wasn't the speed. It was the consistency. I came away excited, a little worried, and with a clearer picture of where AI development is heading and why the people who write the brief matter more than ever.
The problem with one-shot AI coding
We've all done it. You ask an AI tool to build a feature, it hands you a block of code, and then you spend the next hour working out what it got wrong. It looks right, but it's built on guesswork. It doesn't know your constraints, your conventions or why the feature exists in the first place. There's a blunt name for what comes out the other end: AI slop.
What I liked about BMAD is that it flips this round. Rather than asking the AI to get it right in one go, it builds up the context first, in stages, before anyone writes a line of code.
Why context matters so much
This one hits home for me. The more I use AI in my own work, gathering information, pulling it all together and turning scattered notes into user stories in a consistent format, the more I realise how frustrating it is when it doesn't have the context. I've had to work really hard to tune the AI skills and prompts I use to the different ways we work, whether a story is going to an external partner or an internal team. Each audience needs something slightly different, and the AI only knows that if you tell it.
Design is where it shows most. Unless the AI has your design system, it struggles. Even if you point it at a website for reference, it needs lots and lots of information to nail a design that looks and feels like what you're after. That's harder still when a company has no design system or style guide at all. Then all anyone has to go on is a feeling: how the website currently looks and works, and what fits. That feeling lives in a designer's head, not in the AI's.
So when I saw a method built entirely around giving AI the context it needs, it made complete sense to me.
What BMAD is
BMAD is free and open source. These days it's usually called the Breakthrough Method for Agile AI-Driven Development, although it started life as "Build More Architect Dreams", which I quite like. You get a set of specialist AI agents (a product manager, an architect, a developer and a QA tester) and guided workflows that pass the work between them, a bit like a real agile team.
The bit that really clicked for me was where the context lives. It isn't sitting in a ticketing tool or in someone's head. It's written into markdown files on the code branch itself, with a folder for each ticket. So every agent that picks up the work, and every developer, is reading from the same page about what's being built, how and why.
How the workflow runs
- Product. A ticket comes in and the product workflow interrogates it, creating a branch and generating constraints, capabilities, and functional and non-functional requirements. There's a feature called "party mode", where you talk to several agents at once and they also talk to each other, challenging and building on the brief together.
- Architecture. A developer works through a technical review with the architect agent, still with no code. Restrictions, security and testing get discussed the way you would with a colleague at a whiteboard.
- Development. Code is generated against that context. A person still tests it manually against the acceptance criteria.
- Review. AI agents review the pull request in several passes. One, the "Blind Hunter", reviews the code with no knowledge of what it's meant to do, so it judges the code purely on its own merits. Others check style and conventions. Anything that fails goes back to development, and the loop repeats until it passes. The pull request is then raised automatically with a description and summary, ready for a human reviewer.
- QA. A QA agent writes or updates automated end-to-end tests (often with a framework like Playwright), fixes any that break, and flags where manual regression is still needed.
- Release. The change goes to a test environment for sign-off and becomes a release candidate.
Code only reaches a person once the AI review passes. Anything that fails goes straight back to development.
What it needs around it
BMAD doesn't work on its own. To get the most from it, a team needs three things in place together: a Git branching strategy that gives each piece of work its own branch, the BMAD workflow itself, and an automated end-to-end test suite. I like how they depend on each other. The branch holds the context, the workflow uses it, and the tests check the result.
I also like that it doesn't have to be all or nothing. A team can let people write code their own way, but still run everything going into the shared codebase through the same AI review and QA agents. The gates set the standard, not the method.
The benefits
- Consistency across a team. This is the one that sold it to me. Ask an AI tool to build something and you get one answer. Another developer asks the same question, or the same question worded differently, and gets something else entirely. BMAD replaces those one-off conversations with a shared process and shared context, so the whole team builds the same way.
- A virtual team, fast. I love the idea of agents discussing a ticket with each other, challenging and building on it the way developers would around a table. It's like growing your team in minutes.
- Less rework. Most bad AI output comes from missing context. Front-loading it means fewer surprises at review.
- Ideas that were once too expensive to build. If development gets smoother and cheaper, providing token costs stay sensible, we can ship more features, test more ideas and build things that would never have made the cut because of the cost.
- Prototype before you commit. Product managers can try out ideas and prototype them with AI tools before deciding whether they're worth pushing into the development process. I've been doing more of this myself, as I wrote about in How I Redesigned a Client Website with AI.
- Documentation for free. Requirements, architecture decisions and test plans are by-products of the process, stored alongside the code they describe.
- Better code review. The Blind Hunter idea stuck with me. Reviewing without knowing the intent removes the bias of seeing what you expect to see.
- Regression testing that keeps up. One of the biggest time savings is likely to be in regression testing, often the slowest and most painful part of a release. Generate automated tests with every change, split test runs across machines, and a full regression stops being a bottleneck.
- People where they add most value. Humans still make the calls that matter: shaping the brief, approving the architecture, testing against acceptance criteria and signing off the release.
You also don't need to adopt the whole method to benefit from its ideas. Keeping context on the branch, blind code review and automated regression testing all stand on their own.
What it means for product managers
For me, the biggest shift is upstream, before any code is written.
Context is everything. BMAD pins everything on the acceptance criteria: the what and the why. That puts far more pressure on product managers to get the spec right and make sure whatever we build is genuinely for the customer. It also means a lot of context, because the files and folders that build up over a ticket will be large.
Here's the twist. Developers do read the spec, but the longer it gets, the less thoroughly it tends to be read, and it's easy to fill the gaps with your own assumptions rather than following it to the letter. Now they have a tool that reads every word for them, and their job is to guide it.
It also raises big questions for developers, from what happens to the craft to how juniors learn. That deserves its own post, and I'll come back to it soon.
What I'm doing next
Demos only go so far, and I want to see this in action for myself. The next step is hands-on: taking a small, real piece of work, roughly half a day's effort, and running it through the full process from first ticket to release candidate. I'm genuinely excited to see how it goes, and I'll share what I learn. If you want to try it yourself, the official Build Your First Change guide is a good place to start.
BMAD resources
- BMAD Method docs: tutorials, guides and reference
- BMAD-METHOD on GitHub: the source, install instructions and release notes
- Build Your First Change: the getting started tutorial
- Choose a Planning Path: how much planning a change really needs
- Start in an Existing Codebase: adding BMAD to a project you already have
- BMad Code on YouTube: tutorials and walkthroughs from the creator
- GitHub Discussions: the community
- Playwright: the end-to-end testing framework mentioned above