Der schlechteste Rat zu Specs ist gerade auch der häufigste. „Schreib alles vorab auf.“ „Friere den Plan ein.“ „Gib ihn an den Agent.“ So bekommst du genau das, wovor die Kritik warnt: Wasserfall mit Markdown, veraltete Docs und jede Menge Token-Kosten für ein Dokument, das niemand mehr öffnen will.
Diese Gegenreaktion ist echt. Simon Willison hat spec-lastige Workflows kritisch hinterfragt. Birgitta Böckeler war hier hilfreich, weil ihre Einteilung in spec-first, spec-anchored und spec-as-source etwas Offensichtliches festhält, das viele überspringen: Nicht jedes Team sollte gleich arbeiten. Addy Osmanis Format mit sechs Abschnitten hilft auch, aber nur, wenn du es als Ausgangsform behandelst und nicht als heiliges Ritual. GitHub Spec Kit, Kiro, OpenSpec, Traycer, Vibe Kanban, BMAD und der Rest liegen alle irgendwo auf diesem Spektrum. Keins davon rettet dich, wenn deine Spec brüchig ist.
Für Solo Builder in Brownfield-Codebases ist das Problem einfacher. Du schreibst keinen perfekten Plan. Du schreibst Anweisungen, die sich ändernden Code überleben müssen, sich ändernde Annahmen und einen AI Agent, der alles wortwörtlich nimmt. Diese Lücke zählt heute mehr, denn laut dem Developer Survey 2025 von Stack Overflow nutzten 84 % der Befragten KI-Tools oder planten, sie zu nutzen. Specs müssen also zunehmend robust genug sein, um von Maschinen interpretiert zu werden, nicht nur von Menschen – wie in diesem Talk von 2025 über KI-gestütztes Coden und robuste Specs besprochen.
Ob eine Spec nicht zum Refactoring von morgen wird, hängt meist an drei Disziplinen. Schreib auf der richtigen Abstraktionsebene. Markiere Entscheidungen, damit dein künftiges Ich weiß, was sich geändert hat. Bau Auslöser für eine Überprüfung in die Spec ein, damit sie weiß, wann sie falsch sein könnte.
Inhalt
- Lass deine Specs nicht zum Wasserfall mit Markdown werden
- Die drei Disziplinen langlebiger Specs
- Specs für AI Agents schreiben, nicht nur für Menschen
- Muster für lebende Specs, die Drift und Verfall verhindern
- Typische Anti-Patterns, die ein Refactoring garantieren
- Dein Tool wählen und deinen Workflow einbinden
Lass deine Specs nicht zum Wasserfall mit Markdown werden
Die Gegenreaktion zeigt auf einen echten Fehlermodus
Die Kritik liegt nicht falsch, wenn sie schlechte Spec-Arbeit „Wasserfall mit Markdown“ nennt. Sie beschreibt ein Dokument, das die Realität einfrieren will, bevor die Implementierung beginnt. In der Praxis bewegt sich die Realität zuerst.
Bei einer Brownfield-App siehst du das schnell. Du öffnest das Repo, hältst ein Feature für isoliert und stellst dann fest, dass der Auth-State ins Billing durchsickert, ein gemeinsamer Helper an drei Stellen genutzt wird, mit denen du nicht gerechnet hast, und das „einfache Aufräumen“ ein Package berührt, in dem alte Annahmen fest verbaut sind. Wenn die Spec wie ein fester Vertrag geschrieben wurde, ist sie schon veraltet.
Faustregel: Wenn deine Spec davon ausgeht, dass die Codebase stillhält, während gearbeitet wird, ist die Spec Fiktion.
Deshalb sitzt die Gegenreaktion gegen Specs. Viele haben zeremonielle Docs geschrieben und dann zugesehen, wie sich der Code unter ihnen wegbewegt. Das Problem war nicht, Dinge aufzuschreiben. Das Problem war, so zu tun, als müsste sich das Dokument nie ändern.
Ein großer Teil der öffentlichen Debatte bleibt genau dort hängen. Wenn du die grundsätzlichere Kritik lesen willst: dieser Text zur Frage, ob Spec-driven Development nur Wasserfall mit Markdown ist, bringt die Spannung klar auf den Punkt.
Eingefrorene Specs sterben in Brownfield-Code schnell
Was funktioniert, ist eine Spec, die so geschrieben ist, dass sie den Kontakt mit der Implementierung überlebt. Das heißt: weniger Aussagen über Interna, mehr Klarheit über Grenzen und ausdrückliche Notizen dazu, was neu betrachtet wird, wenn sich die Bedingungen ändern.
Bei KI-Coding-Agents zählt das noch mehr. Ein Mensch kann fehlende Absicht oft aus dem Wissen im Team ableiten. Ein Agent kann das nicht. Er füllt Lücken mit Vermutungen. Bei einer sauberen Spielzeug-App auf der grünen Wiese kommst du damit vielleicht durch. Bei einer Codebase, die schon Geschichte, Abkürzungen und versteckte Kopplung mitbringt, nicht.
Eine eingefrorene Spec ignoriert außerdem, wie Refactoring wirklich funktioniert. In reifer Engineering-Praxis ist Refactoring eine fortlaufende Wartungsaufgabe, die Design und Anforderungen in Einklang hält, während sich die Software weiterentwickelt, und keine einmalige Aufräumphase – so argumentiert Ben Nadels Beitrag über Refactoring im Intent Programming.
Das ändert, wie du die Spec schreibst. Du versuchst nicht, Veränderung zu verhindern. Du versuchst, künftige Veränderung billiger zu machen.
Die drei Disziplinen langlebiger Specs
Beschreib Verhalten und lass Raum für die Implementierung
Die erste Disziplin ist einfach. Spezifiziere Verhalten, nicht Implementierungen.
Schlechte Zeile in einer Spec:
- Brüchige Anweisung: „Füge
handleGoogleAuthinauth.tshinzu, aktualisiere den Session-Serializer und schreib das Callback-Ergebnis nachusers.provider_id.“
Bessere Zeile:
- Stabiler Vertrag: „Man kann sich mit Google anmelden. Wenn das Konto schon existiert, wird Google als zusätzliche Anmeldemethode verknüpft. Der bestehende Login mit E-Mail und Passwort muss weiter funktionieren.“
Die erste Version legt einen Weg durch die Codebase fest. Die zweite definiert den Vertrag, den Nutzende sehen. Dieser Vertrag kann ein Refactoring überleben.
Das ist keine abstrakte Reinheitslehre. Es ist praktisch. Ein spät gefundener Fehler kostet mehr. IBM und das Systems Sciences Institute berichteten, dass ein Fehler, der im Design gefunden wird, etwa das 1-Fache kostet, derselbe Fehler aber beim Coden das 6-Fache, beim Testen das 15-Fache und nach dem Release das 100-Fache oder mehr kosten kann. Diese Spanne wird oft angeführt, um dafür zu argumentieren, Einschränkungen und Validierung früh in der Spec festzuhalten, statt sie bis zu späteren Änderungen implizit zu lassen – zusammengefasst in dieser Diskussion über Fehlerkosten im Zeitverlauf.
Markiere Entscheidungen, damit die Geschichte erhalten bleibt
Die zweite Disziplin ist der Status von Entscheidungen. Nutze Proposed / Accepted / Superseded.
Klingt langweilig, bis du ein Feature Monate später wieder aufmachst und dich nicht erinnerst, warum du den ersten Weg verworfen hast. Eine Spec ohne Entscheidungshistorie zwingt dich, alte Fehler neu zu entdecken.
Ein einfaches Muster reicht:
| Entscheidung | Status | Notiz |
|---|---|---|
| Gehostete Suche für v1 nutzen | Accepted | Schneller ausgeliefert, als jetzt eine eigene Ranking-Logik zu bauen |
| Tippfehlertoleranz in der App-Schicht ergänzen | Superseded | Ersetzt durch die Query-Einstellungen des Anbieters |
| Auth neu bauen, bevor SSO dazukommt | Proposed | Blockiert, bis die aktuellen Session-Bugs eingegrenzt sind |
In r/ClaudeCode hob ein Thread über ADRs hervor, wie wertvoll es ist, nicht nur festzuhalten, was entschieden wurde, sondern auch, was abgelöst wurde. Das verhindert, dass Teams zu gescheiterten Wegen zurückkehren, ohne sich zu erinnern, warum sie überhaupt gescheitert sind – nachzulesen in diesem Reddit-Thread über ADRs und die Historie abgelöster Entscheidungen.
Halte Sackgassen fest. Dein künftiges Ich gehört zu den wichtigsten Lesern der Spec.
Bau Überprüfungsauslöser ein, bevor du sie brauchst
Die dritte Disziplin wird oft übersprungen. Bau Überprüfungsauslöser in die Spec ein.
Beispiele:
- Abhängigkeits-Auslöser: Diesen Abschnitt prüfen, wenn sich die Version der Stripe-API ändert.
- Traffic-Auslöser: Annahmen zum Rate Limit prüfen, wenn Hintergrundjobs anfangen, Uploads zu bündeln.
- Architektur-Auslöser: Zuständigkeit für Dateien prüfen, wenn Auth von der Middleware an Service-Grenzen wandert.
- Produkt-Auslöser: Onboarding-Regeln prüfen, wenn eingeladene Team-Accounts live gehen.
Diese Zeilen wirken klein. Sie leisten viel. Sie geben zu, dass die Spec falsch werden wird, und sagen dir, wann du sie wieder aufmachen solltest.
Ohne Auslöser verfallen Specs. Mit Auslösern werden sie zu lebenden Docs, die an echte Ereignisse gebunden sind.
Specs für AI Agents schreiben, nicht nur für Menschen
Ein Mensch kann Lücken füllen. Ein AI Agent kann das meistens nicht. Das ändert, wie präzise du sein musst.
Beginn mit einem Rahmen, den Menschen lesen können
Addy Osmanis Spec-Format mit sechs Abschnitten ist eine gute Basis, weil es dich zwingt, Kontext von Handlung zu trennen: Hintergrund, Ziele, Nicht-Ziele, Implementierung, offene Fragen, Erfolgskennzahlen. Es ist gut lesbar. Und es macht sichtbar, wo Denkarbeit fehlt. Wenn du keine Nicht-Ziele aufschreiben kannst, hast du die Aufgabe vermutlich noch nicht eingegrenzt.
Für Solo Builder sind die Nicht-Ziele oft der wertvollste Abschnitt. Viele Refactoring-Ratschläge gehen davon aus, dass du immer weiter von Hand prüfen und polieren kannst, aber in kleinen Teams ist die Grenze die Kapazität, nicht die Disziplin. Deshalb zählen ausdrückliche Nicht-Ziele und testbare Akzeptanzszenarien, wenn die Zeit für Validierung knapp ist – so argumentiert dieser Text über Refactoring, Kapazität und weniger Nacharbeit.
Eine ordentliche Ausgangsform sieht so aus:
- Hintergrund: Welches Problem es im Produkt und in der Codebase gibt
- Ziele: Welches für Nutzende sichtbare Ergebnis eintreten muss
- Nicht-Ziele: Was diese Arbeit nicht verändern darf
- Implementierungshinweise: Einschränkungen, betroffene Systeme und bekannte Gefahren
- Offene Fragen: Was noch beantwortet werden muss
- Erfolgskriterien: Beobachtbare Ergebnisse, die du überprüfen kannst
Wenn du eine tiefere Einordnung willst, warum das beim agentischen Coden funktioniert, sind die KI-Einsichten von Samuel Woods hilfreich, weil sie über einmaliges Prompten hinaus in Richtung Kontextdesign gehen.
Dann mach sie wörtlich genug für eine Maschine
An der zweiten Ebene scheitern die meisten Specs. Sie lesen sich für Menschen gut und lassen einem Agent trotzdem zu viel Raum zum Improvisieren.
Ergänze diese Felder, wenn KI die Arbeit umsetzt:
Betroffene Dateien und Verzeichnisse
- Gib vollständige Pfade an, wenn du sie kennst.
- Wenn das Finden der Pfade Teil der Aufgabe ist, sag das ausdrücklich.
Geschützte Bereiche
- Benenne, was nicht verändert werden darf.
- Beispiel: „Das Verhalten der Session-Speicherung nicht verändern.“
Schnittstellenverträge
- Liste Endpoints, Events, Jobnamen, Erwartungen an das Schema und Fehlerbedingungen auf.
- Wenn der Agent eine Grenze nicht sicher ableiten kann, schreib sie aus.
Akzeptanzkriterien, formuliert wie Tests
- Beispiel: „WHEN jemand eine Datei hochlädt, die kein Bild ist, THEN antwortet die API mit 400 und die UI zeigt
Invalid file type.“ - Das ist viel besser als „Uploads ordentlich validieren“.
- Beispiel: „WHEN jemand eine Datei hochlädt, die kein Bild ist, THEN antwortet die API mit 400 und die UI zeigt
Ausgeschlossenes Verhalten
- Sag, was du in Ruhe lässt, auch wenn es hässlich ist.
- Brownfield-Arbeit braucht Zäune mehr als Inspiration.
Je wörtlicher die ausführende Umgebung, desto weniger kannst du dich auf unausgesprochene Absichten verlassen.
Wenn du ein praktisches Template für diesen Schreibstil brauchst, lohnt es sich, diesen Leitfaden zum Schreiben technischer Specs griffbereit zu haben.
Muster für lebende Specs, die Drift und Verfall verhindern
Eine Spec beginnt an dem Tag zu altern, an dem du sie schreibst. Der Trick ist, diesen Verfall so weit zu bremsen, dass sie nützlich bleibt.
Risiko-Tags zeigen, was am ehesten bricht
In unmarkierten Annahmen verstecken sich die Bugs von morgen. Mir haben „offensichtliche“ Annahmen mehr Ärger gemacht als die bekannten schwierigen Stellen.
Schreib Annahmen so:
- [ASSUMPTION LOW] Wer beim Billing ankommt, hat bereits eine verifizierte E-Mail-Adresse.
- [ASSUMPTION HIGH] Der Webhook-Anbieter liefert Events in einer vorhersehbaren Reihenfolge.
- [ASSUMPTION HIGH] Die bestehenden Worker für die Bildverarbeitung kommen mit dem neuen Bereich an Dateigrößen zurecht.
Der Tag ist wichtig, weil er dir sagt, wo du Review-Zeit investieren solltest. Wenn du allein arbeitest, zählt das mehr als perfekte Vollständigkeit. Meistens hast du nicht genug Zeit, jeden Satz gleich gründlich zu prüfen.
Eine lebende Spec braucht außerdem einen Ort, an dem sie in Würde altern kann. Das ist der Unterschied zwischen einem nützlichen Dokument und einem toten Artefakt. Wenn du die Einordnung dazu willst: dieser Text über lebende und eingefrorene Specs trifft den Unterschied genau.
Akzeptanzkriterien müssen beobachtbar sein
Viele Specs scheitern, weil sie Wünsche beschreiben statt Prüfungen.
Schlechte Beispiele:
- Vage: „Das Dashboard lädt schnell.“
- Vage: „Der Sync-Prozess sollte zuverlässig sein.“
- Vage: „Der Upload soll sich flüssig anfühlen.“
Bessere Beispiele:
- Beobachtbar: „Das Dashboard zeigt entweder geladene Daten oder einen sichtbaren Ladezustand. Es rendert nie eine leere Hülle ohne Status.“
- Beobachtbar: „Wenn der Sync mit dem Anbieter fehlschlägt, sieht man die Zeit des letzten erfolgreichen Syncs und eine Aktion zum erneuten Versuchen.“
- Beobachtbar: „Wenn die Upload-Validierung fehlschlägt, bleibt der Formularzustand erhalten, und der Fehler erscheint direkt neben dem Dateifeld.“
Du legst fest, was jemand von außerhalb des Systems sehen kann. Das ist die sicherste Ebene, um sie durch Refactorings zu retten.
Deshalb passen langlebige Specs auch gut zu einem Red/Green/Refactor-Vertrag. Definier zuerst das kleinste von außen sichtbare Verhalten und halte den Scope dann so eng, dass sich die Implementierung ändern kann, ohne den Vertrag neu zu schreiben. Das senkt das Regressionsrisiko, weil du Änderungen schrittweise validieren kannst – erklärt in diesem Refactoring-Leitfaden von TechTarget.
Hier ein schnelles Muster, das ich nutze:
| Schwaches Kriterium | Starkes Kriterium |
|---|---|
| „Ungültige Eingaben behandeln“ | „Nicht unterstützte Dateitypen mit einem sichtbaren Fehler ablehnen, ohne dass ein halber Datensatz angelegt wird“ |
| „Suchergebnisse verbessern“ | „Die Suche nach der vollständigen E-Mail-Adresse liefert genau das passende Konto in den Ergebnissen“ |
| „Onboarding verständlich machen“ | „Neue Accounts sehen die nächste erforderliche Aktion, bevor es weitergehen kann“ |
Ein kurzes Erklärvideo hilft hier:
Validierungsszenarien machen Refactorings sicherer
Mit Validierungsszenarien hört deine Spec auf, Kommentar zu sein, und wird zu ausführbarem Denken.
Nutze Given / When / Then für die riskanten Pfade:
Given jemand hat eine abgelaufene Einladung
When der Einladungslink geöffnet wird
Then erscheinen ein Abgelaufen-Status und eine Aktion, um eine neue Einladung anzufordernGiven ein erneuter Zahlungsversuch gelingt nach einem vorherigen Fehlschlag
When der Webhook zweimal ankommt
Then wird nur ein einziger erfolgreicher Zahlungsstatus gespeichertGiven jemand verliert mitten im Speichern die Netzwerkverbindung
When es über die UI erneut versucht wird
Then vermeidet das System doppelt angelegte Datensätze
Diese Szenarien erzwingen Klarheit. Sie helfen auch, echtes Refactoring von versehentlichen Verhaltensänderungen zu unterscheiden.
Typische Anti-Patterns, die ein Refactoring garantieren
Specs, die so tun, als wäre die Codebase sauber
Die „magische Spec“ ist das Dokument, das so geschrieben ist, als wäre die aktuelle App aufgeräumt, stimmig und offensichtlich. Das ist sie meistens nicht.
Wenn du dir den bestehenden Code nicht ansiehst, bevor du die Spec schreibst, übersiehst du die hässlichen Einschränkungen, die die Implementierung prägen. Dann entdeckt dein Agent sie für dich – spät, schlecht und mit Nebenwirkungen.
Am schnellsten erzeugst du das Refactoring von morgen mit einer Spec, die Folgendes ignoriert:
- Versteckte Abhängigkeiten: gemeinsame Utilities, Nebenwirkungen von Middleware, alte Callbacks oder Scheduler-Jobs
- Zuständigkeit für den Zustand: Welche Schicht für die Wahrheit verantwortlich ist
- Bestehende Fehlermodi: Timeouts, Retries, veraltete Caches, doppelte Events
- Geschütztes Altverhalten: Seltsames Verhalten, auf das sich Nutzende schon verlassen
Eine Spec für ein Brownfield-Feature, die das alte System nicht erwähnt, ist keine Spec. Sie ist Wunschdenken.
Refactorings, vermischt mit Feature-Arbeit
Das zweite Anti-Pattern ist, Aufräumen mit Verhaltensänderungen zu vermischen, weil „du ja sowieso schon drin bist“. Das vergrößert fast immer den Wirkungsradius.
Refactoring-Ratgeber wiederholen nicht ohne Grund immer denselben Punkt. Schreib oder prüf Tests, bevor du Code änderst. Vermisch Refactorings nicht mit neuen Features. Scope Creep macht aus einem sicheren Refactoring eine gefährliche Verhaltensänderung – so beschrieben in diesem Refactoring-Leitfaden von Cheesecake Labs.
Die Abkürzungen, die später wehtun, sind vorhersehbar:
- Specs, die bei der Implementierung anfangen: Sie legen Funktionen, Klassen und Schema-Entscheidungen fest, bevor du weißt, was das kleinste stabile Verhalten ist.
- Keine Nicht-Ziele: Der Agent wandert in benachbarte Systeme, weil nichts sie abgezäunt hat.
- Vergessene Abhängigkeiten: Die Spec nennt den neuen Endpoint, aber nicht den Cronjob, den Worker, die Policy, das Analytics-Event oder den Cache, die ebenfalls berührt werden.
- Gebündeltes Aufräumen: „Wo wir schon mal hier sind“ baut die Struktur um und fügt Features in einem Durchgang hinzu.
Wenn du dich bei dem Satz ertappst „Wir können das aufräumen und gleichzeitig den neuen Flow einbauen“, halt an und teile die Arbeit auf.
Dein Tool wählen und deinen Workflow einbinden
Die meisten Solo Builder sollten bei Spec-anchored bleiben
Birgitta Böckelers Einordnung ist nützlich, weil sie verhindert, dass man direkt zum extremsten Workflow springt. Es gibt einen Unterschied zwischen Spec-first, Spec-anchored und Spec-as-Source. Für die meisten Solo Founder mit einer bestehenden Codebase ist Spec-anchored der Sweet Spot.
Das heißt: Die Spec steht im Mittelpunkt, ist aber nicht heilig. Du schreibst sie vor der Implementierung. Du aktualisierst sie während der Implementierung. Du hältst sie an Tests, Grenzen und Entscheidungen gebunden. Aber du tust nicht so, als sollte das ganze System aus ihr generiert werden.
Dieser Mittelweg passt zur Natur von Brownfield-Arbeit. Du brauchst Struktur, aber auch Spielraum, um dich anzupassen, wenn das Repo am zweiten Tag etwas Unangenehmes offenbart.
Langfristiger Kontext ist das eigentliche Problem. In Foren wie r/VibeCodeDevs stoßen alle, die allein mit KI entwickeln, immer wieder auf dasselbe: Der Chatverlauf ist ein miserabler Ersatz für ein lebendes Dokument, das Architektur und sich entwickelnde Anforderungen über die Zeit festhält – nachzulesen in diesem Thread in r/VibeCodeDevs über langfristiges Kontextmanagement.
Wähl das leichteste Tool, das du auch weiter nutzt
Du brauchst kein riesiges Framework, wenn du es nicht pflegst. Du brauchst einen Workflow, der den echten Gebrauch überlebt.
Hier die Abwägungen aus praktischer Sicht:
| Option | Worin es gut ist | Wo es bricht |
|---|---|---|
| Schlichtes Markdown im Repo | Günstig, flexibel, schnell begonnen | Hängt stark von deiner Disziplin ab |
| GitHub Spec Kit | Starke Struktur und wiederholbare Templates | Kann sich bei chaotischen bestehenden Systemen starr anfühlen |
| OpenSpec | Brownfield-taugliche Delta-Specs und ein schlankerer Fußabdruck | Braucht trotzdem eine Gewohnheit für Review und Überprüfung |
| Tekk.coach | Loops lesen, was sich in deinem GitHub-Repo geändert hat, und schreiben Specs für dich als Proposals, die du mit Greenlight freigibst; Akzeptanzkriterien und eine Checkliste schließen jede Spec, sobald ihr PR gemergt ist | Ein weiteres Tool in deinem Stack, und derzeit nur für GitHub |
Das ist die entscheidende Frage. Nicht, welche Marke gewinnt. Sondern welchen Loop du durchhalten kannst.
Ein einfaches Setup, das ich den meisten Solo Buildern empfehlen würde, sieht so aus:
Halte Specs in der Versionskontrolle
- Die Spec sollte nah am Code liegen, nicht in Chat-Threads, die verschwinden.
Nutze ein einziges kanonisches Template
- Erfinde nicht jede Woche ein neues Format.
- Nimm Ziele, Nicht-Ziele, betroffene Systeme, Annahmen, Entscheidungen, Überprüfungsauslöser und Validierungsszenarien auf.
Gib die Spec von Hand an den Agent
- Prüf das Ergebnis dann gegen die Akzeptanzkriterien, nicht nach Bauchgefühl.
Aktualisiere die Spec nach wesentlichen Erkenntnissen
- Vor allem, wenn eine Entscheidung von Proposed zu Accepted oder von Accepted zu Superseded wechselt.
Trenne Notizen zu technischen Schulden vom aktuellen Scope
- Wenn du Aufräumbedarf nebenan siehst, notier ihn. Nimm ihn nicht mit auf.
Für eine breitere Einordnung, wie Teams über den Aufräumdruck durch KI-generierte Arbeit nachdenken, lohnen sich diese Einsichten zum Umgang mit technischen Schulden durch KI.
Wenn du in Brownfield-Code arbeitest, hängt die Wahl des Tools auch davon ab, wie viel Zeremonie du aushältst. OpenSpec lohnt einen Blick für Specs im Delta-Stil. GitHub Spec Kit ist nützlich, wenn du mehr Struktur willst. Wenn du Ansätze für bestehende Repositories vergleichst, passt der Brownfield-Fokus von OpenSpec meist besser zur Solo-Arbeit als schwerere Prozess-Stacks. Wenn du eine breitere Kritik suchst, wo diese Workflows helfen und wo sie zur Zeremonie werden, ist Seite 47 zur ehrlichen Kritik lesenswerter als die meisten Landingpages von Tools. Für den Realitätscheck im Repo lohnt auch Seite 39 zu SDD im Brownfield, und der zentrale Hub zu Spec-driven Development verbindet die Modelle.
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, und der Merge, der die Arbeit abschließt, schließt auch die Spec – so bleibt sie nicht als Refactoring von morgen liegen.
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.