Vibe Coding ist nicht gescheitert, weil die Leute, die damit bauen, faul geworden wären. Es ist gescheitert, weil dem Workflow selbst irgendwann die Straße ausgeht.
Genau diesem Teil weichen viele noch immer aus. Der Gegenwind gegen Spec-driven Development war 2026 real. Manche nannten es „Wasserfall mit Markdown“. Andere eine Produktivitätsfalle, Spec Drift im schickeren Gewand oder eine Token verbrennende Zeremonie für alle, die das Schreiben von Docs vermisst haben. Ein Teil dieser Kritik ist berechtigt. Schlechte Specs sind bloß Bürokratie mit besserer Formatierung. Eingefrorene Specs sind nutzlos. Ein winziges Feature zu überspezifizieren ist selbst zugefügter Schmerz.
Der größere Fehler ist aber, so zu tun, als wäre die Alternative sauber, schnell und nachhaltig.
Das ist sie nicht. Vibe Coding ist großartig – bis zu dem Moment, in dem der Code den Kontakt mit der Realität überleben muss. Ausliefern. Debuggen. Auditieren. Erweitern. Jemand anderem übergeben. Nach einem Monat zurückkommen und verstehen, warum er funktioniert. Genau da zeigen sich die Risse. Die aktuelle Welle hin zu SDD kam nicht aus einer Ideologie. Sie kam daher, dass Leute immer wieder gegen dieselbe Mauer gelaufen sind und ihr dann einen Namen gegeben haben.
Diese Mauer ist das Prompting.
Inhalt
- Das Versprechen von Vibe Coding und sein Problem in Produktion
- Was ist Vibe Coding? Aufstieg und Fall eines Prototyp-Helden
- Die Prompting Wall: Warum dein AI Agent den Faden verliert
- Was undiszipliniertes KI-Coding in der Praxis kostet
- Die SDD-Welle: eine operative Antwort, keine Ideologie
- SDD ohne Zeremonie einführen: ein Leitfaden für Solo Builder
- Dein nächster Schritt: vom Vibe zu nachhaltigem Tempo
Das Versprechen von Vibe Coding und sein Problem in Produktion
Das Versprechen lag auf der Hand. Du beschreibst, was du willst. Das Modell schreibt Code. Du flickst, was falsch ist. Du machst weiter.
Für Wegwerfarbeit ist das immer noch nützlich. Wenn du in Cursor, Claude Code, Codex oder Gemini eine Idee ausprobierst, kann sich Vibe Coding absurd produktiv anfühlen. Du kommst in Schwung, bevor du in deinem Kopf auch nur den Architektur-Tab geöffnet hast. Das zählt, wenn du allein bist und Tempo dein Sauerstoff ist.
Das Problem in Produktion beginnt, wenn du schnelles Generieren mit dauerhaftem Verständnis verwechselst.
Schnell ausliefern heißt nicht, Software auszuliefern
Sobald Code Änderungen standhalten muss, fängt Vibe Coding an, Zinsen zu verlangen. Nicht, weil KI-Code immer schlecht wäre. Oft ist er in Ordnung. Das Problem ist, dass der Workflow dazu verleitet, zu akzeptieren, bevor du verstanden hast. Du fragst nicht mehr: „Warum ist das System so aufgebaut?“, sondern: „Kriege ich das noch durch einen weiteren Test?“
Für eine Demo funktioniert das. Für ein Produkt ist es schwach.
Faustregel: Wenn das Gedächtnis deines Projekts hauptsächlich im Chatverlauf steckt, hat dein Projekt kein Gedächtnis. Du hast ein scrollendes Transkript.
Deshalb trifft auch der Gegenwind gegen SDD nur zur Hälfte. Ja, Specs können zur Zeremonie werden. Ja, Leute können Templates nachahmen, ohne sie zu verstehen. Ja, „spec-first“ kann zu Prokrastination mit Überschriften werden. Simon Willisons Forderung nach Code, der reviewt, getestet und verstanden ist, ist ein nützliches Korrektiv. Birgitta Böckelers Einordnung in spec-first, spec-anchored und spec-as-source ist wichtig, weil sie hilfreiche Struktur von starrem Dogma trennt. Addy Osmanis Spec-Format mit sechs Abschnitten ist nützlich, weil es konkret ist und nicht mystisch.
Die praktische Erkenntnis ist einfach. Du brauchst nicht mehr Prozess. Du brauchst ein dauerhaftes Artefakt, das die Aufmerksamkeitsspanne des Modells überlebt – und deine eigene.
In einem Punkt hat der Gegenwind recht
Manche SDD-Fans haben es überverkauft. Wenn du für jede winzige Aufgabe eine riesige Markdown-Datei schreibst, verschwendest du Zeit. Wenn sich deine Spec nicht mehr ändern lässt, sobald du etwas dazulernst, hast du Wasserfall nachgebaut und es modern genannt. Wenn du mehr Tokens darauf verwendest, Arbeit zu beschreiben, als sie zu erledigen, ist die Kritik verdient.
Eine schlanke Spec vermeidet all das:
- Sie legt Grenzen fest. Was im Scope ist und was nicht.
- Sie liefert Akzeptanzkriterien. Was wahr sein muss, bevor du es fertig nennst.
- Sie hält Annahmen fest. Vor allem die riskanten.
- Sie übersteht eine Übergabe. An dein künftiges Ich, an jemanden aus dem Team oder an eine andere Modell-Session.
Deshalb sollten das Vibe-Coding-Problem und die Prompting Wall, die die SDD-Welle ausgelöst hat, als operative Lektion behandelt werden, nicht als Kulturkampf.
Was ist Vibe Coding? Aufstieg und Fall eines Prototyp-Helden
Vibe Coding ist das, was passiert, wenn natürliche Sprache zu deiner wichtigsten Schnittstelle für das Erstellen von Software wird. Du sagst dem Modell, was du willst. Es gibt dir Code. Du reagierst. Es überarbeitet. Der Loop fühlt sich lebendig an, schnell und seltsam kreativ.
Anfang 2025 war der Begriff gerade erst aufgetaucht. Am 2. Januar 2026 veröffentlichte Stack Overflow bereits eine eigene Kritik an „Vibe Coding ohne Code-Kenntnisse“ – das zeigt, wie schnell die Idee vom Nischen-Workflow zum Mainstream-Streitthema der Softwareentwicklung wurde, nachzulesen in der Kritik von Stack Overflow an Vibe Coding ohne Code-Kenntnisse.
Warum es sich wie Schummeln anfühlte – im besten Sinn
Eine arXiv-Studie beschrieb Vibe Coding als wiederholte Zyklen iterativer Zielerfüllung. Das Modell prompten. Den generierten Code prüfen. Testen. Bugs finden. Den Prompt verfeinern. Wiederholen. Dieser Loop passt perfekt dazu, wie viele Solo Builder ohnehin arbeiten, wenn sie im Erkundungsmodus sind.
Und in diesem Modus hilft er wirklich.
Du kommst von einer vagen Idee zu einem klickbaren Prototyp, ohne die übliche Einrichtungssteuer zu zahlen. Du musst nicht das ganze System im Kopf haben, um etwas ins Rollen zu bringen. Du kannst Anforderungen entdecken, indem du mit einer groben Umsetzung herumspielst, statt alles vorab durchzudenken.
Das ist das ehrliche Argument für Vibe Coding. Es ist kein Fake. Es ist nicht trivial.
Viele merkten auch, dass sich die Granularität der Prompts flexibel anpassen ließ. Manchmal reichte ein Prompt auf hoher Ebene. Manchmal reagierte das Modell besser, wenn die Anweisungen schmerzhaft genau waren. Diese Flexibilität ließ die Methode anpassungsfähig wirken.
Warum der Prototyp-Held zum Wartungsschurken wurde
Dieselbe Flexibilität ist auch die Falle.
Wenn dein Workflow zwischen vagen Wünschen und detaillierten technischen Anweisungen hin- und herpendelt, kannst du vorankommen, ohne eine stabile Aufzeichnung deiner Absicht zu schaffen. Du hast lokalen Schwung, kein gemeinsames Verständnis. In einem kleinen Experiment ist das beherrschbar. Wackelig wird es, sobald das Projekt Edge Cases, versteckte Annahmen und Patches ansammelt, die nur innerhalb der ursprünglichen Unterhaltung Sinn ergaben.
Devs fingen an, das in öffentlichen Threads laut auszusprechen. Du siehst diese Wende in Diskussionen wie warum Vibe Coding dein Projekt versenkt und wie du das vermeidest und in der pragmatischeren Formel, dass das beste Vibe Coding Vibe Coding mit Leitplanken ist. Diese Verschiebung ist wichtig. Sie zeigt, dass die früheren Fans nicht KI-Coding abgelehnt haben. Sie haben die Vorstellung abgelehnt, dass Chat allein genügt.
Vibe Coding ist großartig beim Helfen und miserabel beim Erinnern.
Das ist Aufstieg und Fall in einem Satz. Held im Prototyp. Risiko im Produkt.
Die Prompting Wall: Warum dein AI Agent den Faden verliert
Wer oft mit KI codet, kennt das Gefühl. Die Session startet stark. Das Modell ist hilfreich, kohärent und überraschend scharfsinnig. Dann fängt es an, Rahmenbedingungen zu übersehen, die du schon genannt hast. Es bearbeitet die falsche Datei. Es macht einen früheren Fix wieder kaputt. Es erfindet einen Pfad, den es nicht gibt. Du korrigierst es, kurz wird es besser, dann wackelt es wieder.
Das ist nicht einfach Pech. Das ist die Prompting Wall.
Natürliche Sprache ist eine schwache Designoberfläche
Dave Farleys Argument ist unverblümt und richtig. Natürliche Sprache ist vage. Sie ist ungenau. Deshalb taugt sie schlecht dazu, exakt festzulegen, was ein System tun muss, und schlecht dazu, zu prüfen, ob es das tut. IBM macht denselben Punkt aus einem anderen Blickwinkel: Vibe Coding sei nützlich für Prototypen, aber nicht ideal für verteilte Anwendungen, die Struktur, Optimierung, Disziplin beim Debuggen und Sicherheitskontrollen brauchen – besprochen in Dave Farleys Analyse, warum Prompts in natürlicher Sprache in der Softwarearchitektur versagen.
Das ist das Systemproblem unter dem Workflow-Problem.
Wenn die Oberfläche deiner Anweisungen unterspezifiziert ist, muss das Modell Lücken füllen. Manchmal füllt es sie gut. Manchmal mit plausiblem Unsinn. Je größer der Scope, desto mehr summieren sich diese Lücken. Der Agent verliert nicht den Faden, weil du eine magische Formulierung vergessen hast. Er verliert ihn, weil der Faden nie präzise genug festgehalten wurde, um stabil zu bleiben.
Viele reagieren darauf, indem sie versuchen, besser im Prompt Engineering zu werden. Das hilft, bis zu einem gewissen Punkt. Wenn du diesen Skill schärfen willst, ist der Leitfaden von SupportGPT eine nützliche Einführung dazu, wie Prompting in der Praxis funktioniert.
Aber besseres Prompting ist nur ein Teil der Antwort.
Warum besseres Prompting das Problem nicht ganz löst
Prompting verbessert lokale Ergebnisse. Es schafft keine dauerhafte Architektur. Es gibt deinem Projekt kein Gedächtnismodell. Es setzt keine Grenzen, zu denen das Modell nach einer langen Session oder in einem frischen Context Window verlässlich zurückfindet.
Deshalb haben Teams und Solo Builder angefangen, explizitere Kontextschichten und Agent-Workflows einzuführen, darunter Ansätze, wie sie in Mustern für AI Agent Orchestration in Softwareteams besprochen werden. Die Kernidee ist keine schicke Orchestrierung um ihrer selbst willen. Es geht darum, dass das Modell mit stabilen Artefakten arbeitet statt mit einem Haufen Gesprächsrückständen.
Die Prompting Wall zeigt sich meist als Bündel von Symptomen:
- Kontextverfall: Frühere Entscheidungen prägen spätere Ergebnisse nicht mehr.
- Wachsende Mehrdeutigkeit: Kleine vage Formulierungen werden zu großen Fehlern in der Umsetzung.
- Stiller Scope Creep: Der Agent löst mehr, als du verlangt hast – oft schlecht.
- Falsche Sicherheit: Das Ergebnis sieht so poliert aus, dass du weniger sorgfältig prüfst.
Sobald das Modell anfängt, Architektur zu improvisieren, steuerst du den Build nicht mehr. Du verhandelst mit ihm.
An diesem Punkt hört „prompte halt besser“ auf, ein ernsthafter Rat zu sein.
Was undiszipliniertes KI-Coding in der Praxis kostet
Die Kosten von undiszipliniertem KI-Coding lassen sich in der ersten Woche leicht verstecken. Später kaum noch.
Ein grober Prototyp mit wackeligem Innenleben kann trotzdem beeindrucken. Ein chaotisches Feature kann trotzdem eine gute Demo abgeben. Frühes Tempo fühlt sich wie der Beweis an, dass der Workflow funktioniert. Dann altert das Projekt ein wenig, und die Rechnung kommt – in Form von Wartung, Debugging und verlorenem Vertrauen.
Die klarste öffentliche Beschreibung dafür ist die Drei-Monats-Mauer. Berichte über Vibe Coding versus SDD beschrieben 2026, dass Vibe Coding Prototypen zwar schnell ausliefern kann, aber nach etwa drei Monaten meist zusammenbricht, weil Anforderungen driften, der Wartungsaufwand steigt und der Chatverlauf nicht mehr als dauerhaftes Projektgedächtnis taugt – so beschrieben in dem Vergleich von Vibe Coding und Spec-driven Development bei Augment Code.
Die Kosten zeigen sich nach der Demo
Sobald du diese Mauer erreichst, ist das Fehlerbild vertraut:
| Was du anfangs spürst | Womit du später kämpfst |
|---|---|
| Schneller Feature-Output | Langsamere Änderungen, weil die Absicht unklar ist |
| Leichtes Flicken | Regressionen durch lokale Fixes |
| Flexibles Prompting | Inkonsistentes Verhalten über Sessions hinweg |
| Reibungsarmer Start | Reibungsreiche Wartung |
Eine Weile kannst du damit leben, wenn nur du den Code anfasst und wenig auf dem Spiel steht. Ungemütlich wird es, sobald einer dieser Punkte zutrifft:
- Du musst Verhalten auditieren.
- Du musst Probleme in Produktion debuggen.
- Du musst Secrets und Deployment-Pfade absichern.
- Du musst Arbeit über die Zeit hinweg übergeben, selbst wenn am anderen Ende nur dein künftiges Ich sitzt.
Ein Großteil des Schmerzes landet zuerst an unsichtbaren Stellen. Konfiguration. Auth-Flows. Migrationen. Retry-Logik. Berechtigungsgrenzen. Wenn du Umgebungen über mehrere Tools und Agents hinweg einrichtest, lohnt sich der Beitrag von EnvManager zum Absichern von Env-Dateien, weil der Umgang mit Secrets eine der ersten Stellen ist, an denen schlampige KI-gestützte Workflows vermeidbare Risiken schaffen.
Security-Schulden sind auch Schulden
Tenables Warnung ist eindeutig. Vibe Coding heißt oft, das Modell Code schreiben und reparieren zu lassen, bei minimaler Prüfung, und der Einsatz in Produktion sollte sich nicht auf blind akzeptierte Ergebnisse verlassen. Code braucht Review, Tests in niedrigeren Umgebungen und Validierung durch Unit- und Integrationstests, wie das FAQ von Tenable zu Risiken und Schutzmaßnahmen beim Vibe Coding erklärt.
Dieser Punkt wiegt schwerer als jedes Argument aus dem Hype-Zyklus.
Wenn du nicht erklären kannst, warum ein kritischer Pfad funktioniert, gehört er dir nicht. Du mietest ihn von einem Modell.
Die eigentlichen Kosten bestehen nicht darin, dass KI schnell Code schreibt. Sie bestehen in dem, was passiert, wenn du Tempo ohne Verifikation akzeptierst.
Die SDD-Welle: eine operative Antwort, keine Ideologie
Spec-driven Development hat nicht abgehoben, weil Devs plötzlich ihre romantische Ader für Prozesse entdeckt hätten. Es hat abgehoben, weil ein Weg nötig war, die Absicht außerhalb des Chatfensters festzuhalten.
Das ist der praktische Kern der SDD-Welle. Eine Spec ist nicht dazu da, dich auszubremsen. Sie ist dazu da, die Arbeit an etwas festzumachen, das dauerhaft genug ist, damit sich Menschen und Modelle weiter einig sein können, was gebaut wird.
Was sich in der Praxis geändert hat
Der Kontrast ist einfach. Vibe Coding folgt meist einem Loop aus Prompt → Code → Patch. SDD führt einen strukturierteren Ablauf ein: Spec → Design → Aufgabenplan → Umsetzung → Verifikation. Diese Verschiebung war einer der klarsten Gründe, warum SDD überhaupt Fahrt aufgenommen hat, denn Specs schaffen kürzere und wirksamere Feedback-Loops über echte Arbeit hinweg, nicht nur innerhalb einer einzelnen Modell-Session.
Achte darauf, was das nicht ist. Es ist keine Forderung nach gewaltigen Vorab-Docs. Es ist kein Verbot von Experimenten. Es heißt nicht, dass jede Aufgabe ein volles Ritual verdient.
Es heißt, dass das Modell etwas Besseres als Vibes braucht, sobald die Arbeit zählt.
Deshalb sind so viele Frameworks und Communities bei ähnlichen Ideen gelandet, auch wenn sie andere Namen dafür hatten. Die Diskussionen um das Thoughtworks Tech Radar, GitHub Spec Kit, Kiro, OpenSpec, Traycer, Vibe Kanban, BMAD, Drew Breunigs Texte über den Aufstieg von SDD und Birgitta Böckelers Taxonomie zeigen alle auf dieselbe operative Wahrheit. Du brauchst ein Artefakt, das Scope, Annahmen, Rahmenbedingungen und Akzeptanzkriterien in einer Form festhält, die mehrere Umsetzungsdurchläufe übersteht.
Einen knappen Einstieg bietet dieser Leitfaden zu Spec-driven Development.
Was dir eine Spec gibt und ein Chatverlauf nie
Eine gute Spec erledigt vier Jobs auf einmal:
- Sie engt Mehrdeutigkeit ein. Der Agent hat weniger Raum zum Raten.
- Sie macht Entscheidungen sichtbar. Du verlässt dich nicht auf dein Gedächtnis.
- Sie verbessert das Review. Du kannst das Ergebnis mit der Absicht vergleichen.
- Sie reduziert Nacharbeit. Klare Grenzen verhindern ungewolltes Ausufern.
Der letzte Punkt ist der Grund, warum die Kritik an der „Token verbrennenden Zeremonie“ bei einer schlanken Spec ins Leere läuft. Eine kurze, scharfe Spec spart oft Tokens, weil sie später lange Korrektur-Loops verhindert.
Hier die Version ohne Ideologie. SDD ist das, was aus KI-Coding wird, wenn du das Generieren nicht mehr für den schwierigen Teil hältst. Der schwierige Teil ist, die Absicht zu bewahren, während sich das System verändert.
SDD ohne Zeremonie einführen: ein Leitfaden für Solo Builder
Wenn du allein baust, ist es der falsche Weg, SDD einzuführen, indem du den Prozess eines großen Unternehmens nachahmst. Du brauchst keine Freigabestufen, keine Gremiendokumente und keine sechs Planungsebenen. Du brauchst genug Struktur, damit deine Agents nützlich bleiben, nachdem die erste Welle der Begeisterung verflogen ist.
Das ist alles.
Fang kleiner an, als dir die Spec-Fans raten
Die meisten Solo Builder korrigieren über. Entweder schreiben sie gar keine Spec oder ein riesiges Pseudo-PRD für ein Feature, das ein paar Stichpunkte hätte sein sollen.
Nimm eine einfache Regel: Je teurer der Fehler, desto expliziter die Spec.
Für winzige Aufgaben reichen ein paar Zeilen. Für alles, was Zahlungen, Auth, die Form der Daten, Migrationen, Berechtigungen oder externe APIs berührt, schreib zuerst die Spec. Nicht, weil das heilig wäre. Sondern weil genau dort vage Absichten zu teuren Aufräumarbeiten werden.
Ein schlanker Einstieg sieht so aus:
- Fang mit Grenzlinien an. Halte fest, was die Aufgabe umfasst und was nicht.
- Schreib Akzeptanzkriterien in einfacher Sprache. Was wahr sein muss, damit die Arbeit als erledigt gilt.
- Halte Annahmen fest. Vor allem, wenn sich der Agent darauf verlassen wird.
- Ergänze Validierungsszenarien. Ein paar Prüfungen, die falsche, aber plausible Ergebnisse erwischen.
Eine schlanke Spec, die wirklich hilft
Addy Osmanis Spec-Format mit sechs Abschnitten ist nützlich, weil es genug Struktur gibt, ohne einen Roman zu verlangen. Du musst kein Template exakt kopieren, aber diese Teile verdienen sich meist ihren Platz:
| Teil der Spec | Warum er wichtig ist |
|---|---|
| Problem | Bindet die Arbeit an ein echtes Nutzerbedürfnis |
| Scope | Verhindert, dass das Projekt ungewollt ausufert |
| Anforderungen | Gibt dem Agent konkrete Ziele |
| Akzeptanzkriterien | Macht das Review schneller und weniger subjektiv |
| Risiken und Annahmen | Bringt versteckte Schwachstellen ans Licht |
| Validierung | Zwingt dich, an Beweise zu denken, nicht nur ans Generieren |
Wenn du einen Ausgangspunkt willst, ist ein solides Template für ein Product Requirements Document besser, als mit einer leeren Seite anzufangen und so zu tun, als würde Struktur von allein entstehen.
Praxistest: Wenn deine Spec einem Agent nicht sagen kann, was er nicht bauen soll, ist sie wahrscheinlich zu vage.
Die besten Specs für Solo-Arbeit sind kurz genug, um aktuell zu bleiben. So vermeidest du Spec Drift und eingefrorene Specs. Die Spec ist ein lebendiges Artefakt. Wenn sich die Realität ändert, ändert sich die Spec. Wenn sich der Code ändert und die Spec nicht, verrottet das Artefakt bereits.
Dein Toolset wählen, ohne in die Falle zu tappen
Für den Anfang brauchst du keine spezielle Software.
Einfaches Markdown in deinem Repo reicht für viele. GitHub-Issues plus eine Spec-Datei reichen. Ein Docs-Ordner mit einem aktuellen Feature-Brief reicht. GitHub Spec Kit ist interessant, weil es schnell Struktur gibt, aber manchen ist es für kleine Aufgaben zu schwer. OpenSpec setzt auf Offenheit und Portabilität, was attraktiv ist, wenn du proprietären Workflow-Lock-in nicht magst. Kiro und Traycer sprechen alle an, die stärker geführte Systeme wollen. Vibe Kanban und BMAD richten sich an Teams, die ihr Tempo halten und trotzdem Leitplanken einziehen wollen.
Die nützliche Frage beim Vergleich ist nicht „Welches ist das beste?“, sondern „Welches bringt die wenigste Zeremonie und erzwingt trotzdem Klarheit?“
Nimm diesen Filter:
- Als Solo Founder mit hohem Tempo: Fang mit Markdown und einem leichtgewichtigen Template an.
- Als kleines Team, das KI-Workflows teilt: Wähl etwas, das Specs sichtbar und leicht aktualisierbar macht.
- Bei Brownfield-Codebases: Setz auf Tools und Gewohnheiten, die Specs an die bestehende Architektur binden, nicht nur an Greenfield-Generierung.
Wenn ein Tool dich mehr Zeit mit Formatieren als mit Entscheiden verbringen lässt, wirf es raus. Wenn es dir hilft, Cursor, Claude Code, Codex oder Gemini saubereren Kontext zu geben und Ergebnisse schneller zu prüfen, behalt es.
Darum geht es im Kern.
Dein nächster Schritt: vom Vibe zu nachhaltigem Tempo
Vibe Coding hat vielen den ersten echten Vorgeschmack auf Tempo in der Softwareentwicklung gegeben. Dieser Teil war wertvoll. Es hat die Hürde gesenkt, Dinge auszuprobieren. Es hat Prototyping leichter gemacht. Es hat Leuten, die allein arbeiten, eine Zeit lang erlaubt, über ihrer Gewichtsklasse zu boxen.
Aber das Tempo hatte Bedingungen.
Sobald die Arbeit Wartung, Audits, Bugjagden oder Übergaben überstehen musste, brach der Workflow unter dem eigenen fehlenden Kontext zusammen. Das ist der Kern des Vibe-Coding-Problems und der Prompting Wall, die die SDD-Welle ausgelöst hat. Keine Moral. Keine Mode. Eine praktische Grenze.
Du kannst weiter mit besseren Chat-Gewohnheiten gegen diese Grenze ankämpfen. Manches davon hilft. Du kannst beim Review disziplinierter werden. Das hilft auch. Aber nachhaltiges Tempo entsteht nicht dadurch, dass du den Prompt-Loop noch fester auswringst. Es entsteht dadurch, dass du das Problem schärfer fasst, bevor das Modell zu tippen beginnt.
Das leisten Specs, wenn sie richtig gemacht sind. Sie töten das Tempo nicht. Sie bewahren es.
Wenn du mit KI-Coding-Agents echte Produkte baust, besteht dein Job nicht darin, besser zu zocken. Er besteht darin, deine Absicht besser zu definieren. Das heißt: Scope-Grenzen. Akzeptanzkriterien. Annahmen. Validierung. Genug Architektur, damit das System lesbar bleibt. Nicht mehr, als du brauchst. Nicht weniger, als die Realität verlangt.
Wer SDD eingeführt hat, wollte nicht diszipliniert aussehen. Es ging darum, nicht länger die Kontrolle über die eigenen Projekte zu verlieren.
Tekk.coach ist für genau diesen Wandel gebaut. Seine Loops schreiben Specs für dich aus dem, was sich in deinem GitHub-Repo geändert hat. Eine Spec von Hand zu schreiben ist der manuelle Weg auf dasselbe Board, und die Akzeptanzkriterien schließen sie, wenn der PR gemergt 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.