Vibe Coding

Beim Vibe Coding läuft die Arbeit in einer Schleife. Sie beschreiben, was das Programm tun soll, das Sprachmodell schreibt oder ändert den Code, Sie starten das Ergebnis und sehen nach, ob es sich richtig verhält. Klappt etwas nicht, geht die Fehlermeldung als nächster Prompt zurück an das Modell. Den Code selbst lesen Sie dabei nicht. Andrej Karpathy hat den Begriff am 2. Februar 2025 auf X geprägt und genau so beschrieben. Er akzeptiere alle Änderungen immer mit „Accept All“, lese die Diffs nicht mehr und kopiere Fehlermeldungen kommentarlos zurück in den Chat. Gemeint war das für Wochenendprojekte, die niemand warten muss. Collins Dictionary hat „vibe coding“ zum Wort des Jahres 2025 gewählt.

Die Abgrenzung zur KI-gestützten Softwareentwicklung hängt an einer einzigen Frage, nämlich ob ein Mensch den Code prüft. Der Entwickler Simon Willison hat die Grenze im März 2025 gezogen. Wer LLM-Code reviewt, gründlich testet und jemand anderem erklären kann, wie er funktioniert, entwickelt nach seiner Definition ganz normal Software. Dieselben Werkzeuge, also Claude Code, GitHub Copilot oder Cursor, können beides. Den Unterschied macht der Arbeitsablauf, nicht das Tool. Im Alltag wird der Begriff inzwischen für jede Arbeit mit KI-Assistenten benutzt, was die Diskussion über Risiken unscharf macht.

In der CI/CD sieht das so aus. Aus einem Prompt entsteht ein vollständiges Declarative Jenkinsfile mit Build-, Test- und Quality-Gate-Stages, ohne dass jemand Groovy-Syntax nachschlagen muss. Das Schreiben geht damit schneller, der Aufwand wandert aber in die Prüfung. Ein Jenkinsfile läuft mit den Rechten des Build-Systems, und ungeprüft kann es Plugins oder Pakete anfordern, die das Modell erfunden hat. Angreifer registrieren solche erfundenen Paketnamen gezielt, das nennt sich Slopsquatting. Dazu kommen eingebettete Secrets, ungetestete Logik und Shell-Steps, die mehr dürfen als nötig. Review, Linting und Secret-Scanning sind deshalb Pflicht, bevor so ein Entwurf in eine produktive Pipeline kommt.

Für Produktions-Pipelines mit Audit-Trail hat sich Spec-Driven Development als Gegenmodell verbreitet. Dort entsteht zuerst eine Spezifikation, die festhält, was gebaut wird, warum und unter welchen Bedingungen, und erst danach implementiert die KI. Die Spezifikation liegt im Repository und lässt sich reviewen wie Code. Vibe Coding bleibt sinnvoll für Prototypen, Einmal-Skripte und schnelle Entwürfe, bei denen niemand in einem Jahr nachfragt, warum eine Zeile so aussieht.