In über 5.600 produktiv eingesetzten, mit KI generierten Anwendungen hat das Sicherheitslabor Escape.tech Ende 2025 mehr als 2.000 Schwachstellen, über 400 offen im Code liegende Secrets und 175 Fälle von exponierten personenbezogenen Daten gefunden. Diese Anwendungen wurden nicht in einer Forschungsumgebung erzeugt, sondern in Unternehmen, in denen sie Kunden und Geschäftsprozesse bedienen. Sie sind die statistische Spur eines Arbeitsstils, den Andrej Karpathy am 2. Februar 2025 als Vibe Coding bezeichnet hat: einer KI in natürlicher Sprache sagen, was die Software tun soll, und den generierten Code übernehmen, ohne ihn Zeile für Zeile zu prüfen. „Forget that the code even exists", schrieb Karpathy in seinem ursprünglichen Tweet.
Für viele Teams ist daraus ernsthafte Praxis geworden. Funktionierende Prototypen entstehen in Stunden statt Tagen. Gleichzeitig häufen sich Berichte, in denen genau diese Schnelligkeit Folgekosten produziert, die in klassischer Softwareentwicklung erst nach Jahren auftauchen. Für Unternehmen, die Software nicht zum Spaß bauen, sondern damit Geschäft betreiben, ist die Frage deshalb nicht, ob Vibe Coding „erlaubt" ist. Die Frage ist, unter welchen Bedingungen Vibe Coding Software hervorbringt, die mehr als 18 Monate Bestand hat und welche Bedingungen das nicht erfüllen.
Was Vibe Coding genau ist und was nicht
Vibe Coding beschreibt eine konkrete Arbeitsweise mit Coding-Agenten wie Cursor, Claude Code oder GitHub Copilot: Die Person am Rechner beschreibt das Ziel, akzeptiert den vorgeschlagenen Diff weitgehend ungeprüft, kopiert Fehlermeldungen direkt zurück in den Chat und lässt das Modell so lange iterieren, bis es läuft. Code wird zur Black Box.
Davon abzugrenzen ist „KI-gestützte Softwareentwicklung" im weiteren Sinn. Wer mit einem Modell paart, jeden Vorschlag liest, Tests fordert, Sicherheitsfragen stellt und Architekturentscheidungen selbst trifft, vibe-codet nicht. Der Unterschied ist nicht akademisch. Er entscheidet, welche Software am Ende auf einem Produktivsystem läuft.
Was „guter Code" in Enterprise-Software ausmacht
„Funktioniert" ist die niedrigste denkbare Schwelle. Sie ist notwendig, aber weit entfernt davon, ausreichend zu sein. Guter Code in einer Enterprise-Umgebung wird an Kriterien gemessen, die in den ersten Wochen nach Auslieferung kaum sichtbar sind und in den darauffolgenden Jahren über die Wirtschaftlichkeit eines Systems entscheiden.
Sechs Eigenschaften tragen die meiste Last. Wartbarkeit heißt, dass ein Entwickler, der nicht der ursprüngliche Autor ist, den Code in vertretbarer Zeit versteht und ändern kann, ohne anderes zu zerstören. Testbarkeit bedeutet, dass Funktionen isoliert geprüft werden können und Regressionen automatisch auffallen. Sicherheit verlangt mindestens den OWASP-Top-10-Standard, keine Geheimnisse im Quellcode und validierte Eingaben. Performance unter realer Last entsteht aus einem tragfähigen Datenmodell, gesetzten Indexen und erkannten N+1-Mustern. Beobachtbarkeit liefert Logs, Metriken und Traces, mit denen Fehler im Produktivbetrieb gefunden werden, bevor Kunden anrufen. Compliance-Tauglichkeit schließlich verlangt, dass DSGVO, BFSG und branchenspezifische Vorgaben (ISO 27001, BaFin-Anforderungen, MDR im Medizinprodukte-Umfeld) bei Architektur und Datenflüssen mitgedacht und nicht nachträglich draufgeschraubt werden.
Diese Kriterien sind nicht „nice to have". Sie sind das, was eine Software von einem funktionierenden Prototyp zu einem belastbaren Geschäftsasset macht.
Wo Vibe Coding und gute Software auseinanderlaufen
Vibe Coding ist hervorragend darin, das erste Kriterium („funktioniert") zu erreichen. Die anderen sechs erreicht es regelmäßig nicht, und der Grund ist strukturell.
Die Sicherheitsdaten sind inzwischen belastbar. Die genannte Escape.tech-Auswertung an 5.600+ produktiv eingesetzten KI-generierten Anwendungen ist nur ein Baustein. Der Veracode 2025 GenAI Code Security Report stellt fest, dass von KI mitgeschriebener Code im Schnitt das 2,74-Fache an Sicherheitslücken aufweist wie rein menschlicher Code. Der CodeRabbit-Report „State of AI vs Human Code Generation" (Dezember 2025) findet zusätzlich 75 Prozent mehr logische und Korrektheits-Fehler in KI-Code. Und das Sicherheitsunternehmen Apiiro hat unter dem Titel „4x Velocity, 10x Vulnerabilities" einen Anstieg der monatlich entdeckten Schwachstellen in Fortune-50-Unternehmen von rund 1.000 auf über 10.000 zwischen Dezember 2024 und Juni 2025 dokumentiert. Verzehnfachung in sechs Monaten. Das ist keine statistische Schwankung, das ist eine Größenordnung.
Auch jenseits der Sicherheit verschiebt sich das Bild. Die Langzeit-Analyse von GitClear über 211 Millionen Code-Änderungen aus den Jahren 2020 bis 2024 zeigt einen Kollaps der Code-Pflege: Der Anteil bewussten Refactorings ist von 24,1 Prozent der geänderten Zeilen in 2020 auf 9,5 Prozent in 2024 gefallen. Die Zahl identischer Code-Blöcke hat sich im selben Zeitraum auf das Achtfache erhöht. Übersetzt heißt das: Es wird mehr Code geschrieben, aber weniger Code aufgeräumt. Was wie Beschleunigung aussieht, ist häufig vorgezogene technische Schuld. Die Rechnung kommt später.
Der inhaltliche Grund ist einfach. Wer Code nicht liest, kann ihn nicht bewerten. Eine erfahrene Entwicklerin trifft in einer einzigen Stunde Dutzende kleiner Architektur- und Designentscheidungen. Sie sieht eine Datenbankabfrage in einer Schleife, ahnt, dass das bei 50.000 Datensätzen die Seite reißt, und zieht den Query raus, bevor sie weiterschreibt. Das Modell hätte funktionierenden Code geliefert. Im Lasttest sechs Monate später hätte er das System gekostet. Vibe Coding ersetzt diese Entscheidungen nicht. Es überspringt sie.
Was das konkret für Enterprise-Software bedeutet
Enterprise-Software unterscheidet sich von einer Wochenend-App in drei Dimensionen: Sie läuft länger, sie wird von mehr Menschen weiterentwickelt, und ihre Ausfälle haben einen Preis. Genau in diesen drei Dimensionen entfaltet sich das Risiko von Vibe Coding.
Lebensdauer. In Versicherungs-IT laufen Provisionsabrechnungs- und Bestandssysteme regelmäßig zehn bis fünfzehn Jahre. Die ursprünglichen Entwickler sind längst nicht mehr im Haus. Ein in drei Wochen vibe-gecodeter MVP, der in dieser Welt ungeprüft in Produktion geht, durchläuft Hunderte Änderungen durch wechselnde Teams. Ohne Architektur-Dokumentation, ohne Tests und ohne klare Verantwortlichkeiten im Code wird jede Erweiterung teurer als die davor. Irgendwann kostet eine triviale Anpassung mehrere Personenwochen, und die Antwort lautet „lieber neu bauen". Das ist die Rückkehr der Wegwerf-Mentalität auf Systemebene.
Skalierung in der Organisation. Vibe Coding funktioniert, solange eine einzelne Person das Modell, den Kontext und die Auffälligkeiten im Kopf hat. Sobald ein zweites Team dazukommt, öffnet es die Datei und findet drei verschiedene Authentifizierungs-Patterns nebeneinander, sechs Endpunkte ohne Tests und einen Kommentar im Stil von „// works, don't touch". Ein Code, der für sich selbst keine Geschichte erzählt, lässt sich nicht onboarden. Er lässt sich verwalten, mit hohem Risiko.
Haftung und Compliance. Wer im regulierten Umfeld arbeitet (Finanzen, Gesundheit, kritische Infrastruktur), schuldet seinen Aufsichtsbehörden Nachweise: Wer hat welchen Code wann geschrieben, geprüft, freigegeben? Welche Risikoanalyse liegt einer Architekturentscheidung zugrunde? „Das Modell hat es so vorgeschlagen" ist kein gültiger Eintrag in einer Software Bill of Materials (SBOM). Ein gültiger Eintrag nennt Bibliothek, Version, Lizenz, bekannte CVEs und die verantwortliche Person, die diese Abhängigkeit ins System geholt hat. Diesen Eintrag liefert Vibe Coding strukturell nicht.
Wo Vibe Coding angemessen ist
Vibe Coding ist nicht das Gegenteil von guter Softwareentwicklung. Es ist ein Werkzeug mit einem klar umrissenen Anwendungsbereich.
Sinnvoll ist Vibe Coding für Prototypen, deren ausdrücklicher Zweck es ist, weggeworfen zu werden, für interne Skripte und Einmalwerkzeuge ohne Außenwirkung, für explorative Datenanalysen, in denen die Erkenntnis zählt und nicht der Code, und für schnelle UI-Mockups, die später ohnehin von einer Frontend-Entwicklerin neu gebaut werden. In all diesen Fällen entfällt der Großteil der oben genannten Anforderungen, weil die Software die Phase, in der sie wartbar sein müsste, nie erreicht.
Ein zweites legitimes Einsatzgebiet ist die Beschleunigung erfahrener Entwickler. Wer den Code in Sekunden bewertet, weil er ihn ohnehin selbst schreiben könnte, nutzt das Modell als Tastatur, nicht als Architekten. Das ist gelebte Realität in vielen Engineering-Teams und kein Vibe Coding mehr im engeren Sinn.
Was Entscheider daraus mitnehmen sollten
Der Anteil ungelesenen Codes in einer Auslieferung ist die Kennzahl, die heute in keinem Lastenheft steht und die spätere Wartungskosten besser vorhersagt als jede Story-Point-Schätzung. Frage danach. Wenn ein Dienstleister oder ein internes Team ein neues System ausliefert, ist eine legitime Frage: „Welcher Anteil dieses Codes wurde von einem Menschen gelesen, bevor er ins Repository gelangt ist?" Eine ehrliche Antwort liegt im niedrigen einstelligen Prozentbereich oder im hohen zweistelligen, und sie sagt dir mehr über das spätere Risiko als jeder Demo-Termin.
Zweitens: Verlange ein Test-, Sicherheits- und Architekturbild als Teil der Abnahme. Nicht „die App läuft" ist das Abnahmekriterium, sondern „die App läuft, hat eine dokumentierte Architektur, deckt die Kernpfade mit automatisierten Tests ab und ist gegen die OWASP-Top-10 geprüft". Das gilt unabhängig davon, ob KI im Spiel war.
Drittens: Trenne Spielwiese und Produktivsystem organisatorisch. Es ist sinnvoll, dass Teams mit Vibe Coding experimentieren, Prototypen bauen und schnelle Lernzyklen gehen. Es ist nicht sinnvoll, dass derselbe Code ohne weiteren Schritt in das System wandert, das morgen Kundendaten verarbeitet. Eine klare Promotion-Stufe zwischen Prototyp und Produktion (eigenes Repository, eigene Review-Pflicht, eigene Sicherheitsprüfung) ist die wirksamste Maßnahme, die du ohne Engineering-Hintergrund anordnen kannst.
Software, die Bestand hat, entsteht weiterhin durch Menschen, die wissen, was sie tun und warum. KI verkürzt ihre Wege, ersetzt sie aber nicht. Wer das verwechselt, kauft Schnelligkeit auf Kredit, und der Zins ist im Quellcode versteckt.
Wenn du gerade über eine größere Software-Entscheidung sitzt und unsicher bist, wo bei euch die Grenze zwischen sinnvoll beschleunigter und riskant entkernter Entwicklung verläuft, lohnt sich ein externer Blick, bevor der Code im Produktivsystem steht, nicht danach. Wie wir Enterprise-Software-Projekte gemeinsam mit Auftraggebern aufsetzen, beschreiben wir auf unserer Seite zu Enterprise Software, und wie wir eine tragfähige, dokumentierte Architektur planen, statt technische Schuld aufzubauen, in Systemarchitektur und Design.
Quellen:
- Karpathy, A. (2. Februar 2025): Tweet, x.com/karpathy/status/1886192184808149383.
- Escape.tech (Okt 2025): Methodology-Post zur Auswertung von 5.600+ KI-generierten produktiven Apps (escape.tech).
- Veracode (2025): GenAI Code Security Report — 2,74× mehr Sicherheitslücken in KI-Code.
- CodeRabbit (Dez 2025): State of AI vs Human Code Generation — 75 % mehr Logik-/Korrektheits-Fehler.
- Apiiro (2025): „4x Velocity, 10x Vulnerabilities" — Anstieg monatlicher Schwachstellen in Fortune-50-Unternehmen Dez 2024 – Jun 2025.
- GitClear (2025): AI Assistant Code Quality Research, 211 Mio. Code-Änderungen 2020–2024 (gitclear.com).