Den Begriff vibe coding prägte Andrej Karpathy im Februar 2025: Beschreib, was du willst, nimm an, was die KI ausgibt, lies den Code nicht. Sein Rahmen war großzügig gedacht, ein Wochenend-Modus für persönliche Projekte. Was daraus wurde, war etwas anderes. Bis Mitte 2025 hatten zahlreiche Nicht-Ingenieure produktive SaaS-Apps veröffentlicht, vollständig in Cursor, Replit Agent, v0 und bolt.new gebaut, ohne je zu verstehen, was sie da eigentlich gebaut hatten. Die Apps wirkten im Demo überzeugend. Einige brechen in der Produktion zusammen.
Was Vibe Coding tatsächlich bedeutet
Karpathys ursprüngliche Beschreibung ist präzise: Man ist "im Flow", sagt der KI, was man will, akzeptiert den Output, und versteht eigentlich nicht, was da läuft. Er sagte das ausdrücklich: "I don't read the code, I just vibe with it." Für ein persönliches Werkzeug oder einen Wegwerf-Prototyp ist das in Ordnung. Das Problem: Das Tooling-Ökosystem, Replit Agents "Ship your startup in a weekend", die One-Click-Deploys von v0, bolt.news sofortige Full-Stack-Generierung, hat diesen Modus als legitimen Weg in die Produktion vermarktet.
Die entstehenden technischen Schulden unterscheiden sich qualitativ von gewöhnlichem schlechtem Code.
Warum Vibe Code schlechter ist als schlechter handgeschriebener Code
Ein Junior-Entwickler, der schlechten Code schreibt, kennt seine Absicht. Man kann die Logik gemeinsam nachverfolgen und das Problem beheben. Generiert eine KI schlechten Code, den der Betreiber nie gelesen hat, existiert kein mentales Modell zum Wiederherstellen. Der Entwickler kann nicht erklären, warum die Authentifizierung so aufgebaut ist, weil er die Authentifizierung nie gelesen hat. Er kann nicht sagen, welche Drittanbieter-Bibliothek Zahlungen abwickelt, weil er die Datei akzeptiert hat, ohne sie zu öffnen. Der Code ist eine Black Box, die man besitzt, über die man aber nicht nachdenken kann.
Fehlerbilder, die in KI-generierten Produktions-Apps regelmäßig auftauchen:
- In ein Scaffold eingebaute Auth-Bypasses; JWT-Secrets in Beispieldateien für Umgebungsvariablen, die in öffentliche Repositories eingecheckt wurden: typische Befunde in Code-Reviews von KI-unterstützten Projekten ohne Engineering-Aufsicht. KI-generierter Auth-Code kopiert Muster aus Trainingsdaten, ohne das Sicherheitsmodell zu verstehen. Row-Level Security "vorübergehend" während der Entwicklung deaktiviert und in der Produktion so belassen. Rollen-Checks, die String-Literale vergleichen und sofort brechen, sobald ein Feldname geändert wird.
- Kein Error Handling jenseits des Happy Path. Die KI hat den Erfolgsfall implementiert. Was passiert, wenn der Zahlungsanbieter einen 402 zurückgibt? Was passiert, wenn die Datenbankverbindung mitten in einer Transaktion abbricht? In Vibe-codierten Apps lautet die Antwort meistens: ein unbehandelter Promise-Rejection, der als leerer Bildschirm sichtbar wird.
- Vendor Lock-in durch KI-generierte Strukturen. Die KI hat das Datenmodell auf eine bestimmte Art aufgebaut, der Vibe Coder hat es akzeptiert. Jetzt hängt die gesamte App an dieser Struktur. Wer davon wegmigrieren will, muss Code verstehen, den der Entwickler nie gelesen hat.
- Keine Tests. Tests fehlen, weil der Vibe Coder nie danach gefragt hat und die KI sie nicht von sich aus geschrieben hat. Wenn in der Produktion etwas bricht, gibt es keine Test-Suite, die Regressionen im Fix auffängt.
Die Lücke zwischen Demo und Produktion
KI-Werkzeuge sind wirklich gut darin, Code zu generieren, der auf dem Happy Path mit sauberen Eingaben, einem kooperativen Netzwerk und einem einzelnen gleichzeitigen Nutzer funktioniert. Genau das sind die Bedingungen, unter denen ein Demo läuft. Produktion ist das Gegenteil: fehlerhafte Eingaben, unterbrochene Verbindungen, gleichzeitige Schreibzugriffe, Edge Cases, die im Prompt nie spezifiziert wurden.
Das Muster läuft vorhersehbar ab. Eine Vibe-codierte App geht live, wirkt poliert, gewinnt erste Nutzer. Dann: Ein Nutzer mit einem Nicht-ASCII-Zeichen im Namen bricht die Datenbankabfrage. Ein mobiler Nutzer mit langsamer Verbindung löst eine Race Condition im State Management aus. Es gibt Szenarien, in denen API-Endpoints Daten über Nutzerkonten hinweg preisgeben, weil Autorisierungsprüfungen gefehlt haben oder unvollständig waren, eine direkte Konsequenz davon, Code zu veröffentlichen, der nie auf Server-seitige Durchsetzung geprüft wurde. Das sind keine exotischen Ausfälle. Es sind die grundlegenden Konsequenzen davon, Code zu veröffentlichen, den man nie gelesen hat.
KI macht gute Engineers besser, nicht schlechte Engineers überflüssig
Genau das kehrt die Vibe-Coding-Erzählung um. Die Werkzeuge sind real, die Produktivitätsgewinne sind real. Bei webvise kommen Claude Code, Cursor und Multi-Agent-Orchestrierung in jedem Projekt zum Einsatz. Engineers berichten von erheblichen Zeitgewinnen bei Aufgaben, die sonst Tage dauern würden. Dieselben Werkzeuge in den Händen von jemandem ohne Engineering-Grundlagen produzieren ein Demo, das den ersten echten Nutzer nicht übersteht.
Den Unterschied bringt der Engineer zum Werkzeug. Engineering-Grundlagen bedeuten: Systemgrenzen verstehen, Fehlermodi kennen, Sicherheitsmodelle durchdenken, Datenintegrität sicherstellen. Ein Engineer liest den generierten Authentifizierungscode und erkennt, wenn er falsch ist. Ein unerfahrener Entwickler akzeptiert den Vorschlag und veröffentlicht ihn.
| Fähigkeit | Engineer + KI-Werkzeuge | Vibe Coder + KI-Werkzeuge |
|---|---|---|
| Prototyp-Geschwindigkeit | Schnell | Schnell |
| Liest generierten Code | Ja, erkennt Fehler und Sicherheitsprobleme | Nein, akzeptiert und veröffentlicht |
| Behandelt Edge Cases | Spezifiziert sie proaktiv im Prompt | Entdeckt sie in der Produktion |
| Security Review | Im Review-Loop verankert | Nicht vorhanden |
| Kann Produktionsausfälle debuggen | Ja, kennt die Codebase | Nein, Black Box im eigenen Besitz |
| Skaliert über das Demo hinaus | Ja | Selten |
Das spezifische Risiko bei Business-Software
Consumer-Hobby-Apps können die Fehlermodi des Vibe Codings wegstecken. Verliert ein persönlicher Finanz-Tracker ein paar Daten, ist das ärgerlich. Veröffentlicht ein B2B-SaaS, das Kundendaten, Zahlungsabläufe oder interne Workflows verwaltet, die oben beschriebenen Auth- und Error-Handling-Probleme, sind die Folgen rechtlicher, vertraglicher und reputationaler Natur. GDPR-Haftung gilt unabhängig davon, wie der Code generiert wurde. Datenverarbeitender Code erfordert Review.
Mehrere jüngere KI-gestützte SaaS-Produkte haben ein ähnliches Muster durchlaufen: im Demo beeindruckend, frühe Kunden auf Basis des Versprechens gewonnen, dann an die Wand gefahren, als der erste Enterprise-Interessent ein Security Review durchführte oder der erste Traffic-Spitze die fehlende Fehlerbehandlung offenlegte. Die Gründer waren keine Betrüger: Sie wussten schlicht nicht, was sie gebaut hatten.
Worauf Sie bei einem KI-unterstützten Entwicklungspartner achten sollten
Evaluieren Sie einen Entwicklungspartner, der KI-Werkzeuge einsetzt, sollten Sie diese Fragen stellen:
- Führen sie automatisierte Tests auf KI-generiertem Code durch? Lautet die Antwort "Wir vertrauen dem KI-Output", gehen Sie. Test Coverage ist der Mechanismus, mit dem man das Error Handling auffängt, das die KI ausgelassen hat.
- Führen sie Security Reviews an generiertem Authentifizierungs- und Autorisierungscode durch? KI-Werkzeuge kopieren Auth-Muster aus Trainingsdaten. Diese Muster enthalten echte Schwachstellen aus echten Codebasen.
- Können sie die Architektur dessen erklären, was sie gebaut haben? Wer das Datenmodell nicht erklären und begründen kann, hat es nicht entworfen, sondern akzeptiert.
- Versionieren sie ihre Prompts zusammen mit dem Code? Engineering-Disziplin beim Einsatz von KI-Werkzeugen bedeutet, den Prompt als Teil der Codebase zu behandeln, nicht als Wegwerfeingang.
- Haben sie einen Prozess für den Umgang mit KI-Halluzinierungen? KI-Werkzeuge generieren selbstsicher fehlerhafte API-Aufrufe, veraltete Methoden und nicht existierende Bibliotheksfunktionen. Ein erfahrenes Team hat dafür einen Review-Loop. Ein Vibe Coder bemerkt das zur Laufzeit.
Der richtige Rahmen: KI als Kraftmultiplikator, nicht als Ersatz
Die Vibe-Coding-Erzählung ist verführerisch, weil sie teilweise stimmt. KI-Werkzeuge haben die Einstiegshürde für Software-Entwicklung tatsächlich gesenkt. Ein motivierter Nicht-Ingenieur kann an einem Wochenende einen funktionierenden Prototyp veröffentlichen. Das ist wertvoll für Validierung, für MVPs, für internes Tooling mit geringen Anforderungen. Der Irrtum liegt darin, den Boden mit der Decke zu verwechseln: anzunehmen, weil man etwas zum Laufen bringt, bekomme man es auch zuverlässig, skalierbar, sicher und wartbar zum Laufen.
Von KI-Coding-Werkzeugen haben jene Engineers am meisten profitiert, die sie einsetzen, um die mühsamen Teile des Engineering zu eliminieren: Boilerplate, Scaffolding, repetitive Refactors. Ihr Urteilsvermögen behalten sie für die Teile, die zählen: Architektur, Sicherheit, Error Handling und Produktionsreife. Die KI beschleunigt die Arbeit. Der Engineer stellt sicher, dass sie korrekt ist.
webvise setzt KI-unterstützte Entwicklung in jedem Projekt ein, Claude Code, Cursor, Multi-Agent-Pipelines, aber mit der Engineering-Disziplin, die den Output produktionsreif macht. Wer Software baut, die echte Nutzer, echte Edge Cases und echte Sicherheitsanforderungen überstehen muss, kann sich melden, um den Prozess kennenzulernen.
Die Praktiken von webvise sind an den ISO 27001- und ISO 42001-Standards ausgerichtet.