# Das Tempo verfliegt. Die Komplexität bleibt.

> Drei unabhängige Studien, drei verschiedene Methoden — eine gezielte Schwachstellenstudie, ein kontrollierter Mensch-Modell-Vergleich und eine einjährige Untersuchung realer Repositories — kommen zum selben Befund: KI-generierter Code trägt messbare Qualitätskosten, die den Produktivitätsgewinn überdauern, mit dem sie kamen.

Source: https://counterproof.io/de/notes/das-tempo-verfliegt-die-komplexitaet-bleibt/ · Published 25 August 2026 · CounterProof ist eine Praxis der Clavestra Capital Limited (Malta, C 113987).


„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*](https://counterproof.io/notes/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*](https://counterproof.io/notes/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](https://research.counterproof.io/) (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.*