- Spec-Driven Development (SDD) ist ein Ansatz im Wasserfallstil, bei dem vor dem Programmieren umfangreiche Dokumente erstellt werden. Er soll AI-Coding-Assistenten strukturieren, birgt aber das Risiko, die Agilität zu beeinträchtigen
- Die Open-Source-Community hat auf Basis anfänglicher Prompts und Anweisungen Tools entwickelt, die Spezifikationen, Implementierungspläne und Aufgabenlisten automatisch erzeugen; bekannte Beispiele sind Spec-Kit, Kiro, Tessl, BMad Method
- In der Praxis zeigen sich jedoch verschiedene Grenzen wie mangelndes Kontextverständnis, übermäßige Dokumentation, doppelte Code-Reviews und ein trügerisches Sicherheitsgefühl, und in großen Codebasen nimmt die Effizienz stark ab
- Der Artikel weist darauf hin, dass SDD als Versuch, Entwickler zu ersetzen, das Scheitern des Wasserfallmodells wiederholt, und schlägt stattdessen einen iterativen, auf natürlicher Sprache basierenden Entwicklungsansatz vor
- Ein Ansatz, der Agile- und Lean-Startup-Prinzipien kombiniert, ist für moderne Entwicklung mit Coding-Agenten besser geeignet; die nächste Aufgabe ist der Ausbau visueller Interaktionswerkzeuge
Das Aufkommen von Spec-Driven Development (SDD)
- Spec-Driven Development (SDD) führt einen Prozess ein, bei dem vor dem Coding Spezifikationsdokumente erstellt werden, um einen strukturierten Entwicklungsansatz für AI-Coding-Assistenten bereitzustellen
- Auf Basis anfänglicher Prompts und Anweisungen erzeugt ein LLM Produktspezifikationen, Implementierungspläne und Aufgabenlisten
- Jedes Dokument baut auf der vorherigen Stufe auf, und der Nutzer verfeinert die Spezifikation durch Überarbeitungen
- Die fertigen Dokumente werden an Coding-Agenten wie Claude Code, Cursor, Copilot übergeben und zum Schreiben von Code verwendet
- Zu den bekannten Tools gehören GitHubs Spec-Kit, AWSs Kiro, Tessl, BMad Method (BMM)
- Erwähnt wird auch Birgitta Böckelers Vergleichsanalyse Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
Probleme der Markdown-Dokumentation
- SDD-Spezifikationen bestehen meist aus Markdown-Dateien; als Beispiel umfasst eine einfache Funktionsimplementierung mit GitHub Spec-Kit 8 Dateien und 1.300 Zeilen
- Auch der Fall, in Atomic CRM mit Kiro ein Feld „referred by“ hinzuzufügen, ist in zahlreiche Dokumente aufgeteilt
- In der Praxis zeigen sich folgende Nachteile
- Mangelndes Kontextverständnis (Context Blindness): Vorhandene Funktionen oder Codekontexte werden übersehen, daher ist fachkundige Prüfung weiterhin nötig
- Übermäßige Dokumentation (Markdown Madness): Lange Dokumente kosten viel Zeit, selbst für die Suche nach einfachen Fehlern
- Systematische Bürokratie (Systematic Bureaucracy): Unnötige Wiederholungen und übertriebene Detailtiefe führen zu Ineffizienz
- Pseudo-Agile (Faux Agile): Das Konzept der „User Story“ wird missbräuchlich eingesetzt und sorgt für Zerstreuung
- Doppelte Code-Reviews (Double Code Review): Sowohl der Code in der Spezifikation als auch die tatsächliche Implementierung müssen geprüft werden
- Trügerisches Sicherheitsgefühl (False Sense of Security): Der Agent folgt der Spezifikation nicht vollständig
- Abnehmender Nutzen (Diminishing Returns): In frühen Projekten nützlich, bei wachsender Größe jedoch immer langsamer
- Da die meisten Coding-Agenten bereits einen plan mode und Task-List-Funktionen bieten, ist der zusätzliche Nutzen von SDD begrenzt und kann die Entwicklungskosten sogar erhöhen
Die Rache des Projektmanagers
- Die Grenzen von SDD könnten auf unreife Tools zurückzuführen sein, entspringen aber grundlegend einer falsch gestellten Problemdefinition
- Sie setzt das Ziel voraus, „Entwickler aus der Softwareentwicklung zu entfernen“
- Entwickler sollen durch Coding-Agenten ersetzt und diese durch detaillierte Planung kontrolliert werden
- Das ähnelt dem Wasserfallmodell: Durch umfangreiche Dokumentation werden Entwickler auf die Rolle bloßer Übersetzer reduziert
- Softwareentwicklung ist jedoch ein nichtdeterministischer (non-deterministic) Prozess, bei dem Unsicherheit nicht allein durch Planung beseitigt werden kann (Verweis auf den Aufsatz No Silver Bullet)
- SDD erfordert sowohl in der Anforderungsphase die Expertise von Business-Analysten als auch in der Entwurfsphase die von Entwicklern, sodass es in der Praxis nur von wenigen genutzt werden kann, die beide Rollen ausfüllen
- Letztlich verspricht es wie No-Code-Tools „Entwicklung ohne Entwickler“, braucht am Ende aber doch Entwickler
Eine neue Alternative: iterative Entwicklung auf Basis natürlicher Sprache
- Die Agile-Methodik begegnet dem Problem nichtdeterministischer Entwicklung, indem sie statt Vorhersagbarkeit auf Anpassungsfähigkeit setzt
- Für den Einsatz von Coding-Agenten ist entscheidend, komplexe Anforderungen in mehrere einfache Probleme zu zerlegen
- Vorgestellt wird ein einfaches iteratives Verfahren nach Lean-Startup-Prinzipien
- Die riskanteste Annahme des Produkts identifizieren
- Das kleinstmögliche Experiment entwerfen, um sie zu validieren
- Das Experiment entwickeln und je nach Ergebnis iterieren
- Als Beispiel wird mit Claude Code in etwa 10 Stunden ein 3D-Sculpting-Tool (sculpt-3D) entwickelt
- Ohne Spezifikation werden Funktionen mit kurzen Anweisungen schrittweise ergänzt
- Fehlentwicklungen werden sofort korrigiert, wodurch schnelle Iterationen möglich sind
- Dieser Ansatz ermöglicht auch ohne wasserfallartige Dokumentation eine schnelle Konvergenz; durch die Kombination von Agile und Coding-Agenten wird Produktentwicklung in Echtzeit möglich
- Allerdings sind Coding-Agenten textzentriert und bieten zu wenig visuelle Interaktion; künftig braucht es daher Tools zur Stärkung visueller Interfaces
Fazit
- Die Agile-Methodik hat Spezifikationsdokumente im Grunde bereits überflüssig gemacht, und SDD wird als Versuch bewertet, sie wiederzubeleben
- SDD ist ein theoriegetriebener Ansatz, der Entwickler ausgrenzen will, und verpasst damit die Chance, eine neue Generation von Entwicklern durch Coding-Agenten zu befähigen
- Coding-Agenten werden mit dem Verbrennungsmotor verglichen: Während SDD sie an die Lokomotive fesselt, sollten wir sie in Autos, Flugzeuge und andere Formen weiterentwickeln
- Abschließend gilt: Wer die Umwelt berücksichtigt, sollte Coding-Agenten maßvoll einsetzen
1 Kommentare
Hacker-News-Kommentare
Als Entwickler war die größte Produktivitätssteigerung für mich, mir anzugewöhnen, jede Aufgabe im Voraus zu planen
Bei jedem Ticket zerlege ich die Arbeit in eine große TODO-Liste und kläre Design, Abhängigkeiten und Spezifikationen vorab
Dadurch komme ich beim Programmieren häufiger in einen Flow-Zustand
Dass dieser Ansatz auch für AI-Coding-Agenten gut funktioniert, liegt daran, dass man den Denkprozess vorab auslagert
Mehr Details stehen in meinem Beitrag
In der Praxis ist es gut, Probleme zu zerlegen und Spezifikationen zu schreiben
Das Problem sind nur unveränderliche Spezifikationen. Wenn die Implementierung erst Monate später beginnt, verhärtet sich die Spezifikation
Agile wird dagegen oft als Ausrede genutzt, strategische Planung aufzuschieben. Das führt dann zu viel Nacharbeit
Am Ende ist es eine Frage des Gleichgewichts, und ich denke, „It depends“ ist sowohl fürs Leben als auch für die Entwicklung ein gutes Motto
Wenn LLMs die Spezifikationen verwalten, könnte das den Wartungsaufwand verringern
Der zugehörige Text ist hier
Wenn Vorhersagen schwierig sind, machen wir zuerst einen Spike, um Code und Bibliotheken zu erkunden
Wir erstellen sowohl ein ideales Strukturdiagramm als auch eines, das reale Einschränkungen abbildet, um langfristig Architekturfallen zu vermeiden
Ich habe ein paar Monate lang vibe coding gemacht und bin in den letzten sechs Monaten auf spec-driven development umgestiegen
Ich schreibe täglich 2–3 Stunden lang Spezifikationen und deploye noch am selben Tag getestete Funktionen
Durch das Schreiben von Spezifikationen bin ich nicht weniger agil geworden. Im Gegenteil: So sind schnelle Iterationen im 8-Stunden-Takt möglich
Die Spezifikation ist kein Prompt, sondern ein Kriterium zur Beurteilung von Korrektheit
Gut definierte End-to-End-Tests reduzieren AI-Fehler erheblich
Bei jedem Lauf fällt das Ergebnis anders aus, und am Ende muss doch ein Mensch prüfen, was ineffizient sein kann
Eine eintägige Aufgabe als „Spezifikation“ zu bezeichnen, ist missverständlich. Im Grunde bekommt der bestehende Prozess nur einen neuen Namen
Selbst einfache Logikformeln interpretieren sie oft falsch, daher ist es riskant, sie natürliche Sprachspezifikationen verstehen zu lassen
Die gebe ich an den Agenten weiter, der die Implementierung übernimmt, während ich zwischendurch nur prüfe
Während die AI arbeitet, schraube ich an meinem Rennwagen herum, also eine komplette Win-win-Situation
Am Ende zählt nur, dass der Code die Tests besteht
Dieser Beitrag scheint für Leute geschrieben zu sein, die bereits zu dem Schluss gekommen sind, dass „spec-based development nichts für mich ist“
Ich sehe Spezifikationen als Kontexteinstiegspunkt für ein LLM
Wenn man genügend Informationen über Projektstruktur, Modelle, Funktionen und Anforderungen liefert, versteht das LLM den Kontext und kann darauf aufbauen
Außerdem werden agile Iterationen möglich, wenn das LLM die Spezifikation selbst aktualisiert
Tests dienen dem LLM als Grounding in der Realität und verhindern Halluzinationen
Tests sind zugleich Dokumentation und Qualitätsmaßstab, und man sollte ein LLM wie einen Junior-Entwickler führen
Wenn mehrere Agenten parallel laufen und sich über eine Testschicht gegenseitig prüfen, kommen erstaunliche Ergebnisse heraus
Dank LLMs kann man die komplette Spezifikation nur günstiger und schneller iterieren, aber das Grundprinzip bleibt gleich
Zu lange Spezifikationen behindern eher exploratives Denken
LLMs sind keine deterministischen, sondern probabilistische Systeme, also müssen wir jetzt Spezifikationen statt Code debuggen
Entwickler müssen sich nun zu Architekten kognitiver Systeme weiterentwickeln
Es gibt sowohl Spezifikationen auf hoher Ebene als auch detaillierte Komponentenspezifikationen
Ich habe mit GitHubs Spec-Kit ein CLI-Tool gebaut, aber dafür waren zu viele Schritte aus Korrigieren, Analysieren und Umschreiben nötig
Es fühlte sich frustrierend an, weil wie bei Waterfall zu wenig iteratives Feedback da war
Am Ende war es besser, neu anzufangen, statt fehlerhaften Code zu analysieren und nach der Ursache zu suchen
Mit LLMs zusammen zu coden ist gut, aber SDD wirkte auf mich wie ein schwerfälliger und ineffizienter Workflow
LLMs mögen Kontext, deshalb muss man sie wiederholt klar anweisen
Als Beispiel kann man beim Bauen einer NextJS-App Login, RBAC und test-first-Implementierung eindeutig beschreiben
Es ist besser, klein anzufangen und nach und nach Funktionen hinzuzufügen
Das Problem bei Waterfall waren lange Lead Times und teure Iterationskosten
Bei SDD sind diese beiden Punkte gelöst, deshalb halte ich es für akzeptabel
Eine Spezifikation, an der man ein paar Stunden arbeitet, als Waterfall zu bezeichnen, ist übertrieben
Wenn man zu schnell in einen komplexen Lösungsraum springt, wird es schwer, einfache Probleme zu lösen
Agile startet in einem kleinen Raum und erweitert ihn schrittweise
Ist die Spezifikation detailliert genug, werden Iterationen langsam; ist sie zu knapp, funktioniert das LLM nicht richtig
Am Ende bleibt derselbe von Managern geliebte Widerspruch des Waterfall-Modells bestehen
LLMs funktionieren am besten, wenn man ihnen in kleinen Einheiten klare Anweisungen gibt
Sie schreiben mehrjährige Spezifikationen, lassen alle sechs Monate ein LLM laufen und geben bei Misserfolg den Entwicklern die Schuld
Hier schreibt der Autor selbst
Ich finde es immer noch interessant, dass die Debatte Waterfall vs. Agile so lebhaft ist
Es macht auch Spaß, die Hintergründe der Leute zu lesen, die SDD für wertvoll halten
Ich nutze vor der Implementierung aber ohnehin schon den Plan-Modus, daher bietet mir SDD keinen zusätzlichen Mehrwert
Ein Coding-Agent hat bei mir fast nie auf Anhieb perfekt implementiert
Am Ende braucht man ohnehin Iterationen, wodurch der Sinn von Big Design Up Front verloren geht
Trotzdem glaube ich, dass Coding-Agenten ein neues Entwicklungsparadigma eröffnen
Das erinnerte mich an dieses Video
Darin ging es darum, was Ingenieure und Programmierer voneinander lernen können, und besonders der Wert von Planung im Voraus blieb mir im Gedächtnis
Man sagt, Agile habe Spezifikationsdokumente getötet, aber in Wirklichkeit hat es sie nur in Tausende Jira-Tickets zerlegt
AI könnte all diese verstreuten Entscheidungen und Kontexte festhalten und Fragen stellen, wenn sie früheren Entscheidungen widersprechen
So etwas wie: „Gilt der Grund, warum Jim diesen Code vor fünf Jahren so geschrieben hat, noch immer?“
Dieser Beitrag wirkte auf mich etwas seltsam
Mit unvollständigen Spezifikationen zu arbeiten und sich per Versuch und Irrtum durchzuschlagen, ist für menschliche Entwickler und AI gleich
Wenn man etwas klar weiß, sollte man detaillierte Anweisungen geben
Vielleicht geht es im Kern einfach um „schlechte Spezifikationen“
Insgesamt wirkt das wie eine Selbstverteidigungslogik der Agile-Industrie
Ich habe SDD mit mehreren Markdown-Spezifikationsdateien ausprobiert, und wirklich effizient war nur ** beads**
Damit kann der Agent dem Arbeitsbaum folgen und fokussiert bleiben
Es zerlegt jede Aufgabe per TDD und lässt den nächsten Schritt erst zu, wenn die Tests bestanden sind
Der Agent zeigt sogar Review-Kommandos an, wodurch Code Reviews leichter werden
Spec-Kit ist zu schwergewichtig, beads ist deutlich praktischer
Das vollständig vibe-basiert erstellte Projekt zmx habe ich später übrigens anhand des vom Agenten erzeugten Codes komplett neu geschrieben