Ja, Spec-driven Development ist eine Produktivitätsfalle – bei Solo-Experimenten, Hotfixes und beim Ausprobieren. Zum Multiplikator wird es, wenn die Arbeit gut spezifiziert ist: Solche Aufgaben erledigen Devs 55 % schneller, auch wenn 67 % am Anfang des Workflows noch zusätzliche Zeit ins Setup stecken.
Genau das übersehen die lautesten Meinungen. Der aktuelle Gegenwind ist nicht falsch. Manchmal ist Spec-driven Development wirklich Wasserfall mit Markdown, Spec Drift und Zeremonie, die Tokens verbrennt. Manchmal ist es einfach Prokrastination mit Architektur-Abzeichen.
Aber auch das Anti-Spec-Lager schießt übers Ziel hinaus. Wenn du mit Cursor, Claude Code, Codex oder Gemini auslieferst und bei allem, was nicht trivial ist, auf Struktur verzichtest, zahlst du meistens später dafür – mit Nacharbeit, Debugging und Aufräumen. Die Falle sind nicht die Specs. Die Falle ist, für jeden Job dasselbe Spec-Gewicht zu nehmen. Wenn du erst die Grundlagen brauchst, lies was Spec-driven Development wirklich ist.
Inhalt
- Die ehrliche Antwort auf die Spec-Falle
- Woran du merkst, dass du in der Falle sitzt und Specs dich ausbremsen
- Wann Specs deinen Output mit AI Agents verzehnfachen
- Ein pragmatisches Entscheidungsraster für Solo Builder
- Deinen Workflow wählen: von Spec-light bis Spec-heavy
- Hör auf zu spekulieren und fang an auszuliefern
Die ehrliche Antwort auf die Spec-Falle
Ja, es kann eine Falle sein. Nein, deshalb ist der Ansatz nicht als Ganzes falsch.
Wenn du eine vollständige Spec für eine Änderung an einer einzigen Datei, einen Bugfix oder eine Produktidee schreibst, die du morgen vielleicht wieder löschst, verschwendest du Zeit. Über genau diese Version machen sich Leute auf Reddit und YouTube lustig, und das zu Recht. Viele Teams haben aus einer nützlichen Idee ein Ritual gemacht.
Praxisregel: Passe das Gewicht der Spec an das Gewicht der Arbeit an.
Das heißt: leichte Specs für Arbeit mit wenig Risiko. Schwerere Specs für chaotische, dateiübergreifende, Brownfield- oder agentgetriebene Arbeit. Wenn du Spec-driven Development wie eine Religion behandelst, bekommst du Zeremonie. Wenn du es wie ein Werkzeug behandelst, bekommst du Kontrolle.
Woran du merkst, dass du in der Falle sitzt und Specs dich ausbremsen
Du sitzt in der Falle, wenn die Spec mehr kostet als der Fehler.
Das zeigt sich meistens in ein paar typischen Situationen. Du testest eine Idee. Du behebst etwas Offensichtliches. Du kennst die Änderung schon genau. Oder du fasst Code an, der die Woche nicht überleben wird. In diesen Fällen sind seitenweise Markdown nur eine weitere Art, das Ausliefern vor dir herzuschieben.
Der Geruchstest für kleine Aufgaben
- Wegwerf-Experimente: Wenn du die Produktrichtung abtastest, zählt Tempo mehr als Feinschliff.
- Winzige Hotfixes: Wenn Bug und Fix beide offensichtlich sind, mach einfach die Änderung und prüf sie.
- UI-Anpassungen mit klaren Akzeptanzkriterien: Ein paar Stichpunkte schlagen ein formales Dokument.
- Kontext für eine Person, eine Session: Wenn die ganze Aufgabe in deinen Kopf passt, erfinde keinen Prozess.
Der Gegenwind kommt aus echtem Schmerz. Der Reddit-Thread zu Spec vs. gesundem Menschenverstand in r/vibecoding und die Beschwerde, dass Spec-Kit in r/OpenAIDev Tokens frisst, treffen denselben Nerv. Schwere Templates können kleine Features schlechter machen.
Brownfield wird erst schlechter, bevor es besser wird
Es gibt noch eine Falle, die niemand gern zugibt. Spec-driven Development bremst bestehende Produkte oft erst einmal aus. Augments Leitfaden zu Spec-driven Development erklärt, warum: In Brownfield-Codebases musst du das Verhalten oft erst aus sichtbaren Artefakten rekonstruieren, bevor du eine brauchbare Spec schreiben kannst.
Wenn du die App erst per Reverse Engineering verstehen musst, bevor du die Änderung beschreiben kannst, ist die Spec eine zweite Aufgabe und keine Abkürzung.
Aus einem verwandten Grund mag ich den Ansatz von WeekBlast gegen Scope Creep. Er zwingt dich, Grenzen zu ziehen, ohne so zu tun, als verdiene jede Aufgabe einen schwergewichtigen Planungsprozess.
Wann Specs deinen Output mit AI Agents verzehnfachen
Specs glänzen, wenn Mehrdeutigkeit ein Kostenfaktor ist. Deshalb zählen sie am meisten, wenn du Arbeit an einen KI-Coding-Agent übergibst.
Ein nützliches Bild dafür: Die Spec ist der API-Vertrag zwischen deinem Kopf und dem Modell. Ist der Vertrag schwach, rät der Agent. Dann prüfst du Vermutungen, flickst Edge Cases und streitest dich mit generiertem Code, der technisch funktioniert, aber am Thema vorbeigeht.
Allstacks' Erklärung, warum Spec-driven Development kein Wasserfall ist, bringt den Kernpunkt besser auf den Punkt als die meisten. Der alte Loop von der Spec zur Erkenntnis dauerte grob sechs Monate. Mit einem AI Agent kann er auf etwa 20 Minuten schrumpfen. Das ändert alles. Gründliches Nachdenken vorab ist nicht mehr auf dieselbe Weise teuer, weil du die Spec fast sofort testen kannst.
Wo sich Specs bezahlt machen
- Dateiübergreifende Features: Auth-Flows, Billing-Änderungen, Sync-Logik, Berechtigungen, Migrationen
- Brownfield-Arbeit: vor allem, wenn versteckte Annahmen quer durchs Repo verteilt sind
- Übergabe an den Agent: wenn Cursor oder Claude Code umsetzen sollen, ohne auf eigene Faust loszulegen
- Alles mit Geschäftsregeln: denn an Edge Cases gehen vage Prompts zugrunde
Eine nützliche Ergänzung, wenn du über Agent-Workflows nachdenken willst und nicht nur über Prompting-Tricks: agentive KI mit Flaex.ai einordnen.
Später im Workflow zählt Review trotzdem. Um die Validierung kommst du nicht herum. Du hörst nur auf, für dieselbe Mehrdeutigkeit dreimal zu zahlen. Wenn dir Kontext aus der Codebase wichtig ist, liefert dieser Text zu Codebase-aware AI Planning das richtige Denkmodell.
Ein praktisches Walkthrough hilft hier:
Eine Spec soll nicht alles vorhersagen. Sie soll verhindern, dass der Agent erfindet, was du nie entschieden hast.
Ein pragmatisches Entscheidungsraster für Solo Builder
Nutze das, bevor du mit der Arbeit anfängst. Nicht erst, wenn die KI schon ein Chaos angerichtet hat.
Ein Branchenleitfaden von 2025 berichtet, dass 67 % der Devs, die KI-Tools nutzen, zusätzliche Zeit ins Setup stecken, gut spezifizierte Aufgaben aber 55 % schneller erledigt werden können und manche Features 50–80 % Implementierungszeit sparen. Die Setup-Steuer ist also real. Der Gewinn ist es auch.
Stell dir diese fünf Fragen
Berührt das mehrere Dateien oder versteckte Abhängigkeiten?
Wenn ja, schreib eine strukturierte Spec.Gibst du das an einen AI Agent ab?
Wenn ja, leg vorher Scope, Rahmenbedingungen und Abnahmeprüfungen fest.Ist die Codebase alt, seltsam oder schlecht dokumentiert?
Wenn ja, fang mit einer Teil-Spec aus den sichtbaren Artefakten an.Wäre eine falsche Implementierung teuer zurückzubauen?
Wenn ja, verlagere mehr Denkarbeit nach vorn.Ist das zum Wegwerfen?
Wenn ja, nimm Stichpunkte statt Bürokratie.
Du brauchst nicht den einen Workflow. Du brauchst eine Entscheidungsregel. Dasselbe Urteilsvermögen gilt auch für die Arbeit an der Roadmap. Dieser Leitfaden zu einer Roadmap für die Produktentwicklung ist hilfreich, weil er dich zwingt, Experimente von Zusagen zu trennen.
Deinen Workflow wählen: von Spec-light bis Spec-heavy
Nicht jeder Job braucht GitHub Spec Kit. Aber nicht jeder Job sollte auch reines Vibe Coding sein.
Yuval Yerets Sicht auf Spec-driven Development trifft die Balance. In Brownfield-Codebases sollten Specs gerade so viel Denken vorab sein, dass Lernen billiger wird. Keine erschöpfende Planung. Kein Dokumenten-Cosplay.
Nimm den leichtesten Workflow, der Nacharbeit noch verhindert
| Workflow | Am besten für | So sieht es aus |
|---|---|---|
| Spec-light | Experimente, schnelle Fixes, Spikes | ein paar Stichpunkte, Notizen zur Abnahme, direkt coden |
| Mid-Spec | normale Features, Übergabe an einen Agent, mittleres Risiko | Scope, Rahmenbedingungen, betroffene Dateien, Testplan |
| Spec-heavy | komplexe Brownfield-Features, Migrationen, architekturkritische Änderungen | strukturierte Spec, Teilaufgaben, explizite Prüfungen, Risikonotizen |
An dieser Stelle trennen sich auch die Tools. Vibe Kanban und leichte Notizen reichen zum Erkunden. GitHub Spec Kit und schwerere Frameworks helfen bei großen Änderungen, können sich bei kleinen Aufgaben aber aufgebläht anfühlen. Die Fachpresse hat den Schwenk zu Specs bemerkt, etwa Visual Studio Magazine über GitHub Spec Kit, während kritische Diskussionen wie Prasad Kulkarnis Einschätzung zum SDD-Hype und dazu, was funktioniert, sehenswert sind, wenn du Cargo-Cult-Prozesse satthast.
Wenn die Falle darin besteht, dass Specs überhaupt geschrieben werden müssen, nimmt dir Tekk.coach diesen Teil für bestehende GitHub-Repos ab. Seine Loops lesen, was sich in deinem Code geändert hat, und schreiben die Spec als Proposal, das du mit Greenlight freigibst oder ablehnst; selbst schreiben kannst du trotzdem eine. Dein Coding-Agent (Cursor, Claude Code, Codex) baut sie, und der gemergte PR schließt sie. Das passt zum Bereich zwischen Mid-Spec und Spec-heavy für Solo Builder, die in echtem Code arbeiten und nicht in sauberen Demos.
Hör auf zu spekulieren und fang an auszuliefern
Specs sind nicht die Arbeit. Sie nützen nur, wenn sie Verwirrung, Nacharbeit oder das Abdriften des Agents verringern. Lass sie bei kleinen Wegwerf-Aufgaben weg. Setz sie konsequent ein bei dateiübergreifenden, riskanten, Brownfield- und agentgetriebenen Änderungen.
Specs von Hand zu schreiben ist der manuelle Weg. Die Loops von Tekk.coach schreiben sie für dich aus dem, was sich in deinem Code geändert hat: dasselbe Board, dieselben Akzeptanzkriterien, geschlossen mit dem Merge des PR.
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.