Two structured approaches to AI-assisted development have been picking up traction in engineering teams. BMAD organises the work around personas — analyst, architect, developer — each handing off to the next. SpecOps starts with a written spec and hands that to the AI to implement. Both are trying to solve the same problem: getting consistent, production-quality output from AI coding tools. They go about it very differently.
What BMAD is
BMAD — Breakthrough Method of Agile AI-Driven Development — is an open-source framework built around roles. You start with a Business Analyst persona that defines what needs to be built, move to a Product Manager that shapes user stories, then an Architect that designs the system, then a Developer that writes the code. Each role has a clear scope and a clear handoff.
The idea is to make decisions explicit. Without structure, AI coding tools tend to fill in gaps silently — making assumptions the developer doesn't catch until something breaks. BMAD forces those decisions to the surface at each stage, where a human can review them before work continues.
Teams like it because it feels familiar. The roles map onto how engineering organisations already work, so there's no new mental model to learn — just a more structured way to apply the one you already have.
What SpecOps is
SpecOps starts before the AI does anything. You write a complete spec first: data models, API contracts, edge cases, acceptance criteria. Then you hand that spec to the AI and ask it to implement against it.
The core argument, spelled out in their methodology doc, is that most AI coding failures are prompt failures. Vague instructions produce plausible but wrong output. A tight spec closes that gap — the AI either satisfies the contract or it doesn't, and you can see which.
The side benefit is that the spec has value beyond the AI task. A well-written spec helps with testing, onboarding, and code review. Writing it also tends to expose design problems before any code exists.
The key difference
BMAD structures the process. SpecOps structures the output.
BMAD works well when requirements are still emerging. The persona workflow helps you figure out what you're building as you go, while keeping decisions documented and reviewable.
SpecOps works well when requirements are already clear. If you can write a precise spec without guessing, the upfront investment pays off — you get clean, testable implementation with no surprises.
The failure mode of BMAD: the persona handoffs become busywork. Teams go through the motions without the decisions getting any clearer. The structure is there but the ambiguity isn't resolved.
The failure mode of SpecOps: over-specifying things you don't actually know yet. Writing a complete spec for exploratory work forces premature choices and gives you false confidence. You end up implementing the wrong thing precisely.
What tends to work in practice
Most teams end up mixing both. A common pattern: use BMAD's personas lightly to get to a draft spec, then apply SpecOps discipline to tighten it before implementation starts. You get the flexibility of BMAD for the uncertain parts and the rigour of SpecOps for the parts that are well understood.
The core insight from BMAD — make AI decisions explicit and reviewable — is worth keeping regardless of which framework you use. So is the core insight from SpecOps — treat the spec as a real artifact, not just a prompt.
Neither replaces engineering judgement. They're tools for applying that judgement more consistently when AI is doing a significant share of the work.
Which one to use
If you're building something fast and the requirements are still shifting, BMAD fits better. If you're building something well-defined — an integration, a migration, a new API with a clear contract — SpecOps pays off.
The mistake is picking based on what sounds more rigorous rather than what the work actually needs.
---
If you're working out how to bring AI into your development process without losing quality or control, book a call — it's a short conversation and usually there's a clear path forward.