Gute Last, schlechte Last – Die versteckten Kosten von Spec-driven Development

Ich hab in den letzten Monaten viel mit Spec-driven Development (SDD) Frameworks gearbeitet – auch bei der Entwicklung von klygl.kids. Dabei habe ich gemerkt, dass ich nach vielen Runden erschöpfter war als vorher. Das hat mich beschäftigt, und ich hab die Beobachtungen in einem eher technischen Artikel für den INNOQ-Blog ausgearbeitet.

Dieselbe Struktur, die mir in der Denkphase hilft, kann mich in der Bauphase ausbremsen. Dann baue ich nicht mehr. Ich manage, formuliere und dokumentiere.

Das Kernproblem ist nicht, dass dieses Vorgehen, erst die Anforderungen aufzuschreiben falsch ist. Es ist, dass es zwei sehr unterschiedliche Arten von Last erzeugt, je nachdem in welcher Phase man gerade steckt. In der Denkphase zwingt mich so ein Framework dazu, noch sehr diffuse Anforderungen sauber auszuarbeiten. Das ist gute Last – anstrengend, aber sinnvoll investiert. In der Bauphase dreht sich das aber. Statt am lebenden Code zu iterieren, versuche ich Intuition in Text zu pressen, bevor ich überhaupt etwas gebaut habe.

Was mich überrascht hat

Eine Story kann auf 1070 Zeilen wachsen, ohne dass das Verständnis mitwächst – Für ein simples Feature wurde eine Story mit 19 Akzeptanzkriterien, Datenbankfelder, Komponenten-Mapping, File-Listen und Test-Checklisten. Und irgendwann liest niemand mehr richtig. Statt das Feature selbst zu bauen, kämpft man sich durch Berge von Text.
Intuition lässt sich nicht vollständig vorab in Text übersetzen – Erfahrene Entwickler:innen spüren oft früh, welche Entscheidung in drei Schritten Probleme machen wird – ohne das vorher formulieren zu können. Wenn man mit KI-Agenten arbeitet, versucht man schnell, diese Lücke mit Dokumenten zu schließen. Aber der Wechsel aus dem Modus des Erkennens in den Modus des Erklärens kostet wahnsinnig viel Energie.
"Shared documents are not shared understanding" – Das ist ein Zitat von Jeff Patton, und das hat mich bei diesem Artikel eingeholt. In einem Teamprojekt haben andere meine ausführlichen Stories nicht als Diskussionsentwurf gelesen, sondern als fertiges Übergabedokument. Der Feedback-Loop wurde nicht kürzer, sondern länger – weil plötzlich Dinge auf dem Tisch lagen, die an dieser Stelle noch gar nicht entschieden werden mussten.