Mit Spec-driven Development habe ich in den letzten Monaten oft mehr und besseren AI-generierten Output produziert als vorher. Gleichzeitig war ich nach vielen Sessions auch deutlich erschöpfter.
Nicht trotz der Struktur, sondern oft wegen ihr.
Das hat mich erst irritiert. Denn Spec-driven Development verspricht ja erstmal genau das Richtige: weniger Chaos, mehr Klarheit, bessere Ergebnisse mit Agenten. Und das stimmt auch. Nur nicht durchgängig.
Mein Eindruck ist inzwischen ziemlich klar: Dieselbe Struktur, die mir in der Denkphase hilft, kann mich in der Bauphase ausbremsen. Dann baue ich nicht mehr. Ich manage, formuliere und dokumentiere.
Und genau da entstehen für mich die versteckten Kosten von Spec-driven Development.
Mich interessiert dabei weniger die Grundsatzfrage, ob SDD nun gut oder schlecht ist. Mich interessiert die praktischere Frage: Wann schafft diese Arbeitsweise echte Klarheit, und wann verschiebt sie Denkarbeit an die falsche Stelle?
Gute Last, schlechte Last
Nicht jede Last ist automatisch schlecht. Ein Teil von Entwicklungsarbeit ist anstrengend, weil das Problem an sich anstrengend ist. Ein anderer Teil ist anstrengend, weil die Arbeitsweise unnötige Reibung erzeugt.
Genau dieser Unterschied ist für mich bei Spec-driven Development spannend geworden. Ich kann mit einem Framework wie BMAD ein Vorhaben sauberer durchdenken als früher. Ich werde gezwungen, unscharfe Anforderungen explizit zu machen.
Ich muss Randbedingungen benennen. Ich muss schneiden. Ich muss Lücken sehen, bevor ich sie mit generiertem Code überdecke. Das ist erstmal hilfreich.
Gleichzeitig merke ich aber: Diese Struktur fühlt sich nicht in jeder Phase gleich sinnvoll an. Manchmal reduziert sie Komplexität. Manchmal verlagert sie sie nur.
Und der Unterschied ist für mich nicht theoretisch. Ich merke ihn sehr konkret in Fokus, Tempo und Energie.
Darum würde ich SDD inzwischen nicht mehr pauschal bewerten. Die entscheidende Frage ist für mich eher, welche Art von Last es gerade erzeugt.
Hilft mir die Struktur beim Verstehen? Oder zwingt sie mich, Dinge auszuformulieren, die ich beim Bauen viel leichter direkt am lebenden Objekt klären würde?
Warum SDD in der Denkphase helfen kann
Spec-driven Development löst auf der grünen Wiese ein echtes Problem. Wer mit Agenten arbeitet, merkt schnell, dass guter Kontext kein Nice-to-have ist.
Gut strukturierter Kontext trägt maßgeblich zur Lösung bei.
Wenn ich Anforderungen, grobe Architektur, UX-Leitplanken und erste Story-Schnitte sauber festhalte, wird später vieles leichter. Diffuse Gedanken landen in klareren Schubladen. Das Problem wird kleiner, weil ich es vorher schon einmal sortiert habe.
Und der Agent hat später etwas, woran er sich festhalten kann, statt bei jeder Aufgabe wieder bei null anzufangen.
Gerade in frühen Projektphasen hilft mir das sehr. Nicht, weil ich vorher nie nachgedacht hätte. Sondern weil mich das Framework dazu zwingt, lose Gedanken wirklich sauber auszuarbeiten und festzuhalten.
Was soll dieses und jenes Feature eigentlich für wen leisten? Welche Randbedingungen sind relevant? Wo will ich bewusst noch nichts entscheiden? Für diese Art von Denkarbeit ist etwas Struktur nützlich.
Wenn ich das mit Daniel Westheides Cognitive-Load-Linse beschreiben würde, dann so: In dieser Phase reduziert das Framework Komplexität. Es zerlegt ein großes Problem in kleinere, bearbeitbare Teile.
Das ist gute Last. Oder zumindest Last, die sich für mich sinnvoll anfühlt.
Wenn Bauen zu Dokumentationsarbeit verkommt
Das Problem beginnt bei mir oft genau dort, wo es eigentlich produktiv werden sollte: bei der Implementierung.
Dann sitze ich nicht mehr vor dem eigentlichen Problem. Ich sitze vor einer Story-Spec und formuliere Akzeptanzkriterien für Dinge, die vielleicht nie eintreten. Ich beschreibe Verhalten für Sonderfälle, die ich beim direkten Bauen wahrscheinlich in zwei Iterationen mit dem Agenten geklärt hätte.
Ich versuche, Intuition vorab in Text zu pressen.
Besonders deutlich merke ich das beim Erzeugen einer Story aus einem Epic. Vorher habe ich noch über Functional Requirements, Non-Functional Requirements und grobe Story-Rümpfe gesprochen. Also für wen bauen wir das, was soll passieren, woran merken wir, dass es reicht.
Stattdessen rutschen dann ganz schnell technische Details und Code-Beispiele hinein.
Ein konkretes Beispiel hat mir das sehr deutlich gemacht. Aus einer eigentlich simplen Story wie „Create User Profile" wurde bei mir ein riesiges Paket aus 19 Acceptance Criteria, Datenbankfeldern, Komponenten-Mapping, Dependency-Hinweisen, File-Lists, Test-Checklisten und später sogar Review-Follow-ups. 1070 Zeilen Markdown.
Formal hieß das Ding immer noch Story. Praktisch war es schon halb Spezifikation, halb Implementierungsplan und halb QA-Backlog. Ja genau, das sind drei Hälften.
Damit verschiebt sich der ganze Modus. Ich diskutiere nicht mehr über eine verständliche Geschichte für Menschen, sondern über eine vorweggenommene Umsetzung.
Der Feedback-Loop wird länger, weil plötzlich Dinge auf dem Tisch liegen, die an dieser Stelle noch gar nicht entschieden werden müssten.
Noch problematischer wird es dadurch, dass diese Code-Schnipsel nicht neutral sind. Sie primen das Modell, das die Story später umsetzt.
Wenn ich den Code irgendwann umbauen oder mit einem besseren Modell neu generieren will, steckt in der Story schon ein technischer Bias aus einem früheren Planungsschritt.
Der Vorgriff sitzt dann längst im Material.
Warum sich nicht alles explizit machen lässt
Ein Teil meines Unbehagens hat mit etwas anderem zu tun: Ein Teil guter Entwicklungsarbeit lässt sich nicht sauber vorab in Sprache übersetzen.
Am besten beschreiben kann ich das über ein Bild aus dem Autofahren.
Wenn du lange fährst, entwickelst du ein Gefühl dafür, was gleich passiert. Du siehst drei Autos weiter vorne schon Bremslichter aufflackern. Du gehst vom Gas, ordnest dich links ein, überholst, reagierst vorausschauend.
Das läuft schnell und fast beiläufig.
Beim Coden geht mir das ähnlich. Mit etwas Erfahrung spürst du oft früh, welche Entscheidung in drei Schritten vielleicht Probleme machen wird. Du passt etwas an, bevor es kracht.
Nicht, weil du schon alles formulieren könntest. Sondern weil du in der Sache drin bist.
Spec-driven Frameworks versuchen, eine Lücke mit Dokumenten zu schließen. Das ist nachvollziehbar. Aber ein Teil dieser Lücke ist nicht einfach ein Dokumentationsproblem. Es ist ein Problem von implizitem Wissen.
Wir wissen beim Bauen oft mehr, als wir im Voraus sauber sagen können. Wir erkennen Muster. Wir merken, dass etwas schief aussieht, bevor wir erklären könnten, warum.
Der Versuch, genau diese Erfahrung vollständig in Specs zu pressen, kostet viel Energie. Und das ist für mich der eigentliche Verlust: Ich muss aus einem Modus des Erkennens in einen Modus des Erklärens wechseln, bevor ich angefangen habe, irgendetwas zu bauen.
Warum dicke Specs kein gemeinsames Verständnis erzeugen
Aus einer Product-Owner-Schulung von 2017 mit Jeff Patton und Jeff Gothelf ist mir ein Gedanke hängen geblieben: Eine Story ist kein Dokument. Sie ist ein Token für ein Gespräch.
Erst Card, dann Conversation, dann Confirmation. Nicht andersrum.
Akzeptanzkriterien sollten bestätigen, dass man sich verstanden hat. Sie sollten das Verständnis nicht durch immer mehr Vorab-Details ersetzen.
Genau da kippt es für mich in der Bauphase von SDD. Ich schreibe ein Dokument. Der Agent konsumiert es. Es gibt keine echte Konversation, sondern nur eine Übergabe.
Und damit fällt etwas weg, was Stories ursprünglich leisten sollten.
In einem Kundenprojekt im letzten Jahr habe ich genau das erlebt. Ich habe im Team viel Aufwand in detaillierte User Stories (Specs) gesteckt. Ganz ohne BMAD und mit eigentlich guter Intention: ein solider erster Wurf, inklusive vieler Akzeptanzkriterien mit dem das Team ins Rennen gehen konnte und nicht bei null anfangen musste. Aber das Team hat die Specs ganz anders gelesen. Für sie war das kein Diskussionsentwurf, sondern schon ein fertiges Übergabedokument. Da steht doch schon alles. Also wurde viel diskutiert, aber nicht über die Sache, die es zu bauen galt, sondern über den Umfang und die Form der Stories.
Das Ergebnis: Auf der einen Seite jemand, der sich wundert, warum es nur negatives Feedback gibt. Auf der anderen Seite ein Team, das sich fragt, warum es noch mitreden soll, wenn ohnehin schon alles entschieden scheint.
Die Stories blieben eine ganze Weile so dick. Und die Review-Last wuchs mit. Denn aus einer dicken Story fabriziert ein Agent schnell einen riesigen Implementierungsplan inkl. Datenbankschema, Komponentenstruktur, usw.
Und irgendwann liest niemand mehr richtig. Das ist menschlich. Aber es untergräbt genau das, was die Stories eigentlich sicherstellen sollten.
„Shared documents are not shared understanding"
Patton trifft das für mich ziemlich genau. Die Story wird dicker. Ich fühle mich kurz sicherer. Aber daraus folgt noch nicht, dass später auch etwas Besseres gebaut wird.
Das Dokument wächst, aber das Verständnis nicht automatisch mit.
Im schlimmsten Fall passiert das Gegenteil: Ich habe viel Text produziert und bilde mir ein, das Problem sei gründlich durchdrungen, obwohl ich vor allem ein sauberes Übergabedokument erzeugt habe.
Das sieht nach Klarheit aus. Ist aber manchmal nur gut organisierte Scheinsicherheit.
Bei BMAD gibt es einen sogenannten Party-Modus, in dem verschiedene KI-Experten mit unterschiedlichen Perspektiven eine Story diskutieren. Das simuliert ein Teamgespräch und bringt manchmal auch überraschende Einsichten. Aber es bleibt eine Simulation. Und die Insights verbleiben in der KI-Session. Ein Team, das später mit der Spec und dem Code leben muss, lernt davon nichts. Kein geteiltes Verständnis fließt zurück in die Köpfe.
Warum billige Iteration die Rechnung verändert
Viele SDD-Frameworks investieren in der Planungsphase so, als wäre Iteration immer noch teuer. Aber das ist sie mit Agenten oft gar nicht mehr. Ein paar schnelle Runden aus „bau mal so", „nein, jetzt eher so", „ja, jetzt passt’s" sind in vielen Situationen billiger als stundenlang eine perfekte Vorab-Spec zu schleifen.
Manchmal ist die bessere Antwort vielleicht: früher ins Machen gehen und bessere Sicherheitsnetze einziehen. Das heißt nicht, dass Planung überflüssig wird. Es heißt nur, dass sich die Rechnung verschiebt.
Wenn der nächste testbare Prototyp nicht mehr Tage, sondern Minuten entfernt ist, dann verliert ein Teil der Vorab-Bürokratie seinen wirtschaftlichen Vorteil.
Mehr Spec ist nicht automatisch die vernünftigere Form von Risikomanagement. Manchmal ist es in mehrfacher Hinsicht teurerer Denkaufwand.
Was für mich besser funktioniert
Ich bin deshalb nicht bei „Framework weg, einfach vibecoden" gelandet. Das wäre die falsche Gegenreaktion.
Den Planning-Modus eines Agenten finde ich beispielsweise total sinnvoll. Ich will nur nicht, dass alles, was in diesem Denkraum kurzfristig hilfreich ist, dauerhaft in einer Story-Datei landet.
Was ich stattdessen mache und was nicht (mehr):
In der Denkphase bemühe ich mich, zuerst das gemeinsame Verständnis im Team zu sichern, und erst dann die daraus relevanten Informationen in einer Spec festzuhalten. Nicht andersrum. Ich nutze dafür weiterhin eine feste Struktur, entweder durch BMAD oder einen Eigenbau. Und ich schreibe aber nur so viel Spec, wie sie mir oder meinem Team auch echte Klarheit verschafft. Die Story bleibt kurz und beschreibt, was für wen passieren soll und woran wir merken, dass es reicht. Ergänzt um ein paar Links zu mehr Kontext, falls nötig. Sozusagen Progressive Disclosure für gegebenenfalls relevante Zusatzinfos wie das zugehörige Epic, Personas, Requirements, etc.
In der Bauphase arbeite ich in kurzen Loops eng am Code. Nach Möglichkeit im Flow-State. Ich lasse den Agenten auf Basis der Specs planen, aber dieser konkrete Plan darf flüchtig sein. Er ist ein Arbeitsdokument, kein Artefakt. Was ich nicht mehr mache: den Plan inklusive Code-Beispielen, Datenbankfelder oder File-Listen mit in die Story stopfen.
Entscheidungen trenne ich bewusst von der Spec. Wenn während der Planung oder der Implementierung architekturrelevante Entscheidungen fallen, schreibe ich ein ADR. Wenn es eine Produktentscheidung ist, fließt sie zurück ins Refinement oder in eine angepasste Story. Wenn es eine technische Abwägung ist, landet sie als Kommentar im Code oder in einer Architekturdokumentation. Entscheidungen brauchen einen sichtbaren Ort, nicht eine Zeile in einem 1000-Zeilen-Markdown.
Absicherung verlagere ich schrittweise vom Dokument in den Harness: Tests, Linter, Architekturregeln, Reviews und alles, was immer wiederkehrende Probleme zuverlässig und bestenfalls deterministisch für einen Agenten sichtbar macht. Relevante Learnings daraus gehören ins Harness-spezifische Projekt-Memory.
Der Harness-Gedanke gefällt mir deshalb so gut, weil er den Schwerpunkt verschiebt. Systematisch absichern, was wiederholt schiefgeht, statt alles vorher ausformulieren.
Weniger Vorab-Bürokratie. Mehr belastbare Leitplanken.
So viel wie nötig, so wenig wie möglich
Ich halte Spec-driven Development nicht für einen Irrweg. BMAD hat für mich einen klaren Platz: beim Denken, Sortieren, Schneiden und Klären. Das hilft mir nicht nur im Solo-Modus, sondern kann auch im Team unterstützen, besonders wenn dieser Schritt zu kurz kommt oder unter den Tisch fällt.
Aber bei der Implementierungsarbeit schreibe ich schnell mehr über Arbeit, als ich Arbeit habe. Und dann ist die Story kein Gesprächsanlass mehr, sondern ein Übergabedokument, das im stillen Kämmerlein entstanden ist.
SDD-Frameworks erhöhen in jeder Phase spürbar den Output. Aber Output ist nicht Outcome. Oder wie Patton in der Product-Ownership-Schulung sagte:
„Minimize Output, Maximize Outcome & Impact."
Was ich über Umwege daraus gelernt habe: Die dickere Spec war nie das Ziel. Sie war ein Symptom dafür, dass ich Sicherheit im Dokument gesucht habe statt im Prozess.