Der beliebteste Rat zu diesem Thema ist falsch. Du musst dich für keine Seite entscheiden und keiner Glaubensgemeinschaft beitreten.
Spec-driven Development wird als „Wasserfall mit Markdown“ verspottet, als Produktivitätsfalle und als Zeremonie, die Tokens verbrennt. Ein Teil dieser Kritik ist berechtigt. Wenn du jedes Feature in eine kleine Bürokratieübung verwandelst, würgst du dich selbst ab, bevor sich das Produkt sein Existenzrecht verdient hat.
Aber der umgekehrte Rat ist genauso schlampig. Reines Vibe Coding ist großartig – genau bis zu dem Moment, in dem du etwas ändern, einem Bug nachgehen oder dem Output vertrauen musst. Selbst in der Vibe-Coding-Szene sprechen inzwischen Leute das Unausgesprochene laut aus, etwa in Threads wie dieser r/vibecoding-Diskussion darüber, warum Vibe Coding ein Projekt versenken kann. Tempo fühlt sich gut an. Später das Chaos aufzuräumen nicht.
Wenn du als Solo Founder mit Cursor, Claude Code, Codex oder Gemini arbeitest, ist die eigentliche Frage keine ideologische. Es geht um Kontrolle. Wie viel Struktur brauchst du, bis ein AI Agent aufhört zu raten und anfängt, genau das zu bauen, was du wirklich gemeint hast? Das ist der Kipppunkt. Und genau deshalb taucht die Prompting Wall immer wieder auf, sobald eine Codebase nicht mehr wegwerfbar ist – nachzulesen im Text über das Vibe-Coding-Problem und die Prompting Wall, die die SDD-Welle ausgelöst hat.
| Kriterium | Vibe Coding | Spec-driven Development (leichtgewichtig) |
|---|---|---|
| Bester Einsatzzweck | Schnelles Erkunden | Dauerhafte Implementierung |
| Art des Inputs | Lose Prompts | Strukturierte Absicht |
| Zeit bis zum ersten Output | Sehr kurz | Am Anfang länger |
| Änderungen über mehrere Dateien | Riskant | Passt besser |
| Brownfield-Code | Fragil | Robuster |
| Übergabe an dein zukünftiges Ich | Schwach | Stark |
| Sicherheitskritische Arbeit | Vorgaben gehen leicht unter | Vorgaben lassen sich leichter vorab festlegen |
| Steuerung von AI Agents | Reaktiv | Kontrolliert |
| Typisches Scheitern | Chaotischer Drift | Zu viel Zeremonie |
Inhalt
- Die eigentliche Debatte zwischen Specs und Vibes
- Wann Vibe Coding gewinnt: Das Argument für Tempo
- Wann Spec-driven Development gewinnt: Das Argument für Korrektheit
- Den Kipppunkt finden: Die Grauzone
- Ein praxistauglicher SDD-Workflow für Solo Founder
- Ein ehrlicher Blick auf SDD-Tools und -Frameworks
- Das Fazit: So wählst du deinen Workflow
Die eigentliche Debatte zwischen Specs und Vibes
Der Streit geht nicht um Tempo gegen Qualität. Es geht um kurzfristigen Output gegen Software, die überlebt.
Vibe Coding sagt: Bleib in Bewegung. Prompte weiter. Teste weiter. Schubs das Modell so lange an, bis etwas funktioniert. Für einen frischen Prototyp ist das oft genau richtig. Du lernst schneller, wenn du das Ding anfasst, als wenn du es zu Tode planst.
Spec-driven Development sagt: Definiere die Arbeit, bevor du das Modell bittest, sie zu schreiben. Wer das kritisiert, hört darin veraltete Docs, eingefrorene Anforderungen und vorgetäuschte Gewissheit. Daher kommt der Gegenwind. Wenn deine „Spec“ zu einem Dokument wird, das niemand aktualisiert, dann ja: Dann hast du alte Fehlermuster mit besserem Branding neu aufgelegt.
Der Gegenwind ist echt
Viel von der Kritik aus 2026 sitzt, weil manche Teams eine nützliche Idee übertrieben haben. Sie haben einfache Aufgaben in Markdown-Theater verwandelt. Sie haben lange Specs für offensichtliche Arbeit geschrieben. Sie haben riesige Dokumente in Agents gekippt, Tokens verbrannt und trotzdem schlechten Code bekommen, weil die Spec nicht im tatsächlichen Repo verankert war.
Specs helfen, wenn sie Mehrdeutigkeit beseitigen. Sie schaden, wenn sie das Denken ersetzen.
Diese Unterscheidung zählt. Simon Willison setzt sich stark dafür ein, Agentic Engineering als praktische Disziplin zu verstehen, nicht als Papierkram-Fetisch. Thoughtworks hat ebenfalls dazu beigetragen, dass Specs als normaler Teil moderner KI-Workflows gelten können, ohne zu schwerfälligen Prozessen zu werden. Auch Birgitta Böckelers Einordnung hilft hier: Spec-first, Spec-anchored und Spec-as-Source sind nicht dasselbe. Die meisten Solo Founder brauchen das Letzte nicht für jede Aufgabe.
Solo Founder brauchen einen Regler, keine Doktrin
Die nützliche Antwort darauf, wann Spec-driven Development und wann Vibe Coding gewinnt, beginnt mit einer einzigen Frage: Was passiert, wenn der erste Output falsch ist?
Lautet die Antwort „nichts, dann werfe ich ihn eben weg“, sind Vibes in Ordnung.
Lautet die Antwort „dann verliere ich einen halben Tag damit, einen Haufen falscher Änderungen in bestehendem Code zu entwirren“, brauchst du Struktur. Genau da verdient sich eine leichtgewichtige Spec ihren Platz. Nicht, weil Prozesse edel wären. Sondern weil KI am stärksten ist, wenn du den Spielraum für Interpretation verkleinerst.
Viele, die bauen, übersehen das, weil sie den Prompt für das eigentliche Artefakt halten. Das ist er nicht. Ein Prompt ist eine Anweisung für einen Moment. Eine Spec ist eine wiederverwendbare Erklärung deiner Absicht.
Ein besserer Rahmen für die Debatte
Nimm diese Brille statt der üblichen:
- Ist die Aufgabe wegwerfbar, optimiere auf Tempo.
- Muss die Aufgabe überleben, optimiere auf Klarheit.
- Berührt die Aufgabe bestehende Komplexität, verlass dich nicht allein auf Vibes.
- Nutzt du einen Agent für die Umsetzung, gib ihm eine Grenze, keinen Wunsch.
Darum geht die Debatte. Nicht alte Schule gegen neue Schule. Nicht Planung gegen Kreativität. Sondern nur: Wie viel Mehrdeutigkeit kannst du dir bei dieser Aufgabe, in diesem Repo, bei diesem Risiko leisten?
Wann Vibe Coding gewinnt: Das Argument für Tempo
Vibe Coding gewinnt, wenn ein Fehler wenig kostet.
Das ist schon das ganze Argument. Wenn du dir Sackgassen, seltsame Architektur oder Code leisten kannst, den du morgen löschst, zählt Tempo mehr als Struktur. Du versuchst nicht, den Code zu bewahren. Du versuchst zu lernen.
Wo Vibes wirklich glänzen
Für Solo Builder ist Vibe Coding in einigen Situationen nach wie vor ein echter Vorteil:
- Wegwerf-Prototypen. Du testest, ob eine Idee überhaupt existieren sollte.
- Eine neue API erkunden. Du kennst ihren Umfang noch nicht, also zählt Entdecken mehr als Eleganz.
- Interne Skripte. Ein schnelles Einweg-Tool darf hässlich sein, wenn es dir heute Zeit spart.
- Fixes in einer einzigen Datei. Kleine, abgegrenzte Änderungen brauchen oft kein formales Artefakt.
- UI-Experimente. Du willst einen Flow sehen, keine dauerhafte Implementierung entwerfen.
Genau deshalb wurde Vibe Coding überhaupt populär. Es holt dich aus dem Planungsmodus und bringt dich in Kontakt mit der Realität. Ein grobes Feature vor Augen lehrt dich oft mehr als ein sauberes Dokument in deiner Notizen-App.
Warum es später bricht
Das Problem: Vibe Coding hat keinen natürlichen Haltepunkt. Wenn der erste Prompt funktioniert, ist die Versuchung groß, einfach weiterzumachen. Dann hängt ein zweites Feature vom ersten ab. Dann flickst du einen Bug. Dann kommt Auth dazu. Bis du merkst, dass der Code wichtig ist, hast du ihn längst in einem Stil gebaut, der davon ausging, dass er es nicht ist.
Genau dieses Muster ist der Grund, warum so viele „Vibe Coder“ ihren eigenen Rat inzwischen einschränken. Der weiter oben verlinkte Thread ist nicht gegen KI. Er ist gegen Chaos. Das Argument lautet nicht, dass Prompting nutzlos ist. Sondern dass Prompting ohne jede dauerhafte Struktur zerfällt, sobald jemand den Code verstehen, ändern oder ihm vertrauen muss.
Praktische Regel: Wenn du kein Problem damit hättest, den Branch heute Abend zu löschen, ist Vibe Coding noch eine Option.
Du holst auch viel heraus, wenn du Vibes mit besseren Tools kombinierst. Wenn du gerade Editoren und Agent-Workflows sortierst, ist diese Übersicht der besten Vibe-Coding-Tools ein guter Ausgangspunkt.
Halte Vibes an der kurzen Leine
Wenn du schon nach Gefühl codest, setz dir vor dem Start eine Grenze.
Eine einfache Variante:
- Formuliere das Ziel in einem Satz.
- Begrenze den Schadensradius. Wenn möglich eine Datei oder eine isolierte Oberfläche.
- Entscheide vorab, ob der Code nur vorübergehend ist.
- Halte an und wechsle den Modus, sobald die Aufgabe Datenmodelle, Auth, Routing oder bestehende Geschäftslogik berührt.
Vibe Coding ist kein schlechtes Engineering. Grenzenloses Vibe Coding schon.
Gut eingesetzt ist es der schnellste Weg, etwas zu erkunden. Zu lange eingesetzt wird es zu aufgeschobener Komplexität mit einem lustigen Namen.
Wann Spec-driven Development gewinnt: Das Argument für Korrektheit
Spec-driven Development gewinnt, wenn die Aufgabe erst richtig sein muss, bevor sie sich schnell anfühlen darf.
Das beginnt meist in dem Moment, in dem ein Feature mehrere Dateien berührt, bestehenden Code ändert oder echten Schaden anrichten kann, falls das Modell dich missversteht. Dann reichen Prompts nicht mehr. Du brauchst Anweisungen, die Bestand haben.
Arbeit über mehrere Dateien braucht eine Karte
Sobald eine Aufgabe Routen, Modelle, Validierung, UI-Zustände und Tests umfasst, braucht die KI mehr als einen Vibe. Sie muss wissen, was sich ändert, was nicht und wie die Teile zusammenpassen.
Deshalb ist „Specs schlagen Prompts“ zu einem wiederkehrenden Motiv geworden, etwa in diesem r/LLMDevs-Thread darüber, warum Specs Prompts schlagen und in dieser r/Anthropic-Diskussion darüber, warum Specs zuerst wirklich helfen. Der Punkt ist nicht, dass Prompts aufhören zu funktionieren. Der Punkt ist, dass Prompts allein brüchig werden, sobald das Modell mehrere bewegliche Teile koordinieren muss.
Eine ordentliche Spec muss nicht lang sein. Sie muss die Fragen beantworten, bei denen der Agent sonst raten würde:
- Welches Problem gelöst wird
- Welche Dateien oder Systeme im Scope sind
- Welche Vorgaben erhalten bleiben müssen
- Was als fertig gilt
- Welche Edge Cases nicht übersehen werden dürfen
Brownfield-Code bestraft vage Anweisungen
Greenfield-Arbeit verdeckt viele Sünden. Brownfield-Arbeit nicht.
Wenn du ein bestehendes Produkt bearbeitest, läuft die KI in Namenskonventionen, zufällige Kopplungen, halb fertige Migrationen, Geschäftsregeln und Kontext, der nirgendwo offensichtlich steht. RedMonk bringt den Kern in seiner Analyse von Specs gegen Vibes gut auf den Punkt. Specs sind für Menschen lesbare Artefakte, die die Absicht und das „Warum“ hinter dem Code festhalten, und diese Artefakte können sowohl dein Gedächtnis als auch das Token-Fenster einer KI überdauern. Das ist der praktische Wert. Keine Zeremonie. Beständigkeit.
Ein verwandter Aspekt ist der Flow im Team. Auch wenn du heute allein arbeitest, lohnt es sich, über Developer-Flow in KI-Workspaces nachzudenken, denn „Team“ heißt oft einfach: Dein heutiges Ich übergibt Arbeit an dein zukünftiges Ich.
Wenn die Codebase eine Geschichte hat, braucht der Agent Kontext, der den Chat überlebt.
Sicherheitskritische Arbeit sollte nicht nach Gefühl laufen
Sicherheitskritische Features brauchen explizite Vorgaben.
Wenn du mit Auth, Berechtigungen, Abrechnungslogik, sensiblen personenbezogenen Daten oder irgendetwas anderem zu tun hast, bei dem ein subtiler Fehler wehtut, zwingt dich eine Spec, an der richtigen Stelle langsamer zu werden.
Das garantiert keine Sicherheit. Aber es erzwingt klareres Denken:
- Erlaubtes Verhalten definieren
- Verbotene Abkürzungen benennen
- Erwartungen an die Validierung festhalten
- Fehlerfälle sichtbar machen, bevor es Code gibt
Ein Vibe-Prompt optimiert tendenziell auf plausiblen Output. Eine Spec hilft dir, auf korrektes Verhalten zu optimieren.
Den Kipppunkt finden: Die Grauzone
Die meisten Founder leben an keinem der beiden Extreme. Sie vibe-coden nicht alles in einen Sumpf, und sie schreiben kein Mini-PRD für jede Button-Anpassung.
Sie arbeiten in der Grauzone. Dort passiert der Großteil nützlicher KI-gestützter Entwicklung.
Die Frage nach dem Kipppunkt zählt mehr als die Etiketten
Eine der besseren Beobachtungen in der aktuellen Debatte stammt aus diesem Dev.to-Beitrag über den Mittelweg zwischen Vibe Coding und Spec-driven Development. Er weist darauf hin, dass alle sagen, Vibes seien schneller und Specs besser wartbar, aber kaum jemand sagt, ab wann sich der Aufwand auszahlt. Das ist die entscheidende Frage.
Für Solo Founder lautet die bessere Frage: Wie viel Struktur reicht, bevor das Tempo einbricht?
Nicht jede Aufgabe verdient dieselbe Behandlung. Wie viel Spec du brauchst, sollte sich nach drei Dingen richten:
| Art der Aufgabe | Besserer Standard |
|---|---|
| Klein und isoliert | Vibes |
| Mehrere Schritte, aber geringes Risiko | Leichte Spec |
| Bestehende Komplexität oder künftige Wartung | Stärkere Spec |
Nutze Struktur wie einen Dimmer
Vereinfacht gesagt:
- Ein Satz Struktur für winzige Änderungen an UI-Texten oder Styling.
- Eine kurze Checkliste für einen abgegrenzten Endpoint oder ein CRUD-Update.
- Eine echte Spec für alles mit Auswirkungen auf mehrere Dateien, unklaren Edge Cases oder Folgen fürs ganze Repo.
Auf diesen Mittelweg läuft der Markt zu. Erst strukturierter Kontext. Dann kontrollierte Umsetzung. Kein reaktives Chaos. Kein schwerfälliger Prozess.
Abkürzung für die Entscheidung: Je mehr Erklärung eine Aufgabe in einfachen Worten braucht, desto unwahrscheinlicher reicht ein roher Prompt.
Wie die Grauzone in der Praxis aussieht
Ein paar Beispiele machen es klarer.
Eine Layout-Anpassung auf einer einzelnen Seite braucht wahrscheinlich nicht mehr als einen direkten Prompt.
Ein neuer Onboarding-Schritt, der UI-Zustand, Persistenz, Analytics-Events, Validierung und E-Mail-Trigger berührt, sollte nicht mit „bau das Onboarding“ beginnen. So entsteht plausibles Chaos.
Ein Bugfix in einer Datei kann trotzdem gut nach Gefühl gehen. Ein Bug, der durch den Zustandsfluss über drei Schichten entsteht, braucht eine schriftliche Theorie des Problems, bevor du einen Agent bittest, ihn zu „fixen“.
Der Kipppunkt ist keine allgemeingültige Linie. Er ist eine Ermessensfrage. Aber sobald du auf die Form der Aufgabe, das Alter der Codebase und den Schadensradius achtest, fällt die Entscheidung leichter.
Ein praxistauglicher SDD-Workflow für Solo Founder
Ein nützlicher Workflow für Spec-driven Development sollte sich für Solo Founder leicht anfühlen. Fühlt er sich wie Zeremonie an, driftet er schon ab.
Der grundlegende Loop ist einfach. Schreib auf, welches Problem du löst. Mach daraus einen kompakten Plan. Gib den Plan an deinen Coding-Agent. Prüf, was zurückkommt. Wiederholen.
Fang beim Problem an, nicht bei der Implementierung
Der meiste schlechte KI-Output setzt zu tief im Stack an. Der Prompt springt direkt zum Code, bevor die Aufgabe klar ist.
Fang stattdessen mit einfacher Sprache an:
- Beschreib das Problem, das Menschen mit deinem Produkt haben. Was soll nach dieser Änderung möglich sein?
- Zieh die Grenzen des Scopes. Was gehört dazu, und was ist ausdrücklich draußen?
- Benenne die betroffenen Stellen. Routen, Komponenten, Modelle, Background-Jobs, Tests.
- Leg Akzeptanzchecks fest. Was müsste erfüllt sein, damit du sagst: „Ja, das ist fertig“?
Addy Osmanis beliebtes Spec-Format mit sechs Abschnitten ist hier nützlich, weil es dich ehrlich hält, ohne dass du einen Roman schreiben musst. Du brauchst keinen literarischen Schliff. Du brauchst eine Struktur, die das Modell vom Raten abhält.
Halte die Spec kurz und ausführbar
Bei Solo-Arbeit sieht eine gute Spec oft eher wie eine Checkliste aus als wie ein Dokument.
Ein praktisches Template:
Problem
- Welches Problem gibt es gerade – für die Menschen, die das Produkt nutzen, oder fürs Geschäft?
Scope
- Was gehört dazu?
- Was nicht?
Plan
- Welche Teile der Codebase sollen sich ändern?
Vorgaben
- Welche Muster, Abhängigkeiten oder Annahmen müssen intakt bleiben?
Validierung
- Welche Tests oder manuellen Checks sollen bestehen?
Risiken
- Wo könnte das schiefgehen?
Damit hat dein Agent einen stabilen Rahmen. Und du hast etwas, auf das du zurückkommen kannst, wenn der Output danebenliegt. Du streitest nicht mehr im Freitext mit dem Modell. Du korrigierst einen Plan.
Die Übergabe passiert von Hand. Du generierst oder schreibst die Spec und fügst sie dann in Cursor, Claude Code, Codex, Gemini oder was auch immer du nutzt ein. Umsetzung und Review bleiben in deiner Hand.
Erst die Routine lernen, dann Tempo machen
Viele Founder glauben, das bremst sie aus. Am Anfang vielleicht schon. Dann beginnt es, Zeit zu sparen, weil deine Prompts nicht mehr abschweifen.
Wenn du es praktisch durchspielen willst, ist Gui Ferreiras 30-Tage-Video zu Spec Kit eine solide Ressource. Einen eher schulungsorientierten Weg für den Umstieg bietet der Udemy-Kurs „SDD From Vibe-Coding to AI Engineering“.
Wenn du später noch einen kurzen Erklärer in Aktion sehen willst, lohnt sich ein Blick in dieses Video:
Eine gute Solo-Founder-Spec ist nicht lang. Sie ist so konkret, dass ein AI Agent weniger Stellen hat, an denen er sich clever anstellen kann.
Ein ehrlicher Blick auf SDD-Tools und -Frameworks
Rund um Spec-driven Development wird es schnell voll. Das ist ein gutes Zeichen, heißt aber auch, dass viele Founder Wrapper um dieselbe Grundidee vergleichen.
Die nützliche Frage ist nicht, welches Tool das „beste“ ist. Sondern welches Artefakt du am Ende haben willst und wie viel Zeremonie du dafür in Kauf nimmst.
Was diese Tools reparieren wollen
Das stärkste Argument für SDD-Tools ist Beständigkeit. Der weiter oben zitierte Punkt von RedMonk ist der Kern davon. Eine Spec kann dein Gedächtnis überdauern und das Token-Fenster auch. Das macht sie langlebiger als einen großartigen Prompt-Thread.
Diese Langlebigkeit zählt, wenn du Folgendes brauchst:
- Wiedereinstieg nach Kontextverlust
- Brownfield-Änderungen mit Vorgeschichte
- Asynchrone Zusammenarbeit
- Eine Quelle für deine Absicht, getrennt von Chatverläufen
Wenn du auch über Konsistenz jenseits des Codes nachdenkst, ist eine strukturierte Referenz wie eine Styleguide-API eine nützliche Parallele. Der Wert liegt nicht im Format selbst. Sondern darin, eine beständige Source of Truth zu haben, mit der Agents und Menschen gleichermaßen arbeiten können.
Die wichtigsten Kategorien
Ein paar Namen tauchen oft auf:
- GitHub Spec Kit. Gut für Markdown-basierte Workflows im Repo. Klares Denkmodell. Kann sich trotzdem manuell anfühlen, wenn du tiefere Führung willst, die deine Codebase kennt.
- Kiro. Interessant, wenn du eine stärker vorgegebene, IDE-zentrierte Erfahrung willst. Das kann eine Stärke oder eine Einschränkung sein, je nachdem, wie du arbeitest.
- OpenSpec. Vielversprechend als Standardisierungsversuch. Standards helfen, aber nur, wenn Tools und Teams sich daran halten.
- Traycer. Einen Blick wert, wenn du Specs direkter an den Ablauf der Implementierung binden willst.
- BMAD und verwandte Ansätze mit viel Markdown. Nützlich für alle, die explizite Struktur mögen. Leicht zu übertreiben.
Simon Willisons Texte zu Agentic Engineering sind hier relevant, weil sie den Fokus auf Zuverlässigkeit legen, nicht auf Theater. Der Sinn eines Frameworks ist nicht, mehr Dokumente zu produzieren. Sondern KI-Output besser steuerbar zu machen.
Wenn du einen breiteren Überblick willst, wie diese Ansätze in der Praxis zusammenpassen, ist dieser Leitfaden zu Spec-driven Development mit KI eine nützliche Ergänzung.
Was meistens schiefgeht
Die zwei häufigsten Fehler sind simpel:
- Spec Drift. Der Code ändert sich, die Spec nicht.
- Zeremonie vorab. Du verbringst zu viel Zeit damit, Struktur für Arbeit zu schreiben, die keine gebraucht hätte.
Beides lässt sich beheben. Halte das Artefakt nah am Code. Halte es so kurz, dass du es noch aktualisieren kannst. Behandle es als Steuerpult, nicht als Schrein.
Das Fazit: So wählst du deinen Workflow
Fang mit Vibe Coding an. Wechsle früher zu Specs, als du denkst.
Das ist die ehrliche Antwort.
Wenn du in den ersten Stunden eines Projekts steckst und noch testest, ob das Ding überhaupt existieren sollte, erstick dich nicht mit Struktur. Du brauchst Feedback, keinen Prozess. Aber sobald ein Feature den Kontakt mit künftigen Änderungen überleben muss, zahlt sich ein expliziterer Workflow aus.
Eine einfache Regel, die trägt
Nimm diese Regel:
- Passt die Aufgabe in einen Satz und bleibt sie lokal, mach sie per Vibe Coding.
- Braucht die Aufgabe einen Absatz zur Erklärung, schreib eine Spec.
- Berührt die Aufgabe bestehende Komplexität, vertrau nicht allein auf Vibes.
- Hat ein Fehler bei der Aufgabe echte Folgen, leg zuerst die Vorgaben fest.
Das ist nicht bloß Vorsicht. Es ist eine wirtschaftliche Entscheidung. Wie die Diskussion von InfoWorld über Vibe Coding und Spec-driven Development festhält, verbringen Devs etwa 50 % ihrer Zeit mit Wartung, und technische Schulden können im Schnitt rund 23 % der Entwicklungskapazität auffressen. Das zählt, weil Solo Founder keine freie Kapazität haben. Wenn du einen Tag an KI-generierte Nacharbeit verlierst, trägt diese Kosten niemand außer dir.
Das ehrliche Fazit
Spec-driven Development ist nicht automatisch besser. Es gewinnt, wenn der Code weiterleben muss.
Vibe Coding ist nicht unseriös. Es gewinnt, wenn Lerntempo wichtiger ist als Langlebigkeit.
Die meiste echte Solo-Founder-Arbeit liegt zwischen diesen Polen. Deshalb liegt der wichtigere Skill nicht darin, ein Lager zu wählen. Sondern darin zu lernen, wann du den Strukturregler hoch- und wann du ihn runterdrehst. Sobald du das draufhast, fühlt sich KI nicht mehr zufällig an. Sie wird brauchbar.
Der beste Workflow gibt dem Modell genug Klarheit, um erfolgreich zu sein, ohne dir selbst genug Prozess zu geben, um steckenzubleiben.
Wenn du allein baust, wird diese Einschätzung Teil des Jobs. Und sobald dein Projekt kein Spielzeug mehr ist, zählt sie mehr als jedes Etikett, das diesen Monat gerade im Trend liegt.
Wenn du raus aus dem Prompt-Spaghetti und rein in Specs willst, die deine Codebase kennen, probier Tekk.coach aus. Seine Loops schreiben Specs für dich, ausgehend von dem, was sich in deinem Code geändert hat; eine Spec von Hand zu schreiben ist der manuelle Weg auf dasselbe Board. Dein Coding-Agent baut sie, und die Akzeptanzkriterien schließen die Spec beim Merge des PRs.
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.