Das Problem ist meistens kein KI-Coding-Problem. Es ist ein Spec-Problem.
Der verbreitete Rat liegt immer noch auf eine ganz bestimmte Weise daneben. Er sagt dir: Debugge den Output, schärf den Prompt nach, versuch es noch mal, flick den Code und mach weiter. Das fühlt sich produktiv an – bis du bei der fünften Neugenerierung bist, Kontext verbrennst und Code reparierst, der von Anfang an falsch werden musste, weil die Anweisungen vage waren.
Ja, der Gegenwind ist real. Leute nennen Spec-driven Development „Wasserfall mit Markdown“. Sie beschweren sich über eingefrorene Specs, Drift und Zeremonie, die Tokens verbrennt. Diese Beschwerden sind nicht erfunden. Ein Reddit-Thread zu Claude Code prangert den „irren Token-Verbrauch und die Nacharbeitszyklen“ an, die entstehen, wenn man an fehlerhaftem KI-Output herumiteriert – und genau dieses Fehlerbild erzeugen schlampige Specs überhaupt erst; ein Beleg dafür, dass Specs nutzlos sind, ist es nicht (Diskussion zur Nacharbeit mit Claude Code). Die harte Wahrheit ist einfacher. Eine dünne Spec kostet Minuten. Nacharbeit kostet Abende.
Wenn du allein baust, kannst du es dir nicht leisten, KI wie einen Junior-Dev zu behandeln, der deine Absicht wie durch Zauberei aus einem halbgaren Satz und einem chaotischen Repo herausliest. Du brauchst einen wiederholbaren Weg zu sagen, was du willst, was du nicht willst, welche Rahmenbedingungen zählen und woran du Erfolg misst. Genau das ist die Arbeit.
Inhalt
- Dein KI-Coding ist chaotisch, weil deine Specs vage sind
- Der eigentliche Wechsel: vom Prompten zum Spezifizieren
- Anatomie einer präzisen Spec
- Ein praxistauglicher Workflow für Solo Builder
- Das passende Tooling für Spec-driven Development wählen
- Wann du den Output trotzdem debuggen solltest
- Mit strukturierten Specs ausliefern
Dein KI-Coding ist chaotisch, weil deine Specs vage sind
KI scheitert meistens, bevor sie eine Zeile Code schreibt.
Der teure Teil ist nicht das Generieren. Es ist das Aufräumen nach einer schwachen Spec. Du bekommst Code, der plausibel aussieht, einen flüchtigen Blick übersteht und trotzdem die falschen Annahmen über State, Edge Cases, die Form der Daten oder das, was unangetastet bleiben muss, fest einbaut. Dann wird die Session zur Archäologie.
Deshalb ist der Rat von Addy Osmani so wichtig: Fang mit einer klaren, knappen Spec an, lass das Modell daraus einen Plan entwickeln und prüf den Plan, bevor er ausgeführt wird (Addy Osmani darüber, wie man eine gute Spec schreibt). Die Spec ist kein Projekt-Papierkram. Sie ist die Steuerfläche.
Die größte Verschwendung ist Nacharbeit
Bei Solo Buildern sehe ich immer wieder dasselbe Fehlermuster. Sie bitten in ein paar lockeren Sätzen um ein Feature, bekommen einen ordentlich aussehenden Entwurf und verbringen die nächste Stunde damit, dieselbe Art von Fehler in mehreren Dateien zu flicken.
Eine vage Anfrage wie „füg Team-Billing mit Stripe hinzu“ lässt zu viel offen. Wer darf Plätze verwalten? Was passiert beim Downgrade? Welche Webhook-Events zählen? Dürfen sich bestehende Account-Modelle ändern? Wie geht man mit fehlgeschlagenen Zahlungen um? Das Modell füllt diese Lücken mit Vermutungen, und jetzt debuggst du Vermutungen.
Halte dich an eine einfache Regel.
Praxisregel: Wenn der Output immer wieder auf dieselbe Weise falsch ist, hör auf, den Code zu bearbeiten, und repariere die Spec, aus der er entstanden ist.
Das ist der Schritt, der skaliert. Eine geflickte Datei hilft einmal. Eine schärfere Spec hilft bei jeder Neugenerierung, jeder Folgeaufgabe und jedem benachbarten Feature, das dasselbe Verhalten berührt.
Warum der Gegenwind trotzdem am Kern vorbeigeht
Ein Teil der Kritik an spec-basierter KI-Arbeit ist berechtigt. Eine lange Markdown-Datei, die niemand liest, ist Overhead. Eine Spec, die sich vom Repo entfernt, ist fast sofort veraltet. Ein Prozess, der aus einer kleinen CRUD-Änderung ein Ritual macht, verbrennt Zeit und Tokens.
Aber das ist nicht das Fehlerbild, das ich am häufigsten sehe.
Solo Builder spezifizieren die Arbeit meistens zu wenig. Sie erwarten, dass das Modell Produktentscheidungen trifft, Architekturregeln errät, versteckte Invarianten bewahrt und selbst festlegt, wann etwas fertig ist. Da beginnt das Chaos. Wenn der Abnahmetest nur in deinem Kopf existiert, kann das Modell ihn nicht anpeilen. Akzeptanzkriterien, die ein Agent tatsächlich prüfen kann, schließen einen großen Teil dieser Lücke.
Brauchbare Specs sind kurz und operativ. Sie nennen Rahmenbedingungen, vorhandenen Kontext, Fehlerfälle und Prüfungen. Teams, die schon mit verhaltensgetriebenen Gewohnheiten arbeiten, erkennen das Muster wieder. BDD-Best-Practices und CI/CD lassen sich sauber auf KI-Coding übertragen, weil beide Ansätze besser funktionieren, wenn das Verhalten vor der Implementierung explizit ist.
Der praktische Trade-off ist simpel. Steck zehn Minuten mehr ins Spezifizieren der Arbeit – oder verbring die nächste Stunde damit, Code zu debuggen, der aus vorhersehbaren Gründen falsch war. Ich habe aufgehört, mich für die zweite Option zu entscheiden.
Der eigentliche Wechsel: vom Prompten zum Spezifizieren
Prompten ist ein Gespräch. Spezifizieren ist operativ.
Dieser Unterschied ist wichtiger, als die meisten Ratschläge zum KI-Coding zugeben. Ein Prompt sagt: „Bau mir X.“ Eine Spec sagt: „Bau X innerhalb dieser Grenzen, mit diesen Inputs, diesen Outputs, diesen Annahmen und diesen Prüfungen.“
Ein Prompt bittet, eine Spec begrenzt
Die meisten missratenen KI-Coding-Sessions beginnen mit einer Anfrage wie dieser:
Füg meiner App Team-Billing hinzu. Nimm Stripe. Halt es einfach.
Das ist keine Spec. Das ist ein Wunsch.
Eine brauchbare Spec benennt das Verhalten, die Grenzen und die Fehlerbedingungen. Sie sagt dem Modell, was schon existiert, was sich nicht ändern darf, welche Edge Cases zählen und was als fertig gilt. Deshalb ist Osmanis Rat so wirkungsvoll, mit einer groben Vision zu beginnen, die KI daraus einen detaillierten Plan machen zu lassen und strukturierte Review-Loops zu fahren. Der Wert liegt nicht in einem längeren Prompt. Er liegt in weniger Mehrdeutigkeit.
Wenn du Prompts schon als aufrufbare Schnittstellen begreifst, macht es schneller klick. Eine gute Begleitlektüre dazu: KI-Prompts wie Funktionen behandeln, mit strikten Inputs und definierten Outputs. Hier gilt dieselbe Idee. Du bekommst besseres Verhalten, wenn du den Vertrag definierst.
Warum das den Job des Agents verändert
Ohne Spec muss der Agent die fehlende Absicht erfinden. Manchmal hat er Glück. Oft erfindet er mit großer Überzeugung das Falsche.
Mit einer Spec wird der Job enger:
- Weniger interpretieren, weil die Anforderungen ausgesprochen sind.
- Bessere Fragen stellen, weil die Lücken sichtbar sind.
- Kleinere Häppchen generieren, weil die Arbeit aufgeteilt ist.
- Gegen etwas Echtes prüfen, weil es Akzeptanzkriterien gibt.
Am letzten Punkt brechen die meisten Workflows immer noch. Ein Modell schreibt Code schnell, aber dein Validierungs-Loop muss mithalten. Wenn du eine praktische Brücke zwischen dem Schreiben von Specs und testbarem Verhalten suchst, sind BDD-Best-Practices und CI/CD nützlich, weil sie erwartetes Verhalten in ein Format zwingen, das du prüfen kannst, statt nur darüber zu reden.
Der Wechsel ist einfach. Hör auf, vom Modell Cleverness zu verlangen. Fang an, es zur Präzision zu zwingen.
Sobald du diesen Wechsel vollzogen hast, klingt „Hör auf, KI-Output zu debuggen. Schreib lieber bessere Specs“ nicht mehr nach Philosophie, sondern fühlt sich an wie grundlegende Engineering-Hygiene.
Anatomie einer präzisen Spec
Die meisten Ratschläge enden bei „schreib bessere Specs“. Das reicht nicht. Du brauchst eine Form, die du wiederverwenden kannst.
Die kleinste brauchbare Spec für Solo Builder ist kurz, explizit und Mehrdeutigkeit gegenüber feindselig. Sie sollte in den Kontext des Modells passen, ohne zu einem riesigen Planungsartefakt zu werden, das niemand pflegen will.
Die sechs Teile, auf die es ankommt
Eine präzise Spec braucht sechs Teile.
| Teil | Wozu er dient | Was du schreibst |
|---|---|---|
| Ziel | Legt das angestrebte Ergebnis fest | Einen Absatz zum Ergebnis, das Nutzende sehen |
| Scope-Grenzen | Verhindert Gold-Plating | Eine schonungslose „bauen wir nicht“-Liste |
| Technische Anforderungen | Verankert die Implementierung | Vorhandene Dateien, Services, Libraries, Grenzen der Architektur |
| Akzeptanzkriterien | Definiert, wann es fertig ist | Beobachtbare Prüfungen mit Bestanden oder Durchgefallen |
| Validierungsszenarien | Bringt Edge Cases ans Licht | Happy Path, Fehlerpfad, schräger Pfad |
| Zentrale Annahmen | Legt versteckte Wetten offen | Alles, was falsch sein könnte |
Diese Struktur funktioniert, weil versteckte Annahmen das sind, was KI-Output meistens sprengt. Augments Text zu Code Quality bei KI-generiertem Code argumentiert, dass die härtesten Fehler aus „unsichtbaren Annahmen“ im generierten Code kommen und dass ein Code Review zu spät kommt, wenn die Absicht nie explizit gemacht wurde (Spec-driven Development und versteckte Annahmen).
Wenn du eine kürzere Version als das vollständige Template unten willst, ist dieses minimale Spec-Format eine gute Basis.
Vorher und nachher
Hier ist eine schwache Spec.
Füg einen Endpoint für Rechnungsdownloads hinzu. Er soll sicher sein und mit unserer aktuellen Auth funktionieren.
Hier ist dieselbe Anfrage in einer Form, die ein Agent ausführen kann.
Ziel
Einen Backend-Endpoint hinzufügen, über den angemeldete Nutzende eine PDF-Rechnung für ihren eigenen Account herunterladen können.Scope-Grenzen
Endpoint und Auth-Prüfung bauen. Billing nicht neu gestalten. Keine Rechnungssuche für Admins hinzufügen. Die bestehende Auth-Middleware nicht ändern.Technische Anforderungen
Die bestehende Express-API verwenden. Die aktuelle Session-Auth wiederverwenden. Rechnungsdatensätze existieren bereits in der Billing-Tabelle. PDF-Dateien liegen im aktuellen Object-Storage-Pfad, den die Billing-Exporte nutzen.Akzeptanzkriterien
Angemeldete Nutzende können nur Rechnungen herunterladen, die mit ihrem Account verknüpft sind. Nicht angemeldete Requests schlagen fehl. Requests nach der Rechnung eines anderen Accounts schlagen fehl. Fehlende Rechnungen liefern einen klaren Fehler. Die bestehenden Billing-Routen bestehen weiterhin ihre Tests.Validierungsszenarien
Gültige Nutzende laden die eigene Rechnung herunter. Abgemeldete Nutzende fordern eine Rechnung an. Angemeldete Nutzende fordern die Rechnung eines anderen Accounts an. Der Rechnungsdatensatz existiert, aber die Datei fehlt.Zentrale Annahmen
Die Billing-Tabelle speichert eine stabile Zuordnung von Rechnung zu Account. Die aktuellen Berechtigungen des Object Storage erlauben den serverseitigen Abruf.
Die zweite Version ist länger, aber nicht aufgebläht. Sie ist ausführbar.
Nutze diesen schnellen Kontrast beim Entwerfen:
- Schlecht heißt: „Bau X.“
- Besser heißt: „Bau X für diese Nutzenden, in dieser Codebase, unter diesen Rahmenbedingungen.“
- Am besten heißt: „Bau X, vermeide Y, beweis es mit Z.“
Schreib Specs so, dass eine müde, zukünftige Version von dir erkennen kann, ob das Modell das Richtige getan hat, ohne die ganze Codebase noch einmal zu lesen.
Ein praxistauglicher Workflow für Solo Builder
Solo Builder brauchen nicht mehr KI-Chat. Sie brauchen einen wiederholbaren Loop, der in eine normale Dev-Session passt und ein Artefakt hinterlässt, das sie nächste Woche wiederverwenden können.
Der Loop in fünf Schritten
Nutze einen Workflow, der mit Kontext aus dem Repo beginnt und mit einer überarbeiteten Spec endet, nicht mit einem Haufen von Hand bearbeiteter Patches.
Kontext sichten
Hol dir den minimalen Kontext aus dem Repo, den es für richtige Entscheidungen braucht. Meistens heißt das: die Route oder den Einstiegspunkt, das beteiligte Datenmodell, vorhandene Berechtigungsprüfungen, zugehörige Tests und ein oder zwei benachbarte Implementierungen, die den Hausstil zeigen. Das ganze Repo ins Modell zu kippen, erzeugt Rauschen. Es auszuhungern, erzeugt Vermutungen.Die Spec entwerfen
Schreib die Aufgabe in einem Format, das du schnell überfliegen kannst: Ziel, Scope-Grenzen, technische Rahmenbedingungen, Akzeptanzkriterien, Validierungsszenarien, Annahmen. Halte sie kurz genug, um sie in einem Durchgang zu lesen. Sei so konkret, dass das Modell den Scope nicht ausweiten kann.An deinen Agent übergeben
Nimm Cursor, Claude Code, Codex, Gemini oder was auch immer in deinem Editor sitzt. Bei allem, was über eine winzige Änderung hinausgeht, lass dir vor dem Code einen Plan und eine Liste der geänderten Dateien geben. So fängst du falsche Annahmen ab, solange sie noch billig sind.Gegen die Akzeptanzkriterien prüfen
Prüf das Ergebnis gegen die Spec, nicht gegen die vage Version in deinem Kopf. Spiel die offensichtlichen Szenarien durch. Prüf, ob die Implementierung die richtige Auth, die richtigen Zustandsübergänge, den richtigen Storage-Pfad, die richtigen Namenskonventionen und die richtigen Tests wiederverwendet hat.Zuerst die Spec reparieren
Wenn der Output die Form der Aufgabe verfehlt hat, änder die Spec und lass es noch einmal laufen. Verbring keine dreißig Minuten damit, Code zu polieren, der auf falschen Annahmen steht. So wird aus einem Fünf-Minuten-Feature ein ganzer Nachmittag.
Die Verschwendung steckt selten im Generieren selbst. Sie zeigt sich beim Klären, Aufräumen und Debuggen, nachdem sich das Modell auf die falsche Interpretation festgelegt hat. Wie oben erwähnt, ist dieses Muster so verbreitet, dass es allen bekannt vorkommt, die regelmäßig mit KI ausliefern. Die praktische Lösung ist einfach: Prüf den Plan, schärf die Annahmen und lass das Modell beweisen, dass es die Akzeptanzkriterien erfüllt hat.
Ein kurzes Walkthrough hilft hier:
Ein echtes Beispiel mit einem API-Endpoint
Nimm ein kleines Feature: POST /api/projects/:id/archive.
Eine schwache Übergabe sieht aus wie eine Notiz, die du dir um 18 Uhr selbst geschrieben hast:
- Projekt archivieren
- Nur Owner dürfen das
- UI auch anpassen
Dieser Prompt lädt zum Erfinden ein. Das Modell muss raten, was „archivieren“ bedeutet, wo Ownership durchgesetzt wird, ob es ein Soft Delete oder eine Statusänderung ist und wie weit „UI auch“ reicht.
Ein brauchbarer Workflow ist enger gefasst.
Zuerst sichtest du den Kontext. Öffne die aktuellen Projektrouten, die Ownership-Prüfung, die anderswo schon verwendet wird, das Enum für den Projektstatus und die Tests rund um Löschen, Sichtbarkeit oder Auflisten. Hol nur diese Dateien in die Unterhaltung.
Als Nächstes schreibst du die Spec. Halte fest, dass Archivieren eine weiche Statusänderung ist. Halte fest, dass Owner archivieren dürfen und Collaborators nicht. Halte fest, dass archivierte Projekte aus den aktiven Listen verschwinden, aber weiterhin im Verlauf auftauchen, falls es diese Ansicht schon gibt. Halte fest, dass die Aufgabe kein Redesign des Schemas, kein neues Berechtigungssystem und keine Admin-Features umfasst.
Dann übergibst du sie mit einem Planungsschritt. Frag den Agent, welche Dateien er voraussichtlich ändert und warum. Schlägt er für eine Route, die schon eine Autorisierungsschicht hat, eine neue vor, hör an dieser Stelle auf.
Die Validierung wird einfacher, weil das Review ein Ziel hat. Prüf, ob der Code den vorhandenen Berechtigungspfad wiederverwendet hat. Prüf, ob er die Listenlogik angepasst hat, ohne unbeteiligte Screens anzufassen. Prüf, ob die Tests den Zustandsübergang und den verbotenen Zugriff abdecken. Wenn das Modell Archivieren wieder wie Löschen behandelt hat, liegt das Problem vermutlich in der Formulierung der Spec rund um den Zustand, nicht im finalen Diff.
Dieser Loop fühlt sich nur langsamer an, wenn du ihn damit vergleichst, einen vagen Satz zu tippen und auf das Beste zu hoffen. Vergleich ihn stattdessen mit dem ganzen Feature-Zyklus. Für Solo Builder bedeutet das: weniger neue Versuche, weniger versteckte Nebenwirkungen und weniger Abende, an denen du Code per Reverse Engineering entschlüsselst, den das Modell nie hätte schreiben sollen.
Das passende Tooling für Spec-driven Development wählen
Die Wahl des Tools ist weniger wichtig, als viele denken. Für Solo Builder ist der Job einfacher: Nimm das leichteste Setup, das Specs nah am Code hält, leicht zu aktualisieren ist und sich während der Implementierung kaum ignorieren lässt.
Fang einfach an, bevor du dir Prozess einkaufst
Schlichtes Markdown im Repo ist immer noch der beste Standard.
Eine kleine Struktur reicht:
specs/feature-name.mdspecs/templates/minimal-spec.mddocs/architecture.mddocs/assumptions.md
Dieses Setup funktioniert, weil es zum tatsächlichen Dev-Loop passt. Du kannst die Spec schreiben, sie im selben Commit wie den Code einchecken, im Review den Diff ansehen und sie aktualisieren, wenn sich die Implementierung ändert. Drift wird sichtbar, statt sich in einem Chat-Verlauf oder einem vergessenen Dokument zu verstecken.
Template-Kits können helfen, wenn du Features immer wieder überbaust, weil deine Prompts unscharf bleiben. Sie geben dir wiederholbare Abschnitte, und das ist nützlich. Sie schaffen aber auch ein neues Fehlerbild: Du fängst an, Formulare für winzige Änderungen auszufüllen, die nie Zeremonie gebraucht hätten.
Wo spezialisierte Tools helfen und wo sie schaden
Die nützliche Frage ist praktisch: Welches Tool verringert die neuen Versuche bei der Art von Arbeit, die du machst?
Nutze diese Tabelle als Filter:
| Option | Stärke | Schwäche |
|---|---|---|
| Markdown im Repo | Günstig, versioniert, leicht neben dem Code zu bearbeiten | Keine Leitplanken, leicht zu überspringen, wenn du es eilig hast |
| Template-Kits | Einheitliche Struktur über alle Aufgaben | Kann bei kleinen Änderungen zum Ritual mit wenig Ertrag werden |
| Spec-Tools | Geführte Erfassung, wiederverwendbare Formate, teils Entwürfe mit Repo-Kontext | Eine weitere Schicht, die du pflegen und lernen musst |
| Reine Chat-Workflows | Schnell bei Wegwerf-Aufgaben | Kontext verschwindet schnell, Rahmenbedingungen gehen verloren, Drift zeigt sich früh |
Der Trade-off heißt nicht Tempo gegen Qualität. Er heißt Setup-Kosten gegen die Kosten neuer Versuche.
Eine Textänderung in einer einzigen Datei braucht zum Beispiel keine Spec-Plattform. Ein Feature, das Routing, Auth, Datenform und UI-State berührt, meistens schon. Den größten Nutzen aus Tooling ziehen Solo Builder im Mittelfeld, wo die Aufgabe zu groß für einen einzelnen Prompt und zu klein für einen schwergewichtigen Prozess ist.
Die Diskussionen in der Community rund um Spec Drift machen das Kernproblem deutlich. Tooling hilft nur, wenn es die Spec an den Code und die aktuelle Aufgabe gebunden hält, statt sie zu veralteter Prosa werden zu lassen (Diskussion zu Spec Drift und Tooling).
Eine praktische Option in dieser Kategorie ist Tekk.coach. Seine Loops lesen dein GitHub-Repo und schreiben Specs für dich aus dem, was sich in deinem Code geändert hat, und auf demselben Board kannst du auch selbst eine schreiben. Cursor, Claude Code oder Codex baut die Spec über den Tekk-MCP-Server. Das ist nützlich, wenn das Schreiben von Specs vor dem leeren Blatt dein Engpass ist. Weniger nützlich ist es, wenn deine Arbeit vor allem aus kleinen Änderungen besteht, bei denen das Öffnen eines weiteren Tools mehr kostet, als es spart.
Das richtige Tool hinterlässt dir ein lebendiges Artefakt im Repo. Das falsche gibt dir ein poliertes Dokument, das niemand aktualisiert.
Wann du den Output trotzdem debuggen solltest
„Zuerst die Spec reparieren“ ist die Standardregel. Eine Religion ist es nicht.
Manchmal ist die Spec in Ordnung, und das Modell versemmelt es trotzdem. Es missversteht vielleicht eine Library, erfindet einen Helper, den es nicht gibt, oder verdrahtet die richtige Logik im falschen Teil deiner App. In solchen Fällen verschwendet sturköpfiges Umschreiben der Spec nur einen weiteren Zyklus.
Eine schnelle Diagnoseregel
Stell zuerst eine Frage.
Kam der Fehler aus fehlender Absicht, fehlendem Kontext oder schlechter Ausführung?
Diese Aufteilung ist wichtiger, als viele denken. Ein Kommentar zum KI-gestützten Review argumentiert, dass der Engpass nicht nur das menschliche Review ist, sondern das Missverhältnis zwischen der hohen Output-Rate der KI und alten Feedback-Mechanismen – deshalb brauchst du kleinere Häppchen und stärkere Validierung. Die nützliche Unterscheidung ist die zwischen Spec-Problemen und Implementierungsproblemen. Fehlende Anforderungen sind das eine. Grenzen von Modell oder Tooling sind etwas anderes (Engpässe im KI-Review und Feedback-Loops).
Nutze diese Tabelle, wenn du entscheidest:
| Symptom | Wahrscheinliche Ursache | Was du tust |
|---|---|---|
| Agent hat das Feature in der falschen Form gebaut | Spec-Problem | Anforderungen und Grenzen neu schreiben |
| Agent hat unbeteiligte Dateien geändert | Kontextproblem | Dateiauswahl und Architekturnotizen eingrenzen |
| Agent hat eine erfundene API oder falsches Library-Verhalten verwendet | Implementierungsproblem | Debuggen oder von Hand korrigieren |
| Agent hat einen Edge Case verpasst, den du nie genannt hast | Spec-Problem | Validierungsszenario ergänzen |
| Agent scheitert trotz klarer Anforderungen und Tests | Grenze von Modell oder Tool | Selbst eingreifen |
Die Ausnahmen, die zählen
Den Output solltest du in der Regel debuggen, wenn:
- der Bug lokal ist und das beabsichtigte Verhalten bereits explizit ist.
- das Modell einen falschen API-Aufruf gewählt hat, obwohl die Spec die richtige Library und die Einschränkung für ihre Nutzung genannt hat.
- das Tooling versagt hat, etwa bei der Umgebung, beim Auflösen von Abhängigkeiten oder bei externen Services.
- du kurz vor dem Ziel bist und ein Fix von Hand billiger ist als ein weiterer kompletter Generierungszyklus.
Eine gute Faustregel: Wenn die reparierte Spec dem Agent etwas Wiederverwendbares beibringt, schreib die Spec um. Wenn du einen einmaligen Fehler in ansonsten gültiger Arbeit korrigierst, debugge den Code.
Diese Unterscheidung bewahrt dich davor, dogmatisch zu werden. Specs sind die Lösung, die skaliert. Debuggen ist trotzdem der richtige Schritt, wenn der Fehler kein Spec-Fehler ist.
Mit strukturierten Specs ausliefern
Mit strukturierten Specs hören Solo Builder auf, Stunden mit Code zu verbrennen, um den sie nie gebeten haben.
Eine brauchbare Spec ist kurz genug, um sie zu pflegen, und konkret genug, um dagegen zu testen. Sie benennt die Aktion der Nutzenden, das erwartete Verhalten des Systems, die Dateien oder Oberflächen im Scope, die Rahmenbedingungen, die zählen, und die Prüfungen, die über Bestehen oder Durchfallen entscheiden. Damit bekommt das Modell ein Ziel, das du bewerten kannst. Wenn du Full-Stack-Apps schnell ausliefern willst, zählt dieses Ziel mehr als eine weitere Runde cleveres Prompting.
Der praktische Loop ist einfach. Schreib die Spec in einem wiederholbaren Format. Generier daraus. Vergleich den Output mit der Spec, nicht mit deiner vagen Absicht. Wenn der Output abdriftet, reparier zuerst die Spec, sofern der Fehler auf fehlenden Scope, unklare Rahmenbedingungen oder unausgesprochene Edge Cases hindeutet.
Das ist es, was für eine einzelne Person skaliert.
Tekk.coach passt von der anderen Seite in diesen Workflow. Seine Loops schreiben Specs für dich aus dem, was sich in deinem Code geändert hat; selbst eine zu schreiben ist der manuelle Weg auf dasselbe Board, und die Akzeptanzkriterien sind das, was die Spec schließt, beim Merge des PR, der sie baut. Verbinde das Repo, gib mit Greenlight frei, was es wert ist, gebaut zu werden, und schärf dann die Spec nach, bis der Output vorhersehbar wird.
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.