Vibe Coding im Unternehmen trägt bei Prototypen & wird im Betrieb zum Risiko

Der Begriff Vibe Coding stammt von Andrej Karpathy, der ihn im Februar 2025 auf X einführte. Gemeint war eine Arbeitsweise, bei der man der KI folgt und den Code selbst kaum noch ansieht. Im November 2025 kürte Collins den Begriff zum englischen Wort des Jahres. Für Unternehmen stellt sich seitdem eine sehr praktische Frage. Welcher Code darf so entstehen, und welcher braucht den vollen Entwicklungsprozess?

Die Antwort hängt an drei Punkten, die sich in jedem Projekt klären lassen. Wer versteht den Code, wer prüft ihn, und wer betreibt ihn danach im Alltag?

Vibe Coding beschreibt Software ohne Blick in den Code

Vibe Coding ist eine Arbeitsweise, bei der ein Sprachmodell aus Anweisungen in natürlicher Sprache lauffähigen Code erzeugt. Die Person am Rechner prüft das Ergebnis im Browser oder in der App und kaum im Quelltext. Fehler meldet sie einfach als neuen Prompt an das Modell zurück. Verständnis für Aufbau, Sicherheit und Abhängigkeiten des Codes ist dabei keine Voraussetzung.

Die wichtigste Abgrenzung stammt vom Entwickler Simon Willison aus dem März 2025. Wer KI Code reviewt, gründlich testet und einer anderen Person erklären kann, betreibt für ihn Softwareentwicklung. Das Werkzeug bleibt in beiden Fällen gleich, den Unterschied machen Prüfung und Verständnis. An dieser Linie entscheidet sich, ob KI generierter Code im Unternehmen trägt.

Im professionellen Alltag ist reines Vibe Coding bislang eher selten. In der Umfrage von Stack Overflow vom Juli 2025 sagten knapp 77 Prozent, es gehöre nicht zu ihrer Arbeit. KI Werkzeuge selbst gehören dagegen in den meisten Teams längst zum Standard. Laut DORA Report 2025 nutzen 90 Prozent der Fachleute in der Softwareentwicklung KI. Rund 30 Prozent vertrauen den Ergebnissen dabei nur wenig oder gar nicht. Bei Stack Overflow nutzten 2025 bereits 84 Prozent der Befragten KI Werkzeuge oder planten es.

Die aktuelle Umfrage von Stack Overflow vom Oktober 2026 zeigt ein ähnliches Bild. Coding Assistenten oder Coding Agenten setzen dort 66 Prozent der Befragten ein. Fast die Hälfte vertraut der KI, wenn sich das Ergebnis leicht prüfen lässt. Für wichtige Entscheidungen würden sich nur 6,6 Prozent auf sie verlassen.

Prototypen & interne Werkzeuge vertragen schnellen KI Code

Für manche Aufgaben ist ungeprüfter KI Code ein vertretbares Risiko. Willison fragt selbst, warum man bei Prototypen und Projekten mit geringem Risiko nicht einfach loslegen sollte. Der Wert eines Prototyps liegt in der Erkenntnis, die er dem Team liefert. Ist die Frage beantwortet, darf der Code danach wieder verschwinden.

Typisch sind vier Einsatzfelder, in denen schneller KI Code seinen Zweck gut erfüllt.

• Klickbare Prototypen, mit denen ein Team eine Idee testet, bevor Budget fließt.
• Machbarkeitstests, etwa ob sich eine Schnittstelle grundsätzlich ansprechen lässt.
• Interne Einmalwerkzeuge wie Auswertungsskripte, die nach Gebrauch wieder verschwinden.
• Demos für Workshops und Pitches, die nie mit echten Daten arbeiten.

Kriterien für den schnellen Weg

Gemeinsam ist diesen Fällen ein begrenzter Schaden, wenn etwas schiefgeht. Sie haben keine externen Nutzer, keine personenbezogenen Daten und keine Zahlungen. Ein Zugriff auf Produktivsysteme fehlt ebenso, und die Lebensdauer ist kurz. Selbst hier nennt Willison drei Fallen, die schnell teuer werden können.

Dazu zählen offengelegte Zugangsschlüssel und der Umgang mit privaten Daten. Hinzu kommen Kosten durch APIs, die nach tatsächlicher Nutzung abgerechnet werden. Kritisch wird es außerdem, wenn aus dem Prototyp stillschweigend das Produkt wird. Ab diesem Moment braucht der Code dieselben Prüfungen wie jede andere produktive Software.

Ob ein Werkzeug Prototyp bleiben darf, klären fünf Fragen an die Geschäftsführung.

1. Nutzt nur das eigene Team die Anwendung oder auch Kunden und Partner?
2. Verarbeitet sie Testdaten oder personenbezogene und geschäftskritische Daten?
3. Lebt sie nur wenige Wochen oder voraussichtlich mehrere Jahre?
4. Wer wartet sie, wenn die Person, die sie erstellt hat, nicht mehr da ist?
5. Kostet ein Fehler einen Nachmittag oder Umsatz, Haftung und Vertrauen?

Im Produktivbetrieb werden die Risiken messbar

Sobald Software echte Nutzer und echte Daten hat, verschiebt sich die Rechnung. Mehrere Studien aus den Jahren 2025 und 2026 beziffern die Risiken inzwischen recht genau.

Schwachstellen im generierten Code

Veracode ließ im Juli 2025 über 100 Sprachmodelle insgesamt 80 Programmieraufgaben lösen. Danach prüfte das Unternehmen den erzeugten Code mit statischer Analyse. Bei Java lag die Fehlerquote in der Sicherheitsprüfung über 70 Prozent. Bei Python, C# und JavaScript lag sie zwischen 38 und 45 Prozent. Gegen Cross Site Scripting sicherten die Modelle ihren Code in 86 Prozent der Fälle nicht ab, gegen Log Injection in 88 Prozent.

CodeRabbit verglich im Dezember 2025 insgesamt 470 Pull Requests aus Open Source Projekten. Beiträge mit KI Beteiligung enthielten im Schnitt 10,83 Probleme, rein menschliche Beiträge 6,45. Fehler in Logik und Korrektheit traten dabei um 75 Prozent häufiger auf. Probleme bei der Lesbarkeit kamen mehr als dreimal so oft vor. Bei Sicherheitsproblemen lag der Faktor im Vergleich bei bis zu 2,74.

Zugangsdaten und erfundene Pakete

Die Cloud Security Alliance wertete im März 2026 Daten von GitGuardian aus. Danach enthielten KI gestützte Commits in 3,2 Prozent der Fälle Zugangsdaten. Im Durchschnitt aller öffentlichen Commits auf GitHub lag der Wert bei 1,5 Prozent. Dieselbe Auswertung zählte für 2025 rund 28,65 Millionen neue Secrets in öffentlichen Commits. Zugangsdaten für KI Dienste stiegen gegenüber dem Vorjahr um 81 Prozent.

Ein neueres Risiko betrifft die Abhängigkeiten eines Projekts. Die Alliance zitiert eine Studie mit 576.000 Codebeispielen, die von KI erzeugt wurden. In rund 20 Prozent davon empfahl das Modell Pakete, die es gar nicht gibt. Angreifer können solche Namen registrieren und darunter eigenen Schadcode veröffentlichen. Das Muster trägt inzwischen den Namen Slopsquatting.

Plattformen mit unsicheren Voreinstellungen

Im April 2026 dokumentierte die Cloud Security Alliance den Fall Lovable. Ein Scan von 1.645 Anwendungen der Plattform fand 303 verwundbare Endpunkte in 170 Anwendungen. Ursache war fehlende Row Level Security in Supabase, die nur auf ausdrückliche Anweisung entstand. Das Vibe Security Radar der Georgia Tech ordnete bis März 2026 insgesamt 74 Sicherheitslücken mit CVE Kennung KI Code zu. Im Januar 2026 kamen 6 neue Fälle hinzu, im März waren es bereits 35. Die Forscher schätzen die tatsächliche Zahl auf das Fünf bis Zehnfache.

Im März 2026 berichtete die Alliance außerdem über einen Scan von Escape.tech mit über 1.400 KI gebauten Anwendungen. Bei 65 Prozent davon fanden sich Sicherheitsprobleme, bei 58 Prozent mindestens eine kritische Lücke. Im Juli 2025 meldete Wiz Research eine Umgehung der Anmeldung bei der Plattform Base44.

Agenten mit Schreibrechten

Im Juli 2025 löschte ein KI Agent bei Replit nach Angaben des Nutzers Jason Lemkin eine produktive Datenbank. Ein Code Freeze war zu diesem Zeitpunkt bereits angeordnet. Laut eWeek kündigte Replit danach an, Datenbanken für Entwicklung und Produktion automatisch zu trennen. Dazu kam ein Modus, in dem der Agent nur plant und nichts ausführt.

Für KI Agenten mit Zugriff auf Firmensysteme folgt daraus eine klare Regel. Schreibrechte auf Produktivdaten erhalten sie nur mit Freigabe durch einen Menschen. Bei Anbindungen über das Model Context Protocol legt der jeweilige Server fest, welche Werkzeuge ein Agent nutzen darf.

Wartbarkeit entscheidet über die Kosten im zweiten Jahr

Code, der heute läuft, kann in der Weiterentwicklung teuer werden. GitClear analysierte Codeänderungen bis einschließlich 2024, darüber berichtete DevClass im Februar 2025. Blöcke mit fünf oder mehr duplizierten Zeilen nahmen 2024 um das Achtfache zu. Verschobene Zeilen, ein Indikator für Refactoring, gingen um 39,9 Prozent zurück. 2024 übertrafen kopierte Zeilen damit erstmals die Zahl der verschobenen Zeilen.

Duplikate sind teuer, weil jede Änderung an mehreren Stellen nötig wird. Bleibt eine Kopie unverändert, entsteht beim nächsten Update leicht ein neuer Fehler. Refactoring räumt solche Stellen auf und hält eine Codebasis überschaubar.

Ein zweites Problem ist Code, der fast stimmt. In der Stack Overflow Umfrage 2025 nannten 66 Prozent KI Lösungen, die fast richtig sind, als Problem. In derselben Umfrage misstrauten 46 Prozent der Genauigkeit von KI Werkzeugen, 33 Prozent vertrauten ihr. Rund 45 Prozent gaben an, dass die Fehlersuche in KI Code mehr Zeit kostet. Für die Planung heißt das, Zeit für Prüfung und Korrektur fest einzurechnen.

Für Entscheider zählt deshalb vor allem die Frage nach der Betreuung. Jemand muss die Anwendung in zwölf Monaten noch verstehen, aktualisieren und absichern können.

Produktiver Code braucht feste Prüfschritte

Der DORA Report 2025 beschreibt KI als Spiegel und Verstärker. Über 80 Prozent der Befragten berichten von höherer Produktivität, 59 Prozent von besserer Codequalität. In fragmentierten Organisationen legt sie vorhandene Schwächen offen. Für produktiven Code gelten deshalb die bekannten Regeln der Softwareentwicklung, nur konsequenter.

Tests und Review

Automatisierte Tests sind das Abnahmekriterium für jede einzelne Änderung. Sie laufen in der Pipeline, bevor neuer Code zusammengeführt wird. KI kann Tests schreiben, die Anforderungen legen aber Menschen fest. Dasselbe Prinzip gilt für KI Anwendungen selbst, etwa bei Tests für einen KI Chatbot im Kundenservice.

Danach prüft jemand den Code, der ihn auch erklären kann. Das ist Willisons Kriterium und zugleich ein Schutz gegen Code, den niemand versteht. Automatische KI Reviews können diesen Schritt als zusätzlichen Filter ergänzen. Die Alliance empfiehlt außerdem, Teams gezielt im Review von Code zu schulen, den sie nicht selbst geschrieben haben.

Sicherheitsprüfung in der Pipeline

Die Cloud Security Alliance empfiehlt, KI Code so lange als nicht vertrauenswürdig zu behandeln, bis er alle Prüfungen bestanden hat. Ihre Empfehlungen lassen sich in fünf Bausteine für die Pipeline übersetzen.

• Statische Analyse als blockierende Stufe vor jedem Merge.
• Secret Scanning vor jedem Commit, auch für Schlüssel von KI Diensten.
• Lockfiles, Allowlists und die Prüfung von Paketnamen vor der Installation.
• Eine Softwarestückliste, kurz SBOM, für Codebasen mit hohem KI Anteil.
• Eine Kennzeichnung, welcher Code mit KI Unterstützung entstanden ist.

Prüftiefe nach Einsatzfall

Wie viel Prüfung nötig ist, hängt vom Einsatz und vom möglichen Schaden ab. Die Übersicht zeigt eine mögliche Staffelung der Prüftiefe.

Regeln und Verantwortung

Die Alliance rät außerdem zu klaren Regeln, wann KI für Produktivcode eingesetzt werden darf. Das betrifft vor allem personenbezogene Daten, Authentifizierung und externe Schnittstellen. Solche Regeln sind Teil einer KI Strategie, die Geschäftsführung und IT gemeinsam festlegen.

Seit dem 11.09.2026 gelten außerdem die Meldepflichten des Cyber Resilience Act. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwere Vorfälle melden. Die Frühwarnung muss innerhalb von 24 Stunden erfolgen, die ausführliche Meldung innerhalb von 72 Stunden. Für ausgenutzte Schwachstellen folgt der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur. Wer den Code geschrieben hat, Mensch oder KI, spielt für diese Pflichten keine Rolle. Die Meldungen laufen über eine zentrale Plattform, die seit diesem Tag bei ENISA in Betrieb ist.

Klare Regeln machen KI Code im Unternehmen nutzbar

Vibe Coding eignet sich für Prototypen, Machbarkeitstests und kurzlebige interne Werkzeuge. Software, die Kunden nutzen oder die Daten und Umsatz trägt, braucht den vollen Prozess. Dazu gehören Tests, Reviews, Sicherheitsprüfungen und eine verantwortliche Person. Wie wir Apps, Plugins und eigene Software entwickeln, testen und betreiben, zeigt die Seite zu Software & Development.