Die meisten Ratschläge zu Spec-driven Development verdrehen einen Punkt. Sie halten das Schreiben der Spec für den schwierigen Teil. Ist es nicht. Schwierig ist, die Spec wahr zu halten, nachdem dich die Umsetzung zum ersten Mal wirklich überrascht hat.

Deshalb hat die Gegenbewegung teilweise recht. Viele Spec-first-Workflows sind tatsächlich Wasserfall mit Markdown. Du bekommst ein poliertes Dokument, einen Schwall Agent-Output, und drei Stunden später passen Code und Plan nicht mehr zusammen. Ab da ist die Spec keine Orientierung mehr. Sie ist Schutt.

Als Solo Builder trifft dich dieses Scheitern härter. Niemand korrigiert als Product Manager den Scope, niemand fängt als Staff Engineer architektonischen Drift ab, und kein Team hält die Docs aktuell. Wenn du mit Cursor, Claude Code, Codex oder Gemini arbeitest, werden veraltete Specs zu frischen Fehlern. Schnell.

Die sinnvolle Trennlinie verläuft nicht zwischen Spec-driven und gar keinen Specs. Sie verläuft zwischen Living Specs und Frozen Specs.

Hier die Kurzfassung.

Dimension Living Spec Frozen Spec
Rolle Source of Truth, mit der du arbeitest Kickoff-Artefakt
Zustand, sobald das Coden beginnt Wird mit neuen Erkenntnissen aktualisiert Bleibt liegen
Verhältnis zum Code Folgt der Realität Driftet von der Realität weg
Bester Einsatzzweck Mehrstufige Arbeit, Arbeit mit Agents, Architekturänderungen Winzige Aufgaben, die du erledigst, bevor sich der Kontext verschiebt
Fehlerbild Etwas Pflegeaufwand Fehlleitung, Nacharbeit, Verwirrung
Wie es sich anfühlt Leichtgewichtiges Steuern Wasserfall mit Markdown

Wenn du dir nur einen Satz merkst, dann diesen: Living Specs ändern sich mit dem Code. Frozen Specs fangen an zu lügen, sobald die Arbeit vom Plan abweicht.

Inhalt

Die Kritik an Spec-driven Development hat in einem Punkt recht

Die Kritik ist nicht falsch. Wenn du eine Spec schreibst, sie zur Wahrheit erklärst und dann gegen sie codest, ohne sie zu aktualisieren, hast du Wasserfall in einem hübscheren Dateiformat nachgebaut.

Simon Willison hat genau hier von der praktischen Seite aus nachgehakt. Auch Birgitta Böckelers Taxonomie hilft weiter. Der Unterschied liegt nicht darin, ob vor dem Coden eine Spec existiert. Der Unterschied liegt darin, ob die Spec während der Umsetzung veränderbar bleibt. Addy Osmanis Format mit sechs Abschnitten kann gut funktionieren. Es kann aber auch zur Zeremonie werden, wenn es nach dem Kickoff niemand mehr anfasst.

Jemand sitzt frustriert am Bürotisch vor einem Stapel qualmender, verstaubter Ordner voller Anforderungsdokumente.

Der Ausdruck Wasserfall mit Markdown sitzt, weil viele ihn selbst erlebt haben. Sie schreiben ein schönes Dokument, geben es einem Agent und verbringen den Rest der Aufgabe damit, all das auszugleichen, was das Dokument nicht vorhergesehen hat. Diese Kritik ist berechtigt. Die Antwort ist nicht „hör auf, Specs zu nutzen“. Die Antwort ist „hör auf, sie einzufrieren“.

Eine hilfreiche Analogie kommt von außerhalb der Softwarewelt. Eine Studie in Human Reproduction ergab, dass ein dynamisches, anpassbares Protokoll für IVF-Zyklen zu höheren kumulativen Erfolgsraten führte als ein starrer Freeze-all-Plan. Das stützt einen allgemeineren Punkt über Pläne, die sich an Echtzeit-Feedback anpassen können, im Vergleich zu Plänen, die vorab festgezurrt werden (Kohortenstudie in Human Reproduction). Anderes Fachgebiet, gleiche Lektion. Wenn sich die Umgebung ändert, während du umsetzt, schneiden starre Pläne schlechter ab.

Praxisregel: Wenn sich die Spec nach Beginn der Umsetzung nicht mehr ändern darf, hilft sie dir nicht beim Denken. Sie zwingt dich, so zu tun, als hättest du nichts gelernt.

Für Solo Builder ist das die wichtigste Trennlinie zwischen nützlichem SDD und Prozesstheater. Eine Living Spec ist einfach ein Dokument, das mit der Realität verbunden bleibt. Eine Frozen Spec ist technische Schuld, verkleidet in Produktsprache.

Wenn du das größere Argument dazu suchst, wann Specs dich schneller machen und wann sie bremsen, lies Tekks Einschätzung dazu, wann Specs dich ausbremsen und wann sie helfen.

Die Frozen-Spec-Falle: Warum die meisten Specs nutzlos werden

Die meisten Specs scheitern nicht beim Schreiben. Sie scheitern in den Stunden nach dem ersten Commit.

Das Muster ist vorhersehbar. Du startest mit klarer Absicht. Dann bringt die Umsetzung Edge Cases, versteckte Abhängigkeiten, Namenskonflikte oder einen UI-Flow ans Licht, der erst Sinn ergibt, wenn du den Code anfasst. Der Code ändert sich. Die Gespräche ändern sich. Die Spec nicht.

Eine Infografik zu den vier Phasen der Frozen-Spec-Falle in Softwareprojekten von Teams.

Der Drift beginnt früher als gedacht

Eine Frozen Spec stirbt meist in vier Schritten:

  1. Optimismus beim Kickoff. Das Dokument wirkt vollständig genug, um loszulegen.
  2. Die Realität drängt sich auf. Du entdeckst Einschränkungen, die bei der Planung nicht offensichtlich waren.
  3. Die Diskussion verlässt das Dokument. Entscheidungen wandern in den Chat, in Commit-Messages, auf Notizzettel und in deinen Kopf.
  4. Der Datei kann man nicht mehr trauen. Du hörst auf, sie zu lesen, weil das einfacher ist, als Wahrheit von Vergangenheit zu trennen.

Das ist die Falle. Eine veraltete Spec ist nicht neutral. Sie führt dein zukünftiges Ich aktiv in die Irre.

Ein Grund dafür ist das Format selbst. In Community-Threads über KI-first-Workflows kreisen viele immer wieder um dieselbe Beschwerde: Markdown allein erzwingt keine Wahrheit. Eine .md-Datei kann direkt neben dem Code liegen und trotzdem unbemerkt verrotten. Der Thread auf /r/VibeCodeDevs über Kontextmanagement fängt diesen Schmerz gut ein. Das Dokument existiert, aber nichts erzwingt die Synchronisierung.

Die Symptome sind offensichtlich, wenn du hinschaust

Einen Frozen-Spec-Workflow erkennst du meist schnell:

  • Der PR oder Commit erwähnt die Spec nicht. Es wurde gearbeitet, aber das Quelldokument hat sich nicht bewegt.
  • Offene Fragen leben woanders. Slack, Discord, Notiz-App, Terminal-History.
  • Der Status ist implizit, nicht ausgesprochen. Niemand weiß, ob die Spec vorgeschlagen, aktiv, veraltet oder tot ist.
  • Du zögerst, bevor du dem Dokument vertraust. Genau dieses Zögern ist das Signal.

Eine ähnliche Frustration taucht in Diskussionen unter Devs darüber auf, wie man KI-Nutzung standardisiert. Das Problem ist nicht nur „Wie schreiben wir Specs?“. Es ist „Wie verhindern wir, dass sie zur abgestandenen Zeremonie werden, sobald die Aufgabe ernst wird?“. Die Antwort ist meist kein ausgefeilteres Template, sondern eine straffere Update-Mechanik.

Wenn du eine parallele Sicht aus dem Blickwinkel eines KI-Dokumentations-Workflows willst, lohnt sich der Beitrag von Halo AI darüber, wie KI hilft, Docs ehrlich zu halten, weil er sich auf das operative Problem konzentriert, nicht auf das ästhetische.

Frozen Specs explodieren selten. Sie verfallen. Deshalb tolerieren Teams sie zu lange.

Das Schlimmste ist, dass sich Frozen Specs verantwortungsvoll anfühlen. Sie sehen nach Sorgfalt aus. Aber wenn du als Solo Founder unter Zeitdruck auslieferst, kosten sie dich doppelt Zeit. Einmal beim Schreiben. Und noch einmal, wenn du um sie herumarbeitest.

Anatomie einer Living Spec

Eine Living Spec ist keine philosophische Haltung. Sie ist ein Dokument mit ein paar eingebauten Mechanismen, die Drift sichtbar und Überarbeitung normal machen.

Hier hilft Birgitta Böckelers Kategorie spec-anchored. Die Spec steht im Zentrum, ist aber nicht heilig. Sie bleibt editierbar, weil dir die Umsetzung Dinge beibringt. Auch Addy Osmanis Spec-Leitfaden ist nützlich, besonders der Gedanke, dass das Dokument genug Struktur braucht, um Überarbeitungen zu überstehen, statt in Fließtext zu zerfallen.

Eine Infografik mit dem Titel „Anatomy of a Living Spec“, die vier zentrale Bestandteile einer dynamischen Projektdokumentation erklärt.

Die minimalen Metadaten, die eine Spec am Leben halten

Du brauchst kein riesiges Framework. Du brauchst Metadaten, die grundlegende operative Fragen beantworten.

Nutze Frontmatter wie dieses:


---
title: Billing retry flow rewrite
status: active
version: 1.2.0
created: 2026-06-12
updated: 2026-06-12
owner: founder
supersedes: ./billing-retry-flow-v1.1.0.md
superseded_by:
review_trigger:
  - schema change
  - prompt change
  - new edge case found in implementation
related_code:
  - app/services/billing/retry.ts
  - app/api/webhooks/stripe.ts

---

Die wichtigen Felder sind einfach:

  • status sagt dir, ob die Datei noch im Spiel ist.
  • version gibt dir eine Historie, die zu Entscheidungen passt, nicht nur zu Commits.
  • supersedes / superseded_by verhindert, dass alte Docs wie Landminen herumliegen.
  • review_trigger sagt dir, wann das Dokument erneut geprüft werden muss.

Ohne diese Felder verlässt du dich auf dein Gedächtnis. Und am Gedächtnis scheitern Solo-Workflows.

Eine Living Spec sollte drei Fragen in Sekunden beantworten: Ist sie aktuell? Wodurch wurde sie ersetzt? Welchen Code betrifft sie?

Wenn du eine ergänzende Anleitung suchst, um wirksamere Spec-Dokumente zu schreiben, hat AIDictation einen praxisnahen Beitrag über wirksame Spec-Dokumente, der gut zu diesem Living-Spec-Ansatz passt.

Die Dokumentform, die wirklich funktioniert

Eine gute Living Spec muss nicht lang sein. Sie muss sich aktualisieren lassen.

Diese Form funktioniert gut für Solo Builder:

Abschnitt Was hineingehört Warum es wichtig ist
TL;DR Die Aufgabe in einfachen Worten Bewahrt dich davor, in Implementierungsdetails zu ertrinken
Scope-Grenzen Was drin ist und was nicht Stoppt schleichende Ausweitung
Annahmen und Risiken Unbekanntes, Abhängigkeiten, Stolperfallen Macht Überarbeitung zum Normalfall
Teilaufgaben Geordnete Schritte Gibt Agents und Menschen eine Reihenfolge
Akzeptanzkriterien Beobachtbare Fertig-Zustände Verhindert schwammige Fertigmeldungen
Änderungsprotokoll Was sich während der Umsetzung geändert hat Hält die Historie an der Spec fest

Ein paar Gewohnheiten sorgen dafür, dass das funktioniert:

  • Aktualisiere an Übergangspunkten. Warte nicht bis zum Ende. Aktualisiere, wenn sich der Scope ändert, wenn du auf einen Blocker stößt oder wenn du einen anderen Weg wählst.
  • Schreib Entscheidungen auf, kein Tagebuch. „Auf Webhook-first-Retry umgestellt, weil der Cron-Pfad mit der bestehenden Idempotenz-Logik kollidiert“ ist nützlich. Eine Zusammenfassung im Bewusstseinsstrom nicht.
  • Markiere konsequent als veraltet. Wenn eine Spec den eingeschlagenen Weg nicht mehr widerspiegelt, markiere sie als veraltet oder abgelöst. Lass sie nicht halb wahr herumliegen.

Eine Living Spec ist weniger ein Vertrag als eher ein ADR, das an laufender Arbeit hängt. Deshalb kommen die ADR-Diskussionen in KI-Coding-Communities so gut an. Sie bewahren Entscheidungen, ohne so zu tun, als wäre die erste Version endgültig gewesen.

Workflows und Tools für Living Specs

Die Mechanik zählt mehr als die Ideologie. Wenn dein Workflow die Realität nicht zurück in die Spec zwingt, driftet die Spec, egal wie gut dein Template aussieht.

Manche Solo Builder schaffen das mit reinem Markdown und Disziplin. Andere brauchen einen strukturierten Loop, damit das Dokument nicht aufgegeben wird, wenn das Coden chaotisch wird. Beide Ansätze können funktionieren.

Ein Diagramm in sechs Schritten, das den automatisierten Workflow zum Verwalten, Validieren und Aktualisieren lebendiger technischer Specs zeigt.

Manueller Workflow, wenn du null Zeremonie willst

Das leichteste brauchbare Setup lebt in deinem Repo.

Leg einen /specs-Ordner an. Eine Datei pro aktivem Vorhaben. Die Regel ist einfach: Wenn sich Code so geändert hat, dass es Absicht, Scope, Akzeptanzkriterien oder Architektur betrifft, ändert sich die Spec in derselben Arbeitssession.

Ein manueller Loop sieht so aus:

  • Starte mit status: proposed. Schreib die kleinste nützliche Spec, bevor du Code anfasst.
  • Stell auf active um, wenn die Umsetzung beginnt. Diese kleine Statusänderung zählt. Sie markiert die Datei als lebendiges, operatives Dokument.
  • Häng eine kurze Änderungsnotiz an, wenn sich die Realität verschiebt. Scope gekürzt, Komponente umbenannt, Schema angepasst, Abhängigkeit entdeckt.
  • Schließ mit completed, deprecated oder superseded ab. Lass den Endzustand nie offen.

Für viele Indie-Projekte reicht das. Es funktioniert am besten, wenn eine Person die ganze Aufgabe verantwortet und die Aufgabe fertig ist, bevor der Kontext verdunstet.

Strukturierter Workflow, wenn Disziplin allein immer wieder scheitert

Wenn dein Markdown-Ordner zum Friedhof wird, ergänze eine Workflow-Schicht.

GitHubs Spec Kit ist eine Option. OpenSpec ist eine weitere nützliche Referenz, weil es den Lebenszyklus mit Propose / Apply / Archive explizit macht. Diese Struktur leistet etwas Wichtiges. Sie behandelt das Ablösen einer Spec als Normalfall statt als Zeichen dafür, dass die ursprüngliche Spec gescheitert ist.

Hier ein praktisches Spektrum:

Ansatz Passt gut, wenn Schwäche
Reines Markdown im Repo Du diszipliniert bist und allein arbeitest Updates gehen leicht vergessen
Template plus Repo-Konventionen Du Konsistenz ohne viel Tooling willst Hängt trotzdem an Gewohnheit
Spec-Workflow-Frameworks wie OpenSpec Du explizite Zustände im Lebenszyklus willst Etwas mehr Setup
Planungstools, die deine Codebase kennen Du die Spec eng an die Realität im Repo koppeln willst Prüfen und überarbeiten musst du trotzdem selbst

Die richtige Wahl ist das kleinste System, das du tatsächlich aktuell hältst.

Ein nützliches Muster ist ein Review-Rhythmus, der an Ereignisse gekoppelt ist statt an das schlechte Gewissen beim Blick in den Kalender. Prüf die Spec, wenn eines davon passiert:

  • Ein Prompt ändert die Richtung. Der Agent brauchte eine neue Anweisung, weil der ursprüngliche Plan falsch oder unvollständig war.
  • Die Liste der berührten Dateien wächst. Die Arbeit schwappt in Bereiche außerhalb der ursprünglichen Scope-Grenze.
  • Ein Akzeptanzkriterium wird unmöglich oder irrelevant.
  • Du entdeckst eine Designentscheidung, die es wert ist, festgehalten zu werden.

Dieses ereignisgesteuerte Review funktioniert für Solo Builder besser als „Docs jeden Freitag aktualisieren“. Freitagsrituale fallen aus. Updates, die von der Arbeit selbst ausgelöst werden, nicht.

Wenn du das in einen Agent-Workflow einpassen willst statt in einen klassischen Teamprozess, ist Tekks Leitfaden zu einem AI-Agent-Workflow eine nützliche Ergänzung, weil er die Übergabe und den Überarbeitungs-Loop um die tatsächliche Umsetzung herum aufbaut.

Warum KI-Coding-Agents Living Specs brauchen

KI-Coding-Agents nehmen alles wörtlich, und zwar auf die denkbar schlechteste Art. Sie wissen nicht, welchen Teilen deiner veralteten Spec sie misstrauen sollen. Sie gehen davon aus, dass die Karte, die du ihnen gibst, noch zum Gelände passt.

Dadurch sind Frozen Specs in der Entwicklung mit Agents viel gefährlicher als beim Coden von Hand. Wer selbst codet, merkt, dass das Dokument alt ist, und gleicht das aus. Ein Agent setzt oft sauber das Falsche um.

Agents folgen der Karte, die du ihnen gibst

An diesem Punkt sind Living Specs kein „netter Prozess“ mehr, sondern eine operative Notwendigkeit.

Eine Studie zu 600 abgelehnten KI-generierten Pull Requests ergab, dass Alignment-Verlust während der Ausführung mehr Fehlschläge verursachte als eine anfangs fehlerhafte Aufgabenbeschreibung. Das ist ein starkes Signal dafür, dass Drift während der Umsetzung in mehrstufigen KI-Workflows das größere Risiko ist (Augment Code über Living Specs vs. statische Specs).

Dieser Befund deckt sich mit dem, was Builder in der Praxis sehen. Der erste Prompt ist oft gut genug. Das Scheitern passiert später, wenn sich die Codebase mitten in der Aufgabe weiterentwickelt und die ursprüngliche Spec nicht.

Der Agent ist nicht verwirrt. Er gehorcht veralteten Anweisungen.

Deshalb fühlt sich Prompting bei großen Aufgaben oft teuer und seltsam fragil an. Du zahlst nicht nur für die Generierung. Du zahlst für wiederholte Versuche gegen veralteten Kontext.

Für einen breiteren Blick darauf, wie KI-gestützte Entwicklung die Planung verändert, packt Tekks Artikel über Codebase-aware AI Planning dasselbe Problem von der Planungsseite an.

Wo Frozen Specs Agent-Workflows kaputtmachen

Das Fehlermuster sieht meist so aus:

  • Die Spec sagt, eine Komponente soll die Logik übernehmen.
  • Die Umsetzung zeigt, dass die Logik stattdessen in eine Service-Schicht gehört.
  • Du passt den Code an, aber nicht die Spec.
  • Der nächste Agent-Durchlauf baut wieder Arbeit an der falschen Stelle ein, weil das Dokument es immer noch so sagt.

Oder so:

  • Die Akzeptanzkriterien wurden geschrieben, bevor du den tatsächlichen Edge Case gesehen hast.
  • Du entdeckst den Edge Case beim Testen.
  • Du umschiffst ihn mit einem Patch im Code.
  • Der nächste Lauf „repariert“ deinen Patch, weil der Agent die alten Akzeptanzkriterien immer noch für maßgeblich hält.

Wenn du mobile oder plattformübergreifende Produkte baust und Codegenerierung im Spiel ist, liefert der Beitrag von AppLighter, wie KI deine Produktivität mit React Native steigert, nützlichen Kontext, weil er zeigt, wie stark die Qualität des Outputs davon abhängt, wie klar und aktuell deine Vorgaben sind.

Living Specs lösen das, indem sie die Lücke zwischen Planung und Ausführung verkleinern. Nicht perfekt. Aber genug, damit der Agent weiter in die aktuelle Richtung zieht, statt tote Entscheidungen wiederzubeleben.

Ein Entscheidungsrahmen für Solo Builder

Du brauchst nicht für jede Aufgabe eine Living Spec. Für manche Arbeit wäre das übertrieben. Der Trick ist zu wissen, wann „kurz eine Notiz und los“ reicht und wann dich diese Abkürzung später teuer zu stehen kommt.

Screenshot von https://tekk.coach

Wann eine Frozen Spec in Ordnung ist

Eine Frozen Spec ist akzeptabel, wenn alles davon zutrifft:

  • Die Aufgabe ist winzig. Du rechnest damit, fertig zu sein, bevor sich der Kontext verschiebt.
  • Der Wirkungsradius ist klein. Ein kleiner Bug, eine isolierte Komponente, ein offensichtlicher Fix.
  • Es gibt keine nennenswerten Architekturentscheidungen. Du legst keine Patterns, Grenzen oder Datenverträge fest.
  • Du brauchst das Dokument später nicht. Die Notiz ist nur eine vorübergehende Startrampe.

In diesem Fall reicht ein kurzes, statisches Briefing. Aufgabe aufschreiben, erledigen, Notiz wegwerfen.

Wann eine Living Spec Pflicht ist

Sobald die Aufgabe nicht mehr trivial ist, kippt die Kostenrechnung.

Nutze eine Living Spec, wenn auch nur eines davon auf die Arbeit zutrifft:

Signal Warum es wichtig ist
Mehrstufige Umsetzung Drift verstärkt sich von Durchlauf zu Durchlauf
Mehrere Dateien oder Schichten betroffen Der Plan ändert sich, wenn Abhängigkeiten auftauchen
Architektur- oder Schemaänderungen Du brauchst eine dauerhafte Entscheidungshistorie
Ein AI Agent arbeitet mit Veraltete Anweisungen werden wörtlich ausgeführt
Arbeit, die wahrscheinlich pausiert und wieder aufgenommen wird Dein zukünftiges Ich braucht einen wahrheitsgetreuen Stand
Unklarer Scope Die Spec muss Erkenntnisse aufnehmen, nicht leugnen

Wenn du Tooling dafür willst, passt Tekk.coach zum Living-Spec-Modell. Seine Loops lesen, was sich in deinem GitHub-Repo geändert hat, und schreiben Specs für dich als Proposals; du kannst auch selbst eine schreiben. Jede Spec hat Akzeptanzkriterien und eine Checkliste und wird erst geschlossen, wenn ein PR mit Closes TEK-123 gemergt wird und die Checkliste erledigt ist. Hinkt der Status hinter dem her, was gemergt wurde, meldet Tekk das. Das ist nützlich, wenn du Specs willst, die deine Codebase kennen, ohne so zu tun, als müsste der erste Entwurf eingefroren bleiben.

Wenn dich die Aufgabe überraschen kann, muss sich die Spec ändern dürfen.

Das ist die ganze Entscheidungsregel.

So startest du morgen mit Living Specs

Fang nicht mit einem Framework an. Fang mit einer Gewohnheit an.

Leg für deine nächste nicht triviale Aufgabe eine Markdown-Datei in deinem Repo an und schreib das hier ganz oben hinein:


---
title: [task name]
status: proposed
updated: 2026-06-12

---

Wenn du anfängst zu coden, ändere proposed zu active.

Wenn dir die Umsetzung etwas Wichtiges beibringt, füge unter einer Überschrift ## Change log eine kurze Notiz hinzu. Nicht jeden Gedanken. Nur die Entscheidungen, die die Form der Arbeit verändert haben. Wenn du den Plan aufgibst, markiere ihn als deprecated. Wenn eine neue Datei ihn ersetzt, füge superseded_by hinzu.

Das reicht, um den Muskel aufzubauen.

Wenn du noch eine nützliche Regel willst, leih sie dir von den ADR-Gewohnheiten, die in KI-Coding-Communities diskutiert werden. Behandle jede wesentliche Entscheidung als etwas, das es wert ist, dort festgehalten zu werden, wo die Arbeit ohnehin lebt. Nicht im Chat. Nicht in deinem Kopf. In der Datei, die der nächste Agent-Lauf liest.

Ein minimales Starter-Template:


---
title: Add invoice retry guard
status: active
version: 0.1.0

---

## TL;DR
Prevent duplicate retries when webhook and manual retry overlap.

## Scope
In: retry guard, idempotency check
Out: full billing refactor

## Acceptance criteria
- Duplicate retry attempt is ignored
- Existing success path still works

## Change log
- Moved guard from controller to service after implementation exposed shared call path

Mach das eine Woche lang, und du spürst den Unterschied. Das Dokument ist keine Zeremonie mehr, sondern wirkt wie ein Gedächtnis, dem du trauen kannst.

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, und der Merge, der die Arbeit abschließt, schließt auch die Spec. Keine Spec bleibt eingefroren.

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.