Die meisten Ratschläge zu SDD setzen immer noch ein Team voraus, jemanden, der den Prozess verantwortet, und Zeit für Zeremonie. Deshalb sind so viele, die selbst bauen, daran abgeprallt. Wenn dein erster Kontakt mit Spec-driven Development ein riesiges Markdown-Template war, ein belehrender Workflow oder ein Repo voller veralteter Docs, ist der Gegenwind nachvollziehbar. „Wasserfall mit Markdown“ ist eine faire Beleidigung, wenn die Spec nie den Code berührt, der Agent sie sowieso ignoriert und du mehr Zeit mit dem Pflegen von Aufgaben verbringst als mit dem Ausliefern.
Aber der Gegenwind übersieht auch, was sich verändert hat. 2026 hörte SDD auf, eine starre Methode zu sein, und wurde zu einer breiten Palette von Tools mit unterschiedlichen Trade-offs, unterschiedlichen Schwerpunkten im Workflow und unterschiedlich viel Kontrolle. Für Solo Founder zählt das mehr als die Ideologie. Du brauchst kein Prozesstheater. Du brauchst einen Weg, deinen Coding-Agent davon abzuhalten, in Teile der App zu wandern, die er nie anfassen sollte.
Das ist der nützliche Rahmen für Die Framework-Landschaft: Wo SDD-Tooling 2026 steht. Nicht: „Solltest du in irgendeinem doktrinären Sinn Spec-first werden?“ Die eigentliche Frage ist einfacher. Welche Art von Spec-Workflow verringert neue Versuche, hält den Scope eng und hilft dir, das nächste Feature auszuliefern, ohne die Codebase zu ruinieren? Wenn dir Zuverlässigkeit, Prüfbarkeit und vernünftige Übergaben wichtig sind, ist sogar der angrenzende Rat in den SDLC-Security-Erkenntnissen von Digital ToolPad relevant, denn schlampige Build-Prozesse und schlampige Übergaben an die KI scheitern meistens aus demselben Grund: Niemand hat die Grenzen klar definiert.
Wenn du schon gegen die Prompting Wall gelaufen bist, passt dazu unsere Analyse des Vibe-Coding-Problems und der Prompting Wall hinter der SDD-Welle.
Inhalt
- Der Gegenwind gegen SDD ist da – die Chance auch
- Was SDD 2026 wirklich ist
- Die Landkarte des SDD-Toolings 2026
- Die wichtigsten Frameworks im Detail
- Specs mit KI-Coding-Agents verbinden
- Praktische Einstiegswege für Solo Builder
- Deinen Stack wählen und das nächste Feature ausliefern
Der Gegenwind gegen SDD ist da – die Chance auch
Der Gegenwind kam nicht aus dem Nichts. Devs haben schwere Templates, aufgeblähte Prompts und starre Workflows ausprobiert. Dann haben sie zugesehen, wie Specs veralteten, während der Agent weiter seltsamen Code produzierte. Aus dieser Erfahrung folgt die naheliegende Reaktion: Das ist Overhead, der sich als Engineering ausgibt.
Der Gegenwind ist real
Simon Willisons allgemeinere Kritik daran, KI-Coding zu sehr zu vertrauen, lässt sich sauber auf den Missbrauch von SDD übertragen. Wenn du eine Spec wie Magie behandelst, verlierst du trotzdem. Birgitta Böckelers Analyse auf Martin Fowlers Seite ist hier hilfreich, weil sie nicht so tut, als sei jedes SDD gleich. Sie teilt das Feld in die Ansätze Spec-first, Spec-anchored und spec-as-source auf – eine viel bessere Linse als das übliche Geschrei „Pro-SDD gegen Anti-SDD“, nachzulesen in ihrer vergleichenden Analyse von Kiro, Spec Kit und Tessl.
Den Frust sieht man auch in Community-Threads. Der Reddit-Post über Spec-Kit-Müdigkeit beschreibt ein sehr verbreitetes Fehlerbild: Der Prozess fühlt sich im Verhältnis zur Arbeit zu schwer an, vor allem wenn du allein bist und einfach ein Feature ausliefern willst. Ein anderer Reddit-Thread über leichtere Frameworks wie Measure zeigt, warum kleinere Workflows Aufmerksamkeit bekommen. Wer selbst baut, will genug Struktur, um den Agent zu führen – nicht so viel, dass Backlog-Management wie im Konzern wiederauferstehen muss.
„Wasserfall mit Markdown“ sitzt, wenn die Spec zu einem Artefakt wird, das bei der Implementierung niemand nutzt.
Warum die Chance trotzdem besteht
Der entscheidende Punkt: Die besten Workflows von 2026 versuchen nicht, Anforderungen einzufrieren. Sie versuchen, das Verhalten eines Agents einzugrenzen. Das ist ein anderer Job.
Thoughtworks hat Spec-driven Development auf seinen Radar gesetzt, weil Teams Specs als operativen Vertrag zwischen menschlicher Absicht und der Ausführung durch den Agent nutzten, nicht als nostalgische Rückkehr zu Anforderungen alter Schule. GitHub hat Spec Kit in seinem Launch-Post zum Open-Source-Toolkit ähnlich eingeordnet. Es geht nicht um Dokumentenanbetung. Es geht darum, KI-Output prüfbar zu machen, bevor er zum Schaden im Repo wird.
Wer als Founder allein arbeitet, versteht diesen Trade-off sofort:
- Schlechte Zeremonie: Docs schreiben, die der Agent ignoriert.
- Nützliche Struktur: Grenzen definieren, über die der Agent nicht gefahrlos hinausimprovisieren kann.
- Schlechtes Tempo: vage Prompts durchhetzen und die Arbeit dreimal neu machen.
- Nützliches Tempo: vorab etwas länger investieren und das Neuschreiben vermeiden.
Deshalb ist die Chance noch da. Nicht weil die Kritik falsch ist. Sondern weil sie oft eine schlechte Umsetzung einer nützlichen Idee beschreibt.
Was SDD 2026 wirklich ist
Modernes SDD ist kein riesiges Anforderungsdokument. Es ist ein strukturiertes Briefing, nach dem ein AI Agent handeln kann und das du prüfen kannst, bevor Code in Bewegung gerät.
Es sind nicht die alten Anforderungsdokumente
Ein Update zur Kategorie aus dem Jahr 2026 berichtete von 863 % Wachstum bei den GitHub-Sternen für ein Framework, während ein anderes um 18 % wuchs, und das breitere Feld des KI-Codings umfasste am 16. Mai 2026 bereits zehn verschiedene KI-Coding-Tools in drei Architektur-Lagern, so der YouTube-Marktüberblick zur Beschleunigung der Kategorie. So ungleiches Wachstum verrät etwas Praktisches. Wer baute, übernahm keine „Dokumentation“. Übernommen wurden Tools, die agentgetriebene Arbeit besser steuerbar machten.
Der Kern-Loop, der sich durchgesetzt hat, ist einfach:
- Specify: Ergebnis und Grenzen festlegen.
- Plan: den technischen Ansatz planen.
- Tasks: die Arbeit in Einheiten zerlegen, die der Agent bewältigen kann.
- Implement: umsetzen, mit einem Review zwischen jedem Schritt.
Dieser Loop ist wichtig, weil er den Job des Menschen verändert. Du hörst auf, dich wie ein Live-Prompt-Automat zu verhalten. Du fängst an, als Reviewer mit Checkpoints zu arbeiten.
Die drei Dinge, die Leute mit SDD meinen
Böckelers Taxonomie ist der sauberste Weg durch den Lärm:
| Modell | Was es in der Praxis bedeutet | Passt gut zu | Typisches Scheitern |
|---|---|---|---|
| Spec-first | Die Spec startet die Arbeit | Neuen Features | Zu viel Zeremonie, wenn das Feature winzig ist |
| Spec-anchored | Die Spec bleibt an Codeänderungen und Entscheidungen gebunden | Brownfield-Arbeit | Drift, wenn niemand die Ankerpunkte aktualisiert |
| spec-as-source | Die Spec erzeugt generierte Artefakte direkt | Stark strukturierten Domänen | Kann sich außerhalb enger Workflows starr anfühlen |
Für Solo Builder ist Spec-anchored oft der Sweet Spot. Du willst keinen formalen Prozess betreiben. Du gibst Claude Code, Cursor oder Gemini genug Kontext, damit sie aufhören, auf eigene Faust loszulegen.
Addy Osmanis Spec-Stil mit sechs Abschnitten passt auch gut zu dieser Realität. Er ist leicht genug, um ihn wirklich zu nutzen, aber strukturiert genug, um die Übergabe vernünftig zu halten. Du brauchst kein riesiges Template. Du brauchst Scope, Rahmenbedingungen, betroffene Dateien, Akzeptanzkriterien, Edge Cases und das, was ausdrücklich nicht gebaut wird.
Praxisregel: Wenn deine Spec dem Agent nicht sagen kann, was er nicht anfassen soll, ist sie wahrscheinlich zu vage.
Eine gute Spec von 2026 lebt während der Implementierung. Sie ist nicht eingefroren. Sie wird aktualisiert, wenn Annahmen nicht mehr halten. Das ist der Unterschied zwischen einem nützlichen Steuerungsdokument und einem toten Markdown-Relikt.
Die Landkarte des SDD-Toolings 2026
2026 war SDD keine einzelne Framework-Kategorie mit einem klaren Sieger mehr. Ein Überblick zählte über 120 agentische KI-Tools in 11 Kategorien und beschrieb den SDD-Kernablauf als Specify → Plan → Tasks → Implement mit menschlichen Checkpoints in jeder Phase, nachzulesen in StackOnes Feldbericht zu agentischen KI-Tools 2026.
Der Markt, aufgeteilt nach dem Ort des Workflows
Die nützliche Frage ist einfach: Wo soll die Arbeit nach Vorstellung des Tools stattfinden?
Eine technische Zusammenfassung von 2026 teilte den Stack in drei operative Schichten auf: Frameworks zum Schreiben von Specs, Tooling für Ausführung und Leitplanken sowie IDE- oder Agent-Integrationen, nachzulesen in diesem praktischen Überblick, wie Teams SDD-Tools nutzen. Diese Einteilung hält in der Praxis, besonders für Solo Builder, die keine Zeit haben, einen Prozess zu babysitten.
Das ist die Landkarte, auf die es ankommt:
- CLI-first-Frameworks wie GitHub Spec Kit und OpenSpec. Gute Sichtbarkeit im Repo, wenig Lock-in, leicht mit verschiedenen Modellen zu kombinieren.
- Umgebungen mit Leitplanken wie AWS Kiro. Mehr Durchsetzung des Workflows im Produkt selbst – hilfreich, wenn das Tool Schlamperei abfangen soll, bevor Code landet.
- IDE- und Agent-Workflows wie Claude Code und der Plan Mode von Cursor. Schnellerer Loop, weniger Zeremonie, aber mehr Druck, damit die Planung nicht in improvisiertes Prompting zerfällt.
- Methodenschichten wie BMAD. Leichter Prozess über deinem bestehenden Setup. Nützlich, wenn du Orientierung willst, ohne ein komplettes System zu übernehmen.
- Angrenzende Experimente wie Traycer und das inzwischen eingestellte Vibe Kanban. Vor allem deshalb relevant, weil sie zeigen, wie viel Bewegung in dieser Kategorie noch steckt.
Für Solo Founder zählt das mehr als das Branding. Du wählst den Schwerpunkt deiner Feature-Arbeit. Setzt du ihn an die falsche Stelle, fühlt sich jede kleine Änderung schwerer an als der Code selbst.
Wenn du das größere System rund um mehrstufige Agent-Arbeit sortierst, zeigt sich derselbe Designdruck in diesem Leitfaden zu Orchestratoren für Coding-Agents. SDD ist oft eine Schicht in einem größeren Setup, nicht das ganze Setup.
Worin jedes Lager gut ist
Wähl nach deinem häufigsten Fehlerbild.
| Lager | Stärke | Schwäche | Am besten für |
|---|---|---|---|
| CLI-first | Portabilität und klare Artefakte im Repo | Weniger Händchenhalten | Alle, denen Nachvollziehbarkeit wichtig ist und die Lock-in hassen |
| IDE-nativ | Enges Feedback und schnellere Iteration | Mehr Abhängigkeit von einem Editor oder Agent | Solo Builder, die interaktiv ausliefern |
| Framework-light | Wenig Zeremonie und schneller Einstieg | Weniger eingebaute Prüfungen | Founder, die gerade genug Struktur brauchen, um das Abdriften des Agents zu stoppen |
Der typische Fehler ist, zu viele Schichten zu stapeln, bevor sich die erste bewährt hat. Da kommen ein Spec-Framework, ein IDE-Planer, ein Task-Board und ein eigenes Prompt-Paket zusammen. Dann dauert es bei einfacher Arbeit länger, sie aufzusetzen, als sie zu bauen.
Fang mit einem einzigen Workflow-Schwerpunkt an. Füg eine zweite Schicht erst hinzu, wenn du die fehlende Kontrolle in einfachen Worten benennen kannst. Für Indie-Teams heißt das meistens: Entweder mit einem CLI-first-Flow für Klarheit im Repo oder mit einem IDE-nativen Flow für Tempo beginnen und Leitplanken erst ergänzen, wenn Drift zum wiederkehrenden Problem wird.
Die wichtigsten Frameworks im Detail
Das aktuelle Feld ergibt mehr Sinn, wenn du nicht mehr fragst „Welches ist das beste?“, sondern „Welchen Schmerz will dieses Tool beseitigen?“
GitHub Spec Kit
Spec Kit ist nicht ohne Grund zum Bezugspunkt geworden. Es ist klar, strukturiert und hat eine deutliche Meinung dazu, wie man von der Absicht über den Plan zu ausführbaren Aufgaben kommt. Außerdem profitiert es davon, dass es sich wie Infrastruktur anfühlt und nicht wie ein geschlossenes Produkt.
Trotzdem sind die Beschwerden real. Im Reddit-Thread über Spec-Kit-Müdigkeit klingt der Ton vertraut: Viele mögen die Klarheit, aber manche fühlen sich unter dem Gewicht der Templates begraben, wenn die Aufgabe klein ist. Das ist das Fehlerbild. Es kann sich bei einem einfachen Feature anfühlen, als würdest du ein Beschaffungsverfahren aufsetzen.
Passt gut, wenn:
- du eine modellunabhängige CLI-Schicht willst
- dir Portabilität wichtig ist
- du explizite Artefakte im Repo willst
Passt schlecht, wenn:
- du minimales Setup willst
- du den ganzen Tag an winzigen Änderungen arbeitest
- du weißt, dass du die Docs nicht pflegen wirst
AWS Kiro
Kiro steht für den gegenteiligen Instinkt: mehr Intelligenz und mehr Leitplanken in die Umgebung selbst. Das kann großartig sein, wenn das Tool Aufgabengrenzen und Abnahmeprüfungen näher an der Implementierung durchsetzen soll.
AWS hat Kiro als Mittel gegen KI-Slop vermarktet. GeekWires Berichterstattung über das Produkt konzentrierte sich auf Anforderungsanalyse und Spec-Check-ins, und das zeigt genau, wo es im Markt steht. Es ist für alle, die wollen, dass das Tool beim Überwachen des Workflows hilft, statt nur Dateien zu generieren.
Der Trade-off liegt auf der Hand:
- Stärke: stärkere Führung im Tool
- Schwäche: mehr Sogwirkung des Ökosystems und Lock-in-Risiko
Wenn du ohnehin in dieser Welt lebst, kann es sich stimmig anfühlen. Wenn dir ein portabler Workflow wichtig ist, kann es sich schnell einengend anfühlen.
Eine IDE mit Leitplanken ist nützlich, wenn dein größtes Problem ist, dass der Agent zu viel macht. Weniger nützlich ist sie, wenn dein größtes Problem ist, überhaupt klar über das Feature nachzudenken.
OpenSpec und BMAD
OpenSpec und BMAD sprechen das Anti-Zeremonie-Lager aus gutem Grund an. Sie sind leichter. Sie versuchen nicht, dir das Gefühl zu geben, du seist einer Methodik-Zunft beigetreten. Das ist attraktiv, wenn du vor allem ein verlässliches Gerüst für die Planung brauchst und kein komplettes Betriebssystem für die Softwareauslieferung.
Vor allem BMAD kommt bei Foundern gut an, die ein funktionierendes Muster wollen, das sie anpassen können. OpenSpec spricht dich an, wenn du eine offene Schicht im Stil eines Frameworks willst, ohne eine größere Plattform zu schlucken.
Das Risiko bei beiden ist, zu wenig zu spezifizieren. Ein leichterer Prozess funktioniert nur, wenn du trotzdem scharfe Grenzen schreibst. Wenn aus „leichtgewichtig“ „vage“ wird, rät der Agent gleich wieder.
Claude Code und Cursor im Stack
Claude Code und Cursor sind keine reinen SDD-Frameworks, aber in der Praxis wichtige Teile des Stacks. Hier spüren viele den Wert einer guten Spec, weil diese Tools den Unterschied zwischen einer klar begrenzten Aufgabe und einem schlampigen Prompt sofort offenlegen.
Die Reddit-Diskussion, die Spec-driven Development rund um Spec Kitty „das neue Vibe Coding“ nennt, fängt diesen Übergang gut ein. Viele übernehmen SDD nicht als Doktrin. Sie lernen einfach, dass Planung innerhalb des Workflows besser ist, als jede Anfrage im Chatfenster zu improvisieren.
Keins der beiden Tools löst schlechte Specs für dich. Sie machen gute Specs wertvoller.
Specs mit KI-Coding-Agents verbinden
Eine Spec zählt nur, wenn die Übergabe verändert, was der Agent schreibt. Sonst hast du bloß hübscheren Papierkram erzeugt.
So sieht eine gute Übergabe aus
Die stärkste Gemeinsamkeit der Frameworks von 2026 ist der Loop Specify, Plan, Tasks, Implement mit menschlichen Review-Gates, dazu das bewährte Muster, Produkt-, Technik- und Integrations-Specs zu trennen und Aufgaben unabhängig voneinander testbar zu halten, beschrieben in der BCMS-Analyse moderner SDD-Praxis. Genau dieser Teil wird oft übersehen, wenn SDD als bloß teures Prompting abgetan wird.
Eine praktische Übergabe an Cursor oder Claude Code enthält meistens:
- Scope-Grenzen, damit der Agent weiß, was er nicht umschreiben soll
- Akzeptanzkriterien in einem testbaren Format wie Given/When/Then
- Betroffene Dateien oder Module, damit er an den richtigen Stellen anfängt
- Rahmenbedingungen wie API-Kompatibilität, Grenzen bei Migrationen oder UI-Regeln
- Atomare Aufgaben, die in einen fokussierten Lauf passen
Diese Struktur macht das Modell nicht klüger. Sie macht die Anfrage enger.
Für alle, die in bestehenden Repos arbeiten, zählt hier Codebase-aware AI Planning, weil generische Planung schnell zerfällt, wenn der Agent die Architekturgrenzen nicht sehen kann, mit denen du längst lebst.
Warum atomare Aufgaben heroische Prompts schlagen
Nimm ein Brownfield-Beispiel. Du willst einer Billing-Aktion Audit-Logging hinzufügen.
Der schlechte Prompt liegt auf der Hand: „Füg dem Billing Audit-Logging hinzu und sorg dafür, dass es überall funktioniert.“
Die brauchbare Übergabe sieht eher so aus:
- Logging nur im Pfad für Statusübergänge von Rechnungen hinzufügen.
- Die unabhängige Retry-Logik für Zahlungen nicht anfassen.
- Events in den bestehenden Audit-Service schreiben.
- Tests für erfolgreiche und abgelehnte Übergänge hinzufügen.
- In dieser Aufgabe keine UI-Texte ändern.
Das ist langweilig. Gut so. Langweiliges wird ausgeliefert.
Wenn Leute SDD eine Token verbrennende Zeremonie nennen, vergleichen sie meistens ein schweres Setup mit einem einzigen kurzen Prompt. Sie vergleichen es nicht mit den drei gescheiterten Prompt-Iterationen, dem Abdriften in unbeteiligte Dateien und dem Aufräumdurchgang, nachdem der Agent „hilfsbereit“ das halbe Modul refaktoriert hat.
Harte Wahrheit: Ein präziser Lauf ist oft billiger als mehrere vage Läufe plus Reparaturarbeit.
Wenn die Spec klein ist, ist auch der Prozess klein. Das ist der ganze Trick.
Praktische Einstiegswege für Solo Builder
Die schwierigste Frage war 2026 nicht, wie man SDD auf der grünen Wiese betreibt. Sondern wie man es in ein laufendes Repo einführt, ohne das Ausliefern in eine Papierkram-Übung zu verwandeln. Diese Lücke zeigt sich direkt in Allegros Beitrag zu SDD-Best-Practices und den Reibungen bei der Brownfield-Migration.
Fang in einem Feature an, nicht im ganzen Repo
Rüste SDD nicht überall nach. So fängst du an, es zu hassen.
Such dir ein Feature mit diesen Eigenschaften:
- Klare Grenze: ein Endpoint, ein Screen, ein Workflow-Schritt
- Echter Schaden, wenn der Agent falsch rät: Auth, Billing, Migration, Benachrichtigungen
- Klein genug, um es in einer Sitzung zu prüfen: Wenn du das Ergebnis nicht schnell durchsehen kannst, ist es zu groß
Die erste Spec sollte fast schon nervig bescheiden sein. Du beweist keine Methodik. Du testest, ob Struktur dir einen Überarbeitungszyklus spart.
Eine minimale brauchbare Spec
Für Solo Builder kann eine minimale Spec aus sechs kurzen Abschnitten bestehen:
| Abschnitt | Was du schreibst |
|---|---|
| Problem | Welches Problem für Nutzende oder System behoben wird |
| Im Scope | Was diese Aufgabe umfasst |
| Außerhalb des Scopes | Was der Agent nicht anfassen darf |
| Dateien und Komponenten | Bereiche, die sich wahrscheinlich anzusehen lohnen |
| Akzeptanzkriterien | Testbare Ergebnisse |
| Risiken und Annahmen | Unbekannte, die du vor dem Coden prüfen solltest |
Mit einer Checkliste für schnelle Erfolge geht es noch schlanker:
- Schreib eine Ausschlusszeile: „Den Checkout-Flow nicht ändern.“
- Füg einen Abnahmetest hinzu: Ein Given/When/Then reicht für den Anfang.
- Nenn die Zieldateien: Selbst ungefähre Dateiverweise helfen.
- Halte eine Architekturvorgabe fest: den bestehenden Service wiederverwenden, keinen neuen hinzufügen.
- Teil eine große Anfrage in zwei Aufgaben: Allein das verbessert den Output des Agents oft.
Was nicht funktioniert: vom ersten Tag an perfekte Docs erzwingen zu wollen. Dann hörst du auf. Fang dort an, wo Mehrdeutigkeit am meisten kostet.
Deinen Stack wählen und das nächste Feature ausliefern
Solo Founder kaufen meistens zu viel Prozess ein und investieren zu wenig in Klarheit. Der Stack, der zählt, ist der, mit dem du das nächste riskante Feature auslieferst, ohne dass Review zum zweiten Job wird.
Wähle vom Punkt aus, an dem es scheitert, nicht von der Kategorieseite aus.
Wenn das Problem vor dem Code beginnt, nimm eine Spec-first-Schicht. Tekk.coach geht es von einer anderen Seite an: Seine Loops lesen, was sich in deinem Repo geändert hat, finden die Arbeit und schreiben die Spec, und auf demselben Board kannst du auch selbst eine schreiben. Cursor, Claude Code oder Codex baut sie über den Tekk-MCP-Server. Tekk schreibt keinen Code und öffnet keine PRs. Diese Grenze ist nützlich für Solo Builder, die wollen, dass die Arbeit gefunden und definiert wird, ohne den ganzen Workflow abzugeben.
Wenn das Problem während der Implementierung beginnt, nimm das Tool, das dir engere Kontrolle dort gibt, wo sich der Code ändert:
- Nimm Spec Kit oder OpenSpec, wenn du Specs im Repo und ein Format willst, das du zwischen Tools mitnehmen kannst.
- Nimm Kiro, wenn du stärkere Kontrolle darüber willst, wie Arbeit ausgeführt wird.
- Nimm Workflows mit Claude Code oder Cursor, wenn dir das Tempo von der freigegebenen Aufgabe zum generierten Code wichtiger ist als Portabilität.
Wenn du auch den breiteren Build-Stack vergleichst und nicht nur die SDD-Schicht, ist diese Übersicht zum Vergleich von DevOps-Tools für deinen perfekten Stack eine nützliche Referenz. Es gilt dieselbe Kaufregel: Beheb einen wiederkehrenden Engpass. Ignorier den Hype um Kategorien.
Ein einfacher Filter funktioniert besser als eine lange Bewertungsmatrix:
- Deine Anforderungen sind klar, aber Agents driften trotzdem ab. Ergänz stärkere Leitplanken für die Ausführung.
- Du kennst die Codebase, aber das Aufsetzen von Aufgaben ist uneinheitlich. Ergänz eine bessere Spec-Schicht.
- Dir sind spätere Wechselkosten wichtig. Halte die Formate portabel und bleib nah an der CLI.
- Du willst den schnellsten Weg zu ausgeliefertem Code. Bleib in dem Editor, den du schon nutzt.
- Du arbeitest allein, und Kontextwechsel kosten dich Zeit. Streich zuerst eine Übergabe.
Der Gegenwind gegen SDD ist größtenteils Gegenwind gegen aufgeblähte Prozesse. Völlig fair. Solo Builder sollten die Konzernversion dieses Playbooks ignorieren.
Gut eingesetzt ist SDD eine dünne Steuerungsschicht zwischen Absicht und Code. Es hilft bei den Features, bei denen Raten teuer wird. Wenn ein Tool Zeremonie hinzufügt und Nacharbeit nicht verringert, wirf es raus. Wenn es dir hilft, eine riskante Änderung in einer Sitzung zu definieren, zu prüfen und auszuliefern, behalte es.
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.