Ein Feature ist fertig. Tests grün, Demo läuft, der PR ist durch. Irgendwo in der Codebasis steckt ein Auth-Flow, den niemand wirklich gelesen hat — er kam aus dem Modell, er funktionierte, also wurde er gemergt. Andrej Karpathy hat für diesen Zustand drei Wörter gefunden, die präziser sind als jede Warnung: forget that the code even exists1. Das ist keine Nachlässigkeit. Das ist das Produkt. Genau dort beginnt das Problem — nicht weil KI schlechten Code schreibt, sondern weil sie guten schreibt und das Vergessen zur Funktion macht.
Was Karpathy wirklich angeboten hat
Karpathys ursprüngliches Framing war ehrlich: ein Wochenendprojekt, ein Hobby, ein Experiment. Code, der nicht zählt, weil er nie irgendwo ankommt, wo er zählen müsste. Er hat damit etwas Reales beschrieben — den kognitiven Zustand, in dem Entwicklung Spaß macht, weil sie keinen Verantwortungsschmerz produziert. Niemand schaut auf den Auth-Flow. Niemand fragt, woher die Library kommt. Niemand muss in drei Monaten den Code lesen, den er heute geschrieben hat.
Das ist legitim. Für Prototypen, Wegwerf-Skripte, Lern-Sessions, interne Tools ohne sensible Daten — perfekt. Karpathy hat später selbst klargestellt, dass das nicht das ist, was er als professionelle KI-unterstützte Entwicklung versteht1.
Der Punkt ist nicht, dass jemand Vibe Coding erfunden hat. Der Punkt ist, was passiert, wenn dieser kognitive Zustand in Kontexte übertragen wird, in denen er nicht mehr stimmt. Wenn der Code plötzlich doch existiert, weil er produktiv läuft, Kundendaten verarbeitet, abgerechnet wird. Und niemand hat den Wechsel bemerkt.
Der Mechanismus: Guter Output deaktiviert den Prüfinstinkt
Das ist der Kern. Nicht schlechter Code ist das eigentliche Risiko.
Schlechter Code wird erwischt. Er kompiliert nicht, er bricht in Tests, er sieht falsch aus. Das System funktioniert noch — der Prüfinstinkt schlägt an, der Code wird gelesen, verstanden, korrigiert oder verworfen. Das ist der Normalzustand von Entwicklung mit menschlichem Review.
Gefährlich wird Code, der kompiliert. Tests grün. Feature liefert. In diesem Moment fühlt sich Review wie Bremse an, nicht wie Pflicht. Wer trotzdem Zeile für Zeile durchgeht, wirkt wie der Kollege, der nicht versteht, dass es funktioniert. Das ist die Stelle, an der kompetente Teams aufhören zu prüfen — nicht aus Fahrlässigkeit, sondern weil Gewissheitsgefühl entsteht. Die KI deaktiviert den Prüfinstinkt nicht durch schlechten Output. Sie deaktiviert ihn durch guten.
Simon Willison hat dafür eine Faustregel formuliert, die ich für die präziseste in der ganzen Debatte halte: keinen Code committen, den man nicht einer anderen Person vollständig erklären könnte2. Das ist keine Methodologie, kein Framework, keine Checkliste. Es ist eine einzige Frage, die den ganzen Unterschied trägt — und die in dem Moment, in dem Code einfach läuft, unbequem wird.
Genau deshalb ist sie der Maßstab.
Was ungeprüft bleibt: Technisch und rechtlich
Was passiert, wenn der Prüfinstinkt deaktiviert ist, lässt sich messen.
Veracode hat 2025 über hundert verschiedene Sprachmodelle gegen achtzig Coding-Aufgaben getestet. Ergebnis: 45 % des generierten Codes enthielt Schwachstellen aus den OWASP Top 103. Was diesen Befund schlagkräftig macht, ist die Trendlinie dahinter — die Syntaxkorrektheit der Modelle ist über die Zeit auf über 90 % gestiegen. Die Sicherheitsperformance ist nicht gestiegen. Größere Modelle produzieren keinen sichereren Code, sondern sauberer aussehenden unsicheren Code.
Das ist der Mechanismus in Daten: Was schöner aussieht, wird weniger geprüft. Was weniger geprüft wird, geht durch.
Rechtlich ist die Lage in einem Punkt überraschend klar — und in den meisten Teams überraschend wenig diskutiert. Haftung liegt beim deployenden Unternehmen, nicht beim KI-Anbieter4. Alle großen Anbieter schließen Garantien für generierten Code in ihren Nutzungsbedingungen aus. Wer den Output in ein Produkt schiebt, übernimmt ihn vollständig — mit allem, was daran hängt. Urheberrecht und Lizenzfragen sind dabei eigene Baustelle: Rein KI-generierter Code genießt in den USA keinen Urheberrechtsschutz, und die Frage, ob ein Modell beim Training fremde Lizenzen kontaminiert hat, ist prozessual noch offen5. Der EU Cyber Resilience Act greift dabei unabhängig davon, wie der Code entstanden ist — Secure-by-Design, Risikoanalyse, fünf Jahre Security-Updates. KI-generierte Compliance-Dokumentation schützt nicht vor tatsächlichem Risiko6.
Das alles passiert nicht, weil KI-Code juristisch radioaktiv wäre. Es passiert, weil niemand mehr hinschaut.
Was organisatorisch bricht: Ownership und die Schnitzeljagd
Das vielleicht gefährlichste Risiko ist das, über das am wenigsten geschrieben wird, weil es sich am schwersten in eine Statistik packen lässt.
Wenn dieselbe KI Code generiert und validiert, entsteht Schein-Review7. Es gibt keine Separation of Duties mehr — der Generator ist auch der Reviewer, und beides ist derselbe statistische Prozess. Die Validierung sagt nicht, ob der Code richtig ist. Sie sagt, ob die Validierung wahrscheinlich richtig wäre. Das ist nicht dasselbe.
Ownership fragmentiert sich. Der Prompt kam von Person A, die KI hat den Code geschrieben, Person B hat ihn gemergt, Service C ist jetzt zuständig — und niemand kann den Code wirklich erklären, weil niemand ihn geschrieben hat. Wenn etwas bricht, beginnt eine Schnitzeljagd durch eine Codebasis, in der niemand ein mentales Modell hat.
Addy Osmani beschreibt einen Fall, der das gut illustriert: ein KI-generierter Auth-Flow, der initial funktionierte, sauber aussah, durch die Tests lief. Beim Versuch, ihn für neue Rollen und regionsspezifische Datenschutzregeln zu erweitern, kollabierte er vollständig. Rewrite von Grund auf, weil niemand die Logik verstand — auch nicht die Leute, die ihn ursprünglich „geschrieben” hatten8.
Das ist kein Randfall. Das ist das strukturelle Ergebnis von Code ohne mentales Modell. Code, den niemand vergessen müsste, weil ihn niemand je wirklich erinnert hat.
Die Linie: Assistenz versus Blindflug
An dieser Stelle wird oft pauschal. Soll man jetzt keine KI mehr beim Coden verwenden? Doch. Selbstverständlich.
Vibe Coding für Prototypen, interne Wegwerf-Tools, Spike-Lösungen, Lernkontexte — genau richtig. Da ist Karpathys ursprüngliches Framing exakt am Platz. Der Unterschied liegt nicht im Tool, er liegt in Kritikalität und Kontext. Fraunhofer IESE formuliert das nüchtern: Die Risiken skalieren mit der Bedeutung der Anwendung9.
Die Linie ist operational, nicht ideologisch:
KI als Hebel für Boilerplate, Refactoring, Test-Generierung, Doku-Gerüste, schnelle Recherche im eigenen Code — ja. Da, wo der Mensch den Output liest, versteht und im Zweifel auch ohne KI hätte hinschreiben können, ist KI das, was sie sein sollte: ein schnelles Werkzeug.
Generierten Code in Produktion deployen, ohne ihn vollständig zu verstehen — nein. Nicht weil die KI etwas Böses tut, sondern weil in diesem Moment niemand mehr die Verantwortung hält, die juristisch und operativ trotzdem irgendwo liegt. Sie wandert nicht zur KI. Sie wandert zu dem, der deployed hat — auch wenn der nicht mehr weiß, was er deployed hat.
Willisons Frage ist der Maßstab: Könntest du diesen Code einem Kollegen erklären? Wenn nein, hast du gerade nicht KI-unterstützt entwickelt. Du hast vibe-gecoded. Das ist okay, solange du das auch weißt — und solange der Code dort landet, wo das in Ordnung ist.
Schluss
Die Zukunft gehört nicht den Teams, die am meisten KI-Code erzeugen. Sondern denen, die Geschwindigkeit und Ownership gleichzeitig halten — weil sie verstehen, dass das eine ohne das andere kein Vorteil ist, sondern aufgeschobene Schulden.
Vielleicht der ehrlichste Test, den man im eigenen Team machen kann: einmal mit Willisons Frage durch die Codebasis gehen. Gibt es Code, den niemand im Team vollständig erklären könnte? Wenn ja, ist die Linie nicht eine Frage für die Zukunft. Sie ist schon überschritten.
Karpathy hat es nicht falsch beschrieben. Er hat es zu gut beschrieben. Forget that the code even exists ist genau das, was passiert — auch dort, wo der Code sehr wohl existiert. Und sich später erinnert.
Footnotes
-
Not all AI-assisted programming is vibe coding (but vibe coding rocks) – Simon Willison ↩
-
AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks – Veracode ↩
-
AI-generated code and vibe coding: copyright, licensing, and legal risks – DNA Partners ↩
-
Navigating the Legal Landscape of AI-Generated Code – MBHB ↩
-
When the Vibes Are Off: The Security Risks of AI-Generated Code – Lawfare ↩
-
Vibe coding is not the same as AI-Assisted engineering – Addy Osmani ↩
-
Vibe Coding verstehen: Definition, Potenziale und Risiken – Fraunhofer IESE ↩