BMad-Methode: Strukturiert entwickeln mit KI-Agenten

Wer mit Claude Code, Cursor oder einem anderen KI-Coding-Tool arbeitet, kennt das Problem: Es funktioniert erstaunlich gut, solange die Aufgabe klein ist. Aber ab einer gewissen Komplexität verliert die KI den Faden. Features werden halbfertig umgesetzt, Architekturentscheidungen widersprechen sich, und nach drei Stunden Iteration ist der Code schlechter als nach einer.

BMad (Breakthrough Method for Agile AI-Driven Development, oder Build More Architect Dreams) ist ein Open-Source-Framework, das genau hier ansetzt. Es gibt der KI-gestützten Entwicklung Struktur, indem es den Prozess in Phasen teilt und spezialisierte Agenten-Rollen definiert. Seit Ende 2025 ist das Projekt auf über 46.000 GitHub-Stars gewachsen, die aktuelle Version ist 6.6.0 (April 2026). Die Dokumentation ist umfangreich.

Die Grundidee

Vibe Coding, der Begriff, den Andrej Karpathy Anfang 2025 geprägt hat, beschreibt einen Workflow ohne Plan: prompten, ausprobieren, kopieren, hoffen. Für Prototypen reicht das. Für alles andere nicht.

BMad dreht die Reihenfolge um: Erst spezifizieren, dann bauen. Das klingt nach Wasserfall, ist es aber nicht. Der Unterschied liegt in den KI-Agenten, die jeden Schritt begleiten und sich gegenseitig kontrollieren.

Wie BMad funktioniert

BMad teilt die Entwicklung in vier Phasen. Jede Phase hat einen verantwortlichen Agenten und erzeugt ein konkretes Artefakt, das in die nächste Phase fließt:

Das ist der eigentliche Trick: Statt einer langen Chat-Session, in der die KI irgendwann den Anfang vergisst, arbeitet BMad mit persistenten Artefakten. Die Dokumente aus Phase 1 sind der Kontext für Phase 2, und so weiter. Kein Agent muss sich an das gesamte Gespräch erinnern.

Phase 1: Analyse

Der Product-Manager-Agent (Preston) erarbeitet mit dir ein PRD (Product Requirements Document). Das ist kein 30-Seiten-Dokument, sondern eine kompakte Spezifikation: Was soll gebaut werden, für wen, mit welchen Constraints, und woran misst man den Erfolg?

Der entscheidende Unterschied zu einem normalen Chat mit einer KI: Preston hinterfragt dich. Wenn du sagst "ich brauche eine Login-Seite", fragt Preston nach OAuth vs. Passwort, nach Session-Management, nach Sicherheitsanforderungen. Er nimmt nicht einfach hin, was du sagst, sondern arbeitet heraus, was du eigentlich brauchst.

Ein typisches PRD aus dieser Phase hat 1-3 Seiten mit klar definierten Zielen, Nicht-Zielen, Akzeptanzkriterien und technischen Constraints.

Phase 2: Planung

Der Scrum-Master-Agent (Simon) nimmt das PRD und zerlegt es in User Storys. Jede Story bekommt Akzeptanzkriterien, eine grobe Aufwandsschätzung und eine Priorität.

Simon priorisiert dabei nicht nur nach Business Value, sondern auch nach technischen Abhängigkeiten. Wenn Story B auf Story A aufbaut, landet A zuerst im Sprint, auch wenn B wichtiger klingt.

Das Ergebnis ist ein Sprint-Plan mit konkreten Storys, die klein genug sind, um in einer Session implementiert zu werden. Das ist wichtig, weil KI-Agenten bei langen Aufgaben an Qualität verlieren.

Phase 3: Architektur

Der Architect-Agent (Winston) liest PRD und Sprint-Plan und entwirft die technische Lösung. Stack-Entscheidungen, Datenmodelle, API-Design, Ordnerstruktur. Alles wird als Architecture Decision Records (ADRs) dokumentiert: Was wurde entschieden, warum, und welche Alternativen wurden verworfen.

Das passiert, bevor die erste Zeile Code geschrieben wird. Wer schon mal erlebt hat, wie eine KI nach der dritten Story plötzlich die Datenbankstruktur umwirft, weiß warum das sinnvoll ist. Winston legt eine Architektur fest, an die sich der Developer-Agent halten muss.

Phase 4: Implementierung

Jetzt erst wird Code geschrieben. Der Developer-Agent (Devon) nimmt die erste Story, liest die Architektur-Vorgaben und implementiert. Nach jeder Story prüft der QA-Agent (Quinn) den Code in einem Adversarial Review. Quinn sucht aktiv nach Fehlern, nach Abweichungen von der Architektur und nach fehlenden Edge Cases. Nicht "sieht gut aus", sondern "wo könnte das kaputtgehen?"

Wenn Quinn Probleme findet, geht die Story zurück an Devon. Erst wenn Quinn nichts mehr findet, gilt die Story als fertig.

Agenten sind Prompts, keine Programme

Wichtig zum Verständnis: Preston, Simon, Winston, Devon und Quinn sind keine separaten Tools oder Installationen. Es sind Markdown-Dateien mit System-Prompts, die Verantwortlichkeiten, Einschränkungen und erwartete Outputs definieren. Du aktivierst sie innerhalb deines KI-Tools als Persona oder Skill.

Neben den fünf Haupt-Agenten definiert BMad über ein Dutzend weitere Rollen für Spezialfälle: UX-Designer, DevOps-Engineer, Data-Analyst und andere. Die meisten Projekte kommen mit den fünf Kern-Agenten aus. BMad unterstützt Claude Code, Cursor und andere Tools, die Custom System Prompts oder Skills erlauben.

Installation

BMad ist ein npm-Paket:

npx bmad-method install

Der Installer fragt nach dem Zielverzeichnis und dem Tool (Claude Code, Cursor, etc.) und legt die nötigen Konfigurationsdateien an. Danach kannst du im Tool bmad-help aufrufen, um durch den Workflow geführt zu werden.

Für bestehende Projekte gibt es einen nicht-interaktiven Modus:

npx bmad-method install --directory ./mein-projekt --modules bmm --tools claude-code --yes

Quick-Dev vs. Full Workflow

Das ist der Punkt, an dem viele an BMad scheitern oder es vorschnell als zu komplex abtun. BMad hat zwei Modi:

Full Workflow: Der komplette Durchlauf mit sämtlichen Agenten und Artefakten. Sinnvoll für größere Projekte mit mehreren Features, wo Architekturentscheidungen langfristig tragen müssen. In einem direkten Vergleich hat der Full Workflow etwa 6 Tage für ein Feature gebraucht (2 Tage Planung, 4 Tage Implementierung), bei API-Kosten von über 200 Dollar.

Quick-Dev: Ein vereinfachter Zwei-Schritt-Prozess mit reduzierter Planung. Die gleiche Elicitation-Qualität, aber weniger tiefe Architektur-Artefakte. Dauer im gleichen Vergleich: rund 2 Tage, deutlich günstiger. Für die meisten Features in bestehenden Projekten reicht das. Für einen MVP aber trotzdem schnell zu viel Tiefe.

Wann sich BMad lohnt

BMad ist nicht für jeden Anwendungsfall gedacht. Die ehrliche Einordnung:

Gut geeignet:

• Projekte mit mehreren Features, die aufeinander aufbauen
• Teams, die mit KI-generierten Code-Basen arbeiten und Konsistenz brauchen
• Situationen, in denen vorschnelle Implementierung ein bekanntes Risiko ist
• Compliance-sensitive Bereiche (Fintech, Healthtech), wo Architekturentscheidungen dokumentiert sein müssen

Weniger geeignet:

• Einzelne Bug-Fixes oder kleine Features
• Schnelle Prototypen, bei denen Geschwindigkeit wichtiger ist als Langlebigkeit
• Solo-Projekte mit überschaubarem Scope
• Exploratives Arbeiten, bei dem die Anforderungen noch unklar sind

Die häufigste Kritik: BMad kann für kleine Projekte das 10- bis 15-Fache der Zeit kosten, die eine direkte Implementierung brauchen würde. Das ist kein Bug, sondern ein Feature-Mismatch. Man nimmt BMad nicht für einen Hotfix.

Was es kostet

BMad selbst ist kostenlos und MIT-lizenziert. Aber die API-Kosten für die KI-Aufrufe sind real. Ein Praktiker berichtet von durchschnittlich 31.000 Tokens pro Workflow-Durchlauf und monatlichen Kosten um 850 Dollar bei intensiver Nutzung über APIs. Ein großes Projekt verbrauchte 230 Millionen Tokens pro Woche. Nutzt man es über die "Desktop-Subscription", fallen diese Kosten natürlich nicht an, aber es verbraucht vom Wochenquota und limitiert damit andere KI-Tätigkeiten.

Das klingt nach viel, relativiert sich aber, wenn man es mit Entwicklergehältern vergleicht. Und der Quick-Dev-Modus ist deutlich günstiger. Die Frage ist nicht "kostet BMad Geld", sondern "spart BMad mehr als es kostet". Bei einem gut passenden Projekt: ja. Bei einem kleinen Side-Project: nein.

Alternativen

BMad ist nicht das einzige Spec-Driven-Framework.

GSD (Get Stuff Done) ist der Gegenentwurf: Minimal, schnell, wenig Overhead. Optimiert für Claude Code, flache Lernkurve, produktiv in einer Stunde. Mit 61.000 Stars sogar populärer als BMad. Risiko: Ohne Disziplin geht Wissen zwischen Sessions verloren.

OpenSpec hat in einem direkten Vergleich den höchsten Score erreicht (4.0 vs. BMads 3.65-3.74). Beste Developer Experience, paralleles Arbeiten ab Start, aber nur ein einzelner Maintainer.

Ralph fokussiert auf die Implementierungsphase mit einem autonomen Iterate-Until-Done-Ansatz und lässt sich mit BMads Planungsphasen kombinieren.

Superpowers verfolgt einen anderen Ansatz als BMad: Statt benannter Agenten-Personas setzt es auf ein modulares Skills-System mit automatischer Prozess-Durchsetzung. TDD-Zyklen, systematisches Debugging und Design-Validierung sind keine Vorschläge, sondern werden erzwungen. Mit 186.000 GitHub-Stars das mit Abstand populärste Framework in dieser Kategorie, und als offizielles Claude-Code-Plugin direkt über den Marketplace installierbar.

Die Kombination aus BMad-Planung (Phasen 1-3) mit einem leichtgewichtigen Implementierungsloop ist ein Muster, das mehrere Teams unabhängig voneinander entdeckt haben.

Zwei Monate bis es sitzt

Hier muss man ehrlich sein: BMad braucht Zeit. Erfahrungsberichte sprechen von etwa zwei Monaten bis zur souveränen Nutzung. Das liegt nicht daran, dass BMad schlecht dokumentiert wäre, sondern daran, dass es ein echtes Umdenken erfordert.

Wer gewohnt ist, mit einer KI im Ping-Pong-Modus zu arbeiten (Prompt, Ergebnis, nächster Prompt), muss lernen, erst zu spezifizieren und dann zu bauen. Das fühlt sich anfangs langsamer an. Und bei kleinen Aufgaben ist es auch langsamer. Der Gewinn kommt bei mittleren bis großen Projekten, wo die Spezifikationsarbeit verhindert, dass man nach drei Tagen alles umbauen muss. Es bedeutet aber auch, dass Risiken, die in Wasserfall-Projekten auftreten, hier ebenfalls am Horizont sind. Es ist wie immer eine Abwägung zwischen Upfront Design und kurzer Planungsphase mit Planungs-Iterationen im Projekt.

Was das für Teams heißt

BMad löst ein echtes Problem: KI-gestützte Entwicklung ohne Struktur skaliert nicht. Irgendwann produziert Vibe Coding mehr Probleme, als es löst.

Aber BMad ist nicht die einzige Lösung, und es ist nicht für jeden die richtige. Wer ein kleines Team hat und hauptsächlich einzelne Features baut, fährt mit GSD oder einer eigenen leichtgewichtigen Spec-Struktur besser. Wer ein größeres Projekt mit mehreren Entwicklern und KI-Agenten koordinieren muss, sollte sich BMad ernsthaft anschauen.

Der pragmatische Einstieg: BMad installieren, den Quick-Dev-Modus für ein überschaubares Feature nutzen, und nach dem ersten Durchlauf entscheiden, ob die Struktur zum Projekt passt. Nicht mit dem Full Workflow anfangen.