Vibe Coding: Was der Begriff meint und wo die Grenze zum Produktionssystem verläuft

Vibe Coding bedeutet, einer KI in natürlicher Sprache zu beschreiben, was eine Software tun soll, die Vorschläge anzunehmen und den erzeugten Code nicht mehr Zeile für Zeile zu prüfen. Die Grenze zum Produktionssystem ist genau dort überschritten, wo jemand anderes als der Erbauer auf das Ergebnis angewiesen ist — sobald echte Personendaten, echtes Geld oder eine gesetzliche Pflicht daran hängen, reicht «es läuft» als Qualitätsaussage nicht mehr.

Diese beiden Sätze klingen banal, werden in der Praxis aber ständig verwischt. Denn zwischen dem Nachmittag, an dem ein Prototyp entsteht, und dem Montag, an dem drei Kolleginnen ihn produktiv benutzen, liegt kein sichtbares Ereignis. Niemand ruft «jetzt ist es ein Produktionssystem». Genau deshalb lohnt es sich, den Begriff und die Linie sauber zu definieren.

Was der Begriff ursprünglich meint — und was nicht

Vibe Coding ist keine Sammelbezeichnung für KI-Unterstützung beim Programmieren, sondern beschreibt einen bewussten Kontrollverzicht. Andrej Karpathy beschrieb am 2. Februar 2025 auf X eine Arbeitsweise, bei der man sich «den Vibes hingibt» und «vergisst, dass der Code überhaupt existiert»: Vorschläge werden angenommen, ohne die Änderungen zu vergleichen, Fehlermeldungen werden kommentarlos ins Chatfenster zurückgeworfen, und die Codebasis wächst über das hinaus, was der Mensch am Steuer noch überblickt.

Der Begriff traf einen Nerv. Collins kürte «vibe coding» im November 2025 zum Wort des Jahres und definierte es als das Erzeugen von Computercode über natürliche Sprache mithilfe von KI.

Für die Praxis ist die Abgrenzung wichtiger als die Definition. Wer mit Cursor arbeitet, jede vorgeschlagene Änderung liest, sie ablehnt oder anpasst und anschliessend Tests laufen lässt, betreibt kein Vibe Coding, sondern KI-gestützte Entwicklung. Das Werkzeug ist identisch, die Verantwortungslage ist es nicht. Diese Unterscheidung entscheidet später darüber, ob ein System wartbar ist.

Warum der Erfinder den Begriff selbst schon abgelöst hat

Karpathy hat «Vibe Coding» Anfang 2026 für überholt erklärt und den Nachfolgebegriff «Agentic Engineering» vorgeschlagen — mit der Begründung, man schreibe den Code in den allermeisten Fällen ohnehin nicht mehr selbst, sondern steuere Agenten und übe Aufsicht aus; das Wort «Engineering» soll betonen, dass genau darin eine Fachdisziplin liegt.

Diese Korrektur ist mehr als Wortklauberei. Sie beschreibt exakt die Reifung, um die es hier geht: Vibe Coding heisst «beschreiben und annehmen». Agentic Engineering heisst «System entwerfen, Agenten anleiten, Ergebnis prüfen». Für Unternehmen ist nur das Zweite eine tragfähige Arbeitsweise, und die KI-gestützte Entwicklung unterscheidet sich von der ersten Variante vor allem durch das, was nach der Generierung passiert.

Interessant ist auch, was der Begriffswechsel über die Werkzeuge sagt: Die agentischen Varianten wie Claude Code oder Cursor im Agent-Modus sind heute gut genug, dass die eigentliche Engstelle nicht mehr die Codeerzeugung ist, sondern die Aufsicht darüber.

Die Grenze verläuft an vier Fragen, nicht am Werkzeug

Ob ein System die Grenze zum Produktionsbetrieb überschritten hat, entscheidet nicht die verwendete Plattform, sondern vier Fragen, die sich in fünf Minuten beantworten lassen.

Wessen Daten liegen darin? Testdaten und Beispieleinträge sind unkritisch. Sobald echte Namen, Adressen, Gesundheits- oder Finanzdaten von Kundinnen im System liegen, gilt das Schweizer Datenschutzgesetz mit allem, was dazugehört: Zweckbindung, Auskunftsrecht, Löschkonzept, Bearbeitungsverzeichnis. Ein Prototyp hat davon in der Regel nichts.

Wessen Risiko trägt das System? Wenn ein Ausfall dich einen Nachmittag kostet, ist es ein Prototyp. Wenn er einen Kunden eine Bestellung kostet, ist es ein Produktivsystem.

Wer liest den Code? Nicht «wer könnte ihn lesen», sondern: Hat ihn tatsächlich jemand gelesen, der beurteilen kann, ob die Zugriffsprüfung an der richtigen Stelle sitzt? Bei Vibe Coding im ursprünglichen Sinn lautet die Antwort per Definition: niemand.

Wer betreibt das in achtzehn Monaten? Diese Frage ist die unbequemste. Software, die nur eine Person versteht, ist ein Klumpenrisiko — dieselbe Falle, die auch bei der klassischen Make-or-Buy-Entscheidung regelmässig übersehen wird.

Was die Sicherheitszahlen konkret bedeuten

Der häufigste Irrtum lautet: Wenn es läuft, ist es richtig. Die Zahlen sagen etwas anderes. Veracode hat in seiner Auswertung vom Frühjahr 2026 achtzig Programmieraufgaben in vier Sprachen über mehr als 150 Sprachmodelle laufen lassen und den erzeugten Code statisch geprüft. Ergebnis: Über 95 % des Codes war syntaktisch korrekt, aber nur 55 % bestand die Sicherheitsprüfung. Nach Sprachen aufgeschlüsselt reichte die Spanne von 62 % bei Python bis 29 % bei Java. Nach Schwachstellenart war das Bild noch schärfer: SQL-Injection wurde in 82 % der Fälle korrekt vermieden, Cross-Site-Scripting nur in 15 %.

Rechne das auf ein realistisches kleines Projekt herunter. Eine Kundenanwendung mit Login, Formularen und einer Übersichtsliste enthält leicht vierzig Stellen, an denen eine sicherheitsrelevante Entscheidung fällt — jede Eingabe, jede Ausgabe, jede Datenbankabfrage, jede Rechteprüfung. Bei einer Trefferquote von 55 % sind das rechnerisch achtzehn Stellen, die nicht dem sicheren Muster folgen. Nicht achtzehn ausnutzbare Lücken, aber achtzehn Stellen, die jemand anschauen muss. Und da ausgerechnet Cross-Site-Scripting mit 15 % am schlechtesten abschneidet, konzentriert sich das Problem auf genau die Stelle, an der Benutzereingaben wieder auf dem Bildschirm landen — also im Kern jeder Formular-Anwendung.

Dazu passt der Befund der Stack-Overflow-Entwicklerumfrage 2025: 84 % der Befragten nutzen KI-Werkzeuge oder planen es, aber 46 % misstrauen der Genauigkeit der Ausgaben — gegenüber 31 % im Vorjahr. Und 66 % nennen als grösste Reibung Lösungen, die «fast richtig» sind. Genau dieses «fast» ist der Grund, warum ungelesener Code im Produktivbetrieb teuer wird: Er scheitert nicht laut, er scheitert leise.

Zwei Zonen, eine Tabelle

Ein Prototyp und ein Produktivsystem unterscheiden sich in sieben Dimensionen, und in jeder einzelnen ist der Unterschied kategorial statt graduell: Testdaten gegen echte Personendaten, ein Passwort gegen ein Rollenmodell, ungelesener Code gegen geprüften Code. Die folgende Aufstellung ist deshalb kein Reifegradmodell, sondern eine Zuordnung.

Der springende Punkt: Kein einziger Eintrag in der rechten Spalte entsteht durch besseres Prompten. Es sind alles Dinge, die zusätzlich gebaut, geprüft und betrieben werden müssen. Wer den Aufwand für den Übergang plant, sollte ihn deshalb nicht als «Politur» kalkulieren, sondern als eigenständigen Arbeitsschritt mit eigenem Budget.

Wo Vibe Coding klar die richtige Wahl ist

Vibe Coding ist immer dann die richtige Wahl, wenn die Software eine Frage beantworten soll und danach niemand mehr von ihr abhängt — bei der Ideenvalidierung, bei Wegwerf-Werkzeugen und bei kleinen internen Hilfsmitteln ohne sensible Daten. In diesen drei Fällen ist der Kontrollverzicht kein Mangel, sondern der eigentliche Vorteil.

Der erste Fall ist die Ideenvalidierung. Wenn noch offen ist, ob überhaupt jemand ein Werkzeug braucht, wäre sauberes Engineering verschwendetes Geld. Ein klickbarer Beweis, der nach dem Test weggeworfen wird, darf schlecht gebaut sein — das ist der ganze Zweck einer Prototyp-Validierung, und ein realistischer Ablauf dafür passt in fünf Arbeitstage.

Der zweite Fall sind Wegwerf-Werkzeuge: das Skript, das eine Excel-Liste einmalig umformt, der kleine Rechner für eine Kampagne, die Auswertung, die eine Frage beantwortet und dann nie wieder läuft. Hier ist die Lebensdauer so kurz, dass Wartbarkeit schlicht kein Thema ist.

Der dritte Fall ist das interne Hilfsmittel mit engem Nutzerkreis und ohne sensible Daten — eine Übersicht über Termine, ein Formular für interne Meldungen. Hier ist ein pragmatisch gebautes Werkzeug oft besser als gar keins. Die Bedingung bleibt dieselbe: Sobald Kundendaten hineinfliessen, wechselt das System die Zone. Für diesen Fall lohnt sich früh die Frage, ob eine eigene Web-Anwendung oder eine Standardlösung der bessere Weg ist — dieselbe Abwägung wie beim Thema CRM kaufen oder entwickeln.

Fazit: eine Linie, die man selbst ziehen muss

Vibe Coding ist eine legitime, sehr produktive Arbeitsweise für alles, was nicht getragen werden muss. Es ist keine Methode, um Software zu bauen, auf die andere Menschen angewiesen sind — nicht weil die Werkzeuge schlecht wären, sondern weil die Definition den entscheidenden Prüfschritt ausdrücklich weglässt.

Praktisch heisst das: Baut schnell, aber schreibt auf, in welcher Zone ihr euch befindet. Definiert vorher, was den Zonenwechsel auslöst — echte Kundendaten, ein externer Nutzer, ein Ausfall mit Geschäftsfolge. Und plant den Übergang als eigenes Vorhaben mit Datenmodell, Rechten, Tests und Betrieb. Wer diesen Schritt bewusst geht, bekommt beides: das Tempo der Sprachmodelle und ein System, das in zwei Jahren noch änderbar ist. Wenn ihr unsicher seid, wo eure aktuelle Lösung steht, ist eine nüchterne Einordnung der Sinn einer KI-Beratung — und wenn der Übergang ansteht, begleitet eine Vibe-Coding-Agentur genau diesen Schritt.