Spec-Driven Development ist Domain-Driven Design für Ungeduldige

This blog post is also available in English

TL;DR

• Gleiche Wand, gleicher Grund: Wenn deine Organisation DDD nicht sauber hinbekommt, kann sie auch nicht von BMADs Spezifikationsschicht profitieren.
• Kein Wissen, keine Spec: Die Spezifikationsschicht hängt vollständig von der Qualität des Domänenwissens ab, das der Mensch ins Interview mitbringt. Der Agent kann kein Domänenwissen herbeizaubern.
• Wasserfall in neuem Gewand: Der dominante Ablauf bleibt: erst planen, dann implementieren. Ein Domänenmodell, das durch Implementierung und wiederholte Zusammenarbeit entsteht, bildet Dinge ab, die kein Vorab-Interviewprozess zuverlässig ans Licht bringt.
• Sweet Spot – Solo-Gründer:innen: BMAD passt dort, wo eine Person gleichzeitig Domänenexpert:in, Product Owner und Entwickler:in ist. Kein Proxy-Problem, keine Organisationsgrenzen. Das Wissen ist bereits im Raum.
• Erst die Organisation, dann die Tools: Bevor du fragst, ob Spec-Driven Development dein Requirements Engineering beschleunigen kann – frag dich, ob dein Team echten Zugang zu Domänenexpert:innen hat.

In meinem Beitrag Erst agil, dann agentisch habe ich argumentiert, dass Agentic Engineering auf organisationaler Ebene nur dann Vorteile bringt, wenn Organisationen bestimmte Fähigkeiten aus der Agile- und DevOps-Bewegung mitbringen. Denn wenn du die Entwicklungsarbeit nur beschleunigst, ohne deine Organisation entsprechend anzupassen, werden diese lokalen Vorteile nicht zu Verbesserungen auf Systemebene führen.

Spec-Driven Development Tools wie BMAD bekommen gerade viel Aufmerksamkeit – und das aus gutem Grund. Sie zielen darauf ab, ein reales Problem zu lösen, das ich in diesem Beitrag beschrieben habe: Requirements Engineering kann mit KI-unterstützten Entwicklungsteams nicht mithalten. Wenn Agenten eine sauber spezifizierte Story in Minuten implementieren können, wird der vorgelagerte Prozess zum Engpass. BMAD verspricht, das zu lösen, indem es über strukturierte KI-Interviews schnell gehaltvolle Spezifikationen erzeugt. Das Ergebnis: kein Warten mehr auf den Product Owner!

Sind BMAD und andere Spec-driven Development Tools also das fehlende Puzzlestück, damit Agentic Engineering richtig durchstartet? Vielleicht. Unter bestimmten Bedingungen. Das Problem ist die Annahme, die sich hinter den großen Versprechen versteckt.

Was BMAD tatsächlich macht

BMAD stellt mehrere Agenten bereit, die jeweils eine klar abgegrenzte Rolle in einem Software-Produktentwicklungsteam abdecken. Einer davon ist Mary, der Analysten-Agent. Mary führt strukturierte Discovery-Interviews, macht Wettbewerbsanalysen, bewertet Geschäftsmodelle und erstellt umfassende Product-Requirements-Dokumente. Für jemanden, der bisher per Vibe-Coding eigene ad-hoc Anforderungen «irgendwie» entstehen ließ, ist das ein deutlicher Schritt nach vorn.

Die Spezifikation ist nur so gut wie das Domänenwissen im Team

Aber hier ist der Punkt: Die Spezifikationsschicht hängt vollständig von der Qualität des Domänenwissens ab, das der Mensch ins Interview mitbringt. Der Agent stellt präzise Fragen und kann dabei ziemlich hartnäckig sein. Er lässt dich nicht mit vagen oder ausweichenden Antworten davonkommen, sondern bohrt nach, bis etwas Konkretes vorliegt, mit dem er arbeiten kann. Das ist wertvoll. Aber er kann kein Domänenwissen herbeizaubern.

Domain-Driven Design-Expert:innen kennen das

Domain-Driven Design-Expert:innen werden diese Einschränkung sofort wiedererkennen. DDD erfordert eine dauerhafte, echte Zusammenarbeit zwischen Entwickler:innen und Domänenexpert:innen, um eine gemeinsame ubiquitäre Sprache und ein reichhaltiges Domänenmodell aufzubauen. Wenn Organisationen mit DDD kämpfen (und meiner Erfahrung nach tun das die meisten), liegt das selten daran, dass Entwickler:innen nicht gut genug ausgebildet sind. Häufiger ist das Problem, dass Domänenexpert:innen für Entwickler:innen nicht direkt erreichbar sind. Oft sitzen sie hinter vorgeschalteten Proxy-Product-Ownern. Und egal wie gut diese Product Owner ihre Arbeit machen, es geht dabei fast immer etwas in der Übersetzung verloren. Leider leiden viele Organisationen unter Strukturen und einer Kultur, die die direkte Zusammenarbeit über Bereichsgrenzen hinweg aktiv ausbremsen. Genau diese Zusammenarbeit ist aber entscheidend für erfolgreiches Domain-Driven Design.

BMAD stößt aus exakt demselben Grund gegen dieselbe Wand. Wenn deine Organisation DDD nicht sauber hinbekommt, kann sie auch nicht von BMADs Spezifikationsschicht profitieren.

Vorab-Spezifikation vs. Continuous Discovery

Es gibt allerdings einen wichtigen Unterschied. DDD setzt voraus, dass Domänenexpert:innen während der Entwicklung kontinuierlich verfügbar sind. Du gehst zu ihnen zurück, wenn dein Domänenmodell bei der Implementierung konzeptionelle Reibung erzeugt – und das passiert wiederholt und nicht planbar. Das Modell entsteht durch Iteration, nicht durch eine Vorab-Spezifikation. Eric Evans sagt das ausdrücklich: Discovery ist kontinuierlich und keine Phase, die man abschließt, bevor man mit dem Coden beginnt.

Spezifikationsgetriebene Entwicklung basiert auf einer anderen Annahme: Discovery passiert upfront über strukturierte Interviews, und die daraus entstehende Spezifikation steuert die Umsetzung.

Ja, BMAD unterstützt iterative Verfeinerung innerhalb der Planungsphase. Aber der dominante Ablauf bleibt: erst planen, dann implementieren. Kritiker:innen von Spec-Driven Development sagen, hier schlage „Waterfall strikes back“ zu – mit Big Design Up Front in Form von KI-generierter Dokumentation. Da ist was dran. Ein Domänenmodell, das durch Implementierung und wiederholter Zusammenarbeit entsteht, bildet Dinge ab, die kein Vorab-Interviewprozess zuverlässig ans Licht bringt.

Wo Spec-Driven Development wirklich passt

Es gibt einen Kontext, in dem BMAD meiner Meinung nach gut passen kann: die technische Gründerperson, die ihre eigene Produktidee umsetzt. Sie ist gleichzeitig Domänenexpert:in, Product Owner, Architekt:in und oft auch Entwickler:in. Es gibt kein Proxy-Problem. Es gibt keine Organisationsgrenzen, die man überwinden muss. Der Analysten-Agent interviewt jemanden, der die Produktidee selbst entwickelt hat, die potenziellen Nutzer:innen idealerweise kennt und zumindest ein grundlegendes Verständnis des Wettbewerbsumfelds mitbringt.

Für diese Person können BMADs Wettbewerbsanalyse, Marktrecherche und Geschäftsmodellbewertung ziemlich wertvoll sein. Und das Spezifikationsinterview funktioniert, weil das Wissen bereits im Raum ist.

Die Produktivitätsversprechen, die man in manchen Blogposts liest – etwa dass sich die Planungszeit von Wochen auf Stunden reduziert – werden sich wahrscheinlich vor allem in genau diesem Kontext von Solo-Gründer:innen oder Solo-Entwickler:innen materialisieren.

Repariere die Organisation, nicht die Toolchain

Bevor du überlegst, ob spezifikationsgetriebene Entwicklung dein Requirements Engineering beschleunigen kann, stell dir eine andere Frage: Kann dein Team bei Bedarf echten Zugang zu Domänenexpert:innen bekommen? Sind diese Expert:innen bereit und verfügbar, sich tiefgehend mit Entwicklungsfragen zu beschäftigen? Unterstützen Struktur und Kultur deiner Organisation diese Art der Zusammenarbeit?

Wenn die Antwort ja lautet, können BMAD und andere Methoden aus dem Spec-Driven Development eine sinnvolle Option sein.

Wenn die Antwort nein lautet, hast du ein Organisationsproblem, das kein Interview-Agent lösen kann. Das Tool wird dieses Problem nur expliziter sichtbar machen als ein traditioneller Requirements-Prozess. BMADs hartnäckiges Nachfragen macht Wissenslücken früh sichtbar – und zwar unübersehbar. Aber es kann sie nicht schließen.

Die Voraussetzung ist dieselbe, die ich in meinem eingangs erwähnten Beitrag beschrieben habe: erst organisatorischer Wandel, dann Tools, die ihn verstärken.