Was ist Vibe Coding? Definition und Bedeutung
Vibe Coding bezeichnet eine Arbeitsweise, bei der Software im Gespräch mit einem KI-Modell entsteht. Man beschreibt in normaler Sprache, was das Programm tun soll. Das Modell erzeugt den Code. Man probiert das Ergebnis aus, beschreibt, was noch nicht stimmt, und lässt es überarbeiten.
Der Unterschied zum klassischen Programmieren liegt weniger im Werkzeug als in der Prüfung. Wer selbst programmiert, versteht jede Zeile, die er schreibt. Beim Vibe Coding beurteilt man das Ergebnis daran, ob es sich richtig verhält – nicht daran, wie es aufgebaut ist. Genau darauf spielt der Name an: Man geht nach dem Eindruck.
Woher der Begriff kommt
Geprägt hat ihn Andrej Karpathy, Mitgründer von OpenAI und früher KI-Leiter bei Tesla, Anfang 2025 in einem kurzen Beitrag über seine eigene Arbeitsweise. Der Ausdruck verbreitete sich innerhalb weniger Wochen.
Neu war dabei nicht die Sache selbst – KI-gestützte Codevorschläge gab es schon vorher. Neu war, dass die Modelle gut genug wurden, um ganze kleine Programme zu erzeugen statt einzelner Zeilen, und dass damit auch Menschen ohne Programmierausbildung zu brauchbaren Ergebnissen kamen.
Wie Vibe Coding in der Praxis abläuft
Der Ablauf ähnelt einem Gespräch und nicht einem Bauplan.
Am Anfang steht eine Beschreibung dessen, was entstehen soll: welche Daten hereinkommen, was damit geschehen soll, was am Ende herauskommt. Das Modell erzeugt daraus einen ersten Entwurf. Dieser wird ausprobiert, und was nicht passt, wird beschrieben – nicht als Fehlerbericht in Fachsprache, sondern in gewöhnlichen Worten. Das Modell überarbeitet, man probiert erneut.
Die Qualität des Ergebnisses hängt dabei weniger an der Formulierung der Anweisungen als an der Klarheit der Umgebung. Ein Modell, das weiß, wie die Datenquelle aufgebaut ist, welche Felder es gibt und in welchem Format sie kommen, liefert brauchbaren Code. Ein Modell, das raten muss, liefert Code, der plausibel aussieht und nicht funktioniert.
Wofür sich die Arbeitsweise eignet
Am besten für Dinge, die klein sind, einen klaren Zweck haben und nicht über Jahre betrieben werden müssen.
Typisch sind Auswertungen, die eine bestimmte Frage beantworten und für die kein fertiger Bericht existiert. Ebenso kleine Hilfsprogramme, die einen wiederkehrenden Handgriff abnehmen – Daten umformen, Listen abgleichen, Dateien umbenennen. Und Prototypen, an denen sich zeigen lässt, ob eine Idee trägt, bevor jemand ernsthaft investiert.
Was diese Fälle verbindet: Der Schaden bleibt überschaubar, wenn das Ergebnis nicht stimmt, und der Fehler fällt schnell auf.
Grenzen und Kritik
Die Einwände richten sich weniger gegen die Arbeitsweise als gegen die Erwartung, sie ersetze das Programmieren.
Code, den niemand geprüft hat, kann funktionieren und trotzdem falsch sein – etwa, weil er einen Sonderfall übersieht, der erst in drei Monaten auftritt. Fehler, die man nicht selbst gemacht hat, sind zudem schwerer zu finden, weil einem der Aufbau nicht vertraut ist. Und was heute in zwanzig Minuten entstanden ist, muss in zwei Jahren immer noch verstanden, angepasst und betrieben werden.
Dazu kommen die Punkte, die bei jeder Software gelten und beim schnellen Entstehen leicht übersehen werden: Wer darf auf welche Daten zugreifen, wie werden Zugänge abgesichert, was passiert bei einem Fehler.
Die praktische Schlussfolgerung ist nicht, auf die Arbeitsweise zu verzichten, sondern das Ergebnis wie jede andere Software zu behandeln. Was in den produktiven Betrieb geht, wird geprüft, bekommt einen eigenen Zugang mit möglichst wenigen Rechten und wird von jemandem verantwortet. Damit bleibt der Zeitgewinn erhalten, ohne dass daraus später eine Altlast wird.