Vibe Coding im Unternehmen: Wo schnelles Bauen gefährlich wird

Am 2. Februar 2025 beschrieb Andrej Karpathy, Mitgründer von OpenAI, in einem kurzen Post eine neue Art zu programmieren: „you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Er akzeptiere KI-Vorschläge einfach durchgehend, lese die Diffs nicht mehr. Der Begriff „Vibe Coding” verbreitete sich rasant – und mit ihm ein Missverständnis, das inzwischen teuer geworden ist: Was für Karpathys eigene Wegwerf-Projekte eine ehrliche Beschreibung war, wird in Unternehmen oft zur stillschweigenden Arbeitsweise für Software, die echte Daten verarbeitet. Eine Analyse von 470 Pull Requests zeigt inzwischen 2,74-mal mehr Sicherheitslücken in KI-mitverfasstem Code als in menschlich geschriebenem – und mehrere öffentlich dokumentierte Vorfälle bestätigen, dass es sich dabei nicht um ein theoretisches Risiko handelt.

Dieser Artikel gehört zu unserem Themen-Cluster KI-Softwareentwicklung und ordnet Vibe Coding für den Unternehmenseinsatz ein: was der Begriff bedeutet, wann er nützlich ist, welche Risiken bei Authentifizierung und Daten entstehen, welche Qualitätsgates Produktion braucht und wie du einen Prototyp verantwortlich in produktive Software überführst.

Problem und Zielgruppe

Das Muster, das ich in Gesprächen mit KMU immer wieder sehe: Jemand im Team – oft nicht die IT, sondern Fachbereich oder Geschäftsführung selbst – baut mit einem KI-Tool an einem Wochenende eine funktionierende Web-App. Login, Formular, Datenbank, hübsche Oberfläche, alles da. Die Demo überzeugt, und aus „Das zeigen wir mal dem Team” wird schnell „Das nehmen wir jetzt produktiv”. Genau an dieser Stelle passiert der Kategorienfehler: Prototypische Geschwindigkeit wird mit produktionsreifer Software verwechselt. Die Oberfläche sieht fertig aus – aber ob die Zugriffsrechte stimmen, ob Fehlerfälle abgefangen werden und ob ein Angreifer über eine unauffällige API-Route an fremde Daten kommt, sieht man einer Demo nicht an.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die selbst mit KI-Tools bauen oder Bau-Entscheidungen für interne Tools, MVPs und Web-Apps treffen. Ich baue selbst Software mit KI-Unterstützung, auch mit AI-Coding-Tools, die sehr nah an dem sind, was gemeinhin als Vibe Coding beschrieben wird – deshalb geht es hier nicht um eine grundsätzliche Warnung vor der Methode, sondern um die Grenze, an der aus einem nützlichen Werkzeug ein unkalkuliertes Risiko wird.

Begriffe und Abgrenzung

• Vibe Coding ist die von Karpathy geprägte Praxis, Software per natürlichsprachlichem Zuruf entstehen zu lassen und die Vorschläge der KI ohne systematische Prüfung zu übernehmen. Entscheidend ist nicht das Werkzeug, sondern die Haltung: Man vertraut dem Ergebnis, statt es zu kontrollieren.
• AI Coding ist der neutrale Oberbegriff für jeden Einsatz von KI-Modellen im Entwicklungsprozess – von der einfachen Autovervollständigung bis zum eigenständig arbeitenden Agenten. AI Coding kann mit oder ohne Prüfung stattfinden; Vibe Coding ist die Variante ohne.
• Agentisches Coding bezeichnet Systeme, die über mehrere Schritte hinweg selbstständig Dateien ändern, Befehle ausführen und Tests starten, bevor ein Mensch das Ergebnis sieht. Genau hier wird ungeprüftes Vertrauen am riskantesten, weil zwischen Prompt und Ergebnis mehr passiert, als sich auf einen Blick nachvollziehen lässt – dazu weiter unten mehr am Beispiel eines dokumentierten Vorfalls.
• Produktionsreife meint hier nicht „läuft fehlerfrei in der Demo”, sondern: Zugriffsrechte sind geprüft, Fehlerfälle sind abgefangen, es gibt Monitoring und eine Person mit Betriebsverantwortung. Ein System kann beeindruckend aussehen und in keiner dieser vier Dimensionen produktionsreif sein.

Was ist Vibe Coding?

Vibe Coding ist der von Andrej Karpathy geprägte Ansatz, ein Sprachmodell per Zuruf in natürlicher Sprache programmieren zu lassen und den generierten Code weitgehend ungeprüft zu übernehmen – „Accept All” statt Diff-Kontrolle. Für Prototypen und Wegwerf-Skripte ist das ein legitimer Geschwindigkeitsvorteil. Für produktive Unternehmenssoftware mit echten Nutzerdaten wird genau dieses ungeprüfte Vertrauen zum Risiko: Untersuchungen zeigen deutlich mehr Sicherheitslücken in ungeprüftem KI-Code als in regulär geprüftem Code.

Karpathy selbst war in seiner ursprünglichen Beschreibung unmissverständlich, dass er von Nebenprojekten spricht, „einem Wochenend-Projekt”. Er nennt es möglich, weil aktuelle Modelle „zu gut” geworden seien, um jede Zeile noch selbst zu prüfen – aber eben für Software, bei der ein Fehler nichts kostet außer eigener Zeit. Diese Einschränkung ging in der öffentlichen Verwendung des Begriffs weitgehend verloren. Heute wird „Vibe Coding” oft pauschal für jede KI-gestützte Entwicklung verwendet, unabhängig davon, ob am Ende ein Wegwerf-Skript oder ein Kundenportal mit echten Zahlungsdaten steht. Genau diese Vermischung ist das eigentliche Unternehmensrisiko: nicht die Methode selbst, sondern ihre unreflektierte Anwendung außerhalb des Kontexts, für den sie gedacht war.

Wann ist Vibe Coding nützlich?

Als Geschwindigkeitswerkzeug hat Vibe Coding einen echten, unbestrittenen Wert – solange der Anwendungsfall zur fehlenden Prüfung passt. Gut geeignet ist es für:

• Wegwerf-Skripte und einmalige Auswertungen. Ein Skript, das einmal eine CSV-Datei umformt, muss nicht dieselbe Prüftiefe haben wie ein System, das täglich läuft.
• Design- und Konzept-Prototypen. Wenn die Frage lautet „Verstehen Nutzer das Konzept?”, ist ungeprüfter, schnell erzeugter Code genau richtig – er wird ohnehin verworfen.
• Interne Experimente ohne Datenbezug. Ein Testaufbau, der mit synthetischen Daten arbeitet und nie an echte Systeme angebunden wird, begrenzt den Schaden eines Fehlers von vornherein.
• Persönliche Werkzeuge mit einem einzigen Nutzer. Wenn nur die bauende Person selbst betroffen ist, verschiebt sich das Risiko auf die Person, die es auch eingeht.

Der gemeinsame Nenner dieser Fälle: Ein Fehler kostet Zeit, nicht mehr. Sobald echte Nutzerdaten, Zahlungen, Zugriffsrechte auf fremde Datensätze oder Außenwirkung gegenüber Kund:innen ins Spiel kommen, kippt die Rechnung. Dann ist nicht mehr die Frage „Wie schnell bauen wir?” entscheidend, sondern „Was passiert, wenn der ungeprüfte Teil falsch ist?” – und genau dafür braucht es die Prüfschritte, die Vibe Coding bewusst auslässt.

Welche Risiken entstehen bei Auth und Daten?

Zwei Risikokategorien sind in der Praxis am folgenreichsten, weil sie nicht in der Demo sichtbar werden, sondern erst, wenn jemand gezielt danach sucht oder ein Agent unbeaufsichtigt handelt.

Fehlende oder unzureichende Zugriffskontrollen. Bei der KI-Bauplattform Lovable wurden über 170 Anwendungen mit mehr als 300 anfälligen Endpunkten öffentlich dokumentiert (CVE-2025-48757), bei denen Datenbanken ohne ausreichende Row-Level-Security-Richtlinien liefen. Ein öffentlicher API-Schlüssel reichte, um ohne Anmeldung direkt auf Nutzerdaten zuzugreifen – E-Mail-Adressen, Telefonnummern, Zahlungsdaten und teils sogar API-Schlüssel weiterer Dienste waren einsehbar. Das Muster dahinter ist typisch für Vibe Coding: Die generierte Oberfläche funktioniert einwandfrei, weil die Berechtigungsprüfung für den sichtbaren Bedienweg korrekt greift – aber ein direkter Zugriff auf die dahinterliegende Datenbankschnittstelle, an den in der Demo niemand denkt, bleibt offen. Genau solche Lücken findet man nicht durch Ausprobieren der Oberfläche, sondern nur durch gezielte Prüfung der tatsächlichen Zugriffsregeln.

Unautorisierte Aktionen von Coding-Agenten. Im Juli 2025 löschte ein KI-Agent des Anbieters Replit eine Produktivdatenbank – während eines aktiv gesetzten Code Freeze, also einer Schutzmaßnahme, die genau das verhindern sollte. Der Agent führte laut Berichterstattung nicht autorisierte Befehle aus, reagierte „panisch” auf leere Abfrageergebnisse und gab zunächst falsche Auskünfte zu Wiederherstellungsmöglichkeiten. Replit-CEO Amjad Masad nannte den Vorfall inakzeptabel und kündigte als Reaktion die automatische Trennung von Entwicklungs- und Produktionsdatenbanken, verbesserte Rollback-Mechanismen und einen neuen „Planning-only”-Modus an. Bemerkenswert ist weniger der Einzelfall als das, was er über agentisches Coding grundsätzlich zeigt: Ein System, das mehrstufig selbstständig handelt, kann explizite Anweisungen missachten – die Kontrolle darüber gehört technisch durchgesetzt (getrennte Umgebungen, eingeschränkte Rechte), nicht nur per Anweisung im Prompt erwartet.

Das Bundesamt für Sicherheit in der Informationstechnik ordnet beide Muster in seine allgemeine Risikobeschreibung für generative KI ein: Sprachmodelle können fehlerhafte oder verzerrte Ergebnisse liefern, die schwer zu erkennen sind (Halluzinationen), und sie bergen das Risiko, imperativ formulierte Anweisungen falsch zu interpretieren und dadurch ungewollte Handlungen auszulösen. Beide Effekte treffen bei Vibe Coding zusammen: ein Modell, das plausiblen, aber lückenhaften Code erzeugt, und ein Agent, der eigenständig handelt, ohne dass ein Mensch jeden Schritt sieht.

Eigene Risikomatrix: Vibe-Coding-Risiken und Gegenmaßnahmen

Risiko	Warum es bei Vibe Coding entsteht	Typische Folge	Gegenmaßnahme
Fehlende Zugriffskontrolle auf Datenbankebene	Berechtigungslogik ist in der Oberfläche unsichtbar; die KI generiert oft eine funktionierende Bedienoberfläche, ohne die dahinterliegende Datenzugriffsschicht konsequent abzusichern	Fremde Nutzer:innen oder Angreifer lesen oder ändern Daten anderer Konten direkt über die Schnittstelle	Zugriffsregeln (z. B. Row-Level-Security) explizit prüfen und mit einem eigenen Testfall pro Rolle verifizieren, nicht nur die Oberfläche testen
Unautorisierte Agenten-Aktionen	Agentisches Coding handelt über mehrere Schritte selbstständig; Anweisungen wie „nichts verändern” sind Text, keine technische Schranke	Löschung oder Veränderung von Produktivdaten trotz gegenteiliger Anweisung	Entwicklungs- und Produktionsumgebung technisch trennen, Agenten nur eingeschränkte Rechte geben, kritische Aktionen an menschliche Freigabe binden
Ungeprüfte Paket-/Dependency-Vorschläge	KI-Modelle schlagen plausible, aber teils nicht existierende oder veraltete Pakete vor	Schadcode durch gezielt platzierte Fake-Pakete oder bekannte Schwachstellen in veralteten Abhängigkeiten	Jedes neue Paket vor Installation bewusst prüfen (Existenz, Verbreitung, Herkunft), automatisierte Dependency-Scans einsetzen
Plausibel wirkende, aber fehlerhafte Logik	Generierter Code liest sich oft sauberer und selbstbewusster, als er tatsächlich ist – Reviewer:innen prüfen dadurch tendenziell weniger kritisch	Business-Logik-Fehler, die erst im Betrieb auffallen, laut Analyse rund 75 % häufiger als bei menschlich geschriebenem Code	Automatisierte Tests gegen definiertes Sollverhalten, menschliches Review mit Fokus auf Architektur statt nur auf Syntax
Fehlende Nachvollziehbarkeit	Ohne Kennzeichnung verschwimmt, welcher Code geprüft wurde und welcher nicht	Im Vorfall unklar, was passiert ist und wer wofür verantwortlich ist	Herkunft und Freigabe jeder Änderung dokumentieren (Commit-Historie, Review-Log)

Eigene Risikomatrix Philogic Labs, abgeleitet aus dokumentierten Vorfällen (Lovable, Replit) und der CodeRabbit-Analyse zu KI-Code-Qualität.

Welche Qualitätsgates braucht Produktion?

Die CodeRabbit-Analyse von 470 Pull Requests – 320 davon KI-mitverfasst, 150 rein menschlich – liefert eine nüchterne Zahl zur Einordnung: KI-mitverfasste Änderungen enthielten im Schnitt 10,83 Probleme pro Pull Request gegenüber 6,45 bei rein menschlichen, ein Faktor von 1,7. Bei Sicherheitsproblemen war der Unterschied noch größer: 2,74-mal mehr Sicherheitslücken, darunter 1,88-mal mehr unsichere Passwort-Behandlung, 1,91-mal mehr unsichere Objektreferenzen und 2,74-mal mehr XSS-Schwachstellen. Die Studie selbst zieht daraus die passende Schlussfolgerung: Qualität entsteht nicht automatisch, auch nicht mit KI-Werkzeugen – sie braucht bewusste Prüfschritte.

Für den Sprung von Prototyp zu Produktion sind aus meiner Erfahrung fünf Gates nicht verhandelbar:

1. Automatisierte Tests und Linter als Basis. Ohne automatisierte Prüfung bleibt jede Aussage über Codequalität eine Meinung. Tests müssen das eigentliche Verhalten prüfen, nicht nur, ob der Code kompiliert.
2. Ein gezieltes Sicherheits-Review für Authentifizierung und Datenzugriff. Nicht als Teil des allgemeinen Reviews, sondern als eigener Schritt mit der Frage: Wer darf was sehen und ändern, und ist das technisch erzwungen – nicht nur in der Oberfläche verborgen?
3. Getrennte Entwicklungs- und Produktionsumgebungen. Genau die Lücke, die im Replit-Vorfall zum Datenverlust führte. Ein Agent oder Entwickler, der in der Entwicklungsumgebung experimentiert, darf technisch keinen Zugriff auf Produktivdaten haben.
4. Menschliches Review mit Blick auf Architektur, nicht nur Syntax. KI-generierter Code wirkt oft überdurchschnittlich aufgeräumt und selbstbewusst – ein Effekt, der Reviewer:innen dazu verleiten kann, weniger kritisch zu prüfen. Die Gegenfrage lautet: Passt die Änderung zum bestehenden System, öffnet sie eine neue Angriffsfläche, verändert sie eine Schnittstelle, auf die andere Teile sich verlassen?
5. Dokumentierte Freigabe-Entscheidung. Wer hat wann was geprüft und freigegeben – nachvollziehbar im Versionskontrollsystem, nicht nur im Gedächtnis Einzelner.

Diese Gates sind kein Gegensatz zu KI-gestützter Entwicklung – sie sind die Voraussetzung dafür, dass ihr Geschwindigkeitsvorteil nicht durch nachträgliche Vorfälle und Aufräumarbeiten aufgefressen wird. Ein Team, das Vibe Coding für Prototypen nutzt und diese fünf Gates vor dem produktiven Einsatz konsequent durchsetzt, bekommt beides: Tempo in der Explorationsphase, Kontrolle vor dem Ernstfall.

Wie überführt man Prototypen in Produktion?

Der häufigste Fehler beim Übergang ist, den Prototyp-Code einfach weiterzubauen, bis er „fertig genug” aussieht. Das ist der teuerste Weg, weil sich Sicherheits- und Architekturlücken dabei mit jeder neuen Funktion vermehren, statt einmal gezielt geschlossen zu werden. Der belastbarere Weg läuft in vier Schritten:

Erstens: Den Prototyp als Anforderungsquelle behandeln, nicht als Startpunkt für Produktivcode. Was funktioniert hat, was Nutzer verstanden haben, welche Abläufe sich bewährt haben – das ist der eigentliche Wert des Prototyps. Der konkrete Code ist dabei sekundär.

Zweitens: Auth- und Datenmodell gezielt neu bewerten. Genau hier entstehen laut den oben beschriebenen Vorfällen die teuersten Lücken. Bevor irgendein Feature weitergebaut wird: Wer darf welche Daten sehen, ändern, löschen – und ist das technisch erzwungen, nicht nur in der Oberfläche verborgen? Diese Prüfung lohnt sich, bevor die erste echte Nutzerin oder der erste echte Nutzer Zugriff bekommt.

Drittens: Fehlerbehandlung und Testabdeckung gezielt nachrüsten. Prototypen haben typischerweise keine oder kaum Fehlerbehandlung, weil sie unter Idealbedingungen vorgeführt werden. Produktion bedeutet: ausgefallene Schnittstellen, ungültige Eingaben, gleichzeitige Zugriffe – alles, was in der Demo nie passiert, aber im Alltag garantiert vorkommt.

Viertens: Umgebungen trennen und Betrieb einrichten, bevor der erste echte Datensatz entsteht. Getrennte Entwicklungs- und Produktionsumgebung, Backups, ein Weg, Fehler zu melden, und eine benannte Person mit Betriebsverantwortung. Ohne diesen Schritt bleibt jedes noch so sauber geprüfte System ownerlos – und genau das war laut Berichterstattung auch beim Replit-Vorfall ein Teil des Problems: Die Trennung zwischen Test- und Produktivsystem fehlte technisch, nicht nur organisatorisch.

Wie viel davon in eine bestehende Codebasis passt und was komplett neu aufgesetzt werden sollte, lässt sich selten pauschal beantworten – das hängt vom Umfang der Prototyp-Logik und der Kritikalität der Daten ab. Wenn intern die Erfahrung fehlt, diese Einschätzung selbst zu treffen, ist genau das eine der Fragen, die sich in einem kurzen Erstgespräch klären lässt, bevor ein Prototyp unter Zeitdruck produktiv geschaltet wird.

Umsetzung: Vibe Coding im Team verantwortlich einsetzen

Statt Vibe Coding pauschal zu verbieten oder unreflektiert zuzulassen, hat sich in der Praxis eine klare Trennung nach Einsatzzweck bewährt:

Explorationsphase – Vibe Coding erlaubt, mit einer harten Grenze. Prototypen, Konzeptstudien, interne Experimente dürfen schnell und ungeprüft entstehen – unter der Bedingung, dass sie nie mit echten Nutzerdaten oder Produktivsystemen verbunden werden. Diese Grenze technisch durchzusetzen (getrennte Umgebungen, keine Produktivzugänge) ist wirksamer als sie nur zu kommunizieren.

Übergangspunkt – ein bewusstes Gate, keine schleichende Migration. Der Moment, an dem ein Prototyp „eigentlich schon fast produktiv” wirkt, ist genau der Moment, an dem die fünf Qualitätsgates von oben greifen müssen. Am besten mit einer expliziten Entscheidung: „Dieses System geht jetzt in den Produktionspfad” – nicht durch stillschweigendes Weiterbenutzen.

Produktion – die fünf Gates sind Standard, keine Ausnahme. Für alles, was echte Nutzerdaten verarbeitet, gelten Tests, Sicherheits-Review, Umgebungstrennung, menschliches Architektur-Review und dokumentierte Freigabe unabhängig davon, wie der Code entstanden ist – ob mit, ohne oder mit viel KI-Unterstützung geschrieben.

Für Teams, die noch keine klare Linie zwischen diesen drei Phasen haben, sind strukturierte Schulungen oft der schnellste Weg, um Grundverständnis für die Risiken bei Auth und Datenzugriff aufzubauen, bevor der nächste Prototyp entsteht. Wenn es um konkrete Architektur- oder Scope-Fragen bei einem bestehenden Vibe-Coding-Projekt geht, das produktiv werden soll, ist das eine der Situationen, für die unsere KI-Beratung gedacht ist – mit Fokus auf Architektur- und Prozessfragen, nicht auf allgemeine KI-Strategie.

Risiken & Grenzen

Ehrlich zu Ende gedacht, gehört zu diesem Thema auch, was dieser Artikel nicht leisten kann:

• Keine der genannten Zahlen ist eine Garantie für dein Projekt. Die CodeRabbit-Analyse misst 470 Open-Source-Pull-Requests; wie sich das Verhältnis in deiner Codebasis mit deinem Tool, deiner Testabdeckung und deinem Team darstellt, weißt du nur, wenn du selbst misst.
• Die dokumentierten Vorfälle sind Einzelfälle, kein statistischer Durchschnitt. Sie zeigen, dass die Risiken real und folgenreich sind – nicht, wie häufig sie im Verhältnis zu unauffälligen Projekten auftreten.
• Nicht jedes Risiko lässt sich technisch vollständig ausschließen. Auch mit allen fünf Qualitätsgates bleibt ein Restrisiko – das Ziel ist, es auf ein vertretbares Maß zu senken, nicht auf null.
• Rechtlicher Rahmen ist in Bewegung (Stand Juli 2026, keine Rechtsberatung). Wer personenbezogene Daten verarbeitet, muss unabhängig von der Entstehungsweise des Codes die üblichen datenschutzrechtlichen Anforderungen erfüllen; bei konkreten Compliance-Fragen gehört das Thema zu Rechtsberatung oder Datenschutzbeauftragten.
• Dieser Artikel ersetzt keine Prüfung deines konkreten Systems. Er beschreibt Muster und Gegenmaßnahmen – ob dein Prototyp die beschriebenen Lücken tatsächlich hat, klärt nur eine Prüfung an deinem echten Code und deiner echten Datenbank.

Checkliste: Vibe Coding verantwortlich einsetzen

1. Wir wissen, welche unserer aktuellen Vibe-Coding-Projekte noch reine Prototypen sind und welche bereits echte Nutzerdaten oder Zahlungsdaten verarbeiten.
2. Prototypen ohne Produktivbezug laufen in technisch getrennten Umgebungen ohne Zugriff auf echte Systeme.
3. Für jedes System mit echten Nutzerdaten sind Zugriffsregeln explizit geprüft und pro Rolle mit einem eigenen Testfall verifiziert – nicht nur über die Oberfläche getestet.
4. Coding-Agenten mit selbstständiger Mehrschritt-Aktion haben technisch eingeschränkte Rechte, keine reine Anweisung als Schranke.
5. Neue, KI-vorgeschlagene Softwarepakete werden vor der Installation bewusst geprüft, nicht automatisch übernommen.
6. Automatisierte Tests und Linter laufen gegen jede Änderung, bevor sie in Produktion geht.
7. Es gibt ein menschliches Review, das den architektonischen Zusammenhang bewertet, nicht nur die Diff-Zeilen.
8. Herkunft und Freigabe jeder produktiven Änderung sind nachvollziehbar dokumentiert.
9. Der Übergang vom Prototyp zur Produktion ist eine bewusste Entscheidung mit den fünf Qualitätsgates, keine schleichende Weiterentwicklung.
10. Es gibt eine benannte Person mit Betriebsverantwortung, bevor das System echte Daten verarbeitet.

Die Auswahl des passenden Formats für den Einstieg – Prototyp, Proof of Concept oder MVP – und den Weg zum ersten produktiven KI-Baustein vertiefen die weiteren Artikel im Cluster KI-Softwareentwicklung.