Spec-Driven Development is Domain-Driven Design’s Impatient Cousin

Same wall, same reason: If your organization can’t do DDD properly, it can’t benefit from BMAD’s specification layer either.
No knowledge, no spec: The specification layer depends entirely on the quality of domain knowledge the human brings to the interview. The agent can’t conjure up domain expertise that isn’t in the room.
Waterfall with a fresh coat of paint: The dominant flow remains: plan first, then implement. A domain model that emerges through implementation and repeated collaboration will capture things no upfront interview process can reliably surface.
Sweet spot – solo founders: BMAD shines when one person is simultaneously the domain expert, the product owner, and the developer. No proxy problem, no organizational boundaries. The knowledge is already in the room.
Fix the organization, not the toolchain: Before asking whether spec-driven development can accelerate your requirements engineering, ask yourself whether your team has genuine access to domain experts.

In my post First Agile, Then Agentic, I argued that organisations need certain capabilities shaped by the agile and DevOps movements before agentic engineering practices can lead to benefits at the organisational level. If you just speed up development work without adapting your organisation accordingly, those local benefits will not translate to system-level improvements.

Spec-driven development tools like BMAD are receiving a lot of attention right now, and for good reason. They aim to solve a real problem I identified in that post: requirements engineering cannot keep up with AI-assisted development teams. If agents can implement a well-specified story in minutes, your upstream process becomes the bottleneck. BMAD promises to solve this by using structured AI interviews to quickly generate rich specifications. No more waiting for the product owner!

Are BMAD and other spec-driven development tools the missing piece to make your agentic engineering take off? Maybe, under specific conditions. The problem is the assumption hiding underneath the bold claims.

What BMAD actually does

BMAD provides multiple agents, each one covering a distinct role in a software product development team. One of them is Mary, the analyst agent. Mary conducts structured discovery interviews, performs competitor analysis, evaluates business models, and generates comprehensive product requirements documents. For someone who has been vibe-coding their own ad-hoc requirements into existence, this is a significant step forward.

The specification is only as good as the domain knowledge in the room

But here is the thing: the specification layer depends completely on the quality of domain knowledge the human brings to the interview. The agent asks rigorous questions and can be quite persistent. It won’t let you off the hook with vague or evasive answers, probing until it has something concrete to work with. That is valuable. But it cannot supply domain knowledge that isn’t in the room.

DDD practioners have seen this before

Domain-Driven Design practitioners will recognise this constraint immediately. DDD requires sustained, genuine collaboration between developers and domain experts to build a shared ubiquitous language and a rich domain model. When organisations struggle with DDD (and in my experience, most of them do) it’s rarely because developers are not properly trained. More often, it’s because domain experts aren’t directly accessible to developers. Very often, they are buffered behind proxy product owners, and no matter how good a job those product owners do, there is almost certainly a loss in translation. Sadly, many organisations suffer from a structure and culture that actively discourages the direct cross-boundary collaboration that successful domain-driven design requires.

BMAD hits exactly the same wall for exactly the same reason. If your organisation can’t do DDD properly, it can’t benefit from BMAD’s specification layer either.

Upfront specification vs. continuous discovery

However, there is an important difference. DDD requires domain experts to be continuously available throughout development. You go back to them when your domain model hits conceptual friction during implementation, which happens repeatedly and unpredictably. The model emerges through iteration, not upfront specification. Eric Evans is explicit about this: discovery is continuous, not a phase you complete before coding begins.

Spec-driven development operates on a different assumption: Discovery happens upfront through structured interviews, and the resulting specification drives implementation.

Yes, BMAD does support iterative refinement within the planning phase. But the dominant flow is still to plan and then implement. Critics of spec-driven development say that “waterfall strikes back”, leading to big design up front with AI-generated documentation. They have a point. A domain model that emerges through implementation and repeated collaboration will capture things no upfront interview process reliably surfaces.

Where spec-driven development actually fits

There is one context where I think BMAD can be a good fit: The technical founder building their own product idea. They are simultaneously the domain expert, the product owner, the architect, and often the developer. There is no proxy problem. There are no organisational boundaries to cross. The analyst agent interviews someone who conceived the product idea, hopefully knows the potential users and has at least some understanding of the competitive landscape.

For that person, BMAD’s competitor analysis, market research, and business model evaluation can be quite valuable. And the specification interview works because the knowledge is already in the room.

The productivity claims you read about in some blog posts, like planning time reduced from weeks to hours, are likely to primarily materialise in this specific context of solo entrepreneurs or solo developers.

Fix the organisation, not the toolchain

Before asking whether spec-driven development can accelerate your requirements engineering, ask yourself a different question: can your team get genuine access to domain experts when it needs them? Are those experts willing and available to engage deeply with development questions? Does your organisation’s structure and culture support that kind of collaboration?

If the answer is yes, BMAD and other spec-driven development methods can be a viable option.

If the answer is no, you have an organisational problem that no interviewing agent can fix. The tool will surface that problem more explicitly than a traditional requirements process. BMAD’s persistent questioning makes knowledge gaps visible early and right in your face. But it cannot resolve them.

The prerequisite is the same one I explained in my previous post: organisational change first, then the tools that amplify it.