Vibe Coding funktioniert nicht. Warum du ein System brauchst statt Vibes

Alle reden über Vibe Coding. Ich zeige dir warum es in 3 Monaten scheitert. Und was ich stattdessen mache.

323 Stunden Claude Code in einem Monat. Ich code jeden Tag mit KI. Und ich sage dir: Vibe Coding ist der falsche Weg.

Nicht weil KI schlecht ist. Sondern weil Vibe Coding KI falsch nutzt.

Alle reden gerade davon. 22.000 Suchanfragen im Monat allein auf Deutsch bei Google. Y Combinator sagt, 25% ihrer Startups haben Codebases die zu 95% KI-generiert sind. Klingt nach Zukunft.

Ich zeige dir in diesem Newsletter warum das in 3 Monaten scheitert. Und was ich stattdessen mache.

Was ist Vibe Coding?

Andrej Karpathy hat den Begriff geprägt. Der Mitgründer von OpenAI. Seine Definition:

Fully giving in to the vibes.

Was heißt das konkret? Du gibst der KI einen Prompt. Die KI gibt dir Code zurück. Du guckst nicht rein. Du verstehst nicht was passiert. Du lässt es laufen und hoffst dass es funktioniert.

Und wenn es nicht funktioniert? Gibst du den Fehler der KI und hoffst nochmal.

Das fühlt sich produktiv an. Du baust in Stunden was früher Tage gedauert hat. Builder.io beschreibt das in seinem YouTube Video mit:

What feels like productivity.

Klingt gut. Funktioniert halt nicht.

Und ja: Für ein Wochenend-Projekt das du danach löschst, reichen Vibes. Karpathy hat das auch so gemeint. Aber für alles was in Produktion geht, was skalieren soll, was andere Menschen benutzen? Da brauchst du mehr.

Warum Vibe Coding scheitert

1. Du wirst schneller, aber schwächer

Hier sind die Daten.

METR hat eine randomisierte kontrollierte Studie gemacht. Mit erfahrenen Entwicklern. Das Ergebnis: Mit KI-Tools waren sie 19% langsamer. Obwohl sie selbst dachten, sie wären schneller.

Lies das nochmal. 19% langsamer. Trotz KI.

CodeRabbit hat KI-generierten Code analysiert. Das Ergebnis: 1,7 mal mehr schwerwiegende Fehler. 2,74 mal mehr Sicherheitslücken. Nicht ein bisschen mehr. Fast dreimal so viele Sicherheitslücken.

Warum? Brian Kernighan hat das vor 50 Jahren erklärt:

Debugging is twice as hard as writing code.

Wenn du den Code nicht selbst schreiben kannst, kannst du ihn auch nicht debuggen. So einfach ist das.

Builder.io bringt es auf den Punkt:

You’re building code faster, but becoming a weaker developer.

Stell dir vor du baust eine Suchfunktion mit Vibe Coding. 10 Testuser. Alles funktioniert. Kein Debouncing, kein Caching, kein Rate Limiting. Aber 10 User sind halt kein Problem.

Dann kommt Black Friday. 50.000 User gleichzeitig. Totalabsturz. 12.000 Dollar Verlust pro Minute.

Das ist das Problem. Vibe Coding funktioniert im Kleinen. Es explodiert im echten Einsatz.

Und das Schlimmste: Je länger du so arbeitest, desto schwächer wirst du. Ständiges Auslagern lässt dein Problemlösen verkümmern. Deine mentalen Modelle verschwinden.

Der Unterschied zwischen einem Senior und einem Vibe Coder ist nicht der Code. Es ist das mentale Modell dahinter.

KI verstärkt was da ist. Wenn da nichts ist, verstärkt sie halt nichts.

2. Du arbeitest an der App statt am System

IndyDevDan hat den wichtigsten Satz zum Thema gesagt:

You work on the agents, not the application.

Der fundamentale Fehler von Vibe Coding: Du arbeitest AN der App. Aber du solltest AM System arbeiten, das die App baut.

Das ist der Paradigmenwechsel den Vibe Coding komplett verpasst.

Stell dir drei Stufen vor:

No-Loop. Das ist Vibe Coding. Blindflug. Kein Plan, kein System, hoffen dass es klappt.

In-Loop. Das ist wo die meisten Entwickler gerade sind. Du kontrollierst jeden Schritt manuell. Du guckst dir den Code an. Du verstehst was passiert.

Out-of-Loop. Das ist Agentic Engineering. Dein System übernimmt. Du steuerst das System.

Vibe Coding ist nicht mal In-Loop. Es ist No-Loop. Kein Feedback, keine Kontrolle, keine Qualitätssicherung.

IndyDevDan sagt dazu:

Vibe Coding is not knowing and not looking. Agentic Engineering is knowing what will happen in your system so well you don’t need to look.

Standard-Tools reichen dafür nicht. Cursor out of the box. ChatGPT Copy-Paste. Das ist der niedrigste Einstieg. Du brauchst spezialisierte Agenten für DEINE Codebase. Nicht generische Tools für alle.

Roland von Never Code Alone zeigt das in seinem YouTube Video ganz praktisch:

Er hat ein Tool mit Vibe Coding gebaut. Ergebnis: DRY-Verletzungen überall (DRY = “Don’t Repeat Yourself” gleicher Code an mehreren Stellen statt einmal zentral). Obwohl er der KI gesagt hat: Sei DRY. Die KI hat Code dupliziert. Timestamps falsch berechnet. Und behauptet, alles wäre korrekt.

Oder guck dir den Ströer Blog an. Gemini CLI löscht Daten. Replit löscht die Datenbank. Das passiert wenn es keinen Closed Loop gibt. Keine Tests. Kein System. Nur Vibes.

Die Lösung ist nicht weniger KI. Die Lösung ist KI mit System.

Das Gegenmodell: So programmierst du wirklich mit KI

Stripe: Wie 1.300 PRs pro Woche wirklich funktionieren

Wenn du wissen willst wie Programmieren mit KI in groß aussieht, guck dir Stripe an.

Stripe hat ihr System “Minions” getauft und in zwei Blog-Posts auf stripe.dev erklärt: Part 1, Part 2. Keine Marketingversprechen. Engineering-Dokumente.

Die Zahlen:

• 1.300 Pull Requests pro Woche. Von Agenten erstellt. Kein Mensch schreibt den Code

• Hunderte Millionen Zeilen Code in der Codebase

• Über 3 Millionen automatisierte Tests

• Knapp 500 MCP Tools im internen “Toolshed”

• 10 Sekunden bis eine Agent-Sandbox bereit ist

Stripe verarbeitet 1,9 Billionen Dollar pro Jahr. Und ihr KI-System produziert jede Woche 1.300 PRs. Menschen prüfen den Code. Aber der Code kommt komplett von Agenten.

Ist das Vibe Coding? Nein. Das ist ein System:

1. Devbox-Pool: Isolierte Sandboxes, vorgewärmt, in 10 Sekunden bereit. Kein Zugriff auf Produktionsdaten

2. Agent Harness: Stripes eigener Coding-Agent, basierend auf dem Open-Source-Agent “Goose” von Block. Angepasst an ihre Codebase

3. Blueprints: Manche Schritte sind fest programmiert (Linting, Git-Push). Andere überlässt man der KI (Implementierung, Bug-Fixing). Die KI hat Freiheit wo sie Freiheit braucht

4. Rule Files: Kontextspezifische Regeln, an Verzeichnisse gebunden. Wenn der Agent in einen Ordner navigiert, werden die passenden Regeln geladen

5. Toolshed: Zentraler MCP Server mit knapp 500 Tools. Jeder Agent bekommt genau die Tools die für seine Aufgabe relevant sind

6. CI/Testing: Über 3 Millionen Tests. Jeder Agent darf maximal zwei CI-Runden laufen lassen. Danach geht die Aufgabe zurück an einen Menschen

7. Human Review: Jeder PR wird von einem Menschen geprüft bevor er gemerged wird

Und hier wird es interessant: Stripe synchronisiert dieselben Rule Files über Cursor, Claude Code und ihre Minions. Alle drei Plattformen lesen die gleichen Regeln. Das System ist tool-agnostisch.

Stripe nennt das:

Putting LLMs into contained boxes.

Die KI hat Freiraum. Aber innerhalb eines Systems das die Qualität garantiert.

Dein Startpunkt: Spec-Driven mit jedem Coding Agent

Du brauchst nicht Stripes Budget. Du brauchst nicht alle Komponenten am ersten Tag. Du brauchst einen Startpunkt.

Und der Startpunkt ist überraschend einfach: Hör auf zu prompten und fang an zu planen.

Das funktioniert mit jedem CLI-basierten Coding Agent:

• Claude Code (Anthropic). Das nutze ich. Terminal-basiert, tiefe Codebase-Analyse, eigenes Skills-System

• Cursor (Anysphere). IDE mit Agent-Mode und CLI. Stripe nutzt intern beide

• Goose (Block). Open Source. Der Agent den Stripe als Basis für ihre Minions geforkt hat

• Aider (Open Source). Über 100 Sprachen, funktioniert mit jedem LLM

Plus Codex, Cline, Gemini CLI und andere. Das Tool ist nicht der Punkt. Das System dahinter ist der Punkt.

Für mich war der Superpowers-Workflow in Claude Code der Startpunkt. Spec-driven statt prompten und hoffen.

Was macht der konkret?

Brainstorming. Die KI stellt dir Rückfragen. Nicht “mach mir eine App.” Sondern: Was genau soll die App können? Für wen? Warum so und nicht anders? Die KI hinterfragt deine Annahmen bevor eine Zeile Code geschrieben wird.

Implementierungsplan. Nach dem Brainstorming entsteht ein strukturierter Plan. Welche Dateien werden geändert. In welcher Reihenfolge. Welche Abhängigkeiten. Das ist der Unterschied. Vibe Coder prompten und hoffen. Ich plane und delegiere.

Skills als Qualitätssicherung. Zusätzliche Regeln steuern WIE implementiert wird. Einmal definiert, immer aktiv. Das ist im Prinzip das gleiche wie Stripes Rule Files. Nur halt für einen Solo-Entwickler statt für ein Enterprise-Team.

Weniger Bugs. Bessere Architektur. Code den ich wirklich verstehe. Das waren die Ergebnisse ab der ersten Woche.

Aber Superpowers ist eigentlich nur ein Startpunkt.

Das eigentliche Ziel ist ein System das zu DEINER Firma passt. Zu deiner Codebase. Zu deinen Anforderungen. Nicht ein generisches Tool das für alle gleich funktioniert.

Guck dir nochmal an was Stripe macht. Die haben nicht Cursor oder Claude Code out of the box genommen und gehofft. Die haben ihr eigenes System drumherum gebaut. Eigene Blueprints. Eigene Rule Files. Eigene MCP Tools. Und dann das gleiche Regelsystem über alle drei Plattformen synchronisiert.

1.300 PRs pro Woche sind das Ergebnis von jahrelanger Systemarbeit. Nicht von einem besseren Prompt.

So mappt Stripes System auf deins:

• Stripes Blueprints = Deine CLAUDE.md + Skills (oder .cursorrules in Cursor, oder Aider-Conventions)

• Stripes Rule Files = Dein Kontext-Engineering. Projektspezifische Regeln die dein Agent automatisch liest

• Stripes Toolshed = Deine MCP Server

• Stripes CI/Testing = Deine Tests + Linting

• Stripes Agent Harness = Dein CLI Coding Agent. Claude Code, Cursor, Codex, Aider, Goose. Egal welcher

Superpowers ist Schritt 1. Es zeigt dir wie spec-driven Development funktioniert. Es gibt dir schnelle Ergebnisse. Aber das Ziel ist dein eigenes System. Eins das du selbst gebaut hast. Das du verstehst. Das mit dir wächst.

Und jedes Problem das du löst wird ein Skill, ein Rule File, eine Konvention. Einmal gebaut, immer nutzbar. Das System wächst mit dir. Das ist der Unterschied: Du investierst nicht in schnelle Ergebnisse die morgen wertlos sind. Du investierst in ein System das jeden Tag besser wird.

Die Beweise

Hier sind meine Ergebnisse. Nicht theoretisch. Gebaut und im Einsatz.

Email Agent für Kunden: Ein KI-Agent der Support-Emails beantwortet. Accuracy von 93,8% auf 99,2% gebracht. Systematisch iteriert, nicht vibe-gecodet. Das sind 6 Prozentpunkte die den Unterschied machen ob ein Kunde eine richtige oder falsche Antwort bekommt.

SEO-System. Keyword-Datenbank mit über 170 Keywords plus automatisierter /seo Command. In einer Woche gebaut. Mit Superpowers geplant. Ohne System hätte ich drei Wochen gebraucht.

sales-engine. Ein neues SaaS. Auf Hetzner gehostet. €20 im Monat statt €150 bei Azure. Hetzner, Docker, Dokploy. Das ist kein Prototyp. Das läuft in Produktion.

Newsletter Digest. n8n holt jeden Morgen 19 Newsletter aus Gmail. Claude Code bewertet sie gegen mein aktuelles Thema und erstellt einen Morning Report. 95 Minuten manuelles Lesen runter auf 2 Minuten. 6 Nodes in n8n statt 200 Zeilen Python. Das ist mein System in Aktion: n8n orchestriert, Claude Code denkt. Und ich sehe auf einen Blick was relevant ist.

Hätte ein Vibe Coder das geschafft? Vielleicht den Prototyp. Aber nicht das System das danach jeden Tag besser wird.

KI verstärkt was da ist

Ohne System verstärkt Vibe Coding nur Chaos. Mehr Code, mehr Bugs, mehr technische Schuld.

Mit System verstärkt KI alles was du kannst. Mehr Projekte, weniger Fehler, bessere Ergebnisse.

Du musst nicht bei null anfangen. Fang mit einem Brainstorming-Workflow an. Bau deinen ersten Implementierungsplan. Und dann bau weiter. Bis du ein System hast das dir gehört.

Danke fürs Lesen.

Wenn du Fragen hast oder mir zeigen willst wie du mit KI codest, schreib mir gerne auf LinkedIn.

Bis nächste Woche,

Markus