Vibe Coding funktioniert. Bis es in Produktion geht.

Vibe Coding funktioniert. Das meine ich ohne Ironie. Ein Nachmittag, ein paar Prompts, und es steht ein klickbarer Prototyp, für den Sie früher zwei Tage gebraucht hätten. Wer das wegredet, hat seit einem Jahr keinen Agenten mehr laufen lassen.

Das Problem ist nicht, dass es funktioniert. Das Problem liegt an einer bestimmten Stelle, und die meisten Diskussionen zielen daran vorbei. Vibe Coding funktioniert, solange der Schaden lokal bleibt, sich rückgängig machen lässt und günstig zu prüfen ist. Produktion beginnt dort, wo andere Menschen den Preis für einen Fehler zahlen.

Dieser Artikel zieht genau diese Grenze. Er wertet den Modus nicht ab, er grenzt ihn ein, und er zeigt, woran Sie merken, dass der Wechsel fällig ist.

Kurz gefasst: Vibe Coding ist ein Betriebsmodus, in dem schneller Code entsteht, als er verstanden und geprüft wird. Er ist nützlich bei Exploration, persönlichen Tools und Wegwerfskripten. Er zeigt seine Grenzen nicht beim Deployment, sondern sobald vier Fragen ungünstig ausfallen: Reichweite, Reversibilität, Prüfbarkeit und Verantwortung. Wird eine davon kritisch, muss der Modus wechseln. Vom Vibe zur Orchestrierung. Dasselbe Werkzeug, eine ganz andere Disziplin.

Was Vibe Coding ist und was nicht

Den Begriff prägte Andrej Karpathy am 2. Februar 2025 in einem einzigen Post. Viele spätere Zusammenfassungen verschieben das Datum oder verkürzen den Kontext. Wichtiger als das Datum ist aber, was er tatsächlich beschrieb. Es war kein Trend und keine Methode, sondern sein eigener, bewusst nachlässiger Modus: Er las die Diffs nicht mehr, kopierte Fehlermeldungen zurück ins Modell, akzeptierte Vorschläge, ohne sie zu verstehen, und ließ das System wachsen, während sein Überblick darüber schrumpfte.

Wichtig ist der Rahmen, den er selbst gesetzt hat. Karpathy sprach von Wegwerfprojekten am Wochenende. Nicht von Produktionscode, nicht von einer neuen Norm für Teams. Es war eine Beschreibung, kein Manifest.

Was wir heute als Arbeitsdefinition brauchen, lässt sich in einen Satz fassen:

Vibe Coding ist ein Betriebsmodus KI-gestützter Softwareentwicklung, bei dem Code schneller entsteht, als er verstanden und geprüft wird.

Diese Definition leistet zwei Dinge. Sie hält Karpathys Kern fest. Und sie vermeidet den größten fachlichen Fehler dieser Debatte: nicht jede KI-gestützte Entwicklung ist Vibe Coding. Simon Willison, der den Begriff früh und genau benutzt hat, bringt es auf den Punkt: “Not all AI-assisted programming is vibe coding.” Ein Senior, der einen Agenten eng führt, den Diff liest, Tests laufen lässt und die Architekturfolgen abschätzt, arbeitet nicht im Vibe-Coding-Modus. Er orchestriert. Der Unterschied liegt nicht im Tool, sondern in der Disziplin.

Wer also „was ist Vibe Coding“ googelt und als Antwort „Programmieren mit natürlicher Sprache“ bekommt, hat eine zu weite Definition erwischt. Die trifft auch sauber spezifizierte, getestete Agentenarbeit und macht den Begriff damit nutzlos.

Wo Vibe Coding tatsächlich funktioniert

Der ehrliche Teil zuerst, denn ohne ihn ist der Rest nur Miesmacherei.

Der Modus spielt seine Stärke aus, wenn Fehler folgenlos bleiben. Exploration, in der Sie eine Idee erst sehen müssen, um zu wissen, ob sie taugt. Persönliche Werkzeuge, die nur auf Ihrer Maschine laufen. Lernexperimente. Wegwerfskripte, die eine CSV einmal umformen und dann gelöscht werden. Klickbare Prototypen, die eine Diskussion mit dem Produktteam ersetzen sollen, nicht den späteren Code.

Das prominenteste Beispiel liefert ausgerechnet Linus Torvalds. Er hat in seinem Repository AudioNoise einen Python-Visualizer im Wesentlichen im Vibe-Coding-Modus gebaut. Daraus wurde die Schlagzeile, sogar Torvalds mache jetzt Vibe Coding. Liest man nach, steht da das Gegenteil der Schlagzeile: Er bezeichnet das ganze Projekt ausdrücklich als Lernspielzeug, das niemand zu ernst nehmen soll. Kein Kernel, kein Produktionssystem, keine Freigabe für irgendetwas, das andere benutzen. Genau so sieht der legitime Einsatzbereich aus. Bewusst risikoarm, nicht verdeckt produktionskritisch.

Das ist kein experimentell bewiesenes Gesetz, sondern die übereinstimmende Einschätzung erfahrener Praktiker. Aber es reicht für eine brauchbare Regel: Solange Sie den Code jederzeit wegwerfen können, ohne dass es jemand außer Ihnen merkt, ist der Modus vertretbar.

Die Grenze ist nicht der Deploy-Button

Hier ziehen die meisten Texte die Grenze falsch. Sie setzen sie bei „lokal versus veröffentlicht“, als entstünde das Risiko in dem Moment, in dem Sie auf Veröffentlichen drücken. Das ist zu grob. Ein internes Tool ohne Deploy kann produktionsähnliche Folgen haben, wenn ein halbes Team seine Entscheidungen darauf stützt.

Die belastbare Grenze ist keine juristische, sondern eine methodische. Sie verläuft entlang von vier Fragen:

1. Reichweite. Wer ist betroffen, wenn der Code falsche Ergebnisse liefert? Nur Sie, ein internes Team oder externe Kunden?
2. Reversibilität. Lässt sich der Fehler zurücknehmen, ohne Datenverlust, Ausfall oder manuelle Reparatur?
3. Prüfbarkeit. Lässt sich das Ergebnis mit vertretbarem Aufwand prüfen, oder entsteht mehr Code, als das Team sinnvoll prüfen kann?
4. Verantwortung. Gibt es einen Menschen, der das Verhalten, die Freigabe und den Betrieb erklären und vertreten kann?

Je schlechter die Antworten ausfallen, desto weniger darf der Workflow auf spontanem Prompten beruhen. Daraus wird eine praktische Risikoleiter, an der Sie jede Aufgabe einsortieren können:

Niemand verbietet Ihnen, für R3-Aufgaben einen Agenten zu benutzen. Die Frage ist nur, in welchem Modus. Für R0 reicht der Vibe. Ab R2 fängt die Orchestrierung an, und ab R3 ist Vibe als Betriebsmodus schlicht die falsche Wahl. Nicht aus Prinzip, sondern weil die vier Fragen sonst unbeantwortet bleiben.

Wenn diese Risikoleiter im Team nicht nur ein Denkmodell, sondern ein Arbeitsprozess werden soll, braucht es klare Regeln für Agentenarbeit. Genau darum geht es im Leitfaden zur kontrollierten Einführung von KI-Coding-Agents.

Warum schnellerer Code das Team langsamer machen kann

Jetzt zur unangenehmen Spannung, an der sich die Debatte regelmäßig verheddert. Die eine Seite zitiert Studien, nach denen KI Entwickler schneller macht. Die andere zitiert Studien, die das Gegenteil nahelegen. Beide haben recht, weil sie verschiedene Ebenen messen.

Die beste Produktivitätszahl stammt aus einer 2026 in Management Science veröffentlichten Analyse von drei randomisierten Feldexperimenten bei Microsoft, Accenture und einem anonymen Fortune-100-Unternehmen, zusammen 4.867 Entwickler. Über alle Experimente hinweg erledigten die Gruppen mit KI-Unterstützung 26,08 Prozent mehr Aufgaben, bei einem Standardfehler von 10,3 Prozent und deutlichen Unterschieden zwischen den Experimenten.

Lesen Sie diesen Satz genau, denn er wird ständig falsch zitiert. Die Zahl gilt für die untersuchten Assistenzwerkzeuge in diesen Kontexten. Sie ist kein „26-Prozent-Speedup für Vibe Coding“, kein Versprechen für autonome Agenten und schon gar kein Garant für 26 Prozent mehr Kundennutzen. Mehr erledigte Aufgaben sind nicht dasselbe wie mehr tatsächlich gelieferter Nutzen.

Dem gegenüber steht der DORA-Sonderbericht zur Wirkung generativer KI. Er fand einen Zusammenhang, keine Ursache: Ein Anstieg der KI-Nutzung um 25 Prozent ging mit rund 1,5 Prozent geringerem Lieferdurchsatz und rund 7,2 Prozent geringerer Lieferstabilität einher. Das ist eine Assoziation aus Beobachtungsdaten. DORA beweist nicht, dass KI die Lieferung verschlechtert. Es beobachtet, dass beides zusammen auftritt.

Diese beiden Befunde widersprechen sich nicht. Sie beschreiben Amdahls Gesetz in neuer Verkleidung. Wenn Sie einen Schritt in der Pipeline beschleunigen, wandert der Engpass zum nächsten. Die Codeerzeugung wird billiger, also stauen sich Review, Integration, Test und Betrieb. DORA nennt größere Änderungspakete als möglichen Mechanismus, und das ist plausibel, aber eine Hypothese, kein Beweis.

Die belastbare Formulierung lautet deshalb:

KI kann die Codeerzeugung beschleunigen. Ob das Team schneller und stabiler liefert, entscheidet der nachgelagerte Prozess.

Genau dort, im Review-Engpass, sitzt der eigentliche Hebel. Warum er sich verschiebt und was das für Pull Requests bedeutet, steht ausführlich im Beitrag zum Engpass im Pull Request.

Die konkreten Risiken: Was in der Praxis schiefgeht

Abstrakte Warnungen überzeugen niemanden. Hier sind drei Fehlerklassen, die messbar sind.

Erfundene Abhängigkeiten. Eine peer-reviewte USENIX-Studie untersuchte 16 codegenerierende Modelle und 576.000 Beispiele in Python und JavaScript. Sie fand mindestens 5,2 Prozent halluzinierte Paketnamen bei kommerziellen Modellen und 21,7 Prozent bei Open-Source-Modellen. Das Modell schlägt also einen Import vor, der plausibel klingt und nicht existiert, oder, schlimmer, den ein Angreifer unter genau diesem Namen vorab registriert hat. „Es kompiliert bei mir“ ist kein Beweis für eine saubere Lieferkette. Verallgemeinern Sie die Zahl nicht zu „jeder fünfte Import ist erfunden“, die Werte hängen stark von Modell, Sprache und Prompt ab.

Repositoryweite Inkonsistenz. Eine ISSTA-Studie zeigt, dass Halluzinationen nicht bei der Syntax aufhören. Sie verletzen API-Verträge, Abhängigkeiten und Annahmen über das bestehende System. Der erzeugte Code sieht für sich genommen richtig aus und passt trotzdem nicht zu dem Repository, in das er eingefügt werden soll.

Bestandene Tests sind nicht gleich Merge-Reife. In einer METR-Auswertung ließ man Maintainer Patches bewerten, die den automatischen SWE-bench-Grader bereits bestanden hatten. Die automatischen Bewertungen lagen im Mittel 24,2 Prozentpunkte über den tatsächlichen Merge-Entscheidungen der Maintainer. Das war eine kleine Studie mit vier Maintainern und drei Repositories, also kein universelles Gesetz. Aber die Richtung ist eindeutig: Ein grüner Testlauf ist notwendige Evidenz, keine vollständige Aussage über Wartbarkeit, Stil, Umfang und architektonische Passung.

Ein viel geteilter Fall aus Mai 2026 zeigt das konkret, verlangt aber die nötige Einordnung: Sicherheitsforscher und Reporter von Axios und WIRED fanden öffentlich erreichbare, mit Vibe-Coding-Plattformen gebaute Apps, die sensible Daten preisgaben. Die kursierende Schlagzeilenquote, 40 Prozent aller solcher Apps würden Daten preisgeben, stammt aus einem Bericht eines Anbieters, dessen Methodik nicht unabhängig prüfbar ist und den die Plattformbetreiber bestreiten. Nehmen Sie den Fall als das, was er ist: ein Beleg, dass offene Zugriffsregeln, veröffentlichte Datenbanken und fehlende Freigabe-Gates tatsächlich öffentlich sichtbar machen. Nicht als Branchenstatistik.

Vibe Coding versus Orchestrierung

Wenn man die Fäden zusammenführt, geht es am Ende nicht um Pro oder Contra, sondern um den richtigen Modus. Dieselbe Plattform, ob Replit, Cursor, Claude Code, Copilot oder Lovable, lässt sich in beiden Modi nutzen. Was den Modus bestimmt, sind nicht die Funktionen, sondern wie Sie damit arbeiten.

Eine Verkürzung kursiert dazu: das eine sei „Raten mit Stil“. Als Spruch funktioniert das. Als Analyse ist es zu breit, weil es auch den legitimen Prototyping-Modus und verantwortete Agentenarbeit abwertet. Die präzisere Unterscheidung ist mir lieber:

Beim Vibe wächst der Code schneller als das Verständnis. Beim Orchestrieren wächst die Absicherung mit.

Und nein, das ist kein dogmatisches „jede Zeile lesen oder Vibe“. Bei zuverlässigeren Agenten verschwimmt die Grenze, das räumt Simon Willison 2026 selbst ein. Ein Senior darf Teile des erzeugten Codes wie eine vertrauenswürdige interne Bibliothek behandeln. Nur muss der fehlende Blick auf jede einzelne Zeile dann durch stärkere Evidenz ersetzt werden: spezifizierte Invarianten, Tests, Berechtigungsgrenzen, Observability, Rollback und eine klare Haftung. Verantwortungsvolle Prüfung richtet sich nach dem Risiko, nicht nach einem Ritual.

Vibe-Coding-Tools sind Kontrollpunkte, keine Rangliste

„Welche Vibe-Coding-Tools soll ich nehmen“ ist die falsche Frage, und jede Bestenliste dazu ist in sechs Wochen veraltet. Die nützlichere Frage lautet: Woran erkennt ein Senior, in welchem Modus ein Werkzeug gerade läuft? An seinen Kontrollpunkten. Acht davon sollten Sie prüfen:

• Umfang und Plan. Zerlegt das Werkzeug die Aufgabe sichtbar, bevor es Code schreibt? Der Cloud-Agent von GitHub Copilot plant und arbeitet in einem eigenen Branch.
• Berechtigungen. Müssen Schreibzugriff, Ausführung und Netzwerkzugriff explizit freigegeben werden? Claude Code startet restriktiv und fragt nach.
• Sandbox. Kann ein fehlerhafter Lauf Dinge außerhalb der eigentlichen Aufgabe verändern, oder ist der Schaden klar eingegrenzt?
• Review-Oberfläche. Entsteht ein prüfbarer Diff oder Pull Request? Der Copilot-Cloud-Agent öffnet Pull Requests, statt direkt zu schreiben.
• Tests und CI. Kann der Durchlauf Tests und Linter ausführen, bevor ein Mensch freigibt?
• Dauerhafte Regeln. Lassen sich Architektur- und Teamregeln im Repository festhalten, etwa über Cursor Rules oder eine AGENTS.md?
• Rollback. Sind Code, Umgebung und Datenzustand rücksetzbar? Replit dokumentiert Checkpoints und Rollbacks.
• Sicherheitsprüfung. Erkennt die Plattform Secrets und kritische Befunde, und kann ein Befund die Veröffentlichung blockieren? Lovable zeigt dafür eine Sicherheitsansicht mit blockierenden Prüfungen.

Diese Liste ersetzt den Vergleich nicht, sie macht ihn risikogerecht. Für Exploration zählen Geschwindigkeit, Sandbox und Rollback. Für ein geteiltes internes Tool werden Versionskontrolle, Rechte und Tests zur Pflicht. Für Produktionscode entscheiden PR-Workflow, CI, Security und Observability. Dieselben Produkte, andere Anforderungen, je nachdem, wo auf der Risikoleiter Sie stehen. (Stand: Juni 2026. Herstellerfunktionen ändern sich schnell, prüfen Sie die jeweils aktuelle Dokumentation, bevor Sie sich darauf verlassen.)

Der Cleanup Specialist ist ein Symptom, kein Beruf

Seit einiger Zeit taucht ein Jobtitel auf: „Vibe Coding Cleanup Specialist“. 404 Media hat 2025 Freelancer und Firmen dokumentiert, die Geld damit verdienen, KI-generierte Projekte wieder beherrschbar zu machen; Golem griff die Recherche auf, und es kursiert mindestens eine konkrete deutsche Remote-Ausschreibung unter diesem Titel.

Bevor daraus die nächste Schlagzeile wird: Das ist ein tatsächlich verwendeter Kundenbegriff, aber kein etablierter Beruf und kein messbarer Jobtrend. Die Belege bestehen aus Einzelfällen, Selbstbezeichnungen und einer Handvoll sichtbarer Angebote. Wer daraus eine Berufskurve mit Gehaltsbändern zeichnet, dichtet.

Interessanter ist, was der Begriff verrät. Er benennt ein echtes Problem auf Kundenseite: Ein Prototyp läuft oberflächlich, aber niemand kann ihn sicher weiterentwickeln oder betreiben. Die Tätigkeit selbst ist klassische Senior-Arbeit unter neuem Etikett: fremden Code verstehen, Risiken sichtbar machen, Code refaktorisieren, Tests und CI ergänzen, Sicherheitsfragen klären, die Architektur bereinigen und dokumentieren. Ein neuer Beruf ist das nicht, nur ein neues Schild an einer alten, teuren Tür.

Die eigentliche Lehre lautet nicht, sich als Aufräumtrupp zu verkaufen. Sie lautet, gar nicht erst in die Lage zu kommen, in der man einen braucht.

Vom Vibe zur Souveränität

Wenn Sie das Gefühl kennen, dass Ihr Team zwar viel KI-Code produziert, aber niemand ihn wirklich versteht, dann brauchen Sie nicht zuerst ein besseres Tool, sondern einen Moduswechsel. Die folgende Umstellung kostet keine neue Lizenz, nur Disziplin:

• Aufgaben vorab einsortieren. Jede Aufgabe bekommt eine Risikostufe (R0 bis R4), bevor ein Prompt geschrieben wird. Die Stufe entscheidet über den Modus, nicht die Tagesform.
• Kontext explizit machen. Repository-Regeln, Architekturentscheidungen, Abgrenzungen und Beispiele gehören ins Repository, nicht in einen flüchtigen Chat-Verlauf.
• Rechte beschneiden. Least Privilege und Sandbox als Standard. Breite Rechte sind die Ausnahme, die jemand begründet.
• Belege statt Gefühl. Diff, Tests, statische Analyse und ein benannter Reviewer auf den kritischen Pfaden. Der Prüfpfad wird vor der Arbeit festgelegt, nicht danach.
• Rückweg sichern. Kleine Änderungen, Checkpoints, ein getesteter Rollback.
• Verantwortung benennen. Für jede Änderung mit Reichweite gibt es einen Menschen, der sie erklären und vertreten kann.

Das ist der Übergang von „es läuft“ zu „ich kann erklären, warum es läuft und was passiert, wenn nicht“. Wer daraus einen Teamstandard machen will, braucht mehr als Werkzeugregeln: Risikoklassifikation, Akzeptanzkriterien, Prüfpfade und benannte Verantwortung. Genau das ist der Kern des Intensivworkshops, in dem man lernt, Coding Agents im Team systematisch zu beherrschen. Davor lohnt der Blick darauf, wer im Agentenzeitalter eigentlich wen im Code-Review prüft.

Fazit

Vibe Coding ist kein Tool und kein moralisches Versagen. Es ist ein Betriebsmodus, der wirklich nützlich ist, solange die Folgen lokal, umkehrbar und billig prüfbar bleiben. Karpathy hat ihn für Wochenendprojekte beschrieben, Torvalds hat ihn auf ein Lernspielzeug angewendet, und beide haben damit recht behalten.

Der Fehler entsteht erst, wenn dieser Wochenendmodus klammheimlich in die Produktion einzieht: in Kundenfunktionen, in gemeinsam genutzte Tools, in langlebige Codebasen. Dann zahlen andere den Preis, und der Engpass wandert von der Tastatur in die Prüfung und in den Betrieb. Die Grenze dazwischen ist kein Deploy-Button. Es sind vier Fragen nach Reichweite, Reversibilität, Prüfbarkeit und Verantwortung.

Die gute Nachricht: Sie müssen den Modus nicht aufgeben, nur wechseln. Beim Vibe wächst der Code schneller als das Verständnis. Beim Orchestrieren wächst die Absicherung mit. Das ist der ganze Unterschied, und er ist erlernbar.

Quellen

• Andrej Karpathy: Original-Post zum Begriff „vibe coding“ (2. Februar 2025)
• Simon Willison: Not all AI-assisted programming is vibe coding
• Simon Willison: Vibe coding and agentic engineering are getting closer than I'd like
• Martin Fowler: Vibe Coding
• Linus Torvalds: AudioNoise-Repository
• Cui et al.: The Effects of Generative AI on High-Skilled Work, Management Science (2026)
• DORA: Impact of Generative AI in Software Development (Version 2025.2)
• Spracklen et al.: We Have a Package for You!, USENIX Security 2025
• Zhang et al.: LLM Hallucinations in Practical Code Generation, ISSTA 2025
• METR: Many SWE-bench-Passing PRs Would Not Be Merged into Main
• Andy Greenberg, WIRED: Thousands of Vibe-Coded Apps Expose Corporate and Personal Data
• Emanuel Maiberg, 404 Media: The Software Engineers Paid to Fix Vibe Coded Messes