Mit KI-Assistenten entsteht Software heute in einem Tempo, das vor drei Jahren undenkbar war: beschreiben, generieren lassen, laufen sehen. Dieses Vibecoding ist produktiv und macht Spaß, und genau darin liegt das Risiko. Der Code sieht fertig aus, fühlt sich fertig an und ist es oft nicht. Dieser Beitrag fasst zusammen, was die Studienlage zu KI-generiertem Code tatsächlich hergibt, und zeigt, wie Unternehmen das Tempo nutzen, ohne sich die Probleme von morgen in die Produktion zu holen.
Was Vibecoding gut kann und wo es kippt
KI-Assistenten sind stark, wenn es darum geht, aus einer klaren Beschreibung schnell funktionierenden Code zu erzeugen: Formulare, Datenbankzugriffe, Auswertungen, ganze Prototypen. Für Fachabteilungen, die ihre Prozesse selbst digitalisieren wollen, ist das ein echter Hebel. Der Umschlagpunkt kommt, wenn aus dem Prototyp unbemerkt ein Produktivsystem wird: Der Code funktioniert im Demo-Pfad, aber niemand hat auf Fehlerfälle, Zugriffsrechte oder Wartbarkeit geschaut.
Das Kernproblem ist nicht, dass KI schlechten Code schreibt. Das Kernproblem ist, dass sie überzeugenden Code schreibt. Plausibilität ersetzt Prüfung, und genau diese Lücke müssen Prozesse schließen.
Die Studienlage: Sicherheit bleibt das schwächste Glied
Der GenAI Code Security Report von Veracode aus 2025 hat über 100 Sprachmodelle mit 80 realistischen Programmieraufgaben getestet. Das Ergebnis: In 45 Prozent der Fälle enthielt der generierte Code eine bekannte Sicherheitslücke, bei Java sogar in rund 70 Prozent. Cross-Site-Scripting wehrten die Modelle in 86 Prozent der einschlägigen Aufgaben nicht ab. Besonders bemerkenswert: Neuere und größere Modelle schrieben zwar funktional besseren, aber nicht sichereren Code. Die Sicherheitsquote blieb über Modellgenerationen hinweg nahezu konstant.
Auch die Wartbarkeit leidet messbar. GitClear hat 211 Millionen geänderte Codezeilen aus den Jahren 2020 bis 2024 analysiert: Der Anteil kopierter Zeilen stieg deutlich, duplizierte Codeblöcke nahmen um ein Mehrfaches zu, und 2024 überstieg Copy-Paste erstmals das Refactoring. Gleichzeitig wuchs der Anteil von Code, der binnen zwei Wochen wieder geändert werden musste, von 5,5 auf 7,9 Prozent. KI-Code entsteht schnell, wird aber überdurchschnittlich oft schnell wieder angefasst.
Gefühltes Tempo ist nicht gemessenes Tempo
Der DORA-Report 2024 von Google fand bei über 39.000 Befragten ein bemerkenswertes Muster: 75 Prozent berichten von Produktivitätsgewinnen durch KI, aber auf Team-Ebene ging eine um 25 Prozent höhere KI-Nutzung mit etwa 1,5 Prozent weniger Durchsatz und 7,2 Prozent schlechterer Stabilität der Auslieferung einher. Mehr Code entsteht, aber größere Änderungspakete und weniger Prüfung machen die Lieferkette wackliger.
In dieselbe Kerbe schlägt ein randomisiertes Experiment des Forschungsinstituts METR aus 2025: Erfahrene Open-Source-Entwickler waren mit KI-Werkzeugen im Schnitt 19 Prozent langsamer, glaubten aber, 20 Prozent schneller gewesen zu sein. Eine Folgeerhebung von 2026 relativierte den Effekt auf ungefähr neutral, der Befund zur Fehlwahrnehmung blieb. Die ehrliche Zusammenfassung lautet: Der Produktivitätsgewinn ist real situationsabhängig, die eigene Einschätzung dazu ist unzuverlässig. Umso wichtiger sind objektive Prüfungen statt Bauchgefühl.
Was daraus folgt: Review ist keine Bremse, sondern die Voraussetzung für Tempo
Die Konsequenz aus der Studienlage ist nicht, Vibecoding zu verbieten. Die Konsequenz ist, es wie jede andere Codequelle zu behandeln, nur mit höherem Durchsatz: Was in Produktion geht, wird geprüft. Automatisch, wo Maschinen gut sind, und menschlich, wo Kontext zählt.
- Automatische Quality Gates vor jedem Einreichen: Secret-Scan, Abhängigkeits-Audit, Schwachstellen-Scan der Container, Prüfung der Datenbank-Migrationen samt Zugriffsregeln.
- Architektur-Leitplanken, die die KI mitliest: Geschäftslogik gehört ins Backend, Zugriffsregeln in die Datenbank, Secrets nie in den Code. Solche Regeln lassen sich der KI als verbindliche Arbeitsanweisung mitgeben.
- Menschliches Review vor dem Go-Live: ein erfahrener Blick auf Datenzugriffe, Fehlerfälle und die Frage, ob der Code das Problem wirklich löst statt nur den Demo-Pfad.
- Kleine, nachvollziehbare Einheiten: eine App, ein Zweck, ein Verantwortlicher, ein Audit-Log. Rollback eingeplant statt erhofft.
- Betrieb als Teil des Prozesses: Monitoring, Backups und fortlaufende Sicherheits-Scans, denn ein Review zum Go-Live ersetzt keine Beobachtung im Betrieb.
So setzen wir das mit Kinster um
In unserer App-Plattform Kinster ist dieser Prozess eingebaut statt angeklebt: Fachabteilungen beschreiben ihre App und entwickeln sie KI-gestützt in VS Code im Browser, innerhalb von Leitplanken, die die KI als Arbeitsanweisung mitliest. Einreichen lässt sich ein Stand nur, wenn die automatischen Prüfungen ihn durchlassen, und produktiv geht er erst nach dem Review durch needful-apps. Deployments laufen ohne Unterbrechung, der vorige Stand bleibt für den Rollback bereit, und jede Entscheidung steht im Audit-Log.
So bleibt vom Vibecoding das Beste erhalten, nämlich das Tempo und die Nähe der Fachabteilung zu ihrem Prozess. Und die Zahlen aus den Studien oben bleiben das, was sie sein sollten: eine Warnung vor dem ungeprüften Weg, nicht Ihre Betriebsrealität.
Häufige Fragen
Was ist Vibecoding?
KI-gestütztes Programmieren, bei dem Menschen in natürlicher Sprache beschreiben, was entstehen soll, und ein KI-Assistent große Teile des Codes erzeugt. Der Begriff betont den Fluss dieser Arbeitsweise: schnell beschreiben, generieren, ausprobieren. Produktionsreif wird das Ergebnis erst durch Prüfung und Review.
Reichen automatische Scans nicht aus, warum noch ein menschliches Review?
Scanner finden bekannte Muster: verratene Secrets, verwundbare Abhängigkeiten, typische Schwachstellen. Ob eine App die richtigen Daten den richtigen Personen zeigt, ob Fehlerfälle sinnvoll behandelt werden und ob die Lösung zum Prozess passt, erkennt kein Scanner. Die Kombination ist der Punkt: Maschinen prüfen breit, Menschen prüfen tief.
Macht das Review den Geschwindigkeitsvorteil der KI nicht wieder zunichte?
Nein, es verlagert ihn dahin, wo er hingehört. Ein Review kostet Stunden, ein Sicherheitsvorfall oder ein unwartbares System kostet Wochen. Die DORA-Daten zeigen, dass ungeprüftes KI-Tempo die Auslieferung instabiler macht, und instabile Auslieferung ist die teuerste Form von Langsamkeit.
Gilt das auch für kleine interne Tools ohne Außenkontakt?
Gerade dort. Interne Tools verarbeiten oft die sensibelsten Daten (Personal, Kalkulationen, Kunden) und werden am seltensten geprüft. Der Aufwand darf kleiner sein als bei einem öffentlichen Produkt, aber Zugriffsregeln, Backups und ein kurzes Review vor dem Go-Live sind auch hier die Mindesthöhe.