Vibe Coding bedeutet, Software zu schreiben, indem man in natürlicher Sprache beschreibt, was man möchte, und das Ergebnis des Modells übernimmt, ohne den zugrunde liegenden Code zu prüfen oder nur oberflächlich zu prüfen. Der Engineer steuert nach Gefühl, anstatt die Ausgabe zu lesen und zu analysieren.
Herkunft des Begriffs
Andrej Karpathy prägte den Begriff Anfang 2025, um eine Arbeitsweise zu beschreiben, bei der man „fully give in to the vibes“ und aufhört, sich um den Code selbst zu kümmern. Die Aussage war teils deskriptiv, teils ironisch gemeint. Sie setzte sich durch, weil sie etwas benannte, das bereits gängige Praxis war.
Wie das in der Praxis aussieht
Ein Entwickler gibt einem Modell Anweisungen, führt das Ergebnis aus, beschreibt den Fehler, wenn etwas nicht funktioniert, und wiederholt den Vorgang. Kein Lesen des Diffs. Kein Hinterfragen, warum das Modell eine bestimmte Entscheidung getroffen hat. Der Code wird als undurchsichtiges Artefakt behandelt. Er funktioniert, bis er es nicht mehr tut.
Dies unterscheidet sich vom Agentic Coding, bei dem ein Coding-Agent mehrstufige Aktionen innerhalb einer Codebasis ausführt und ein Mensch das Ergebnis noch prüft. Beim Vibe Coding fehlt genau diese Prüfung, es geht nicht um die Automatisierung an sich.
Warum Prototypen damit schnell entstehen
Für einen Proof of Concept, den man danach wegwirft, ist der Ansatz schnell. Das Modell übernimmt Boilerplate, Verdrahtung und die naheliegende Struktur. Der Mensch prüft nur, ob sich das Ergebnis wie beschrieben verhält. Die Feedback-Schleifen sind kurz.
Für diesen Anwendungsfall ist der Kompromiss oft vertretbar.
Warum der Prototyp den Kontakt mit der Produktionsumgebung selten übersteht
Probleme häufen sich in den Bereichen an, die nicht überprüft wurden.
Sicherheit. Modelle reproduzieren gängige Muster, einschließlich gängiger Schwachstellen. Wenn Sie den Code nicht gelesen haben, wissen Sie nicht, ob Eingaben validiert werden, ob Geheimnisse ordnungsgemäß behandelt werden oder ob Zugriffskontrollen vorhanden sind. Prompt injection ist ein spezifisches Risiko; es gibt viele weitere.
Wartbarkeit. Code, den beim Schreiben niemand verstanden hat, lässt sich später nur schwer ändern. Der nächste Entwickler, oder derselbe Entwickler drei Monate später, hat kein mentales Modell, auf das er zurückgreifen kann.
Korrektheit in Randfällen. Modelle sind selbstsicher. Sie produzieren Code, der richtig aussieht und den offensichtlichen Fall abdeckt. Randfälle, domänenspezifische Einschränkungen und Wechselwirkungen zwischen Komponenten sind jedoch die Stellen, an denen sich Fehler verbergen. Genau diese Dinge treten in einer schnellen Demo nicht zutage.
Debugging. Wenn in der Produktion etwas schiefgeht, müssen Sie über den Code nachdenken können. Wenn Sie ihn nie gelesen haben, haben Sie keine Grundlage dafür.
Das Übergangsproblem
Einen per Vibe Coding erstellten Prototypen in die Produktion zu überführen ist keine Frage des „Aufräumens“. Es bedeutet in der Regel, jede Zeile zu lesen, zu verstehen, was der Code tatsächlich tut und nicht nur, was man beabsichtigt hatte, die Stellen zu finden, an denen das Modell eine plausible, aber falsche Entscheidung getroffen hat, und festzulegen, was neu geschrieben werden muss. In der Praxis dauert das häufig länger, als es von Anfang an sauber zu entwickeln.
Das ist keine Kritik am Einsatz von KI zur Beschleunigung der Entwicklung. Es ist eine Beschreibung dessen, was eine prüfungsfreie Generierung im Nachhinein kostet.
Wie kompetente AI-native Entwicklung stattdessen aussieht
Ein erfahrener Engineer, der KI-Tools sinnvoll einsetzt, liest die Ausgabe trotzdem. Er behandelt generierten Code als fähigen ersten Entwurf, nicht als fertiges Produkt. Er erkennt die Stellen, an denen das Modell selbstsicher, aber falsch lag. Er versteht den Kontext, mit dem das Modell gearbeitet hat, und wo es möglicherweise vom Kurs abgewichen ist.
Das ist eine andere Fähigkeit als sowohl Vibe Coding als auch das klassische zeilenweise Schreiben. Es ist auch die Fähigkeit, die KI-gestützte Entwicklung sicher für Nutzer macht. Unter how to review AI-generated code erfahren Sie, wie dieser Prozess abläuft.
Was wir prüfen
Vibe Coding ist genau das Verhalten, das unsere Eignungsprüfung aufdecken soll. In der AI-native Session bearbeiten Kandidaten Tickets mit den Tools, die sie normalerweise verwenden, und wir beobachten, ob sie die Ergebnisse tatsächlich lesen. Die Bewertungskriterien, die dabei am unmittelbarsten relevant sind: Verifikation von KI-Ausgaben – prüft, ob jemand halluzinierte APIs oder subtil fehlerhafte Logik erkennt, bevor sie ausgeliefert wird – und Urteil nach Risiko, das prüft, ob generierter Code unabhängig vom Ton des Tools mit der gleichen Sorgfalt geprüft wird. Alle Details finden Sie unter „Wie wir prüfen“.
Kurze Antworten
Ist Vibe Coding grundsätzlich schlechte Praxis?
Nicht immer. Für einen wegwerfbaren Prototypen oder ein persönliches Skript, das nicht gewartet werden soll, sind die Kompromisse vertretbar. Das Problem entsteht, wenn Vibe-Coding-Ergebnisse ohne den Review-Schritt, der sie produktionsreif machen würde, als produktionsreif behandelt werden.
Wie wandle ich einen vibe-codierten Prototypen in Produktionscode um?
Lesen Sie jede Zeile mit derselben Sorgfalt, die Sie Code aus einer unbekannten Quelle entgegenbringen würden. Prüfen Sie Sicherheitsannahmen, Grenzfälle und Wartbarkeit. Rechnen Sie damit, erhebliche Teile neu zu schreiben. Es ist selten eine schnelle Überarbeitung.
Was ist der Unterschied zwischen Vibe Coding und dem Einsatz von AI-Coding-Tools?
Der Unterschied liegt in der Überprüfung. KI-Tools sinnvoll einzusetzen bedeutet, die Ausgabe zu lesen und zu analysieren. Vibe Coding bedeutet, sie nach Gefühl zu akzeptieren. Die Tools können identisch sein; das Verhalten und die Ergebnisse unterscheiden sich jedoch erheblich.
