Die meisten Ratschläge zu Spec-driven Development fangen am falschen Ende an. Sie beginnen bei den Tools. Genau dort solltest du nicht anfangen.
Im Mai 2026 wurde die Gegenreaktion nicht ohne Grund laut. SDD hieß plötzlich „Wasserfall mit Markdown“, „Produktivitätsfalle“ und ein Ritual, das Tokens verbrennt, während dein Feature immer noch nicht ausgeliefert ist. Simon Willison gehört zu den deutlichsten Stimmen gegen Überspezifizierung. Er hat nicht unrecht. Ein aufgeblähter Spec-Prozess kann absolut zu vorgetäuschter Gründlichkeit werden.
Aber der umgekehrte Fehler ist für einen Solo Builder schlimmer. Wenn du Cursor, Claude Code, Codex oder Gemini einen vagen Prompt auf eine echte Codebase loslässt, bekommst du meistens selbstbewussten Unsinn, ein oberflächliches Verständnis der Codebase und Nacharbeit. Das ist keine Agilität. Das ist Roulette.
Frag also nicht, welches SDD-Framework das beste ist. Frag, welches am wenigsten schlecht zu deinen aktuellen Rahmenbedingungen passt. Allein oder winziges Team. Greenfield oder Brownfield. Knappes Token-Budget oder nicht. CLI-Gewohnheiten, die du nicht aufgeben willst. Wie wohl du dich mit gehosteten Lösungen fühlst. Ein Agent oder mehrere.
Darum geht es bei Dein SDD-Framework auswählen, ein Entscheidungsbaum. Nicht um Ideologie. Um Triage.
Wenn du noch unsicher bist, ob Specs dir helfen oder dich nur bremsen, lies wann Specs dich ausbremsen und wann sie dich zehnmal schneller machen. Dann komm zurück und wähl das leichteste Framework, das deinem Agent genug Kontext gibt, damit er nicht mehr raten muss.
Inhalt
- Die Gegenreaktion auf SDD ist da – warum also der Aufwand?
- Die drei Stufen von Spec-driven Development
- Die Fragen für deinen SDD-Entscheidungsbaum
- Ast eins: leichte und lokale Frameworks
- Ast zwei: strukturierte und gehostete Plattformen
- Ast drei: der Weg der tiefen Integration
- SDD einführen, ohne in die Fallen zu tappen
- Das richtige Framework ist das, das du tatsächlich nutzt
Die Gegenreaktion auf SDD ist da – warum also der Aufwand?
Die Gegenreaktion ist verdient. Viele SDD-Ratschläge sind in Zeremonie abgedriftet.
Du kennst das Muster. Jemand nimmt ein einfaches Feature, packt es in ein riesiges Markdown-Paket, ergänzt Review-Rituale und wundert sich dann, dass das Coden langsamer geworden ist. Birgitta Böckelers Einteilung ist gerade deshalb nützlich, weil sie leichte Spec-first-Arbeit von starreren Spec-anchored- und Spec-as-Source-Ansätzen trennt. Thoughtworks hat Spec-driven Development auf den Tech Radar gesetzt, weil die Idee trägt – das heißt aber nicht, dass jeder Umsetzungsstil deine Zeit verdient.
Die Kritik ist berechtigt
Die üblichen Beschwerden sind nicht erfunden:
- „Wasserfall mit Markdown“ entsteht, wenn die Spec zur Schranke statt zum Wegweiser wird.
- „Produktivitätsfalle“ entsteht, wenn du mehr Zeit damit verbringst, das Doc zu perfektionieren, als das Implementierungsrisiko zu senken.
- „Spec Drift“ entsteht, wenn sich der Code ändert und die Spec schon am zweiten Tag veraltet ist.
- „Eingefrorene Specs“ entstehen, wenn eine frühe Vermutung wie ein Vertrag behandelt wird.
- „Token verbrennende Zeremonie“ entsteht, wenn das Framework das Modell wiederholen lässt, was ohnehin alle wissen.
Überspezifizierung rettet dich nicht. Sie verlagert die Verschwendung nur nach vorn im Zyklus.
Hier greift Simon Willisons grundsätzlichere Kritik. KI-gestütztes Coden funktioniert am besten mit klarem Kontext, nicht mit Prozesstheater. Addy Osmanis inzwischen kanonisches Spec-Format mit sechs Abschnitten ist nützlich, weil es Klarheit über Problem, Rahmenbedingungen, Scope und Validierung erzwingt. Schlecht wird es, wenn daraus eine bürokratische Religion gemacht wird.
Warum es dich trotzdem interessieren sollte
Wenn du allein baust, fehlen dir nicht die Ideen. Dir fehlt ein zweites Gehirn, das Produktabsicht, Einschränkungen der Codebase, Edge Cases und Implementierungsplan gleichzeitig im Kopf behält.
Ein ordentliches SDD-Framework schließt diese Lücke. Es gibt deinem Coding-Agent ein besseres Startbriefing. Das zählt am meisten bei Brownfield-Arbeit, bei Änderungen mit versteckten Nebenwirkungen und bei Features, bei denen „größtenteils richtig“ trotzdem kaputt bedeutet.
Nutze SDD, wenn Unklarheit teuer ist. Lass schweren Prozess weg, wenn die Aufgabe offensichtlich ist.
Das ist die Grenze.
Die drei Stufen von Spec-driven Development
Bevor du ein Framework auswählst, brauchst du das richtige Denkmodell. Birgitta Böckelers Einteilung in spec-first, spec-anchored und spec-as-source ist die sauberste, die ich kenne. Sie schneidet durch das Rauschen.
Spec-first ist der Einstieg
Das ist die leichteste Variante. Du schreibst vor dem Code ein strukturiertes Briefing. Meistens in Markdown. Meistens zuerst für Menschen lesbar.
GitHub Spec Kit, einfache BMAD-Abläufe und viele Templates für Solo Founder sind hier angesiedelt. Ebenso viele selbstgebaute Workflows rund um Addy Osmanis Format mit sechs Abschnitten. Du beschreibst das Feature, listest Grenzen auf, notierst Annahmen, ergänzt vielleicht Akzeptanzkriterien und gibst das Ganze dann an deinen Coding-Agent.
Passt gut: Greenfield-Arbeit, kleine Features, alle, die Setup hassen.
Passt schlecht: chaotische Brownfield-Systeme, in denen Dateipfade, Abhängigkeiten und versteckte Kopplung wichtiger sind als Produktprosa.
Spec-anchored ist der richtige Ort für die meisten Solo Builder
Für viele, die mit KI echte Apps bauen, ist das der Sweet Spot.
Die Spec ist nicht mehr nur ein Dokument. Sie ist an die Codebase gebunden. Sie verweist auf konkrete Module, bekannte Einschränkungen, bestehende Schemas und den wahrscheinlichen Wirkungsradius. Kiro, Workflows im Stil von OpenSpec und strukturiertere Ansätze, die das Repo kennen, sind meist hier zu Hause. Die Spec bleibt für Menschen lesbar, funktioniert aber zunehmend wie eine Landkarte statt wie ein Wunschzettel.
Das ist wichtig, weil die meisten misslungenen KI-generierten Änderungen nicht an schwachen Coding-Skills scheitern. Sie scheitern an fehlendem Kontext.
Faustregel: Wenn du in einem bestehenden Repo arbeitest, schlägt Spec-anchored meistens Spec-first.
Du brauchst keine vollständig maschinenlesbare Orchestrierung. Du brauchst genug Verankerung, damit der Agent aufhört, Architektur zu erfinden.
Spec-as-Source ist mächtig – und schnell übertrieben
Das ist das ambitionierte Ende der Leiter. Die Spec wird zu einem zentralen Artefakt im Build-Lebenszyklus. Sie kann Prüfungen, Workflow-Zustände oder sogar generiertes Verhalten steuern. Vibe Kanban und ähnliche Systeme gehen in diese Richtung. Ebenso strengere Frameworks, bei denen die Spec die Arbeit über Implementierung, Validierung und Änderungsverfolgung hinweg koordinieren soll.
Dieser Weg kann hervorragend sein, wenn du Konsistenz und Wiederholbarkeit willst. Er kann aber auch schnell starr werden.
Hier die Abwägungen in einfachen Worten:
| Stufe | Was du gewinnst | Was du riskierst | Am besten für |
|---|---|---|---|
| Spec-first | Tempo, Einfachheit | Drift, oberflächlicher Kontext | Greenfield-Arbeit allein |
| Spec-anchored | Besseres Verständnis des Repos | Mehr Setup | Solo Builder im Brownfield |
| Spec-as-Source | Tiefe Konsistenz | Starrheit, Lock-in, Zeremonie | Sehr disziplinierte Builder |
Der Fehler ist nicht, für immer die „falsche“ Sprosse zu wählen. Der Fehler ist, zu weit oben anzufangen, weil das Framework auf GitHub beeindruckend aussah.
Die Fragen für deinen SDD-Entscheidungsbaum
Das richtige Framework ergibt sich aus deinen Rahmenbedingungen. Nicht aus deinen Idealen.
Die sieben Fragen, auf die es wirklich ankommt
Beantworte sie der Reihe nach:
Arbeitest du allein oder in einem winzigen Team?
Wenn du allein bist, tendier zu Tools mit wenig Zeremonie. Team-Workflows bringen nur dann etwas, wenn Koordination das Problem ist.Ist es für dich okay, an eine IDE gebunden zu sein?
Manche Tools fühlen sich in einem Editor flüssig an und überall sonst sperrig. Wenn du zwischen Cursor, Claude Code, Terminal-Tools und eigenen Skripten wechselst, nervt der IDE-Lock-in schnell.Achtest du auf deine Token-Kosten?
Diese Frage zählt mehr, als viele zugeben. Ein Thread in r/OpenAIDev über den Token-Verbrauch von SpecKit fängt den Frust gut ein. Wenn sich jede Verfeinerungsrunde teuer anfühlt, ist dein Framework zu geschwätzig für dein Budget.Arbeitest du auf der grünen Wiese oder im Brownfield?
Neue Projekte vertragen leichtere Specs. Bestehende Repos bestrafen oberflächlichen Kontext.Nutzt du einen Haupt-Coding-Agent oder mehrere?
Ein Workflow mit nur einem Agent kommt mit lockererer Formatierung durch. Wenn du zwischen Cursor, Claude Code, Codex und Gemini hin- und herspringst, werden strukturierte Specs wichtiger.Willst du eine gehostete Lösung oder selbst verwalten?
Gehostet bekommst du Komfort und dauerhaften Kontext. Selbst verwaltet behältst du die Kontrolle und hängst weniger von der Produktstrategie anderer ab.Hast du schon einen CLI-Workflow, den du magst?
Wenn ja, wirf ihn nicht weg, außer der Ersatz ist klar besser.
Wenn du nebenbei auch plattformübergreifende Produktarbeit erkundest, hilft es, parallel die Optionen für die Entwicklung mobiler Apps kennenzulernen. Nicht, weil Mobile-Frameworks und SDD-Frameworks dasselbe wären, sondern weil deine Plattformwahl bestimmt, wie viele Implementierungsdetails deine Specs brauchen.
Wie du antwortest, ohne dich selbst zu belügen
Oft werden diese Fragen nach dem Wunschbild beantwortet. Das ist ein Fehler.
Antworte nicht danach, was fortgeschritten klingt. Antworte danach, was du an einem Dienstagnachmittag tatsächlich tust, wenn du müde bist.
- Wenn du das Terminal ungern verlässt, wähl einen lokalen Workflow.
- Wenn dein Repo alt und eigenwillig ist, mach dir nichts vor: Ein generisches Markdown-Template trägt nicht genug Kontext.
- Wenn du oft die Tools wechselst, meide Frameworks, die nur in einer Umgebung glänzen.
- Wenn du Docs ungern aktualisierst, wähl kein System, das zusammenbricht, sobald die Spec veraltet.
Wähl für deine heutigen Gewohnheiten, nicht für den Workflow, den du gern hättest.
Diese eine Regel streicht schon die Hälfte der Fehlgriffe.
Ast eins: leichte und lokale Frameworks
Wenn du allein arbeitest, mit editorzentrierten Tools klarkommst und an deinen CLI-Gewohnheiten hängst, ist dieser Ast meist der beste Startpunkt.
Wähl diesen Ast, wenn Reibung dein eigentlicher Gegner ist
Lokale Frameworks gewinnen in einem Punkt. Sie verlangen nicht, dass du dein Leben umkrempelst.
GitHub Spec Kit, Traycer und BMAD sprechen alle denselben Instinkt an. Die Artefakte bleiben im Repo. Der Prozess bleibt sichtbar. Die Übergabe an den Coding-Agent bleibt manuell und offensichtlich. Das ist attraktiv, weil es Plattformabhängigkeit vermeidet und die Spec nah am Code hält.
Genau deshalb driften diese Tools aber auch so leicht ab. Nichts zwingt dich, die Spec aktuell zu halten. Nichts hindert dich daran, ein hübsches Doc zu generieren, eine andere Implementierung auszuliefern und die beiden nie wieder abzugleichen.
Worin sich GitHub Spec Kit, Traycer und BMAD unterscheiden
Hier die ungeschönte Version:
| Framework | Stark bei | Schwachstelle | Meine Einschätzung |
|---|---|---|---|
| GitHub Spec Kit | Saubere Struktur direkt im Repo, vertraute GitHub-Anziehungskraft | Kann sich langatmig und tokenhungrig anfühlen, wenn du es mit Verfeinerungs-Loops übertreibst | Gut, wenn du Konventionen willst und Nacharbeit am Text dich nicht stört |
| Traycer | Leichtgewichtige Nachverfolgung von der Absicht bis zur Implementierung | Weniger Leitplanken als gehostete Systeme | Gut für alle, die Klarheit wollen, ohne auf eine Plattform umzuziehen |
| BMAD | Vollständigere Planungsabläufe, kann tieferes Nachdenken unterstützen | Schnell übertrieben, vor allem wenn du jedes Feature wie ein formales Projekt behandelst | Gut, wenn das Feature chaotisch genug ist, um den Aufwand zu rechtfertigen |
Ein paar praktische Hinweise:
- GitHub Spec Kit funktioniert am besten, wenn GitHub für dich ohnehin der Schwerpunkt deines Entwicklungsprozesses ist. Der Vorteil liegt auf der Hand: Es ist über das GitHub-Topic zu Spec-driven Development leicht zu finden. Der Nachteil: Teams übernehmen die Struktur oft, ohne zu entscheiden, ob sie die Zeremonie überhaupt wollen.
- Traycer passt zu allen, die einen Weg von der Anforderung zur Auswirkung im Code wollen, ohne in Templates zu ertrinken.
- BMAD ist am stärksten, wenn du gründlichere Anforderungserhebung, Diagramme oder einen bewussteren Denkprozess brauchst. Am schwächsten ist es bei winzigen Aufgaben.
Addy Osmanis Format mit sechs Abschnitten ist ein guter Maßstab für diesen Ast. Wenn dir ein Framework nicht hilft, Absicht, Grenzen, Implementierungshinweise, Annahmen, Validierung und offene Fragen klar zu formulieren, ist es zu locker. Wenn es für ein winziges Feature eine Dissertation verlangt, ist es zu schwer.
Einen ausführlicheren direkten Vergleich am leichtgewichtigen Ende findest du unter leichtgewichtige SDD-Frameworks im Vergleich.
Ein lokales Framework ist großartig, wenn du schon weißt, wie man denkt. Vor schlampigem Denken bewahrt es dich nicht.
Meine Empfehlung ist einfach. Fang hier an, wenn du auf der grünen Wiese startest, überwiegend allein arbeitest und allergisch auf Setup reagierst. Halte deine Specs aber so kurz, dass du sie auch dann noch bearbeitest, wenn sich der Code geändert hat.
Ast zwei: strukturierte und gehostete Plattformen
Dieser Ast ist für alle, die es leid sind, vor jedem ernsthaften Feature den Kontext von Hand zusammenzutragen.
Wähl diesen Ast, wenn das Kontextsammeln dir ständig den Schwung nimmt
Gehostete und strukturierte Plattformen lohnen sich bei Brownfield-Arbeit. Dort zählen Repo-Verständnis, gespeicherter Kontext und geführtes Schreiben von Specs.
Das übliche Muster ist simpel. Du verbindest deine Codebase, beantwortest Fragen und bekommst eine fundiertere Spec zurück, als du sie normalerweise von Hand schreiben würdest. Das kann ein großer Fortschritt sein, wenn die eigentliche Arbeit nicht das Tippen von Code ist, sondern herauszufinden, wo die Änderung hingehört, was sie kaputt machen könnte und welche Annahmen geprüft werden müssen.
Der Haken ist ebenso offensichtlich. Du hängst von einem Produkt ab. Du akzeptierst einen Workflow mit eigener Meinung. Und meistens gibst du etwas von der rohen Flexibilität auf, die dir ein schlichter Markdown-Ordner bieten würde.
Kiro, OpenSpec und gehostete strukturierte Workflows im Vergleich
Ich würde nicht alle strukturierten Tools in einen Topf werfen, denn sie lösen unterschiedliche Probleme.
- Kiro ergibt mehr Sinn, wenn dein Prozess ohnehin auf Zusammenarbeit ausgelegt ist und du eine stärkere gemeinsame Struktur willst. Für einen Solo Founder kann sich das nach zu viel Framework anfühlen, solange das Projekt nicht unübersichtlich wird.
- OpenSpec ist interessant, weil es auf eine Standardform für Specs hinarbeitet, ohne den schwerstmöglichen Prozess zu verlangen. Das ist attraktiv, wenn du Portabilität und sauberere Übergaben zwischen Tools willst.
- Gehostete strukturierte Workflows sind generell am stärksten, wenn du ein älteres Repo hast, immer wieder Kontextprobleme oder mehrere Agents, die ein einheitliches Briefing brauchen.
Auch andere Namen in diesem Umfeld zählen. OpenSpec, Kiro und GitHub Spec Kit fallen meist zuerst auf, aber SDD, GSD und Repo-bewusste Ansätze im Stil von AI-DLC zielen alle auf dasselbe Grundbedürfnis: bessere Verankerung als ein frei formulierter Prompt.
Für Solo Builder hier mein Filter, mit klarer Meinung:
| Wenn das nach dir klingt | Wähl |
|---|---|
| „Mein Repo ist alt, und der Agent übersieht ständig versteckte Einschränkungen“ | Strukturierter gehosteter Workflow oder ein Ansatz im Stil von OpenSpec |
| „Ich will, dass meine Specs zwischen Tools portabel bleiben“ | OpenSpec |
| „Ich brauche mehr teamtauglichen Prozess als persönliche Notizen“ | Kiro |
| „Ich will das Leichteste, was meine Codebase trotzdem kennt“ | Einen einfacheren strukturierten Workflow statt eines schwereren Teamsystems |
Die Gefahr bei diesem Ast ist meist nicht der Drift. Es ist die Abhängigkeit. Wenn die Plattform verschwindet, die Richtung wechselt oder dich in mehr Zeremonie drängt, als du brauchst, kann dein Prozess um sie herum verkalken.
Trotzdem: Wenn dein Engpass nicht das Schreiben von Code ist, sondern das ständige Neuaufbauen von Kontext, ist dieser Ast oft die richtige Antwort.
Ast drei: der Weg der tiefen Integration
Dieser Weg ist für alle, die wollen, dass die Spec mehr ist als ein Dokument. Sie soll im Workflow selbst verankert sein.
Wann sich tiefere Integration lohnt
Tief integrierte Systeme wie Vibe Kanban und verwandte Ansätze, die die Spec als operatives Artefakt behandeln, können hervorragend sein, wenn Konsistenz wichtiger ist als Spontaneität.
Du bekommst einen engeren Loop zwischen Absicht, Implementierung, Review und Validierung. Das System kann Arbeit nachvollziehbarer machen. Es kann mehrdeutige Übergaben reduzieren. Es kann verhindern, dass spontane Prompt-Improvisation zu deinem Engineering-Prozess wird.
Das ist der Ast für alle, die Strenge wollen.
Keine gespielte Strenge. Echte.
Wo Vibe Kanban und ähnliche Systeme zurückbeißen
Der Preis ist Starrheit. Hier ergibt die Sprache der Gegenreaktion plötzlich Sinn.
Wenn das Framework zu nah am Lebenszyklus sitzt, kann sich jede Änderung wie Papierkram anfühlen. Das ist nicht automatisch schlecht. Schlecht ist es, wenn die Aufgabe klein ist und der Prozess trotzdem auf schwergewichtigen Aktualisierungen besteht.
Eine Diskussion im Subreddit r/vibecoding hat Bedenken zur Skalierbarkeit aufgebracht; jemand schrieb dort: „SDD is amazing until you hit 30 repos and 100 devs“ („SDD ist großartig, bis du bei 30 Repos und 100 Devs ankommst“). Das unterstreicht die Reibung, die mit wachsender Komplexität entstehen kann, selbst in kleineren Setups – nachzulesen in diesem Reddit-Thread über das Skalieren von SDD-Workflows.
Dieses Zitat ist wichtig, weil es den Kern dieses Asts trifft. Je integrierter das System wird, desto mehr zählt die Qualität deines Prozesses. Wenn deine Spec-Gewohnheiten schlecht sind, rettet dich tiefe Integration nicht. Sie verstärkt das Chaos.
Diese Tools und Muster ordne ich hier ein:
- Vibe Kanban, für Spec-Tracking direkt im Workflow
- Spec-as-Source-Experimente, bei denen die Spec die Zustände der Implementierung koordiniert
- Starrere SDD-Pipelines, oft genutzt von Teams und Einzelnen, die KI-gestützte Auslieferung von Anfang bis Ende standardisieren wollen
Und diese Vorbehalte würde ich jedem Solo Founder mitgeben:
- Fang hier nicht an, solange Drift dir nicht schon wehtut
- Fang hier nicht an, wenn du es hasst, Prozessartefakte zu pflegen
- Fang hier nicht an, wenn dein Projekt jeden Tag seine Form ändert
- Fang hier an, wenn wiederholt inkonsistente Implementierungen dein Hauptproblem sind
Wenn du eine breitere Landkarte willst, wo diese Frameworks stehen, lies den Überblick über die SDD-Frameworks 2026.
Dieser Weg hat das größte Potenzial und das größte selbstverschuldete Risiko. Deshalb sollten die meisten Solo Builder nicht hier anfangen. Sie sollten sich den Weg hierher erarbeiten.
SDD einführen, ohne in die Fallen zu tappen
Das Framework auszuwählen ist der einfache Teil. Die eigentliche Arbeit ist, es zu nutzen, ohne dass der Prozess zum Selbstzweck wird.
Fang mit einer Spec an, die klein genug ist, um die Realität zu überleben
Deine erste Spec sollte fast schon ärgerlich klein sein.
Kein Anforderungsroman. Kein großes Redesign des ganzen Systems. Ein Feature. Ein Endpoint. Ein Workflow-Fix. Nutze eine kurze Struktur:
- Problem, das du löst
- Scope der Änderung
- Einschränkungen aus der aktuellen Codebase
- Akzeptanzchecks, die du überprüfen kannst
- Offene Fragen, bei denen der Agent nicht raten soll
Diese Form funktioniert, egal ob du GitHub Spec Kit, BMAD, OpenSpec oder ein selbstgebautes Markdown-Template nutzt.
Ein praktisches Beispiel. Du fügst einer bestehenden App einen API-Endpoint hinzu. Du schreibst die Spec in schlichtem Markdown und notierst die Route, die Erwartungen an die Authentifizierung, die betroffene Service-Schicht, Edge Cases und die Tests, die du erwartest. Dann gibst du die Spec von Hand an Claude Code. Der erste Durchlauf kommt zurück. Du aktualisierst die Spec mit dem, was du gelernt hast. Dann kommt der nächste Durchlauf.
So funktioniert das im echten Leben. Kurze Zyklen. Lebendes Doc. Menschliches Urteil.
Nutze die Spec als Werkzeug, nicht als Heiligtum
Eingefrorene Specs töten den Schwung. Endloses Verfeinern auch.
Halte dich stattdessen an diese Regeln:
Schreib weniger, als du für nötig hältst
Wenn der Coding-Agent etwas sicher aus dem Kontext des Repos ableiten kann, wiederhole es nicht.Aktualisiere die Spec, wenn sich die Realität ändert
Wenn die Implementierung eine versteckte Einschränkung ans Licht gebracht hat, muss die Spec nachziehen.Wirf veraltete Abschnitte schnell raus
Alte Vermutungen sind nicht heilig.Beurteile das Framework danach, was ausgeliefert wird
Wenn dein Prozess schöne Docs und langsamere Auslieferung produziert, scheitert er.
Die beste Spec ist die, die den nächsten Coding-Durchlauf verbessert, nicht die, die einen Dokumentationswettbewerb gewinnt.
Die meisten Geschichten über die „Produktivitätsfalle“ beginnen nicht mit dem falschen Tool, sondern mit dem falschen Verhalten. Das Artefakt wird plötzlich als Ergebnis behandelt. Ist es aber nicht. Das Ergebnis ist das ausgelieferte Feature.
Das richtige Framework ist das, das du tatsächlich nutzt
Es gibt nicht das eine beste SDD-Framework. Es gibt nur das, das zu deinen aktuellen Rahmenbedingungen passt, ohne dich in Zeremonie zu ziehen, die du nicht durchhältst.
Wenn du allein und schnell unterwegs bist, fang leichtgewichtig an. Wenn du mit einem Brownfield-Repo ringst, geh in Richtung Spec-anchored-Struktur. Wenn Konsistenz und Integration in den Workflow schon wichtiger sind als reines Tempo, kann der Weg der tiefen Integration sinnvoll sein.
Probier einen Weg eine Woche lang aus. Sei ehrlich. Wenn er deinem Agent hilft, beim ersten Versuch näher am Ziel zu landen, behalte ihn. Wenn er nur Prozess hinzufügt und sonst nichts, streich ihn.
Ausgelieferte Features schlagen schöne Specs. Jedes Mal.
Egal, welches Framework du wählst: Specs von Hand zu schreiben ist der manuelle Weg. Die Loops von Tekk.coach schreiben sie für dich, ausgehend von dem, was sich in deinem Code geändert hat: dasselbe Board, dieselben Akzeptanzkriterien, geschlossen, sobald der PR gemergt ist.
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.