Aus dem Fachgespräch wird die Spec

Aus einer Stunde Reden wird mehr Spec als aus einem Tag Tippen.

In einem agentischen Mini-Team ist nicht mehr das Schreiben von Code die teure Arbeit. Entscheident ist das gemeinsame Verstehen. (Was es eigentlich auch immer schon war)

Warum ich in kleinen, fokussierten Mini-Teams die Zukunft der agentischen Softwareentwicklung sehe, habe ich an anderer Stelle beschrieben. Hier geht es um die praktische Frage, die danach kommt: Wie kriegt so ein Team das Fachwissen aus den Köpfen in eine Form, mit der ein Agent etwas anfangen kann?

Das ist die eigentliche Knochenarbeit. Ein Fachexperte weiß unglaublich viel, aber das meiste davon ist nie aufgeschrieben. Es steckt in Gewohnheiten, in Sonderfällen, in Sätzen wie „das machen wir hier immer so”. Genau dieses Wissen muss in die Spec, sonst baut der Agent schnell und sauber am Problem vorbei.

Dabei geht es um mehr, als dem Agenten zu erklären, was gebraucht wird. Das Team muss selbst tief durchdenken und gemeinsam verstehen, welches Problem hier eigentlich gerade gelöst werden soll. Wenn das im Raum keiner sauber sagen kann, hilft auch das beste Modell nicht. Es schreibt dann nur die Unschärfe sauber auf.

KI hilft beim Verstehen, nicht erst beim Bauen

Die meisten setzen Agenten in der Entwicklung ein: Code schreiben, testen, refactoren. Der größere Hebel liegt aber früher. Wenn am Anfang das gemeinsame Verstehen knapp wird, dann gehört die KI genau dorthin, in die Anforderungen und nicht erst in die Umsetzung. Nicht, um die Spec zu schreiben, sondern um das Gespräch zu schärfen, aus dem die Spec entsteht.

Dafür gibt es eine eigene Kategorie Werkzeug: Spec-Driven-Development-Frameworks wie BMAD. Bevor ich beim konkreten Tool lande, lohnt der Blick darauf, was so ein Werkzeug in diesem Moment überhaupt können muss. Es soll zuhören statt reden. Es soll meine Annahmen als Annahmen kennzeichnen und nicht als Fakten verkaufen. Widersprüche gehören an die Oberfläche, nicht glattgebügelt. Offene Punkte soll es halten, statt sich selbst schnell eine Antwort auszudenken. Und was am Ende rauskommt, soll das Gespräch abbilden, nicht das, was ein Modell für plausibel hält.

BMAD ist im Kern eine Simulation eines ganzen Teams für Einzelkämpfer. Ich nutze es im Team anders: als genau dieses Werkzeug, das einem Mini-Team hilft, ein gemeinsames Verständnis zu entwickeln. Es ist gerade das, mit dem mir das am besten gelingt.

Stark ist BMAD genau dort, wo Fachwissen heraus muss. Es stellt Fragen, auf die ich selbst nicht gekommen wäre. Und aus dem Mitgeschriebenen wird keine Übergabe von Business an IT, sondern das gemeinsame Arbeitsgedächtnis des Teams.

Das ist für mich der Unterschied zu manch anderem Spec-Driven-Framework. Wenn ich Spec Kit meine Idee hinwerfe, schreibt es mir gleich eine ganze Spec. Eine Markdownwüste, seitenweise, mit jeder Menge Annahmen darüber, wie es wohl gemeint war. Den Großteil davon hat sich das Modell selbst ausgedacht, und nach kurzer Zeit hat niemand mehr Lust, das überhaupt zu lesen. Danach korrigiere ich seitenlang: nein, so nicht, das auch nicht. BMAD dreht das um. Es bleibt komplett bei dem, was wir als Menschen gesagt haben. Trifft es doch eine Annahme, macht es sie fett als Annahme sichtbar. Ist etwas noch unklar, parkt es den Punkt auf einer Liste auf Wiedervorlage, statt sich etwas auszudenken. Und widersprechen sich zwei Aussagen, hält es nach: „Vorhin hieß es, Freigaben laufen immer über die Teamleitung. Jetzt sagt ihr, unter 500 Euro entscheidet die Sachbearbeitung selbst. Was gilt?”

Der Punkt, der mir wichtig ist: Eine gute Spec entsteht nicht aus dem ersten Antwortversuch eines Modells. BMAD bringt dafür einen ganzen Werkzeugkasten mit, fast 70 Kreativtechniken, um einen Abschnitt noch einmal aufzugreifen, bevor er stehen bleibt. Drei, die ich besonders oft nutze:

Das klingt nach Workshop-Folklore, holt aber genau die Annahmen ans Licht, über die sonst niemand redet.

Reden lassen, mitschneiden

Richtig rund wird das erst mit dem Nutzen von gesprochenen Worten. In einem Fachgespräch will ich nicht hektisch mitschreiben, ich will zuhören und nachfragen.

Aufnehmen statt mitschreiben

Also zeichne ich das ganze Gespräch als Sprachaufnahme auf, immer mit Einverständnis, und transkribiere es lokal, ohne dass ein Wort in die Cloud geht. Auf dem Mac nehme ich dafür MacWhisper (kostet ca. 60€). Plattformübergreifend und kostenlos geht es mit handy.computer, das auch unter Windows läuft. Ein Detail aus der Praxis: Die eingebauten Mikrofone vieler Windows-Notebooks sind schlecht und sitzen oft direkt neben dem Lüfter. Ein Konferenzmikro auf dem Tisch entscheidet dann über brauchbares oder unbrauchbares Transkript. (Oder auch schon ein DJI Mic Mini 2 als Bluetooth-Mikrofon, einzeln ab 33€)

Vom Transkript zur Spec

Das komplette Transkript wird zum Input für den Agenten. Ich muss nicht vorher entscheiden, was wichtig war. Ein gutes Modell zieht aus der ganzen Textmenge die Begriffe, Entscheidungen, Annahmen und offenen Punkte heraus. Das ist der Teil, der vorher schlicht nicht ging. Früher hatte ich die Wahl: zuhören und die Hälfte vergessen, oder mitschreiben und das Gespräch ausbremsen. Jetzt habe ich beides. Das klappt allerdings nur mit einem starken Modell. Ein großes Kontextfenster bringt wenig, wenn das Modell darin nicht mehr zuverlässig wiederfindet. Warum ich deshalb das beste verfügbare Modell nehme, habe ich hier aufgeschrieben.

Ganze Workshops mitlaufen lassen

Das ist für mich der eigentliche Hebel. So halte ich inzwischen Workshops: Wir reden normal, fachlich, im kleinen Kreis, und die Aufnahme läuft durchgehend, mit Einverständnis aller im Raum. Kein ständiges Starten und Stoppen, es läuft einfach durch. Am Ende stehen Transkripte voller kreuz und quer geredeter Gedanken, mit Sprüngen und Kaffeepausen.

Die kippe ich als Grundlage in BMAD, und damit fängt der eigentliche Prozess erst an. Das Transkript ist der Startpunkt, nicht das Ergebnis. Von dort führt BMAD uns durch das gemeinsame Schreiben der Spec: Es verdichtet, was wir gesagt haben, stellt Rückfragen und deckt Lücken auf, die uns zum Weiterreden bringen. Was dabei an Antworten und neuen Gedanken fällt, kippen wir wieder ins Prompt-Feld. So dreht sich die Schleife: reden, einkippen, nachfragen lassen, weiterreden. Die Spec lesen wir zwischendurch gemeinsam laut vor, und genau dabei entstehen die nächsten Gespräche. Der eine hält ein Feature für die Kernfunktion, der andere will es nach hinten schieben. Das Modell hört alles mit. Manchmal hat es zwei Stunden später eine Information parat, die nur beiläufig gefallen ist und die sich sonst niemand notiert hätte.

Achtung Wasserfall

So nützlich das ist, es hat eine Schattenseite. Wenn das Tooling den gesamten Prozess in ein starres Schema presst, wird aus dem Hilfsmittel schnell ein Korsett. Dicke Specs, viele Phasen, kleinteilige Story-Zerlegung. Das kann helfen, Kontext zu managen. Es kann aber auch Wasserfall mit KI-Anstrich werden. Alles sieht sauber aus, nur lernt man zu spät, dass man das Falsche sauber spezifiziert hat.

Das beste Gegenmittel ist, BMAD nicht für alles zu nehmen. Für mich sind das zwei Werkzeuge mit zwei Aufgaben. Der schnelle Wegwerf-Prototyp ist zum Explorieren, Ausprobieren und Kommunizieren mit der Fachabteilung. Statt einen Punkt totzuspezifizieren, baue ich lieber schnell etwas Anfassbares und werfe es hinterher wieder weg. Das geht inzwischen irrsinnig schnell, und eine laufende Oberfläche sagt mehr als drei Seiten Spec. Sofort ist klar, ob alle dasselbe meinen.

BMAD ist das andere Werkzeug. Es gießt das Gelernte in eine Spec. Beides greift ineinander: Der Prototyp bringt das Verständnis in Bewegung, BMAD hält es fest. Deshalb nutze ich BMAD bewusst vorne, im gemeinsamen Denken, und nicht als durchgetaktete Pipeline bis zum letzten Commit. Es soll das Teamgespräch unterstützen, nicht ersetzen. Der Wert entsteht nicht dadurch, dass eine Maschine eine Spec erzeugt. Er entsteht dadurch, dass zwei oder drei Menschen am Ende dasselbe verstanden haben, und das auch nachlesen können.