Vibe Coding: Schnell, verlockend – und gefährlich

Anfang 2025 prägte Andrej Karpathy den Begriff „Vibe Coding": Man beschreibt, was man will, die AI generiert den Code, man akzeptiert ohne zu lesen. „Forget that the code even exists", wie er es formulierte. Seitdem hat der Begriff eine Eigendynamik entwickelt – und wird mittlerweile für alles verwendet, was irgendwie mit AI und Code zu tun hat.

Inzwischen hat Karpathy selbst nachgelegt und spricht von „Agentic Engineering" – dem bewussten Orchestrieren von AI-Agents mit menschlicher Kontrolle. Das ist ein wichtiger Unterschied. Denn reines Vibe Coding und professionelle AI-gestützte Entwicklung sind zwei grundverschiedene Dinge.

Ich nutze AI-Tools täglich in meiner Arbeit als Freelancer. Cursor, Claude, ChatGPT – sie sind fester Bestandteil meines Workflows. Aber ich habe auch gelernt, wo die Grenze zwischen Produktivitätsboost und Risiko verläuft.

Der klare Vorteil: Geschwindigkeit bei der Validierung

Vibe Coding glänzt in einer Disziplin: Geschwindigkeit. Wenn ich eine Produktidee validieren will, kann ich innerhalb von Stunden einen funktionierenden Prototypen bauen. Kein Boilerplate schreiben, kein Setup von Hand – einfach beschreiben, was ich brauche, und iterieren.

Für folgende Szenarien ist das Gold wert:

• Proof of Concepts: Funktioniert die Idee überhaupt? Gibt es einen Markt? Bevor ich Wochen in saubere Architektur investiere, will ich wissen, ob das Produkt jemand nutzen würde.
• Prototypen für Kundengespräche: Statt Mockups in Figma zu bauen, kann ich eine funktionierende Demo zeigen. Das überzeugt Stakeholder deutlich schneller.
• Scaffolding und Boilerplate: Wiederkehrende Strukturen wie API-Endpoints, CRUD-Operationen oder Formulare – hier spart die AI tatsächlich Zeit, ohne großes Risiko.

Die Kernfrage ist: Willst du herausfinden, ob etwas gebaut werden sollte – oder wie es gebaut werden sollte? Für das „Ob" ist Vibe Coding ein legitimes Werkzeug.

Die Gefahr: Sicherheit als blinder Fleck

Hier wird es kritisch. Vibe Coding ist besonders attraktiv für Menschen ohne technischen Hintergrund – Gründer, Produktmanager, Designer, die endlich „selbst bauen" können. Das Problem: Wer keine Erfahrung in Softwareentwicklung hat, weiß nicht, was fehlt.

Die AI generiert Code, der funktioniert. Aber „es funktioniert" und „es ist sicher" sind zwei völlig verschiedene Dinge.

Was typischerweise vergessen wird:

Input-Validierung: Die AI baut ein Formular, das Daten entgegennimmt und speichert. Aber validiert es die Eingaben serverseitig? Sind SQL-Injections abgefangen? Wird User-Input escaped, bevor er im Frontend gerendert wird?

Authentifizierung und Autorisierung: Ein Login wird generiert, aber ist die Session sicher? Werden Tokens korrekt invalidiert? Gibt es eine saubere Rechtetrennung zwischen Nutzerrollen?

HTTPS, CORS, CSP: Sicherheitsheader sind nicht glamourös. Die AI setzt sie selten von sich aus. Und wer nicht weiß, dass es sie gibt, fragt auch nicht danach.

Eine Studie von CodeRabbit aus Dezember 2025 hat gezeigt, dass AI-generierter Code in Open-Source-Projekten rund 2,7-mal mehr Sicherheitslücken enthält als menschlich geschriebener Code. Das ist keine Panikmache – das ist eine Statistik, die man ernst nehmen sollte.

Im Juli 2025 dokumentierte SaaStr-Gründer Jason Lemkin, wie Replits AI-Agent eine komplette Datenbank löschte – trotz expliziter Anweisung, keine Änderungen vorzunehmen. Bei der Vibe-Coding-Plattform Lovable wurden bei 170 von 1.645 generierten Web-Apps Sicherheitslücken gefunden, durch die persönliche Daten öffentlich zugänglich waren.

Wer Vibe Coding für produktive Software nutzt, muss sich im Klaren sein: Die AI denkt nicht an Security. Du musst es tun.

Das Context-Window-Problem

Ein Nachteil, über den wenig gesprochen wird: Aktuelle LLMs haben ein begrenztes Context Window. Das bedeutet, sie können nur eine bestimmte Menge an Code und Konversation gleichzeitig „sehen".

Bei kleinen Projekten fällt das kaum auf. Aber sobald eine Applikation wächst – mehrere Module, geteilte State-Logik, komplexe Datenflüsse – passiert Folgendes:

Die AI verliert den Überblick. Sie kennt Datei A nicht mehr, während sie Datei B bearbeitet. Das Ergebnis: Sie schreibt Logik um, die bereits funktioniert. Sie erstellt doppelte Implementierungen. Sie bricht bestehende Funktionalität, weil sie den Kontext nicht mehr hat.

Ich habe das selbst erlebt. Ab einer gewissen Projektgröße fängt die AI an, mehr kaputt zu machen als sie repariert. Man verbringt dann mehr Zeit damit, die AI-Änderungen rückgängig zu machen, als man durch sie gespart hat.

Das ist kein temporäres Problem, das mit dem nächsten Modell verschwindet. Context Windows werden größer, ja – aber die Komplexität realer Software wächst schneller. Eine Nuxt-App mit 50+ Komponenten, Pinia-Stores, API-Routen und Middleware übersteigt jedes aktuelle Context Window, wenn man alles gleichzeitig berücksichtigen müsste.

Tests: Das vernachlässigte Sicherheitsnetz

Der vielleicht kritischste Punkt: Vibe Coding produziert fast nie Tests. Und wenn man nicht explizit danach fragt, bleibt es dabei.

Unit Tests: Die AI schreibt eine Utility-Funktion, aber keinen Test dafür. Edge Cases? Werden ignoriert. Null-Checks? Fehlanzeige.

Integration Tests: Kommunizieren die Module korrekt miteinander? Funktioniert die API mit der tatsächlichen Datenbank, nicht nur mit einem Mock? Vibe-Coding-Projekte haben hier typischerweise null Abdeckung.

End-to-End Tests: Funktioniert der komplette User-Flow? Vom Login über die Dateneingabe bis zum Checkout? Ohne E2E-Tests ist jede Änderung ein Glücksspiel.

Das Tückische: Ohne Tests fühlt sich das Projekt erstmal produktiver an. Man spart die Zeit für Testcode. Aber jede Änderung wird zum Risiko. Jedes neue Feature kann bestehende Funktionalität brechen, ohne dass es jemand bemerkt – bis ein Nutzer sich beschwert.

Tests sind nicht optional. Sie sind das Sicherheitsnetz, das verhindert, dass ein funktionierender Prototyp beim ersten Refactoring zusammenbricht.

Fazit: AI als Copilot, nicht als Autopilot

Vibe Coding ist kein schlechtes Konzept. Es ist ein mächtiges Werkzeug für Validierung und Prototyping. Aber es ist kein Ersatz für Software Engineering.

Die Unterscheidung ist einfach: Wenn der Code weggeworfen wird, sobald die Idee validiert ist – Vibe Coding ist fine. Wenn der Code in Produktion geht und echte Nutzer betrifft – braucht es einen Entwickler, der den Code versteht, absichert und testet.

Karpathy hat das selbst erkannt und spricht mittlerweile von „Agentic Engineering" – dem bewussten Einsatz von AI-Agents unter menschlicher Aufsicht. Der entscheidende Unterschied: Man gibt die Verantwortung nicht ab. Man nutzt die Geschwindigkeit der AI, behält aber die Kontrolle über Architektur, Sicherheit und Qualität.

Mein persönlicher Ansatz: Ich nutze AI für Scaffolding, Boilerplate und als Sparring-Partner für Lösungsansätze. Aber ich lese jeden Diff. Ich schreibe Tests. Und ich verlasse mich nicht darauf, dass die AI weiß, was meine Applikation braucht – denn das weiß nur ich.

AI ist der beste Copilot, den Entwickler je hatten. Aber ein Copilot, dem man blind vertraut, wird irgendwann gegen einen Berg fliegen.