Spec-first wird als „Wasserfall mit Markdown“ verspottet. Manchmal zu Recht. Eine aufgeblähte Spec, die niemand liest, ist nur Verzögerung mit schönerer Formatierung. Aber die Kritik übersieht den Kern.
SDD und TDD sind keine konkurrierenden Methoden. Sie arbeiten auf verschiedenen Ebenen. TDD ist ein Loop auf Funktionsebene. SDD ist ein Loop auf Feature-Ebene. Wenn du mit KI baust, ist diese Unterscheidung wichtiger als jeder Parolenkrieg. Ein Test kann dir sagen, ob ein enger Codepfad funktioniert. Er kann einem Agent nicht sagen, wie sich ein Feature über Routen, Dateien, Datenmodelle und Edge Cases hinweg verhalten soll. Eine Spec kann das. Aber eine Spec schützt dich auch nicht vor fragilen Implementierungsdetails oder stillen Regressionen.
Deshalb lautet die sinnvolle Frage nicht „Was ist besser?“, sondern: Wann schlägt Test-first Spec-first, wenn du als Solo Builder schneller und mit weniger Bugs ausliefern willst?
Meine Antwort ist direkt. Nutze Spec-first, um Mehrdeutigkeit zu beseitigen. Nutze Test-first, um Fragilität zu beseitigen. Wenn du mit TDD die Form eines unscharfen Features herausfinden willst, verschwendest du Zeit. Wenn du knifflige Logik mit SDD absichern willst, aber ohne Tests, lieferst du Bugs aus. Wenn du die größere Einordnung suchst, was Spec-driven Development ist, lies diese Aufschlüsselung von Spec-driven Development.
Inhalt
- SDD vs. TDD: Die eigentliche Debatte ist nicht, was besser ist
- Die Kern-Loops: Was TDD und SDD wirklich sind
- SDD vs. TDD: Der direkte Vergleich für Solo Builder
- Wann Test-first Spec-first schlägt
- Wann Spec-first der einzig gangbare Weg ist
- Ein hybrider Workflow für KI-gestützte Entwicklung
- Dein Spec- und Test-Tooling auswählen
SDD vs. TDD: Die eigentliche Debatte ist nicht, was besser ist
Die grundlegende Trennung ist einfach. TDD sorgt für Korrektheit. SDD sorgt für Klarheit.
Wenn du das ignorierst, landest du bei Scheindebatten. Du hörst „Specs werden zu früh eingefroren“, „Tests sind Zeremonie“, „Spec Drift killt die Velocity“ und „TDD ist verkehrt herum“. Das alles kann im falschen Kontext stimmen. Als allgemeine Regel taugt nichts davon.
Die Kritik reagiert auf schlechtes SDD
Die Gegenbewegung gegen Spec-first im Jahr 2026 hat einen Grund. Viele haben Markdown-Rituale erlebt, Prompts, die Tokens verbrennen, veraltete Pläne und riesige Specs, die eingefroren werden, bevor dir der Code überhaupt etwas beigebracht hat. Simon Willison hat dieses Problem aus der Perspektive des Explorierens deutlich angeprangert. Birgitta Böckelers Einteilung in spec-first, spec-anchored und spec-as-source ist wichtig, weil sie eine leichtgewichtige Planungshilfe von einem starren Source-of-Truth-Modell trennt. Thoughtworks Tech Radar, GitHub Spec Kit, Kiro, OpenSpec, Traycer, Vibe Kanban, BMAD und Addy Osmanis Spec-Format mit sechs Abschnitten zeigen alle in dieselbe Richtung. Die Frage ist nicht, ob du etwas aufschreibst. Die Frage ist, wie viel Struktur du hinzufügst, bevor die Struktur anfängt, gegen die Arbeit zu kämpfen.
Praxisregel: Wenn die Pflege deiner Spec länger dauert als der Bau des Features, ist aus Planung Ballast geworden.
Die eigentliche Wahl ist eine wirtschaftliche
Als Solo Builder brauchst du keine Ideologie. Du brauchst den schnellsten Weg zu etwas, das funktioniert und weiter funktioniert.
Das heißt, du fragst dich:
- Ist das Hauptrisiko Mehrdeutigkeit? Wenn ja, starte mit SDD.
- Ist das Hauptrisiko eine Regression? Wenn ja, starte mit TDD.
- Ist die Aufgabe zugleich breit und heikel? Nutze beides, nacheinander.
TDD ist Jahrzehnte älter als die aktuelle SDD-Welle. Kent Beck machte TDD in der Ära von Extreme Programming populär, und sein Buch von 2003 machte Red, Green, Refactor weithin bekannt. Martin Fowler merkt an, dass modernes Spec-driven Development noch ein junger Begriff ist, dessen Definition sich weiter bewegt. Deshalb bleibt TDD die ältere, etabliertere Leitplanke, wenn die Anforderungen schon stabil sind, während SDD früher Wert stiftet, solange die Anforderungen noch unscharf sind, wie Fowler in seiner Erkundung von SDD-Tools und ihrer Geschichte darlegt.
Die Kern-Loops: Was TDD und SDD wirklich sind
Zieh das Branding ab, und beide Methoden sind einfach Loops. Sie beantworten unterschiedliche Fragen.
TDD ist ein Loop für Code-Design
TDD ist der klassische Zyklus Red, Green, Refactor.
- Red. Schreib einen fehlschlagenden Test.
- Green. Schreib den minimalen Code, damit er besteht.
- Refactor. Räum das Design auf, ohne das Verhalten zu ändern.
Dieser Loop ist absichtlich klein. Er zwingt dich, aus Sicht des aufrufenden Codes zu denken. Was soll diese Funktion tun? Was soll dieses Objekt zurückgeben? Wie soll sich dieser Edge Case verhalten? Du entwirfst kein Produkt-Briefing. Du formst Code unter dem Druck ausführbarer Checks.
Der unterschätzte Teil von TDD ist der Designdruck. Gute Tests schieben dich zu kleineren Nahtstellen, weniger versteckten Abhängigkeiten und Code, den du später ohne Angst ändern kannst.
SDD ist ein Loop für Klarheit bei der Ausführung
SDD ist ein anderer Loop. Die einfache Version lautet Spec, Execute, Validate.
Du definierst das Feature, bevor du einen Agent loslaufen lässt. Nicht nur den Happy Path. Scope-Grenzen. Akzeptanzkriterien. Dateien, die sich wahrscheinlich ändern. Einschränkungen. Was ausdrücklich nicht zum Scope gehört.
Dann setzt der Agent gegen diese Form um. Dann prüfst du das Ergebnis gegen die Spec.
Deshalb funktioniert SDD gut für Feature-Arbeit über mehrere Dateien. Eine ordentliche Spec gibt einem KI-Coding-Agent etwas viel Besseres als einen vagen Prompt. Sie gibt dem Modell Absicht, Grenzen und ein Ziel.
So denkst du den Unterschied am einfachsten:
- TDD fragt: Verhält sich diese Einheit korrekt?
- SDD fragt: Bedeutet dieses Feature das, was ich denke?
Ein fehlschlagender Test ist ein scharfes lokales Signal. Eine gute Spec ist ein breites Koordinationssignal.
Wenn du als Solo Builder mit Cursor, Claude Code, Codex oder Gemini arbeitest, ist dieser Unterschied riesig. Der Agent scheitert meist nicht, weil er keinen Code tippen kann. Er scheitert, weil du ein Feature ohne klare Grenzen angefragt hast.
SDD vs. TDD: Der direkte Vergleich für Solo Builder
SDD vs. TDD: Entscheidungsmatrix für Solo Builder
| Kriterium | Test-driven Development (TDD) | Spec-driven Development (SDD) |
|---|---|---|
| Hauptfokus | Verhalten von Funktionen, Klassen, Modulen | Feature, Workflow, Verhalten über Dateien hinweg |
| Bester Feedback-Loop | Sofortiger, ausführbarer Korrektheits-Check | Frühe Klarheit, bevor die Umsetzung beginnt |
| Funktioniert am besten, wenn | die Anforderungen schon stabil sind | die Anforderungen noch mehrdeutig sind |
| KI-Tauglichkeit | Gut, um die Umsetzung zu härten und gegen Regressionen abzusichern | Besser für den ersten Durchlauf eines Agents bei nicht trivialen Features |
| Aufwand vorab | Geringer, wenn die Form des Codes klar ist, verschwendet, wenn du noch explorierst | Höher am Anfang, aber oft billiger als ein Agent, der sich im Kreis dreht |
| Pflegeaufwand | Tests können fragil werden, wenn sie an Interna hängen | Specs können driften, wenn sie zu detailliert sind oder nicht aktualisiert werden |
| Passt am besten zum Zustand der Codebase | Refactoring, Bibliotheken, Bugfixes, bestehende Logik | Neue Features, Feature-Ergänzungen in Brownfield-Code, Änderungen über mehrere Dateien |
Was zählt, wenn du allein arbeitest
Mit einem vollständigen Team könntest du dir mehr Zeremonie leisten. Das hast du aber nicht. Also muss der Vergleich praktisch sein.
TDD gewinnt bei der Granularität. Es liefert dir schnell die Wahrheit. Ein Test schlägt fehl oder besteht. Deshalb ist es hervorragend für Bibliotheksdesign, Parsing-Logik, Abrechnungsregeln, Datentransformationen und Bugfixes. Du ziehst den Code genau an der Naht fest, an der er brechen kann.
SDD gewinnt bei der Koordination. Es ist besser, wenn sich die Arbeit über Routen, Handler, Schemas, UI und Persistenz verteilt. Ein Feature kann fünf Dateien, zwei Edge Cases und eine Migration berühren. Wenn du zuerst Unit-Tests schreibst, weiß der Agent trotzdem nicht, was du mit „Team-Einladungen hinzufügen“ oder „Entwürfe veröffentlichen können“ meinst.
Als Solo Builder musst du dich auch um den Pflegeaufwand kümmern.
- Last bei TDD: fragile Mocks, zu eng festgelegte Interna, mühsame Testpflege, wenn du auf der falschen Ebene testest.
- Last bei SDD: veraltete Docs, überdetaillierte Specs, Scheinpräzision, tokenhungrige Loops.
Der Tausch lohnt sich nur, wenn die Methode mehr Risiko beseitigt, als sie hinzufügt.
Ein guter Standard sieht so aus:
- Greif zu TDD, wenn du das Verhalten schon verstehst und Vertrauen in die Umsetzung brauchst.
- Greif zu SDD, wenn du das Problem nur grob verstehst und einen besseren ersten Wurf von der KI brauchst.
- Greif zu beidem, wenn ein Feature oben breit und unten scharf ist.
Deshalb ist auch die gängige Gegenüberstellung „SDD vs. TDD“ leicht schief. Sie behandelt die beiden als Ersatz füreinander. Das sind sie nicht. Sie bauen aufeinander auf.
Wann Test-first Spec-first schlägt
Eine gute Spec schützt dich nicht vor schwachem Code. Tests schon.
Nutze TDD, wo Fehler lokal und teuer sind
TDD schlägt Spec-first, wenn der schwierige Teil nicht „Was bauen wir?“ ist, sondern „Übersteht dieser Code Veränderungen?“.
Das heißt meistens:
- Alten Code refactoren, wo du ein Sicherheitsnetz brauchst, bevor du schneidest.
- Bibliotheken oder APIs entwerfen, wo der Vertrag wichtiger ist als die UI drumherum.
- Dichte Geschäftslogik umsetzen, etwa Preise, Berechtigungen, Transformationen oder Zustandsregeln.
- Regressionen beheben, wo die erste Aufgabe ist, den Bug zu reproduzieren und seine Rückkehr zu verhindern.
Hier glänzt Test-first. Du zwingst den Vertrag in eine ausführbare Form, bevor du die Umsetzung anfasst. Dieser Druck verbessert die Form des Codes.
Ein kontrolliertes Experiment, das TDD mit Test-last-Entwicklung verglich, berichtete statistisch signifikante Verbesserungen bei den Ergebnissen der statischen Codeanalyse zugunsten von TDD, darunter geringere zyklomatische Komplexität, kürzere Methoden und höhere Kohäsion. Dieselbe Quelle empfiehlt, in Greenfield-Projekten die Testabdeckung von neuem Code bei etwa 80 bis 100 % als praktisches Qualitätsziel zu tracken, laut dem ACM-Paper zu den Ergebnissen der TDD-Praxis.
Das wirtschaftliche Argument für Test-first
Es gibt auch ein schlichtes Kostenargument.
Das Systems Sciences Institute von IBM berichtet seit Langem, dass Defekte in Produktion etwa 15-mal teurer zu beheben sind als während des Designs und nach dem Release bis zu 100-mal teurer. Diese alte Kostenkurve für Defekte ist immer noch einer der klarsten Gründe, warum Test-first Spec-first schlagen kann, wenn das Hauptrisiko die Korrektheit der Umsetzung ist, wie dieser TDD-Hintergrund zur Ökonomie von Defekten zusammenfasst.
Das zählt noch mehr, wenn die KI einen großen Teil des ersten Entwurfs schreibt. Das Modell kann schnell plausiblen Müll erzeugen. Ein Test fängt ihn an der Grenze der Einheit ab, bevor der Bug teuer wird.
Dieses Video würde ich den meisten empfehlen, die ihr TDD-Gespür an echtem Code schärfen wollen:
Wenn du das korrekte Verhalten einer Einheit präzise beschreiben kannst, solltest du den Test meistens schreiben, bevor du den Code anfasst.
Wann Spec-first der einzig gangbare Weg ist
Ein Feature, das du nicht verstehst, kannst du nicht per Test vorantreiben.
AI Agents brauchen Grenzen, keine Vibes
Das ist der Teil, den TDD-Purismus gern überspringt. Wenn du einen AI Agent ein Feature bauen lässt, das sich über Routen, Daten, UI und Seiteneffekte erstreckt, reicht ein Unit-Test nicht, um die Arbeit zu steuern. Das Modell braucht Absicht.
Deshalb ist Spec-first oft der einzig gangbare Weg für:
- Brownfield-Features, die quer zu bestehenden Annahmen liegen
- Änderungen über mehrere Dateien, bei denen Benennung, Scope und Grenzen zählen
- Neue Workflows, bei denen Akzeptanzkriterien wichtiger sind als die interne Umsetzung
- Erste Entwürfe durch Agents, bei denen vage Prompts Nacharbeit erzeugen
Die stärksten verfügbaren Quellen zu KI-gestützter Entwicklung sehen Spec-first als den richtigen Einstieg und empfehlen gerade so viel Strenge in der Spec, wie nötig ist, um Mehrdeutigkeit zu beseitigen, während sie TDD weiterhin als wertvoll für Korrektheit und gegen Regressionen betrachten. Das ist für Solo Builder die zentrale Entscheidungslücke, und Augments Leitfaden macht diesen Trade-off in seiner Darstellung von Spec-driven Development für KI-gestützte Arbeit deutlich.
Ein Reddit-Thread in r/LLMDevs mit dem Titel „specs beat prompts“ fängt die Realität im Feld gut ein. Builder stoßen immer wieder auf dasselbe Problem. Der Agent hängt nicht an der Syntax fest. Er rät, weil die Anfrage zu vage war. Dieser Thread zählt, weil er genau die Lücke beschreibt, die TDD nicht füllt. Tests können Codepfade validieren. Sie definieren nicht die Produktgrenze für eine Änderung in Feature-Größe.
Spec-first heißt nicht schwerfälliger Prozess
Der Fehler passiert, wenn jemand „schreib zuerst eine Spec“ hört und sich ein riesiges PRD vorstellt, das niemand aktualisiert.
Mach das nicht.
Für Solo Builder ist eine nützliche Spec kurz und scharf. Sie sagt:
- was dieses Feature tut
- was es nicht tut
- welche Dateien oder Systeme es berührt
- welche Akzeptanzkriterien zählen
- was als fertig gilt
Wenn du befürchtest, dass Spec-Arbeit zu Overhead wird, ist die Sorge berechtigt. Spec-Arbeit wird häufig übertrieben. Die Lösung ist nicht, Specs aufzugeben, sondern sie so weit zu kürzen, dass sie Mehrdeutigkeit beseitigen, ohne zu einer zweiten Codebase zu werden. Mir gefällt die Einordnung in Tekks Beitrag darüber, wann Specs zur Produktivitätsfalle werden und wann sie helfen.
Ein hybrider Workflow für KI-gestützte Entwicklung
Die besten Builder wählen keine Religion. Sie wählen eine Reihenfolge.
Ein praktischer Loop, der wirklich ausliefert
Das ist der Workflow, den ich für die meiste KI-gestützte Produktarbeit nutzen würde.
- Schreib eine kleine Spec für das Feature. Scope, Einschränkungen, Akzeptanzkriterien, was nicht dazugehört.
- Gib diese Spec dem Agent. Cursor, Claude Code, Codex, Gemini. Spielt kaum eine Rolle.
- Prüf den ersten Durchlauf auf Feature-Ebene. Stimmt der Ablauf? Hat er die richtigen Stellen angefasst?
- Zoom auf riskante Logik. Preise, Berechtigungen, Retries, Parsing, Synchronisierung, Zustandsübergänge.
- Wende dort TDD an. Füg fehlschlagende Tests hinzu, zieh die Umsetzung fest, refactore sicher.
- Prüf das Feature erneut. End-to-End-Verhalten, Edge Cases, Regressionen.
So bekommst du das Beste aus beiden. SDD sagt dem Agent, was er bauen soll. TDD sagt dem Code, wie er nicht kaputtgeht.
Wenn du dir auch das größere Ökosystem rund um Agents und Produktarbeit anschaust, liefert dieser Überblick über KI-Tools für individuelle Web-Apps nützlichen Kontext, weil er zeigt, wie viele Builder inzwischen gemischte Stacks zusammenstellen, statt sich auf einen einzigen monolithischen Workflow zu verlassen.
Brownfield-Arbeit braucht einen lockereren Griff
Brownfield-Codebases brauchen noch mehr Fingerspitzengefühl. Eine aktuelle Forschungsarbeit unterscheidet spec-first, spec-anchored und spec-as-source und sagt ausdrücklich, dass spec-first am besten für die KI-gestützte Erstentwicklung ist, während spec-anchored besser zu langlebigen Produktivsystemen passt. Diese Unterscheidung ist wichtig, weil bestehende Systeme starre Top-down-Specs meist nicht ohne Reibung vertragen, wie die Forschung zum Spec-Spektrum für Brownfield-Systeme darlegt.
Also: Überreagier nicht.
Für eine laufende Codebase willst du meist nicht überall „die Spec ist die Source of Truth“. Du willst genug Spec, um den Agent zu führen, und genug Tests, um das Verhalten zu verteidigen. Das ist spec-anchored gedacht. Es ist leichter, haltbarer und verrottet viel seltener.
Der reife Schritt ist nicht, TDD durch SDD zu ersetzen, sondern mit SDD die Arbeit einzurahmen und TDD dort einzusetzen, wo dir der Code wehtun kann.
Dein Spec- und Test-Tooling auswählen
Tools sind weniger wichtig als die Passung. Trotzdem erzeugen schlechte Tool-Entscheidungen schnell Ballast.
Wähle Test-Tools nach Sprache und Reife
Für TDD nimm die langweiligen Standards.
- JavaScript und TypeScript: Jest oder Vitest
- Python: Pytest
- Ruby: RSpec
Diese Tools sind ausgereift, gut verstanden und für genau den engen Loop gebaut, den TDD braucht. Werd hier nicht kreativ. Dein Test-Stack ist nicht der Ort für Experimente.
Es gibt auch echte laufende Arbeit daran, die Testseite der KI-Umsetzung zu automatisieren. Ein TDD-Bench-Paper von 2024 berichtet, dass Auto-TDD auf SWT-bench Lite eine Fail-to-Pass-Rate von 21,7 % erreichte und damit das bisher beste System übertraf. Das zeigt, wie aktiv daran gearbeitet wird, testgetriebene Loops besser mit Agents zusammenzubringen, laut dem TDD-Bench-Paper.
Wähle Spec-Tools danach, wie du mit Agents arbeitest
Für SDD ist der Markt jünger und weniger gefestigt.
Es gibt ein paar grobe Kategorien:
- Workflow-Kits wie GitHub Spec Kit, die dir eine Struktur für Spec, Plan und Tasks geben.
- IDE-native Ansätze wie Kiro oder die Planungs-Workflows in Cursor.
- Offene Konventionen wie OpenSpec und Projektregeln im Stil von AGENTS.md.
- Manuelle, leichtgewichtige Docs, wenn deine Features klein und deine Agent-Prompts diszipliniert sind.
Von Spec-Tooling willst du keine Magie. Du willst Struktur, die deine Codebase kennt. Dateipfade. Akzeptanzkriterien. Einschränkungen. Notizen dazu, was nicht zum Scope gehört. Einen wiederholbaren Weg, dem Modell Kontext zu übergeben.
Wenn deine Specs schwach sind, driften deine Ergebnisse. Wenn deine Specs aufgebläht sind, hörst du auf, sie zu pflegen. Deshalb sind Akzeptanzkriterien der Teil, den ich nie weglassen würde. Wenn du dafür einen schärferen Maßstab brauchst, nutze diesen Leitfaden zu Akzeptanzkriterien für User Stories.
Marc Brookers Folge bei SE Radio über Spec-driven KI-Entwicklung lohnt sich ebenfalls, wenn du einen Blick aus Richtung formaler Methoden willst. Seine Einordnung hilft, weil sie die Diskussion über „besser prompten“ hinaus zu expliziter Absicht schiebt. Kent Beck liefert dir weiterhin die kanonische TDD-Grundlage. Zwischen diesen beiden Polen ist die praktische Antwort offensichtlich. Nutze Specs, um Feature-Arbeit zu führen. Nutze Tests, um die Teile zu beweisen, auf die es ankommt.
Wenn du Hilfe dabei willst, die Spec-Ebene richtig hinzubekommen, probier Tekk.coach aus. Seine Loops schreiben Specs für dich aus dem, was sich in deinem Code geändert hat – der Testing-Loop meldet riskantes geändertes Verhalten ohne Tests –, und die Akzeptanzkriterien schließen die Spec beim Merge des PR. Eine Spec von Hand zu schreiben ist der manuelle Weg auf dasselbe Board.
Teil des Leitfadens zu Spec-driven Development – ein ehrliches Playbook dafür, mit KI-Coding-Agents auszuliefern. Die andere Hälfte ist Loop Engineering: An der Spec erkennt ein Loop, dass er fertig ist.