„KI schreibt Code schneller" ist unstrittig. Ob sie Code schlechter schreibt, ist eine eigene, empirische Frage — und wir beantworten sie lieber aus Messungen als aus den Talking Points irgendeiner Seite. Drei unabhängige Studien, mit drei verschiedenen Methoden, konvergieren auf dieselbe Antwort.
Die Grundlinie: eine dokumentierte Defektrate
Die Gründungsstudie behandeln wir ausführlich in A Clean Benchmark Is Not a Clean Codebase (auf Englisch): Pearce et al. (IEEE S&P 2022) fanden rund 40 % von 1.689 Copilot-generierten Programmen verwundbar gegenüber den Schwachstellenklassen der MITRE Top 25. Die Studie ist inzwischen alt genug, dass ihre Zahl nicht als aktuell gelesen werden sollte — die Modelle haben sich seit 2022 verändert. Was sie etabliert hat, und worauf spätere Arbeiten aufbauen: Die Frage ist real und mit Standardmethoden beantwortbar — gezielte Szenarien, eine große Stichprobe, statische Analyse gegen eine benannte Schwachstellenliste.
Der Mechanismus: keine zufälligen Bugs, sondern eine systematische Abwesenheit
Eine Zahl allein sagt nicht, was man dagegen tut. Ein kontrollierter Vergleich von menschengeschriebenem und LLM-generiertem Code über Datenstrukturen, Algorithmen, kryptografische Routinen und LeetCode-artige Aufgaben — mit Unit-Tests, Fuzzing und statischer Analyse (arXiv:2409.19182) — ging weiter und fand: LLM-generierter Code ist vor allem deshalb weniger sicher, weil ihm defensive Programmierkonstrukte fehlen — die Bereichsprüfungen und Eingabevalidierungen, die ein sorgfältiger Ingenieur aus Gewohnheit hinzufügt, nicht das Feature, nach dem tatsächlich gefragt wurde. Genau diese Abwesenheit lädt Puffer- und Integer-Überläufe ein. Unter Fuzzing neigte LLM-generierter Code stärker zu Hängern und Abstürzen als die menschengeschriebene Vergleichsbasis. Korrektheitsfehler konnten subtil statt offensichtlich sein: In einem Fall erzeugte das Modell eine fehlerhafte SHA-1-Implementierung, die dennoch sauber kompilierte — falsch, und still darüber.
Der Befund, der jeden beunruhigen sollte, der „frag das Modell, es soll es reparieren" für ein Sicherheitsnetz hält: Dieselbe Studie baute eine Rückkopplungsschleife und bat das Modell, Code neu zu generieren und Probleme zu beseitigen, die ihm gerade gezeigt worden waren. Das funktionierte nicht zuverlässig. In manchen Fällen gelang die Korrektur. In anderen enthielt der „reparierte" Code neue Probleme — und in einigen Fällen brachte der Akt des Promptens Probleme in Dateien, die vor dem Prompt sauber gewesen waren. Den Autor seine eigenen Hausaufgaben benoten zu lassen, ist kein Review.
Die Produktionsevidenz: Die Kosten verfliegen nicht mit der Neuheit
Die jüngste Evidenz kommt ganz von außerhalb des Labors. Eine Studie verfolgte 807 Open-Source-Repositories auf GitHub, die zwischen Januar 2024 und März 2025 den KI-Coding-Assistenten Cursor einführten, gegen eine Kontrollgruppe von 1.380 vergleichbaren Repositories ohne ihn — mit SonarQube als Messinstrument für statische Analysewarnungen, Duplikation und Komplexität, bis August 2025. Die Produktivitätsgeschichte verlief wie erwartet: ein kurzlebiger Anstieg bei Commits und hinzugefügten Zeilen in den ersten ein bis zwei Monaten, zurück auf die Grundlinie im dritten Monat. Die Qualitätskosten verflogen nicht mit. Statische Analysewarnungen stiegen nach der Einführung um rund 30 % und blieben erhöht. Die Codekomplexität stieg um mehr als 40 % — mehr, als das Wachstum der Codebasis allein erklären würde. Der Geschwindigkeitsgewinn war vorübergehend. Die Schuld nicht.
Eine ehrliche Grenze
Das ist keine Behauptung, KI-generierter Code sei immer schlechter, als Pauschalgesetz. Aufgabe, Modell und Arbeitsweise zählen alle — und ein Team, das KI-Ausgaben als ersten Entwurf behandelt, der dieselbe Review-Disziplin verdient wie der Pull Request eines Junior-Ingenieurs, sieht andere Ergebnisse als ein Team, das sie ungeprüft ausliefert. Die Studien oben testen nicht jedes Modell und nicht jede Arbeitsweise, und keine isoliert Review-Disziplin als Variable. Was sie konsistent etablieren, über drei unabhängige Methoden hinweg (gezielte CWE-Tests, kontrollierter Vergleich, longitudinale Produktionsdaten): Der Effekt ist real und systematisch statt gelegentlich — und das Modell seine eigene Arbeit prüfen zu lassen, ersetzt nicht, dass es jemand anderes tut.
Warum das eine Compliance-Frage ist, nicht nur eine Ingenieursfrage
Nach dem Cyber Resilience Act muss ein Hersteller sicherstellen, dass Produkte mit digitalen Elementen „so konzipiert, entwickelt und hergestellt [werden], dass sie angesichts der Risiken ein angemessenes Cybersicherheitsniveau gewährleisten" und „ohne bekannte ausnutzbare Schwachstellen" auf dem Markt bereitgestellt werden (Verordnung (EU) 2024/2847, Anhang I Teil I Nummern 1 und 2 Buchstabe a). Keine der beiden Klauseln erwähnt, wie der Code geschrieben wurde. Beide werden schwerer, nicht leichter zu erfüllen, je mehr der Fläche einer Codebasis von einem Prozess erzeugt wurde, der eine gemessene, systematische Lücke genau in den Konstrukten hat — Bereichsprüfungen, Eingabevalidierung —, die eine bekannte Schwachstellenklasse davon abhalten, ausnutzbar zu werden. Schnellere Generierung ohne entsprechend mehr Review ist keine Abkürzung um diese Pflicht herum. Es ist ein wachsender Abstand zu ihr.
Warum uns das angeht
Bei CounterProof machen wir adversarielles Review maschinengeschriebenen Codes, und diese drei Studien beschreiben genau die Lücke, für deren Schließung unsere Praxis existiert: KI-Ausgaben — generierend wie prüfend — als Behauptung zu behandeln, die zu prüfen ist, nicht als Ergebnis, dem zu vertrauen ist. Siehe das Begleitstück A Clean Benchmark Is Not a Clean Codebase (auf Englisch) dazu, was passiert, wenn auch das Prüfwerkzeug KI-basiert ist und seine eigene Zuverlässigkeit ungeprüft bleibt. Das längere Argument, einschließlich der konditionalen Form jeder Behauptung oben, steht in unserem Arbeitspapier über Kollation und Provenienz für maschinengenerierten Text, hier vollständig lesbar (auf Englisch). Es ist ein Preprint-Entwurf, nicht peer-reviewed, und sagt das auch.
Die oben zitierten Quellen wurden gegen ihre veröffentlichten Abstracts geprüft. Die Zahl von Pearce et al. stammt aus IEEE S&P 2022 und beschreibt Copilot zum Zeitpunkt jener Studie, nicht aktuelle Modelle. Die Cursor-Zahlen stammen aus einer Längsschnittstudie über 807 Repositories gegen eine Kontrollgruppe von 1.380, verfolgt von Januar 2024 bis August 2025. Zitierte CRA-Bestimmungen beziehen sich auf Verordnung (EU) 2024/2847 und wurden gegen den Wortlaut der amtlichen deutschen Sprachfassung geprüft. Diese Seite ist eine Übersetzung des englischen Originals; bei Abweichungen gilt das Original. Wenn hier etwas falsch ist, korrigieren wir es schriftlich auf dieser Seite.