Vibe Coding

Der Code wird dabei zur Black Box: Er erfüllt seinen Zweck im Moment der Ausführung, aber niemand im Team kann zuverlässig erklären, wie er das tut.

Der Begriff wurde am 2. Februar 2025 von Andrej Karpathy geprägt, einem der bekanntesten Vertreter des maschinellen Lernens und Mitgründer von OpenAI. In seinem ursprünglichen Beitrag beschrieb er einen Programmierstil, bei dem man sich „voll dem Vibe hingibt“ und sogar „vergisst, dass der Code überhaupt existiert“. Innerhalb weniger Monate wurde „Vibe Coding“ zum Sammelbegriff für die Praxis, Software fast vollständig durch Prompts an Coding-Agenten wie Cursor, Claude Code oder GitHub Copilot entstehen zu lassen.

Wie sich Vibe Coding von KI-gestützter Entwicklung unterscheidet

Vibe Coding ist nicht dasselbe wie der allgemeine Einsatz von KI in der Softwareentwicklung. Der Unterschied liegt nicht im Werkzeug, sondern in der Haltung gegenüber dem erzeugten Code. Wer mit einem Modell paart, jeden Vorschlag liest, gezielt Tests einfordert, Sicherheitsfragen stellt und Architekturentscheidungen bewusst selbst trifft, betreibt KI-gestützte Entwicklung – aber kein Vibe Coding. Beim Vibe Coding hingegen wird die Bewertungsinstanz Mensch übersprungen: Das Modell schreibt, der Mensch akzeptiert.

Diese Abgrenzung ist entscheidend, weil sie bestimmt, welche Qualität am Ende auf einem System landet. Eine erfahrene Entwicklerin trifft in einer einzigen Stunde Dutzende kleiner Design- und Architekturentscheidungen – etwa, eine Datenbankabfrage aus einer Schleife herauszuziehen, bevor sie bei großen Datenmengen das System ausbremst. Vibe Coding ersetzt diese Entscheidungen nicht, es überspringt sie.

Typische Merkmale

• Zielbeschreibung statt Implementierung: Der Mensch formuliert das gewünschte Verhalten, nicht den Lösungsweg.
• Ungeprüfte Übernahme: Der vorgeschlagene Diff wird akzeptiert, ohne ihn vollständig zu lesen.
• Fehler-Ping-Pong: Fehlermeldungen werden zurück ins Modell gegeben, bis es läuft.
• Code als Black Box: Das Ergebnis funktioniert, ist aber im Team nicht erklärbar.

Wo Vibe Coding sinnvoll ist

Vibe Coding ist kein Gegenteil guter Softwareentwicklung, sondern ein Werkzeug mit einem klar umrissenen Anwendungsbereich. Sinnvoll ist es überall dort, wo die Software die Phase, in der sie wartbar sein müsste, nie erreicht:

• Wegwerf-Prototypen, deren ausdrücklicher Zweck es ist, eine Idee zu validieren und danach verworfen zu werden.
• Interne Skripte und Einmalwerkzeuge ohne Außenwirkung und ohne langfristige Pflege.
• Explorative Datenanalysen, in denen die Erkenntnis zählt und nicht der Code.
• Schnelle UI-Mockups, die später ohnehin neu gebaut werden.

Ein zweites legitimes Einsatzgebiet ist die Beschleunigung erfahrener Entwickler: Wer den generierten Code in Sekunden bewertet, weil er ihn ohnehin selbst schreiben könnte, nutzt das Modell als Tastatur, nicht als Architekten. Das ist in vielen Engineering-Teams gelebte Realität – und im engeren Sinn bereits kein Vibe Coding mehr, weil die menschliche Prüfung erhalten bleibt.

Wo Vibe Coding gefährlich wird

Kritisch wird Vibe Coding, sobald die so entstandene Software produktiv geht und Geschäftsprozesse oder Kundendaten berührt. Untersuchungen aus den Jahren 2024 und 2025 zeigen ein konsistentes Bild: KI-generierter Code weist im Schnitt deutlich mehr Sicherheitslücken auf als rein menschlich geschriebener, die Zahl der monatlich entdeckten Schwachstellen in großen Unternehmen ist in kurzer Zeit drastisch gestiegen, und die Pflege des Codes (Refactoring) ist messbar zurückgegangen, während sich duplizierte Code-Blöcke vervielfacht haben. Was wie Beschleunigung aussieht, ist häufig vorgezogene technische Schuld: Die Rechnung kommt später, in Form teurer Wartung.

Der Grund ist strukturell: Wer Code nicht liest, kann ihn nicht bewerten. Genau die Qualitätsmerkmale, die über die Wirtschaftlichkeit eines Systems über Jahre entscheiden – Wartbarkeit, Testbarkeit, Sicherheit, Performance unter realer Last, Beobachtbarkeit und Compliance-Tauglichkeit – sind in den ersten Wochen nach Auslieferung unsichtbar und werden beim Vibe Coding systematisch nicht adressiert.

Praxisbeispiel: Der MVP, der zu lange lebt

Ein konkretes Muster aus der Praxis: In der Versicherungs-IT laufen Bestands- und Abrechnungssysteme regelmäßig zehn bis fünfzehn Jahre. Ein in drei Wochen vibe-gecodeter Minimum Viable Product, der ungeprüft in Produktion geht, durchläuft über diese Zeit Hunderte Änderungen durch wechselnde Teams. Ohne Architektur-Dokumentation, ohne automatisierte Tests und ohne klare Verantwortlichkeiten im Code wird jede Erweiterung teurer als die vorige – bis eine triviale Anpassung mehrere Personenwochen kostet und die einzige verbleibende Antwort „lieber neu bauen“ lautet. So kehrt die Wegwerf-Mentalität auf Systemebene zurück.

Vibe Coding im Unternehmenskontext absichern

Unternehmen müssen Vibe Coding nicht verbieten, aber sie sollten es organisatorisch einrahmen. Drei Maßnahmen haben sich bewährt:

• Anteil ungelesenen Codes erfragen: Bei der Abnahme eines Systems ist die Frage legitim, welcher Anteil des Codes von einem Menschen gelesen wurde, bevor er ins Repository gelangte. Die Antwort sagt mehr über das spätere Risiko aus als jeder Demo-Termin.
• Abnahmekriterien über „funktioniert“ hinaus: Dokumentierte Architektur, automatisierte Tests auf den Kernpfaden und eine Prüfung gegen gängige Sicherheitsstandards (etwa die OWASP Top 10) gehören zur Abnahme – unabhängig davon, ob KI im Spiel war.
• Spielwiese und Produktion trennen: Eine klare Promotion-Stufe zwischen Prototyp und Produktivsystem (eigenes Repository, eigene Review-Pflicht, eigene Sicherheitsprüfung) ist die wirksamste Maßnahme, die auch ohne Engineering-Hintergrund angeordnet werden kann.

Fazit

Vibe Coding ist eine ehrliche Beschreibung dafür, wie viel Software heute entsteht: schnell, prompt-basiert, ungeprüft. Für Experimente und Wegwerf-Code ist das ein gewaltiger Produktivitätsgewinn. Für Software, die Bestand haben und Geschäft tragen soll, gilt weiterhin: Sie entsteht durch Menschen, die wissen, was sie tun und warum. KI verkürzt ihre Wege, ersetzt sie aber nicht. Wer das verwechselt, kauft Schnelligkeit auf Kredit – und der Zins ist im Quellcode versteckt.

Weiterführend: Andrej Karpathys ursprüngliche Begriffsprägung ist öffentlich dokumentiert (Originalbeitrag auf X, 2. Februar 2025).