Ich habe einen zweitägigen Workshop gehalten, in dem es sehr konkret um einen hands-on Vergleich von BMAD, OpenSpec und Spec Kit ging. Also nicht um eine Tool-Show mit ein paar Folien und viel Meinung, sondern um die Frage, wie sich diese Ansätze anfühlen, wo sie helfen und wo sie einen eher ausbremsen.
Wir haben uns dafür echte Use Cases genommen und die drei Frameworks wirklich benutzt. Einer davon war ein Tool zur Verteilung von Teilnehmern auf Restaurants bei größeren Veranstaltungen. Also kein künstliches Demo-Beispiel, sondern ein ziemlich reales Problem: viele Leute, mehrere Restaurants, begrenzte Kapazitäten, unterschiedliche Essenspräferenzen und am Ende soll die Verteilung trotzdem vernünftig funktionieren.
Dabei sind wir mit vielem bewusst gar nicht bis in die Umsetzung gegangen, sondern in der Spezifizierungsphase geblieben. Das war kein Mangel des Workshops, eher im Gegenteil. Genau dort wurde nämlich sichtbar, wie unterschiedlich die drei Ansätze arbeiten.
Spec Kit war für mich der leichteste Einstieg. Schnell aufgesetzt, wenig Einarbeitung, ziemlich direkt in Richtung Umsetzung. Das ist angenehm, wenn der Rahmen schon steht. Wenn klar ist, was gebaut werden soll, und wenn Architektur und Scope nicht mehr groß zur Debatte stehen, dann kann das sehr gut passen. Mir war aber auch schnell klar, dass es einen an entscheidenden Stellen ziemlich in Ruhe lässt. Wenn die Anforderung noch unscharf ist, wird Spec Kit nicht automatisch der Partner, der sie für einen sauber auseinanderzieht.
OpenSpec saß für mich genau dazwischen. Strukturierter als ein leichter Spec-Flow, aber deutlich pragmatischer als BMAD. Gerade für bestehende Systeme fand ich das interessant. Dort ist ja vieles schon da: Codebasis, Architektur, Randbedingungen, technische Realität. Dann braucht man nicht immer erst den ganz großen Vorlauf, sondern eher eine saubere Beschreibung der Änderung. Genau da wirkt OpenSpec ziemlich passend. Ich hatte aber auch den Eindruck, dass man aufpassen muss, Requirements und Architektur nicht zu früh ineinanderzuschieben.
Am meisten beeindruckt hat mich BMAD. Nicht, weil es besonders elegant oder besonders schnell wäre. Sondern weil es einen mit Fragen bombardiert, auf die man selbst so nicht gekommen wäre. Marktanalyse, Perspektivwechsel, die Sechs-Hüte-Methode, Party Mode mit unterschiedlichen Rollen. Das klingt auf dem Papier erstmal fast ein bisschen nach Spielerei. Im Workshop war davon erstaunlich wenig Spielerei zu spüren. Was am Ende dabei herauskam, war oft ziemlich brauchbar.
Genau das war für mich überhaupt die wichtigste Beobachtung aus diesen zwei Tagen. Im Raum stand nicht nur die Frage, wie man mit Agenten schneller zu Code kommt. Spannender war die andere Frage: Wie kommen wir zu besseren Spezifikationen und besseren Anforderungen? Da war BMAD für mich klar am stärksten. Es zwingt einen dazu, Dinge auszusprechen, die man sonst gern überspringt. Welche Annahmen stecken in der Idee? Welche Perspektive fehlt? Was ist eigentlich schon entschieden, und was nur implizit mitgemeint?
Das Gute daran ist: Das Ergebnis ist nicht nur für agentische Umsetzung brauchbar. Wenn am Ende eine wirklich tragfähige Spezifikation herausfällt, kann damit genauso gut ein menschliches Entwicklerteam arbeiten. Genau deshalb fand ich den Workshop so ergiebig. Der eigentliche Wert lag nicht im Abarbeiten von Tasks, sondern im gemeinsamen Herausarbeiten dessen, was überhaupt gebaut werden soll.
Viel hands-on, viel konstruktiver Austausch und am Ende kein Hype-Fazit, sondern eine ziemlich nüchterne Beobachtung: Wenn die Spezifikation trägt, wird danach vieles leichter. Und BMAD hat in diesem Vergleich am klarsten gezeigt, wie man dahin kommt.