Die BMad-Methode für Java-Entwickler

Brian Madison war zu Gast, um die BMad-Methode vorzustellen: ein Name, der als Spitzname begann und zu einem Open-Source-KI-Workflow-Ökosystem mit über 51.000 GitHub-Sternen geworden ist. Wir haben einen persönlichen Finanz-Tracker mit Quarkus gebaut, aber die eigentliche Geschichte war die Methode dahinter.

Die BMad-Methode ist von außen leicht misszuverstehen. Sie verhält sich eher wie eine gut organisierte Werkstatt als wie eine Prompt-Sammlung oder ein Coding-Framework. /bmad help ist das Werkzeugbrett an der Wand. Die Skills sind beschriftete Schubladen, die man nur öffnet, wenn man sie braucht. Dieselbe Werkbank dient für Brainstorming, Planung, Architektur oder Code.

Co-Speaker

Brian Madison

Erfinder der BMad-Methode

Brian Madison hat die BMad-Methode entwickelt, ein Open-Source-KI-Workflow-Framework mit über 51.000 GitHub-Sternen. Mit über 25 Jahren Erfahrung von NASA-Simulationen und Militärsystemen bei Northrop Grumman bis zur Leitung der KI-Transformation bei Extend bringt er eine systemische Perspektive auf strukturierte KI-Zusammenarbeit mit.

GitHubYouTube

Hilfe als Herzstück

Der Einstieg ist das Hilfesystem. Kein Auswendiglernen von Skill-Namen, Modulpfaden oder einem festen ersten Schritt. Man tippt /bmad help, beschreibt das Ziel, und das System schaut sich installierte Module, vorhandene Artefakte und den aktuellen Kontext an, um den nächsten Schritt vorzuschlagen.

Bei 34 Workflows in mehreren Modulen liegt das Problem nicht in der Qualität der einzelnen Skills. Das Problem ist: Welchen nimmt man, und wann? Das Hilfesystem löst genau das: ein universeller Startpunkt, ein Werkzeugbrett, das nur zeigt, was die aktuelle Aufgabe braucht.

In der Demo habe ich einen persönlichen Finanz-Tracker beschrieben: ein selbst gehostetes Hobbyprojekt für meine Familie, mit Quarkus und Qute Templates. Das Hilfesystem las den Kontext, stellte fest, dass noch keine Artefakte existierten, und schlug ein paar Startpunkte vor: Product Brief, PRD, PRFAQ oder direkt ein Prototyp. Jeder Pfad ist gültig.

Weniger Kontext, bessere Ergebnisse

Brian hat viel Zeit auf Progressive Disclosure verwendet: Skill-Beschreibungen minimal halten, die vollständigen Anweisungen erst laden, wenn die KI sie wirklich braucht.

Er zeigte ein Beispiel aus seiner eigenen Arbeit: Ein früher Skill hatte 2.000 Zeilen Schritt-für-Schritt-Anweisungen. Progressive Disclosure hatte ihn bereits in Unterdateien aufgeteilt, aber er blieb zu stark reglementiert.

Ich habe das alles weggeworfen und durch einen Absatz mit drei Sätzen ersetzt. Ich habe etwa 99 % der gleichen Ergebnisse bekommen.

Der Wechsel: der KI nicht mehr sagen, wie sie arbeiten soll, sondern welches Ergebnis sie liefern soll. Brian verglich es mit dem Setzen eines Key Results, während das Modell selbst den Weg findet, eher wie die Zusammenarbeit mit einem erfahrenen Kollegen als das Einarbeiten eines Praktikanten.

Das funktioniert, weil die Modelle selbst besser geworden sind. Lange, prozedurale Prompts kompensierten früher schwächeres Reasoning. Jetzt liegt der Engpass bei der Zielklarheit, nicht bei der Detailtiefe. Schlankere Skills bedeuten kleineren Kontext: niedrigere Token-Kosten, weniger Halluzinationen.

Ein modulares Ökosystem, kein Framework

Die BMad-Methode bietet mehrere Wege zum gleichen Ziel: Brainstorming, ein Product Brief, ein vollständiges PRD, eine UX-Spezifikation, ein Prototyp oder ein Architekturdokument. Man wählt den Einstiegspunkt, und die Module gehen auch über Code hinaus, etwa Game Design, kreatives Brainstorming und Enterprise-Testing. In der Demo sind wir vom Product Brief zu BMad Spec und dann zu QuickDev gewechselt, wo vier Sub-Agents den Code aus verschiedenen Blickwinkeln prüfen.

Party Mode

Eine der ungewöhnlicheren Funktionen ist der Party Mode: eine Multi-Persona-Sitzung, in der mehrere KI-Agenten mit unterschiedlichen Rollen dasselbe Artefakt diskutieren.

In der Demo haben ein Product Manager, ein Architekt, ein Analyst und ein Scrum Master den Product Brief jeweils aus ihrer eigenen Perspektive bewertet. Der PM drängte auf klareren Scope. Der Architekt vermisste nicht-funktionale Anforderungen. Der Analyst fragte nach Edge Cases. Zusammen fanden sie, was ein einzelner Agent übersehen hätte.

Brians Bild: Ein LLM bewegt sich auf einer Glockenkurve und liefert im Standardfall durchschnittliche Antworten. Party Mode zwingt es über diesen Durchschnitt hinaus, weil mehrere Blickwinkel in derselben Sitzung zusammenkommen. Das funktioniert für Code, aber auch für Reiseplanung oder Team-Prozessentscheidungen.

Dokumentation als neue Software

Brian plädiert dafür, Markdown als erstklassiges Entwicklungsartefakt zu behandeln. Product Briefs, Spezifikationen, Architekturdokumente und Skills sind keine statischen Aufzeichnungen; sie führen die KI aktiv durch die Entwicklung.

Der meiste Code, der gerade geschrieben wird, ist Markdown.

Dokumentation wird zu ausführbarem Wissen. Man aktualisiert die Spezifikation, wenn sich Anforderungen ändern, und die KI überträgt die Änderung in den Code. Das Dokument ist die Source of Truth, keine nachträglich geschriebene Zusammenfassung.

Das passt gut zu Java-Teams: Spezifikationen ergänzen die strukturierte, reviewbare Arbeitsweise, die sie bereits praktizieren. Ob man Quarkus, Spring Boot oder eine bestehende Jakarta-EE-Codebasis verwendet, das Muster bleibt gleich: Spezifikation schreiben, die KI daraus implementieren lassen, die Spezifikation aktuell halten, während das System wächst.

Erste Schritte

Die BMad-Methode ist Open Source unter der MIT-Lizenz und wird mit einem Befehl installiert:

npx bmad-method install

Der Installer führt durch die Modulauswahl, die IDE-Unterstützung (Copilot, Claude Code, Cursor und andere) und die Projekteinstellungen. Er schreibt die nötigen Konfigurationsdateien und Skill-Verzeichnisse in das Projekt oder einen übergeordneten Workspace-Ordner.

In dieser Session haben wir Copilot mit Claude 4.8 Sonnet auf einem Quarkus-Projekt verwendet, BMad funktioniert aber über verschiedene IDEs und LLM-Backends hinweg. Das Demo-Repository des Finanz-Trackers steht als Referenz zur Verfügung.

Abschlussgedanke

Die BMad-Methode zählt, weil sie ein System aufbaut, in dem strukturiertes Wissen, modulare Workflows und das richtige Maß an KI-Autonomie zusammenwirken. Das Hilfesystem senkt die Einstiegshürde. Progressive Disclosure hält den Kontext schlank. Dokumentation als Software zu betrachten macht die Ergebnisse wartbar.

Für Java-Entwickler, die KI-Tools bisher nur als Autocomplete mit Extra-Funktionen genutzt haben, bietet die Methode einen anderen Einstieg: beschreiben, was man bauen will, und die Werkstatt findet den Weg.

Nützliche Links

• BMad Method GitHub: Haupt-Repository mit Dokumentation und Community
• BMad Doku: Tutorials, Anleitungen und Konzepte
• BMad Website: Web Bundles und Übersicht
• BMad Discord: Community-Diskussionen
• Finanz-Tracker Demo-Repository: das live in der Session gebaute Projekt
• Quarkus: das im Demo verwendete Java-Framework