Vibe Coding

Vibe Coding Vibe Coding bezeichnet eine Arbeitsweise, bei der du einer KI die Absicht hinter einer Funktion in natürlicher Sprache beschreibst, statt den Code selbst zu schreiben, und das Ergebnis nur noch am Verhalten beurteilst, nicht an der Quelltextzeile. Geprägt hat den Begriff der KI-Forscher Andrej Karpathy im Februar 2025. Für einen Prototyp funktioniert das gut, weil ein Fehler dort schnell auffällt und wenig kostet. Sobald jemand den Code später warten muss, wird genau das zum Problem, weil niemand mehr genau weiß, was eigentlich drinsteht.

Was Vibe Coding bedeutet

Vibe Coding ist ein Wechsel in der Art, wie Software entsteht. Statt Code Zeile für Zeile zu schreiben, beschreibst du einer KI die Absicht hinter einer Funktion, den „Vibe“. Den Rest übernimmt sie. Nicht mehr die perfekte Syntax zählt, sondern wie präzise du dein Ziel in natürlicher Sprache formulierst.

Das ist im Kern eine Weiterentwicklung von Prompt Engineering, nur direkt im Code-Editor angewendet statt im Chat-Fenster. Der wirkliche Unterschied zu jeder Form von KI-gestütztem Programmieren, die davor kam, liegt in einem zweiten Schritt. Du liest den erzeugten Code nicht mehr. Du testest nur noch, ob er tut, was er soll. Genau dieser zweite Schritt macht Vibe Coding zu einem eigenen Begriff, und nicht bloß zu einem neuen Namen für Autocomplete. Möglich wird das nur, weil Large Language Models inzwischen gut genug sind, um aus einer Beschreibung brauchbaren Code abzuleiten.

Der Ursprung: ein Tweet von Andrej Karpathy

Den Begriff hat Andrej Karpathy geprägt, Mitgründer von OpenAI und ehemaliger KI-Chef bei Tesla. Am 2. Februar 2025 beschrieb er in einem Tweet eine neue Art zu programmieren: „a new kind of coding I call vibe coding, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists“. Er schrieb dazu, dass er Diffs nicht mehr lese. Fehlermeldungen kopiere er kommentarlos zurück in den Editor. Fast beiläufig fügte er hinzu, das funktioniere ganz gut für Wegwerfprojekte am Wochenende.

Dieser letzte Halbsatz ist wichtiger, als er beim ersten Lesen klingt. Karpathy hat die Grenze des Begriffs selbst mitgeliefert, im ersten Tweet dazu. Gut für ein Wochenendprojekt. Keine Aussage über Software, die jemand später warten muss. Trotzdem verbreitete sich der Begriff rasant. Im November 2025 kürte ihn das Collins Dictionary zum Wort des Jahres. Selten hat ein einzelner Tweet so schnell einen festen Platz im Vokabular der Softwareentwicklung bekommen.

Wie sich das von klassischem Programmieren unterscheidet

Klassisches Programmieren heißt, jede Zeile selbst zu schreiben und zu verstehen, warum sie funktioniert. Vibe Coding verschiebt den Fokus vom Mikromanagement einzelner Zeilen zur übergeordneten Architektur. Du arbeitest am System, nicht an jedem seiner Einzelteile. Die Frage, die du dir stellst, ändert sich von „wie schreibe ich das“ zu „was soll hier passieren“.

Das befreit kognitive Ressourcen. Wer nicht mehr über die korrekte Deklaration einer Variable nachdenken muss, kann sich auf das eigentliche Problem konzentrieren. Der Haken liegt genau in dieser Befreiung. Was du nicht mehr denkst, kannst du später auch nicht mehr prüfen, wenn du es brauchst.

Wo Vibe Coding trägt und wo es kippt

Für einen Prototyp ist die Beurteilung am Ergebnis genau richtig. Ein Wochenendprojekt, ein Proof of Concept, ein internes Tool, das morgen schon wieder verworfen wird: Ein Fehler kostet dort nichts außer ein paar Minuten Nacharbeit. Das Lesen jeder Zeile lohnt sich dann nicht.

Kippt der Einsatz, sobald jemand die Software warten muss. Ein Fehler bleibt so lange unentdeckt, bis er in Produktion auffällt. Und wenn er auffällt, fehlt genau das Verständnis, das beim Debuggen geholfen hätte, weil den Code ohnehin niemand gelesen hat. Der Unterschied liegt also nicht in der Qualität des Codes im Moment der Entstehung. Er liegt darin, was in sechs Monaten passiert, wenn jemand eine neue Funktion daneben bauen oder einen Fehler darin finden muss. Diese Unterscheidung entscheidet mehr über den sinnvollen Einsatz von Vibe Coding als jede Diskussion über das richtige Werkzeug: Prototyp gegen Produktivsystem.

Die Werkzeuge: Cursor, Replit Agent und Claude Code

Drei Werkzeuge setzen die Idee des Vibe Coding besonders konsequent um, auch wenn sie unterschiedlich weit gehen.

Cursor AI ist im Kern ein Fork von VS Code, von Grund auf als KI-Editor gebaut. Du chattest direkt im Editor mit deinem gesamten Repository, lässt Code refactorn oder ganze Features aus einer Beschreibung generieren.

Replit Agent geht einen Schritt weiter. Er plant Aufgaben selbstständig, ein Beispiel für Agentic AI in der Praxis. Du gibst ein Ziel vor, etwa „baue eine einfache API für eine To-do-Liste“. Der Agent setzt es autonom um und hostet das Ergebnis gleich mit.

Claude Code bringt dieselbe Agenten-Fähigkeit ins Terminal. Es führt Shell-Befehle aus, verwaltet Git-Commits und navigiert selbstständig durch komplexe Dateistrukturen, statt nur Antworten in einem Chatfenster zu liefern. Wie du damit einsteigst, habe ich in meinem Einstiegs-Guide zu Claude Code beschrieben.

Wie ich selbst mit Claude Code arbeite

Ich baue seit einiger Zeit vieles mit Claude Code, aber nicht im Sinne von Karpathys Tweet. Bei meinem eigenen WordPress-Theme mit Templates, Patterns und kompletter theme.json bin ich genau an dem Muster gescheitert, das den reinen Vibe-Coding-Ansatz kennzeichnet. Ich habe ohne feste Struktur und ohne Kontrolle zwischendurch drauflosgepromptet. Das Ergebnis war ein Haufen Dateien, die nicht zueinander passten. Erst mit klarer Ordnerstruktur, einer kurzen Anweisungsdatei und einer Kontrolle nach jedem Schritt lief das zweite Mal alles zusammen, bis zu einem Pagespeed-Wert von 99 bis 100.

Dasselbe Muster gilt für die zwölf Browser-Tools, die ich mit Claude Code gebaut habe. Rund 4.000 Zeilen Code, dazu 84 Tests, die bei jeder Änderung mitlaufen. Kein „Accept All“, sondern eine Prüfung nach jedem Schritt. Was bei mir tatsächlich nach Karpathys Definition abläuft, ist der erste Entwurf einer Idee. Nicht das, was am Ende live geht.

Genau deshalb nutze ich auch Skills, damit eine einmal gefundene Korrektur nicht in der nächsten Session wieder verschwindet. Vibe Coding ohne diese Kontrollschicht bleibt schnell. Aber es vergisst auch schnell, warum eine Entscheidung getroffen wurde.

Risiken und Grenzen

Wer nicht mehr jede Zeile selbst schreibt, muss sich darauf verlassen, dass die KI korrekten und sicheren Code erzeugt. Das verlangt mehr Sorgfalt bei der Kontrolle, nicht weniger. Debugging wird dadurch anspruchsvoller. Du suchst nicht mehr nur nach eigenen Denkfehlern, sondern auch nach Stellen, an denen die KI etwas erfunden hat, das plausibel aussieht und trotzdem falsch ist.

Die Code-Qualität ist dabei nur so gut wie das Modell und der Prompt zusammen. Ohne ein solides Grundverständnis der eigenen Anwendung entsteht leicht ein System, das niemand im Team mehr vollständig versteht oder guten Gewissens warten kann, selbst wenn es im Moment funktioniert.

Ersetzt KI den Programmierer?

Nein, und die Antwort ändert sich auch nicht durch die Geschwindigkeit, mit der sich Vibe Coding verbreitet hat. Ein Taschenrechner hat den Mathematiker nicht ersetzt. Er hat ihm erlaubt, sich auf schwierigere Probleme zu konzentrieren. Bei Vibe Coding verschiebt sich die Rolle des Entwicklers vom Handwerker zum Architekten. Er setzt weniger Ziegel selbst und verantwortet dafür den Bauplan, der am Ende trägt.

Wer die Grundlagen dahinter genauer verstehen will, etwa Prompt Engineering oder Agentic AI, findet die passenden Begriffe im Glossar.

Zurück zum AI und Automation Glossar.