SDD Sind Nicht Drei Tools — Es Ist ein Stack von Acht Phasen
Martin Fowlers Artikel über SDD-Tools ist lesenswert. Fowler hat eine seltene Fähigkeit, Dinge präzise zu benennen, und seine Rahmung der spec-getriebenen Entwicklung als Antwort auf das "Context Collapse"-Problem bei KI-gestützter Programmierung ist die klarste Artikulation des Kernproblems, die ich je gedruckt gesehen habe.
Aber die Analyse hält bei drei Tools an. Und dieser Haltepunkt verschleiert, was SDD in der Praxis schwierig macht.
Was Fowler Richtig Macht
Fowler identifiziert die drei Tools, auf die die meisten SDD-Implementierungen konvergieren: ein Spec-Format, einen Validierungsmechanismus und ein Genehmigungsportal. Er hat Recht, dass diese drei Primitive notwendig sind. Eine Spec ohne Validierung ist eine Wunschliste. Validierung ohne Genehmigungsportal produziert Chaos — Agenten, die halb genehmigte Anforderungen implementieren und dann zurückrudern.
Seine Beobachtung, dass sich der Engpass von der Code-Generierung zur Korrektheitsprüfung verlagert hat, ist ebenfalls zutreffend und unterbewertet. Das Problem ist nicht, dass KI-Agenten langsam schreiben. Das Problem ist, dass sie selbstsicher in die falsche Richtung schreiben, wenn Anforderungen unklar sind — und niemand bemerkt es, bis die Funktion ausgeliefert wird.
Wo der Drei-Tool-Rahmen zu Kurz Greift
Die drei Tools, die Fowler beschreibt — spec, validieren, genehmigen — decken die Implementierungsschleife ab. Sie decken nicht ab, was davor passiert, oder was danach passiert.
Vor der Implementierung gibt es ein Problem. Ein Entwickler hat eine Idee. Diese Idee muss externalisiert (Brainstorming), in Abnahmekriterien strukturiert (Spec), adversarial auf Vollständigkeit geprüft (Challenge) und auf Implementierungsbereitschaft überprüft werden, bevor ein Agent Code anfasst (Bereitschaftsprüfung). Diese vier Phasen passieren vor dem Genehmigungsschritt, und das Überspringen ist der Grund, warum Specs am Genehmigungsportal ankommen mit Kriterien, die zu vage sind, um korrekt implementiert zu werden.
Nach dem Merge gibt es ein anderes Problem. Code, der zum Zeitpunkt des Merges die Abnahmekriterien erfüllt, kann Wochen später von der Spec abweichen, wenn angrenzende Änderungen sich ansammeln. Fowlers drei Tools haben dazu nichts zu sagen. Der Genehmigen-Validieren-Zyklus endet beim Merge.
Die Acht Phasen
Ein vollständiger SDD-Lebenszyklus hat acht Phasen:
1. BRAINSTORM → die Idee erfassen, bevor sie sich auflöst
2. SPEC → sie in testbare Abnahmekriterien strukturieren
3. CHALLENGE → die Spec adversarial auf Lücken und Widersprüche prüfen
4. READINESS CHECK → verifizieren, dass die Spec implementierbar ist, bevor mit dem Codieren begonnen wird
5. APPROVE → Mensch unterschreibt den Vertrag
6. IMPLEMENT → Agent führt gegen die Spec aus
7. VALIDATE → Implementierung gegen jedes Kriterium prüfen
8. HEAL → Drift nach dem Merge rückwirkend erkennen und korrigierenFowlers drei Tools entsprechen den Phasen 5, 6 und 7. Das lässt fünf Phasen unbedeckt.
Die Phasen, die Teams am häufigsten überspringen, sind Phase 3 (Challenge) und Phase 8 (Heal). Das Überspringen von Challenge bedeutet, dass Abnahmekriterien mit versteckten Mehrdeutigkeiten zur Genehmigung kommen, die erst während der Implementierung auftauchen. Das Überspringen von Heal bedeutet, dass Drift sich still nach dem Merge ansammelt, und die Spec wird zu einem historischen Artefakt statt einem lebenden Vertrag.
Warum Das für die Tool-Auswahl Wichtig Ist
Wenn Sie SDD-Tools bewerten, indem Sie fragen "hat es ein Spec-Format, einen Validierungsmechanismus und ein Genehmigungsportal", besteht fast jedes Tool in der aktuellen Landschaft. Das ist die falsche Frage.
Die richtige Frage lautet: Welches Tool deckt alle acht Phasen ab, und welche Phasen erfordern manuelle Eingriffe?
Ein Tool, das die Phasen 5–7 aber nicht 1–4 abdeckt, zwingt Entwickler, den Workflow vor der Implementierung außerhalb des Tools zu verwalten. Die Challenge- und Bereitschaftsprüfungsphasen — die genau dazu dienen, das zu erkennen, was Menschen verpassen — fehlen.
Ein Tool, das die Phasen 5–7 aber nicht Phase 8 abdeckt, behandelt den Merge als das Ende des Lebenszyklus. Für langlebige Codebases mit häufigen angrenzenden Änderungen ist dies eine erhebliche Lücke.
Fowlers Rahmen Ist Immer Noch Nützlich
Nichts davon ist eine Kritik an Fowlers Analyse. Der Drei-Tool-Rahmen ist eine genaue Beschreibung des minimalen SDD-Workflows. Für Teams, die SDD zum ersten Mal einsetzen, sind die Phasen 5, 6 und 7 der richtige Ausgangspunkt — sie liefern den größten Wert mit dem geringsten Aufwand.
Der Rahmen wird zur Decke, wenn Teams versuchen zu skalieren. Bei höherer Geschwindigkeit, mit parallelen Agenten und langlebigen Specs erzeugen die Phasen außerhalb des Drei-Tool-Fensters die Reibung, die den Durchsatz begrenzt.
Der Vollständige Stack
SDD-Tooling ist keine Feature-Checkliste. Es ist eine Pipeline. Die Frage ist nicht, ob ein Tool Spec-Support hat — es geht darum, ob das Tool die Pipeline von Ende zu Ende abdeckt, einschließlich der Phasen, die die meisten Analysen ignorieren.
Vom Brainstorm bis zum Heal, ohne Lücken.
Weiterführende Lektüre: Weitere Artikel über spec-getriebene Entwicklung · Autonomer Modus: SDD von Ende zu Ende mit /autonomous-sdd · Planu vs SDD-Tools