Lehren aus einer No-Code-Bibliothek: Spec-Driven Development ist kein Gleichungssystem, sondern ein Dreieck
(dbreunig.com)Im Zeitalter der AI-Coding-Agenten ist es ein falscher Blickwinkel, Spec-Driven Development einfach als lineare Gleichung „Spezifikation → Code“ zu verstehen.
Zentrale These
Spec-Driven Development ist keine statische Gleichung, sondern ein dynamisches Dreieck.
Eine Feedback-Schleife, in der sich drei Achsen ständig gegenseitig beeinflussen:
- Spezifikation (Spec)
- Code
- Tests
Diese drei Elemente müssen miteinander synchronisiert sein, damit es richtig funktioniert.
Wichtige Beispiele und Experimente
- Die codefreie Bibliothek whenwords von Drew Breunig
→ Ohne Code wurden nur die Spezifikation (Markdown) und 750 Tests (YAML) veröffentlicht, damit AI-Agenten den Code generieren
→ Aufmerksamkeit von Andrej Karpathy + über 1k Sterne auf GitHub + aktive Beiträge aus der Community
Doch in solchen Experimenten tritt immer wieder dasselbe Problem auf:
- Die Implementierung geht schnell, aber sobald die Komplexität nur leicht steigt, bricht an anderer Stelle etwas, wenn man einen Teil ändert
- Am Ende versanden die meisten Projekte unvollendet
- Selbst mit einer guten Spezifikation gibt es fortlaufend Diskussionen über die Art der Implementierung
Warum ein Dreieck?
Beim Schreiben von Code entdeckt man → Unklarheiten/Fehler in der Spezifikation → die Spezifikation wird korrigiert → neue Tests werden nötig → der Code wird erneut angepasst → …
→ weil dieser Prozess eine sich ständig wiederholende Schleife ist.
Vorgeschlagene Lösungsrichtung: das Tool Plumb
Das von Drew entwickelte CLI-Tool Plumb
- Analysiert bei jedem Git-Commit die Gesprächslogs der Agenten und die Codeänderungen
- Extrahiert Entscheidungen, die der Agent implizit getroffen hat → der Entwickler genehmigt sie
- Genehmigte Entscheidungen → automatische Aktualisierung der Spezifikation
- Liefert einen Bericht über Lücken bei Spezifikation/Test-Coverage
→ Im „Commit-Failure-Mode“ wird erzwungen, dass wichtige Entscheidungen immer von Menschen geprüft werden
Historischer Kontext
Wir erleben gerade erneut die „Softwarekrise“ der 1960er Jahre.
Damals wurde der Code so groß, dass man ihn nicht mehr vollständig im Kopf behalten konnte → Waterfall, Agile und CI/CD entstanden
Heute wird sogar das Lesen von Code unmöglich → es braucht neue Prozesse
→ Die These lautet, dass Tools wie Plumb eine Richtung dafür aufzeigen.
Fazit in einem Satz
Wir leben in einer Zeit, in der AI Code extrem schnell erzeugt,
aber die eigentliche Schwierigkeit besteht darin, das Dreieck aus Spezifikation, Code und Tests fortlaufend zu synchronisieren.
Noch keine Kommentare.