Spec-driven Development heißt: Du schreibst eine strukturierte, in der Codebase verankerte Spec, die ein AI Agent ausführen und ein Mensch prüfen kann. Die nützliche Version ist kein eingefrorenes Dokument. Sie ist ein lebendiges, versioniertes Artefakt, das die Arbeit durch vier Phasen führt: Specify, Plan, Tasks, Implement.

Die meisten schlechten Ratschläge zu diesem Thema setzen beim falschen Engpass an. Viele reden so, als hätte KI-Coding die Softwareentwicklung verändert, weil Code billig geworden ist. Stimmt, ist aber unvollständig. Die unbequeme Wahrheit: Das Coden ist nicht mehr der Hauptengpass. Das Spezifizieren ist es.

Genau deshalb gibt es den Gegenwind. Du kennst ihn. „Wasserfall mit Markdown.“ „Produktivitätsfalle.“ „Token verbrennende Zeremonie.“ Ein Teil dieser Kritik ist verdient. Eine aufgeblähte Spec-Datei, die nie mit der Realität in Berührung kommt, ist bloß alter Prozess mit neuem Etikett. Ein riesiges Markdown-Dokument ohne Tests, ohne Grenzen und ohne Bezug zur Codebase ist nutzlos.

Aber das ist nicht, was Spec-driven Development ist.

Wenn du als Solo Builder mit Cursor, Claude Code, Codex oder Gemini arbeitest, ist das Hauptproblem nicht, überhaupt Code generiert zu bekommen. Es geht darum, den richtigen Code zu bekommen, in der richtigen Form, mit den richtigen Abwägungen – ohne den nächsten Tag damit zu verbringen, die Vermutungen der KI aufzuräumen. Eine gute Spec löst das, indem sie aus einer vagen Feature-Idee etwas Dauerhaftes, Reviewbares und Überprüfbares macht. Kein PRD. Kein Prompt. Kein Chatverlauf, den du nie wiederfindest.

Inhalt

Ist Spec-driven Development nur Wasserfall mit Markdown?

Die bequeme Kritik ist leicht nachgeplappert: „SDD ist nur Wasserfall mit Markdown.“ Das klingt klug – bis du versuchst, mit AI Agents auszuliefern, und merkst, dass das eigentliche Problem nicht zu viele Specs sind. Es sind vage Specs, veraltete Specs und fehlende Specs.

Wenn du vorab ein riesiges Dokument schreibst, es einfrierst und den Build zwingst, ihm zu folgen, obwohl sich die Realität geändert hat, hast du Wasserfall in einer Textdatei nachgebaut. Solo Founder machen das ständig – mit PRDs, Notion-Seiten und riesigen Prompt-Dumps. Das Format ist nicht das Problem. Die Starrheit ist es.

Deshalb dreht sich diese Debatte im Kreis. Mit „Spec“ sind gleichzeitig vier verschiedene Dinge gemeint. Ein Reddit-Thread auf r/ChatGPTCoding nannte „Specification“ den „am meisten überladenen Begriff“. Die Beschreibung passt. Manche meinen ein paar Stichpunkte für ein LLM. Manche einen formalen Vertrag. Manche eine Planungsnotiz. Und manche meinen, dass Code aus Specs generiert werden soll und aus kaum etwas anderem.

Ein schlechter Spec-Prozess fühlt sich wie Zeremonie an. Ein guter fühlt sich wie Kompression an.

Die nützliche Trennlinie ist einfach. Wasserfall behandelt den Plan als feststehend. Spec-driven Development behandelt die Spec als Steuerungsdokument, mit dem gearbeitet wird. Du aktualisierst sie, wenn du etwas lernst, du prüfst sie, bevor weiterer Code entsteht, und du hältst sie so nah an der Codebase, dass ein Agent ihr folgen kann, ohne fehlende Teile zu erfinden.

Was Solo Builder ablehnen sollten

Lass die schiefen Vergleiche weg, dann siehst du schnell klarer.

  • Wasserfall legt Entscheidungen zu früh fest und belohnt Gehorsam statt Lernen.
  • Ein PRD hält die Absicht fest, hört aber meist vor klaren Ausführungsgrenzen und testbaren Akzeptanzkriterien auf.
  • Ein Chatverlauf verschwindet im Scrollback und hinterlässt kein dauerhaftes Artefakt für den nächsten Agent-Lauf.
  • Prompt Engineering versucht, aus unvollständigem Kontext gute Ergebnisse herauszukitzeln. SDD repariert zuerst den Kontext.

Martin Fowlers Einordnung, über die Taxonomie von Birgitta Böckeler, macht dieses Argument präziser als die üblichen Social-Media-Takes. Sie unterteilt das Feld in Understanding SDD auf der Website von Martin Fowler in spec-first, spec-anchored und spec-as-source. Die Unterscheidung ist wichtig, weil die Kritik oft die strengste Variante angreift, während Solo Founder eine leichtere nutzen, die editierbar bleibt.

Die Version, die dir als Solo Founder hilft

Nimm eine engere Definition.

Spec-driven Development heißt: Du schreibst eine strukturierte, in der Codebase verankerte Spec, die ein AI Agent ausführen und du prüfen kannst. Sie liegt in der Versionskontrolle. Sie setzt Grenzen. Sie zerlegt die Arbeit in Schritte. Sie enthält eine Validierung. Sie ändert sich, wenn sich die Arbeit ändert.

Das ist keine Bürokratie. So hörst du auf, Stunden mit Nacharbeit an KI-generiertem Code zu verbrennen.

Wie sich SDD von TDD, BDD und agilen Stories unterscheidet

Wie sich SDD von TDD, BDD und agilen Stories unterscheidet

Der Gegenwind gegen SDD beruht meist auf einem Kategorienfehler.

Solo Founder hören „Spec-driven Development“ und vermuten, hier wolle jemand Enterprise-Prozesse mit frischem Anstrich zurückbringen. Das geht am Punkt vorbei. TDD, BDD, agile Stories, PRDs und Prompts beschreiben jeweils einen Teil der Arbeit. SDD versucht, den ganzen Job in einem Dokument zusammenzuhalten, das ein AI Agent ausführen und du hinterher prüfen kannst.

Dieser Unterschied ist wichtig, weil Solo Builder keinen Product Manager, keinen Tech Lead und kein QA-Team haben, die in getrennten Meetings sitzen. Du hast einen Kopf, wenig Zeit und einen Agent, der Lücken bereitwillig mit Unsinn füllt.

Hier die saubere Abgrenzung:

Praxis Zentrales Artefakt Was die Umsetzung treibt Bester Einsatz
SDD Strukturierte Spec Spec, Rahmenbedingungen, Aufgaben und Validierung Mehrstufige Builds, bei denen die KI dauerhaften Kontext braucht
TDD Automatisierte Tests Fehlschlagende Tests vor dem Code Enge Coding-Loops und Korrektheitsprüfungen
BDD Verhaltensszenarien Gemeinsame Beispiele für erwartetes Verhalten Für User sichtbares Verhalten klären
Agile Stories Story oder Ticket Gewünschtes Ergebnis oder geschäftlicher Bedarf Priorisierung und Planung

TDD ist zu eng, um den ganzen Job zu tragen. Es sagt dir, was zuerst fehlschlagen soll. Systemgrenzen, Änderungen auf Dateiebene, Annahmen zum Rollout oder das, was der Agent in Ruhe lassen muss, legt es meist nicht fest.

BDD liefert dir klareres Verhalten. Aber auch BDD sagt einem AI Agent meist nicht, wie er die Arbeit in einer echten Codebase in geordnete Aufgaben zerlegt.

Agile Stories sind noch dünner. Eine Story kann erklären, warum das Feature wichtig ist, aber „Als User möchte ich X“ ist zu wenig Kontext, damit ein Agent sechs Dateien ändert, ohne Drift zu erzeugen.

Deshalb fällt die Kritik „Wasserfall mit Markdown“ für Solo Founder in sich zusammen. Wasserfall friert Entscheidungen früh ein und schiebt das Entdecken an den Rand. Gutes SDD bleibt editierbar. Es ändert sich, während du lernst. Die Spec ist ein Steuerungsdokument, mit dem gearbeitet wird, keine eingefrorene Übergabe.

Ein praktischer Test hilft. Wenn dein Artefakt diese Fragen nicht beantworten kann, betreibt es noch kein SDD:

  • Welche Dateien sollen sich ändern?
  • Welche Dateien dürfen sich nicht ändern?
  • Welche Rahmenbedingungen zählen?
  • Welche Schritte sollen in welcher Reihenfolge passieren?
  • Wie prüfst du, dass die Arbeit erledigt ist?

Wenn diese Antworten über Tickets, Chats, dein Gedächtnis und halb geschriebene Tests verstreut sind, arbeitet dein Agent mit Fragmenten.

Addy Osmani trifft das Format in How to Write a Good Spec for AI Agents. Der Wert liegt nicht in der Theorie. Der Wert liegt in der Struktur. Klare Abschnitte, explizite Rahmenbedingungen und konkrete Akzeptanzkriterien lassen dem Modell weniger Raum zum Improvisieren.

Die größere Verschiebung zeigt sich auch in den Einblicken von Goptimise zur KI-Entwicklung. Teams holen bessere Ergebnisse aus der KI, indem sie die Struktur ihres Workflows verbessern, nicht indem sie nach raffinierteren Prompts suchen. Als Solo Founder brauchst du diese Lektion mehr als alle anderen, weil du jeden schlechten Loop direkt zu spüren bekommst.

Dasselbe Muster siehst du in einem praktischen Workflow für AI Agents, gedacht für Solo Builder. Die Erfolge entstehen, wenn du dem Agent ein stabiles Arbeitsdokument gibst und die Ausführung dann daran misst.

In einem Satz:

TDD prüft Korrektheit, BDD klärt Verhalten, agile Stories setzen Prioritäten, und SDD koordiniert den gesamten Build, damit ein AI Agent die fehlenden Teile nicht erfindet.

Das ist der entscheidende Unterschied. SDD ist keine Ersatzreligion für Softwareprozesse. Es ist die fehlende Schicht zwischen vager Absicht und verlässlicher Ausführung.

Warum das für KI-Coding-Agents wichtig ist

Das Problem beginnt vor der ersten Codezeile.

Warum das für KI-Coding-Agents wichtig ist

Wenn du länger als eine Woche mit AI Agents gebaut hast, kennst du das Muster. Du promptest ein Feature. Das Modell baut etwas Plausibles. Du testest es. Es hat eine Rahmenbedingung übersehen, die du vergessen hast zu nennen. Du flickst den Prompt. Es behebt das und macht dafür etwas anderes kaputt. Bis es „funktioniert“, hast du einen Haufen Zeit mit Aufräumen und Drift verbrannt.

Deshalb glaube ich, dass der Kernfehler nicht darin liegt, der KI zu sehr zu vertrauen. Er liegt darin, ihr eine vage Absicht zu geben und sich dann zu wundern, dass sie improvisiert.

Wenn du breiter sehen willst, wie Teams ihre Workflows an diese Verschiebung anpassen, lohnen sich die Einblicke von Goptimise zur KI-Entwicklung. Der rote Faden in moderner KI-gestützter Entwicklung ist kein magisches Prompting. Es ist bessere Struktur.

AI Agents scheitern dort, wo Specs schwach sind

Neuere Forschung gibt diesem Problem einen präziseren Namen. Die technische Besonderheit von Spec-driven Development ist Synchronisationsdruck. In spec-anchored Workflows erfordern Änderungen Updates an Code und Spec, und automatisierte Prüfungen schlagen fehl, wenn beide auseinanderlaufen. Das arXiv-Paper beschreibt das als ausführbare Specs: Dinge wie BDD-Szenarien oder API-Contract-Tests machen die Spec zu einem maschinell prüfbaren Vertrag, nachzulesen in dem Paper über ausführbare Specs und Synchronisation.

Genau das übersehen die meisten Solo Builder.

Eine Spec ist nicht wertvoll, weil sie ordentlich ist. Sie ist wertvoll, weil sie Druck gegen Drift erzeugt. Sie zwingt KI und Mensch, sich am selben festgelegten Verhalten auszurichten.

Eine passende Ergänzung zum Workflow-Design für Agents: dieser Leitfaden zu Workflow-Mustern für AI Agents. Die Kernidee ist einfach. Agents brauchen dauerhaften Kontext dringender als clevere Prompts.

Die Spec wird zum Vertrag

Das ist auch der Grund, warum Thoughtworks Spec-driven Development auf sein Radar gesetzt hat. Nicht, weil Softwareteams plötzlich die Dokumentation wiederentdeckt hätten, sondern weil AI Agents dazu neigen, Kontext zu verlieren, Strukturen zu erfinden und Lücken selbstbewusst zu füllen. Eine Spec hält dagegen, indem sie die Lücken kleiner macht.

Eine kurze Erklärung hilft:

Der praktische Effekt zeigt sich an einigen Stellen:

  • Scope-Kontrolle: Der Agent bläht das Feature nicht mehr auf, weil die Zeile „wird nicht gebaut“ explizit dasteht.
  • Aufgabenzerlegung: Die Arbeit kommt vorgeschnitten an, statt mittendrin improvisiert zu werden.
  • Review-Qualität: Du kannst den Plan prüfen, bevor du den Code prüfst.
  • Wiederholbarkeit: Dieselbe Spec lässt sich über mehrere Sessions nutzen, statt jedes Mal aus dem Gedächtnis rekonstruiert zu werden.

Wenn dich die KI immer wieder überrascht, sind deine Eingaben noch zu locker.

Das ist es, was Spec-driven Development für kleine Teams und Solo Founder löst. Nicht die Coding-Geschwindigkeit. Die Klarheit der Entscheidungen.

Anatomie einer Minimal Viable Spec

Die meisten Specs sind zu lang, zu vage oder beides.

Anatomie einer Minimal Viable Spec

Für Solo Builder ist der richtige Zug nicht „schreib die ultimative Spec“, sondern „schreib die kleinste Spec, die teure Fehler verhindert“. So wie ein Produkt eine minimal tragfähige Form haben sollte, sollte es auch dein Planungsartefakt haben. Wenn du eine verständliche Auffrischung zum MVP-Denken willst, helfen Olvys Einblicke zum Minimum Viable Product, weil sie den Fokus auf das legen, was jetzt nötig ist, nicht auf das, was beeindruckend klingt.

Die Minimal Viable Spec, die ich empfehle, hat fünf Teile:

  1. TL;DR
  2. Scope
  3. Teilaufgaben mit Akzeptanzkriterien
  4. Annahmen, nach Risiko markiert
  5. Validierungsszenarien

Wenn du eine ausführlichere Anleitung zum Format willst, ergänzt dieser Leitfaden zum Schreiben technischer Specs das Template unten.

Was deine Spec enthalten muss

Das ist der Standard, den ich verwende.

  • TL;DR
    Ein Satz. Ein Ergebnis. Keine Adjektive.
    Beispiel: „Google-Login hinzufügen, damit man ohne Passwort ein Konto anlegen oder darauf zugreifen kann.“

  • Scope
    Teil ihn in Wird gebaut und Wird nicht gebaut.
    So stirbt der Großteil verschwendeter KI-Arbeit früh.

  • Teilaufgaben mit Akzeptanzkriterien
    Schreib nicht „Auth implementieren“. Zerleg es. Nenn wahrscheinliche Dateien oder Module, wenn du kannst. Leg fest, was „fertig“ bedeutet.

  • Annahmen, nach Risiko markiert
    Markier jede Annahme in einfachen Worten als niedriges, mittleres oder hohes Risiko.
    Annahmen mit hohem Risiko sollten vor der Umsetzung eine Klärung auslösen.

  • Validierungsszenarien
    Das sind deine ausführbaren Prüfungen der Absicht. Keine abstrakten Qualitätsziele. Echte Szenarien, die jemand oder etwas verifizieren kann.

Mach diesen Test: Könnte jemand anderes, oder eine andere Modell-Session, diese Datei morgen aufnehmen und dasselbe Feature bauen, ohne zu raten?

Ein konkretes Beispiel

Hier eine schlanke Spec für Social Login mit Google hinzufügen.

TL;DR

User können sich mit ihrem Google-Konto anmelden oder registrieren.

Scope

Wird gebaut

  • Google-OAuth-Anmeldung von der Login-Seite
  • Google-OAuth-Anmeldung von der Registrierungsseite
  • Zurückgegebene Google-Identität mit einem bestehenden User verknüpfen, wenn die E-Mail-Adressen übereinstimmen
  • Einen neuen User-Datensatz anlegen, wenn noch kein Konto existiert
  • Google-Provider-ID, E-Mail und Avatar-URL speichern
  • Klare UI-Zustände für Erfolg und Fehler

Wird nicht gebaut

  • Apple-Login
  • Konten in den Einstellungen verknüpfen
  • UI zur Verwaltung mehrerer Identitäts-Provider
  • SSO für Teams oder Organisationen
  • Eigenes Onboarding nach der ersten Google-Anmeldung

Teilaufgaben

Auth-Einstieg im Frontend

  • Button „Mit Google anmelden“ auf Login- und Registrierungsseite hinzufügen
  • Bestehenden E-Mail/Passwort-Flow unverändert lassen

Akzeptanzkriterien

  • Der Button erscheint auf beiden Seiten
  • Der Button startet den OAuth-Flow
  • Das bestehende Auth-Formular funktioniert weiterhin

OAuth-Callback verarbeiten

  • Erfolg, Abbruch und Provider-Fehler behandeln
  • Angemeldete User zur App-Startseite oder zum eigentlichen Ziel weiterleiten

Akzeptanzkriterien

  • Nach erfolgreicher Anmeldung landet der User angemeldet in der App
  • Eine fehlgeschlagene Anmeldung zeigt eine klare Fehlermeldung
  • Ein Abbruch legt keinen User an

Änderungen am User-Modell

  • Identitätsmodell der User um Provider-Metadaten erweitern
  • Unterstützung für lokal authentifizierte User beibehalten

Akzeptanzkriterien

  • Der User-Datensatz kann eine Google-Provider-ID speichern
  • Bestehende User gehen durch die Schemaänderungen nicht kaputt
  • Der Pfad mit übereinstimmender E-Mail legt kein doppeltes Konto an

Auth-Logik auf dem Server

  • Die von Google zurückgegebene Identität verifizieren
  • User-Konto anlegen oder finden
  • App-Session starten

Akzeptanzkriterien

  • Ein neuer Google-User bekommt ein Konto
  • Ein bestehender User mit passender E-Mail wird angemeldet
  • Doppelte User werden verhindert

Annahmen

  • Niedriges Risiko: Google-OAuth-Zugangsdaten sind bereits vorhanden.
  • Mittleres Risiko: Der aktuelle Auth-Stack unterstützt Login über Provider ohne großes Refactoring.
  • Hohes Risiko: Das Abgleichen per E-Mail ist für die Kontoverknüpfung in diesem Produkt akzeptabel.

Validierungsszenarien

  • User klickt auf der Login-Seite auf Google-Anmeldung, erlaubt den Zugriff und kommt angemeldet zurück.
  • Ein neuer User registriert sich mit Google und erhält ein gültiges Konto.
  • Ein bestehender User mit derselben E-Mail meldet sich an und wird korrekt verknüpft.
  • User bricht OAuth ab und sieht einen Fehlerzustand, der nichts kaputt macht.
  • Ein Provider-Fehler erzeugt weder eine kaputte Session noch einen halb angelegten User.

Das reicht, um es einem AI Agent zu übergeben.

Nicht, weil es elegant ist. Sondern weil es die offensichtlichen Stellen beseitigt, an denen der Agent sonst raten würde. Es legt das Ziel fest, die Ränder, die Umsetzungsscheiben, die riskanten Annahmen und die Prüfungen. Genau das leistet eine nützliche Spec.

SDD einführen ohne Bürokratie

Das Internet liebt es, aus einer guten Gewohnheit eine Religion zu machen.

SDD einführen ohne Bürokratie

Wenn du allein arbeitest, brauchst du kein formales Ritual um jedes Feature. Du brauchst die minimale Struktur, die verhindert, dass die KI in deiner Codebase auf eigene Faust loslegt.

Der beste Einstieg ist nach wie vor Böckelers Taxonomie aus dem Umfeld von Martin Fowler. Sie gibt dir drei Stufen statt eines Dogmas: spec-first, spec-anchored und spec-as-source. Das ist wichtig, weil oft empfohlen wird, mit der ersten Stufe zu beginnen, statt direkt zur starrsten Variante zu springen.

Fang leichter an, als das Internet dir rät

Für die meisten Solo Founder funktioniert diese Abfolge.

Stufe Was du tust Wann es reicht
Spec-first Die Spec vor der Umsetzung schreiben Neue Features und Änderungen mittlerer Komplexität
Spec-anchored Spec und Code synchron halten, während sich das Feature entwickelt Zentrale Flows, die du oft wieder anfasst
spec-as-source Die Spec als primär gepflegtes Artefakt behandeln Enge Fälle, in denen die Generierung sehr diszipliniert abläuft

Meine Meinung ist unverblümt. Fang mit spec-first an. Bleib länger dabei, als dir der Hype-Zyklus rät. Wechsle nur für die Teile des Produkts zu spec-anchored, die sich ständig ändern und ständig kaputtgehen. Die meisten Solo Builder brauchen spec-as-source nicht für die ganze App.

Genau dort greift auch die Kritik der „Produktivitätsfalle“. Viele führen zuerst die schwerste Variante ein und wundern sich dann, warum sie den halben Tag damit verbringen, Dokumente zu pflegen.

Die Fallen, die deine Zeit verschwenden

Du läufst schnell in dieselben drei Probleme.

  • Spec Drift
    Du hast den Code geändert, aber nicht die Spec.
    Lösung: Aktualisier die Spec in derselben Session wie die Verhaltensänderung.

  • Analyseparalyse
    Du polierst weiter am Plan, statt auszuliefern.
    Lösung: Hör auf, sobald die nächste riskante Entscheidung klar genug ist, um sie umzusetzen.

  • Vergoldete Specs
    Du dokumentierst jeden Edge Case, bevor klar ist, dass das Feature überhaupt zählt.
    Lösung: Spezifiziere zuerst nur den Kern-Flow, die wichtigsten Rahmenbedingungen und die wahrscheinlichen Fehlerpfade.

Schreib Specs, um Nacharbeit zu vermeiden, nicht um Ernsthaftigkeit vorzuführen.

Ein nützlicher Lackmustest ist einfach. Hat das Schreiben der Spec länger gedauert, als sie dir an vermiedenem Hin und Her erspart hat, war sie zu schwer. Hat die KI trotzdem große strukturelle Vermutungen angestellt, war sie zu dünn.

Der Sweet Spot ist langweilig. Genau deshalb funktioniert er.

Dein SDD-Toolset als Solo Builder wählen

Tools sind weniger wichtig, als viele denken. Die Form ist wichtiger.

Dein SDD-Toolset als Solo Builder wählen

Für den Anfang brauchst du keine eigene Plattform. Eine Markdown-Datei in deinem Repo reicht, wenn du schon weißt, wie du Scope, Aufgaben, Annahmen und Validierung festlegst, ohne abzuschweifen.

Wann Markdown reicht

Nimm einfache Docs im Repo, wenn:

  • Dein Feature klein ist: eine Route, ein Job, eine Integration, eine Modelländerung.
  • Du die Codebase gut kennst: Der fehlende Kontext steckt in deinem Kopf, und das ist noch beherrschbar.
  • Du eng reviewen kannst: Es macht dir nichts aus, Drift von Hand zu erwischen.
  • Du null Overhead willst: keine neue Oberfläche, keine Workflow-Migration.

GitHubs Spec Kit ist ein starker Bezugspunkt, weil es eine disziplinierte Form für Spezifizieren und Planen vorgibt. Kiro und ähnliche Tools gehen weiter in Richtung eigener Workflows. OpenSpec ist interessant, wenn dir Standards und Portabilität wichtig sind. Tools wie Traycer, Vibe Kanban und BMAD bedienen benachbarte Workflow-Bedürfnisse, mit unterschiedlichen Abwägungen bei Struktur, Planung und Ausführungsstil.

Wann du mehr Struktur willst

Schau über reines Markdown hinaus, sobald einer dieser Punkte zutrifft:

  • Du schreibst immer wieder dieselbe Art von Spec neu
  • Du arbeitest in einer Brownfield-Codebase mit vielen versteckten Rahmenbedingungen
  • Deinen Agent-Sessions fehlt die Kontinuität
  • Du willst einen wiederholbaren Aufnahmeprozess, bevor die Umsetzung beginnt

Hier helfen Workflow-spezifische Tools. Manche konzentrieren sich darauf, strukturierte Specs zu generieren. Manche auf Orchestrierung. Manche auf Standardisierung.

Eine Option ist dieser Leitfaden zu Spec-driven Development mit Claude Code, besonders wenn Claude Code deine wichtigste Ausführungsumgebung ist.

Eine andere 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; du kannst auf demselben Board auch selbst eine schreiben. Claude Code, Codex oder Cursor baut die Spec über den Tekk-MCP-Server, und der PR mit Closes TEK-123 schließt sie, sobald er gemergt und ihre Checkliste abgehakt ist. Tekk schreibt keinen Code und öffnet keine PRs. Wenn du als Solo Builder das Spec-Format nicht jedes Mal von Grund auf neu erfinden willst, ist das ein praktischer Weg.

Die richtige Wahl ist die, mit der Specs leichter zu schreiben, leichter zu prüfen und schwerer zu ignorieren sind. Wenn ein Tool Prozess hinzufügt, ohne die Klarheit zu erhöhen, lass es weg.

Hör auf zu prompten, fang an zu spezifizieren

Prompting zählt immer noch. Die Grundlagen solltest du kennen, und der Leitfaden von DocsBot zu den wichtigsten Prompt-Techniken ist eine ordentliche Auffrischung. Aber sobald die Arbeit ernst wird, reicht Prompting nicht.

Was Spec-driven Development ist, läuft auf Folgendes hinaus: ein dauerhaftes Artefakt, das deinem AI Agent weniger Raum zum Raten lässt und dir etwas Konkretes zum Prüfen gibt. Kein Manifest. Kein eingefrorener Plan. Kein Markdown-Theater.

Wenn du allein baust, ist das die Disziplin, die KI auch nach der Demo nützlich hält.

Der Engpass ist nicht mehr das Tippen von Code. Er liegt in der Entscheidung, was gebaut werden soll, was nicht gebaut werden soll und woran du erkennst, dass es korrekt ist.

Fang dort an.

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, sobald der PR gemergt ist, der sie baut.

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.