Die meisten Ratschläge zum Coding mit KI gehen immer noch davon aus, dass ein einziger Agent alles erledigen soll. Die Spec schreiben. Die Arbeit planen. Den Code ändern. Den Diff reviewen. Die Regressionen finden. Klingt sauber. Es fällt aber in dem Moment auseinander, in dem die Session abdriftet, das Modell zu clever wird oder dein Repo über Spielzeuggröße hinauswächst.
Wenn du allein baust, geht es bei Spec-driven Development mit deinem Coding-Agent-Stack nicht um Zeremonie. Es geht darum, aus chaotischen Tools vorhersehbaren Output zu holen. Die verbreitete Kritik an Specs hat Biss. Manches davon ist verdient. Aber die Alternative ist keine Freiheit. Sie heißt Nacharbeit, verbrannte Tokens und Code, dem du nach der dritten „kleinen“ Änderung nicht mehr traust.
Inhalt
- Der Gegenwind für Spec-driven Development ist da – und er hat recht
- Eine Spec, sie alle zu knechten
- Agent im Detail: Claude Code
- Agent im Detail: Cursor
- Der richtige Agent für den Job: Copilot, Codex und Gemini
- Die Kunst der Übergabe zwischen Agents
- Deinen Spec-driven Workflow aufbauen
Der Gegenwind für Spec-driven Development ist da – und er hat recht
Der Gegenwind ist real. Im Mai 2026 bezog Spec-driven Development bereits Prügel als „Wasserfall mit Markdown“, „Produktivitätsfalle“ und „Spec Drift“. Yuval Yeret hat es noch genauer benannt. Teams erlebten, dass das Refinement demotivierend wurde, weil eine Person schon mit einer detaillierten Aufschlüsselung auftauchte, bevor das Gespräch überhaupt begonnen hatte. Das ließ weniger Raum für Schätzungen und weniger sinnvollen Umsetzungsaufwand, sobald KI mit im Loop war, wie er in seiner Kritik an Spec-driven Development schreibt.
Die Kritik sitzt, weil schlechtes SDD leicht zu erkennen ist. Jemand schreibt eine riesige Markdown-Datei. Niemand widerspricht. Der Agent führt sie blind aus. Und dann tut das Team so, als sei die Spec die Wahrheit, auch nachdem sich das Produkt längst verändert hat.
Schlechtes SDD sieht genau so aus, wie die Kritik sagt
Die schlimmste Version hat alle Fehlerbilder, über die sich Leute beschweren:
- Eingefrorene Specs: einmal geschrieben, dann weitergecodet, obwohl sich die Realität geändert hat.
- Zeremonie, die Tokens verbrennt: Jede Aufgabe beginnt mit einem riesigen Kontext-Dump, weil die Spec nicht strukturiert genug ist, um sie wiederzuverwenden.
- Spec Drift: Code und Spec laufen auseinander, und jetzt lügen beide.
- Pseudo-Wasserfall: Die Planung wird nach vorn gezogen, aber das Feedback kommt trotzdem spät.
Simon Willison macht sich seit Längerem stark für Engineering-Disziplin beim Arbeiten mit Coding-Agents. Birgitta Böckelers Einteilung in spec-first, spec-anchored und spec-as-source ist aus demselben Grund wichtig. Das ist nicht alles dasselbe. Der meiste Gegenwind zielt auf das starre Ende des Spektrums, nicht auf die pragmatische Mitte, in der eine Spec Entscheidungen verankert, aber trotzdem überarbeitet wird.
Schlechte Specs verringern das Chaos nicht. Sie verlegen es nur nach vorn.
Thoughtworks Tech Radar, GitHub Spec Kit, Kiro, OpenSpec, Traycer, Vibe Kanban und BMAD stehen alle irgendwo in dieser Debatte. Manche behandeln die Spec als festen Vertrag. Manche als geführten Kontext. Manche packen das Ganze in so viel Prozess, dass es alle Solo Founder unter Lieferdruck in die Flucht schlägt.
Warum Solo Builder trotzdem Specs brauchen
Wenn du allein bist oder ein winziges, KI-lastiges Team führst, schaut dir kein Senior Engineer bei jeder generierten Änderung über die Schulter. Das verändert die Rechnung. Die Spec ist nicht dazu da, dem Prozess zu gefallen. Sie ist da, weil dein Coding-Agent die Lücken sonst mit Vermutungen füllt.
Das Schwierige ist nicht, mehr Worte zu schreiben. Sondern die wenigen Worte, die teure Fehler verhindern.
Dazu kommt ein ganz praktischer Sicherheitsgrund. LLMs erzeugen je nach Benchmark in 9,8 % bis 42,1 % der Fälle verwundbaren Code, und das stärkste Argument für SDD ist, dass es passive Dokumentation in ausführbare Verträge verwandelt, die den Output von Agents einschränken – so fasst es der Guide von Augment Code zu Spec-driven Development zusammen. Unit-Tests fangen Architekturverstöße oder API-Drift nicht zuverlässig ab. Eine präzisere Spec schon.
Für Solo Builder lautet die richtige Antwort nicht: keine Specs. Sondern kleinere Specs, lebendige Specs und weniger Lügen.
Eine Spec, sie alle zu knechten
Du brauchst eine Spec, die die Übergabe überlebt. Nicht einen Prompt für Claude, eine andere Notiz für Cursor und eine halb erinnerte Checkliste für Gemini. Ein Dokument. Klein genug, um es noch einmal zu lesen. Strukturiert genug, dass verschiedene Agents es ohne kreative Interpretation verarbeiten können.
Was eine portable Spec braucht
Addy Osmanis kanonischer Aufbau mit sechs Abschnitten ist eine starke Basis, weil er dich zwingt, die Absicht vom Rauschen der Umsetzung zu trennen. Für die Arbeit über mehrere Agents hinweg halte ich das Format sogar noch strenger.
Eine portable Spec sollte sechs Dinge schnell beantworten:
TL;DR
Was sich ändert, für wen und warum jetzt.Scope-Grenzen
Was diese Spec abdeckt und was ausdrücklich nicht.Teilaufgaben mit Akzeptanzkriterien
Teil die Arbeit in Stücke, die sich reviewen lassen. Jedes Stück sollte testbar sein.Annahmen, nach Risiko markiert
Halte fest, was geraten ist, was wackelt und was an Entscheidungen von außen hängt.Validierungsszenarien
Benenne das Verhalten, von dem du erwartest, dass es besteht oder scheitert.Zieldateien
Zeig dem Agent den wahrscheinlichen Wirkungsradius.
Diese Struktur reist gut, weil jedes Tool andere Signale am besten liest. Claude mag vollständigen Kontext. Cursor mag Absichten mit Dateibezug. Gemini profitiert von klaren Szenarien. Copilot profitiert vor allem davon, dass du als Mensch die Mehrdeutigkeit schon reduziert hast.
Ein Spec-Format, dem Agents tatsächlich folgen
Das ist das Format, das ich am häufigsten nutze.
| Abschnitt | Was hineingehört | Was draußen bleibt |
|---|---|---|
| TL;DR | Problem der Nutzenden, gewünschtes Verhalten, Einschränkung | Produktmanifest |
| Scope-Grenzen | Änderungen im Scope, Nicht-Ziele | versteckte „vielleicht später“-Ideen |
| Teilaufgaben | konkrete Umsetzungseinheiten | riesige Feature-Klumpen |
| Annahmen | riskante Unbekannte und Platzhalter | vorgetäuschte Gewissheit |
| Validierungsszenarien | Erfolg, Edge Case, Fehlerfall | vages „funktioniert korrekt“ |
| Zieldateien | Dateien zum Bearbeiten, Ansehen oder Meiden | kompletter Repo-Dump |
Ein schlankes Beispiel:
# Feature
Add team invite expiration handling
## TL;DR
Users can accept invites until expiration. Expired invites show a clear error and cannot create memberships.
## Scope boundaries
In scope:
- invite acceptance API
- invite acceptance UI state
- membership creation guard
Out of scope:
- invite resend flow
- admin analytics
## Subtasks with acceptance criteria
1. Reject expired invites in backend
- acceptance: expired token returns domain-specific error
- acceptance: no membership is created
2. Show expired state in UI
- acceptance: expired invite page renders retry guidance
- acceptance: valid invite flow unchanged
## Assumptions tagged by risk
- [medium] existing invite records already store expiration timestamp
- [high] mobile client does not use this endpoint
## Validation scenarios
- valid invite accepted before expiration
- expired invite rejected
- already accepted invite remains rejected
## Target files
- app/api/invites/accept.ts
- domain/invites.ts
- components/invite/accept-page.tsx
- tests/invite-accept.test.ts
Praxisregel: Wenn zwei Agents einen Satz unterschiedlich auslegen würden, schreib den Satz um.
Wenn du um die Spec herum eine breitere Kontextschicht willst, kann ein umfassendes Context-Protocol-Tool helfen, den Projektkontext außerhalb der Spec zu organisieren. Das ist nützlich, wenn die Spec knapp bleiben soll, das Repo aber trotzdem dauerhafte Leitlinien zu Produkt, Architektur und Workflow braucht.
Eine Erwähnung reicht hier. Auch Tekk.coach gehört in diese Kategorie, nur vom anderen Ende her. Seine Loops lesen, was sich in deinem GitHub-Repo geändert hat, und schreiben Specs in diesem Stil für dich; du kannst auch selbst eine auf demselben Board schreiben. Cursor, Claude Code oder Codex holt sich die Spec über den Tekk-MCP-Server und baut sie. Tekk schreibt nie den Code.
Agent im Detail: Claude Code
Mit Claude Code fange ich an, wenn das Problem noch breit ist. Es verkraftet viel Kontext, liest lange Specs, ohne in Panik zu geraten, und liefert meist den saubersten ersten Wurf für Architektur, Aufgabenzerlegung und Umsetzungsreihenfolge.
Wo Claude Code hingehört
Claude ist ganz oben im Trichter am besten:
- Specs verdauen: lange Anforderungen, Einschränkungen und Hintergrundnotizen
- Pläne erstellen: aus einem Feature aufgabengroße Stücke machen
- Dateiübergreifend denken: erkennen, wie eine Änderung auf Datenmodelle, APIs und UI überschwappt
- Überarbeitungsdurchgänge: eine grobe Spec vor der Umsetzung in klarere Sprache bringen
Deshalb greifen viele Solo Builder zuerst zu Claude. Das Fehlerbild ist meist nicht „kann nicht coden“. Sondern „hat etwas Plausibles gecodet, das nicht der eigentliche Auftrag war“.
Ein brauchbarer Einstiegs-Prompt sieht so aus:
Read this spec as the source of truth.
Your job:
1. Summarize the feature in 5 bullets
2. List ambiguities or risky assumptions
3. Produce an implementation plan in small reviewable tasks
4. Do not write code yet
5. Do not add requirements not present in the spec
Spec:
[paste spec here]
Und dann, nachdem du den Plan geprüft hast:
Implement only Task 1 from the approved plan.
Before editing, restate the acceptance criteria in your own words.
After editing, list changed files and explain how each change maps to the spec.
Wie du Claude aus einer echten Spec heraus promptest
Claude reagiert besser, wenn du die Modi trennst. Verlang nicht Design, Umsetzung und Validierung in einem Atemzug, außer die Aufgabe ist winzig.
Eine einfache Abfolge funktioniert besser:
- Durchgang 1: die Spec verstehen und kritisieren
- Durchgang 2: Aufgaben erzeugen
- Durchgang 3: eine Aufgabe umsetzen
- Durchgang 4: gegen die Akzeptanzkriterien prüfen
Wenn du Beispiele für einen strafferen Claude-first-Workflow brauchst, lohnt sich dieser Text über einen Claude-Code-Workflow, weil er bei echten Umsetzungsschritten bleibt statt bei allgemeinen Prompting-Tipps.
Wenn du auf Budget und Zugang achten musst, kann diese Liste mit Ressourcen zur Finanzierung von KI-Startups helfen, sobald die Nutzung von Claude zum festen Teil deines Build-Loops wird.
Bekannte Grenzen
Claudes größte Schwäche ist nicht die Intelligenz. Es ist der Session-Verfall. Du spürst den Moment, in dem es anfängt, von seiner eigenen letzten Antwort aus zu arbeiten statt von der Quell-Spec. Genau da verbrennen Leute Sessions und landen trotzdem beim Drift.
Echte Threads aus der Entwicklung spiegeln diesen Schmerz. Die Reddit-Diskussion zum Umgang mit Claude-Sessions lohnt sich, weil sie nicht abstrakt ist. Leute beschreiben genau, was passiert, wenn der Thread lang wird und das Modell ins Rutschen kommt.
Füg die Spec erneut ein, bevor das Vertrauen sinkt, nicht danach.
Wenn Claude anfängt, Änderungen außerhalb des Scopes vorzuschlagen, bereits akzeptierte Einschränkungen zu übersehen oder zu selbstsicher zusammenzufassen: Reset. Starte eine neue Session. Füg nur die aktuelle Spec und die aktuelle Aufgabe ein. Kontinuität ist optional. Verankerung ist Pflicht.
Agent im Detail: Cursor
In Cursor will ich das Feature nicht erfinden. Dort will ich es in der echten Codebase landen. Das ist ein anderer Job.
Cursor ist am stärksten, wenn die Spec schon steht
Sobald die Spec stabil genug ist, wird Cursor zum praktischen Arbeitstier, weil es Dateien, Referenzen, Muster in der Nähe und die Form des Repos sieht. Du verbringst weniger Zeit damit, riesige Kontextblöcke einzufügen, und mehr damit, Änderungen zu steuern.
Cursor eignet sich gut für:
- Integration mit Blick auf die Codebase: die Änderung in bestehende Konventionen einfügen
- Änderungen über mehrere Dateien: Route, Schema, Komponente und Tests in einem Durchgang
- Lokale Refactorings: den Wirkungsradius unter Kontrolle halten
- Gezieltes Nachfassen: „Task 2 nur auf diese Dateien anwenden“
Die Multi-Agent-Positionierung von Cursor 2.0 ist interessant, und die Release Notes im Cursor-Blog sind der richtige Ort, um diese Entwicklung zu verfolgen. Der Vorteil ist Tempo im Editor. Der Nachteil ist Undurchsichtigkeit. Manchmal weißt du genau, warum es eine Datei geändert hat. Manchmal nicht.
So arbeitest du in Cursor Spec-first
Kipp nicht die ganze Spec in einen generischen Chat und sag „bau das“. Richte Cursor auf die aktuelle Aufgabe und die relevanten Dateien aus.
Ein nützliches Muster:
Use this spec as the source of truth for Task 2 only.
Acceptance criteria:
- expired invite page renders retry guidance
- valid invite flow unchanged
Inspect:
@components/invite/accept-page.tsx
@app/api/invites/accept.ts
@tests/invite-accept.test.ts
Do not modify unrelated files.
Before editing, tell me the minimal file set you plan to change.
Dann zieh es weiter an, sobald Cursor den Code gelesen hat:
Make the UI changes only.
No backend edits.
Keep copy plain and consistent with existing empty-state patterns.
Deshalb ist es auch wichtig, das sichtbare Verhalten sauber zu beschreiben, bevor die Umsetzung beginnt. Wenn deine Akzeptanzkriterien schwammig sind, macht Cursor die UI fröhlich „besser“, und zwar auf eine Art, um die du nicht gebeten hast. Ein solides Set an User Stories hilft, weil es Akteur, Aktion und erwartetes Ergebnis in die Spec zwingt, bevor der IDE-Agent zu improvisieren beginnt.
Wo Cursor unübersichtlich wird
Cursor erbt Stärken und Schwächen vom Modell darunter. Wenn das Modell driftet, driftet Cursor mit, nur mit schönerer Ergonomie. Der IDE-Kontext lässt es zuverlässiger wirken, als es immer ist.
Es gibt noch ein Problem. Cursor kann dich zur lokalen Optimierung verleiten. Der Diff sieht gut aus. Der Code kompiliert. Aber der übergeordnete Feature-Vertrag kann längst danebenliegen.
Ein schneller Vergleich hilft:
| Gute Nutzung von Cursor | Schlechte Nutzung von Cursor |
|---|---|
| eine freigegebene Aufgabe in bekannte Dateien integrieren | Produktanforderungen mitten in der Bearbeitung entdecken |
| den bestehenden Codestil treffen | Architektur bei null entscheiden |
| kleine Refactorings, wenn eine Spec existiert | eine Spec ersetzen wollen |
| Referenzen in der Nähe prüfen | verborgenem Agent-Verhalten blind vertrauen |
Nutze Cursor, wenn die Frage lautet: wo und wie in dieser Codebase. Nicht für die Frage, was wir bauen.
Der richtige Agent für den Job: Copilot, Codex und Gemini
Die meisten Stacks werden schlechter, weil Leute alle Coding-Agents als austauschbar behandeln. Das sind sie nicht. Du bekommst bessere Ergebnisse, wenn jedes Tool eine engere Rolle hat.
Der größere Rahmen ist hier wichtig. 2026 wurde Spec-driven Development als Disziplin definiert, in der die Spec die Quelle der Wahrheit ist und Code ein generiertes, überprüfbares Artefakt – als direkter Gegenentwurf zu „Vibe Coding“ für wartbare Systeme, wie dieser Überblick über SDD und Tooling von 2026 beschreibt.
Copilot als Finisher
Copilot liest meine Spec nicht als Erstes. Es setzt im Arbeitsfluss um, wenn ich den Job schon verstanden habe.
Die besten Einsatzfälle:
- offensichtlichen Boilerplate ergänzen
- repetitive Tests vervollständigen
- lokale Umformungen vorschlagen
- Code beschleunigen, den du schon entworfen hast
Schlechte Einsatzfälle:
- fehlende Geschäftsregeln erraten
- Datenverträge festlegen
- dateiübergreifende Feature-Arbeit ohne Aufsicht übernehmen
Prompte es mit dem kleinstmöglichen Ausschnitt:
Implement the validation helper described in the current spec.
Do not create new domain rules.
Match the existing test style in this file.
Der praktische Trade-off ist einfach. Copilot fühlt sich schnell an, weil es nah an deinen Händen sitzt. Es erbt aber auch deine Unklarheit. Der Reddit-Thread über Frust mit dem Verhalten von GitHub Copilot fängt den Ärger gut ein. Wenn deine Vorgaben zu dünn sind, rät es fröhlich drauflos.
Codex als programmierbarer Ausführer
Codex ist dann wichtig, wenn du eine explizitere Pipeline von der Spec zur Aufgabe willst, vor allem, wenn du Repo-Regeln gern mit Dateien wie AGENTS.md oder einem specs/-Verzeichnis formst. GitHubs Spec-Kit-Repository ist hier nützlich, weil es einen agentübergreifenden Ansatz zeigt, der mit Copilot, Claude Code, Gemini CLI, Cursor, Windsurf und anderen funktioniert.
Codex ist gut für:
- Anweisungen aus dem Repository befolgen
- Aufgaben aus strukturierten Spec-Dateien ausführen
- generierte Tests, die auf Akzeptanzkriterien zurückführen
- wiederholbare Abläufe, die nicht von einem einzigen Riesen-Chat abhängen
Ein minimaler, repo-orientierter Prompt:
Read /specs/invite-expiration.md and follow AGENTS.md.
Implement only the backend rejection behavior.
Generate or update tests for acceptance criteria in that spec.
Codex ist keine Magie. Es ist nur so diszipliniert wie dein Repo.
Gemini als zweites Paar Augen
Gemini ist nützlich, wenn ich eine andere Lesart derselben Spec will. Nicht weil ein Modell immer schlauer ist, sondern weil verschiedene Agents auf verschiedene Weise scheitern. Das zählt.
Starke Einsatzfälle:
- Logik reviewen, die ein anderer Agent erzeugt hat
- Annahmen hinterfragen, die in der Spec versteckt sind
- unklare Validierungsszenarien umschreiben
- Edge Cases vor dem Merge untersuchen
Ein guter Gemini-Prompt heißt weniger „bau das“ und mehr „nimm das auseinander“:
Read this spec and this diff.
List any behaviors that appear implemented but not specified.
List any specified behaviors that appear unimplemented.
Then propose missing tests.
Gemini beweist oft seinen Wert. Es kann die Umsetzung reviewen, ohne den Gesprächsschwung mitzubringen, der sie geprägt hat.
Noch etwas. Hier gibt es nach wie vor eine echte Lücke in der Evidenz. Der Kurs von DeepLearning.AI zu Spec-driven Development mit Coding-Agents ist nützlich und praxisnah, aber selbst wer SDD befürwortet, weist darauf hin, dass ein systematischer empirischer Vergleich mit lockereren Ansätzen fehlt. Als Solo Founder heißt das für dich: Du bekommst keinen sauberen Benchmark, der beweist, dass genau dein Stack „richtig“ ist. Du musst weiterhin nach Output-Qualität, Nacharbeit und Vertrauen urteilen.
Wenn ein Agent nicht erklären kann, wie sein Code auf die Spec zurückführt, ist er nicht fertig.
Die Kunst der Übergabe zwischen Agents
Die Gewinne zeigen sich, wenn du aufhörst, ein einziges Tool gleichzeitig planen, umsetzen und reviewen zu lassen.
Microsofts Rahmen ist das sauberste mentale Modell, das ich kenne. In seinem KI-nativen Engineering-Workflow zerlegt ein Coordinator die Spec und delegiert die Arbeit, Implementor-Agents führen aus, und ein separater Verifier prüft den Output gegen die Spec, bevor die Arbeit als erledigt gilt – so beschreibt es Microsofts Workflow für Spec-driven Development.
Das ist wichtig, weil Selbstprüfung schwach ist. Derselbe Agent, der den Fehler eingebaut hat, ist oft schlecht darin, ihn zu finden.
Ein Übergabemuster, das funktioniert
Eine praktische Übergabe für Solo Builder sieht so aus:
| Phase | Agent | Job |
|---|---|---|
| Spec formen | Claude oder Gemini | Scope schärfen, Unklarheiten finden |
| Integration in die Codebase | Cursor | freigegebene Aufgaben in echten Dateien landen |
| Inline-Vervollständigung | Copilot | lokale Umsetzung beschleunigen |
| Review-Durchgang | Gemini oder Claude | Code mit der Spec abgleichen |
| Menschliche Entscheidung | du | freigeben, ablehnen oder die Spec umschreiben |
Das ist der grobe Ablauf, zu dem ich immer wieder zurückkomme:
Starte mit einer portablen Spec
Noch keine Varianten pro Agent.Lass einen Agent sie in Aufgaben zerlegen
Das ist deine Coordinator-Rolle, auch wenn es noch ein einziges Modell in einem Fenster ist.Gib dem Umsetzungstool immer nur eine Aufgabe
Meist Cursor für Änderungen mit Blick auf die Codebase.Prüf mit einem separaten Agent
Lass den Implementor nicht seine eigenen Hausaufgaben benoten.Aktualisiere die Spec, wenn sich das Verhalten geändert hat
Wenn du nur den Code änderst, beginnt der Drift sofort.
Ein verwandter Text über einen Coding-Agent-Orchestrator ist nützlich, wenn du in Rollen statt in Markennamen denken willst.
Die Live-Demo unten ist eine gute Ergänzung, weil sie den allgemeinen Ablauf in Aktion zeigt, statt Multi-Agent-Arbeit wie Theorie zu behandeln.
Wann du mitten in einer Spec den Agent wechselst
Wechsle, wenn der Job seine Form ändert, nicht weil dich das aktuelle Tool langweilt.
Gute Momente für einen Wechsel:
- Die Spec ist breit, die Code-Aufgabe jetzt schmal: von Claude zu Cursor.
- Die Umsetzung ist fertig, das Vertrauen gering: von Cursor zu Gemini fürs Review.
- Du schreibst repetitive Tests oder räumst lokal auf: Lass Copilot helfen.
- Die Session vergisst langsam den Vertrag: Starte mit der Quell-Spec in einem anderen Fenster neu.
Wer wirklich baut, macht das längst. Der Reddit-Thread über einen Multi-KI-Dev-Workflow mit Claude und Gemini und die Diskussion unter KI-Solo-Businesses über Multi-Agent-Workflows sind nützlich, weil sie zeigen, wie Leute ihre Stacks um echte Reibung herum zusammenstellen, nicht um saubere Herstellerkategorien.
Wie eine Spec über alle Agents hinweg portabel bleibt
Die Portabilität bricht, wenn die Spec toolspezifische Annahmen enthält. Schreib nicht „Cursor soll diese Dateien prüfen“ in die Quell-Spec. Das gehört in den Übergabe-Prompt.
Halte die Spec toolneutral:
- Beschreib Verhalten, nicht das gewünschte Verhalten des Modells
- Verweise auf Dateien, nicht auf Editor-Features
- Nutze Akzeptanzkriterien, keine Vibes
- Halte Annahmen explizit und nach Risiko markiert
Ein guter Portabilitätstest ist einfach. Kann Claude sie lesen, kann Cursor danach handeln und kann Gemini dagegen reviewen, ohne dass du das Dokument umschreibst? Wenn nicht, ist die Spec noch nicht portabel.
Deinen Spec-driven Workflow aufbauen
Das funktioniert nur, wenn es Routine wird. Nicht aufwendig. Routine.
Das Wichtigste, was du akzeptieren musst: Einmal-Denken nach dem Muster Spec rein, Produkt raus ist Fantasie. Gojko Adzic und Daniel Terhorst-North argumentierten auf der GOTO 2026, dass solche Ansätze zum Scheitern verurteilt sind. Sie verglichen sie mit gescheiterten CASE-Tools und modellgetriebener Architektur und sagten, Erfolg brauche enge, iterative Feedback-Loops statt einer einzigen riesigen Beschreibung, die man der KI in der Hoffnung übergibt, dass es schon klappt – nachzuhören in ihrer Diskussion auf der GOTO 2026.
Der tägliche Loop
Ein praxistauglicher Loop als Solo Founder ist auf gute Weise langweilig:
- Morgens: eine Spec oder ein Aufgabenpaket auswählen
- Mittags: es dem passenden Agent zur Ausführung übergeben
- Nachmittags: einen separaten Review-Durchgang laufen lassen
- Abends: die Spec aktualisieren, wenn sich das Verhalten geändert hat
Wenn du auf GitHub bist, mach den Workflow im Repo selbst sichtbar. Eine einfache Regel hilft: Jede relevante Code-Änderung sollte auf eine Spec-Datei oder einen Spec-Abschnitt zurückführen. Du brauchst keine Bürokratie. Du brauchst eine Spur.
Ich mag außerdem einen leichtgewichtigen CI-Check. Verlange im Template für die PR-Beschreibung einen Link zur Spec oder einen Verweis darauf. Das beweist keine Qualität, fängt aber den Branch nach dem Motto „hab ich mir einfach zusammengevibt“ ab, bevor er normal wird.
Wie deine Specs nicht verrotten
Spec Drift beginnt, wenn es einfacher ist, den Code zu ändern als den Vertrag. Also mach Änderungen an der Spec billig.
Ein paar Regeln halten sie lebendig:
- Bearbeite die Spec, wenn sich das Verhalten ändert: nicht später, jetzt.
- Führe Specs pro Feature oder Aufgabencluster: Riesige Master-Dokumente sterben zuerst.
- Markiere Annahmen nach Risiko: Das gibt dir eine natürliche Review-Warteschlange.
- Schreib nach dem Release um: Entferne tote Details und behalte nur den Vertrag, der noch zählt.
Die Spec sollte kürzer werden, wenn sich das Feature gesetzt hat, nicht länger.
Wenn du lokal arbeitest und nicht jedes Experiment in der Cloud haben willst, ist dieser umfassende Guide, um KI lokal zu betreiben, eine nützliche Ergänzung, sobald du entscheidest, welche Teile deines Workflows auf deinem Rechner bleiben sollen.
Was du automatisierst und was beim Menschen bleibt
Automatisiere die wiederholbaren Teile. Behalte das Urteil dort, wo falsche Entscheidungen wehtun.
Automatisieren:
- Aufgaben aus einer geprüften Spec extrahieren
- Konsistenz zwischen Akzeptanzkriterien und Tests prüfen
- Hinweise im Repo, wenn ein Verweis auf die Spec fehlt
- einfache Validierungsdurchgänge
Beim Menschen lassen:
- Produkt-Trade-offs
- Architekturentscheidungen
- entscheiden, wann die Spec falsch ist
- das letzte Urteil über den Merge
Bei Tekk.coach sind die Loops der asynchrone Teil. Jeder wacht auf, wenn sich dein Code ändert, wenn Sentry anschlägt oder wenn ein Teil seines Bereichs zu lange nicht angeschaut wurde, und bringt höchstens ein Proposal mit. Das ist nützlich, weil es zur Priorisierung zwingt: Du machst es mit Greenlight zur Spec oder lehnst es mit einer Begründung ab. Tekk schreibt keinen Code und öffnet keine PRs. Dein Coding-Agent baut die Spec über MCP, und der PR mit Closes TEK-123 schließt sie, sobald er gemergt und ihre Checkliste erledigt ist.
Ehrlich gesagt haben wir immer noch keine starken empirischen Daten, die diszipliniertes SDD so mit Vibe Coding vergleichen, dass Solo Builder einen wasserdichten Beweis hätten. Selbst wer SDD befürwortet, hat auf diese Lücke hingewiesen, wie die Quellen weiter oben im Artikel zeigen. In der Praxis ist das Signal aber deutlich genug. Wenn der Output deines Agents inkonsistent ist, deine Nacharbeit steigt und Sessions immer wieder an vermeidbarer Verwirrung verbrennen, fehlt meist kein klügerer Prompt. Es fehlt ein besserer Vertrag.
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, und die Spec schließt sich, wenn der PR, der sie baut, 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.