Neun verbreitete Annahmen über KI-Codebasen, einzeln geprüft

Neun Behauptungen zur Kontrolle einer KI-gebauten Codebasis kursieren gerade breit. Wir haben jede gegen unser eigenes Prüfregister und gegen externe Quellen geprüft. Fünf hielten sauber stand, zwei mit einer Korrektur, eine übersteht die Prüfung gar nicht und eine zerfällt am Eigeninteresse der eigenen Quelle.

Rat zur Kontrolle einer KI-gebauten Codebasis kursiert gerade breit. Wir haben neun besonders häufig wiederkehrende Behauptungen geprüft. Jede haben wir gegen unser eigenes Repository und gegen externe Quellen geprüft.

Tabelle 1: Neun Behauptungen, unser Urteil zu jeder.

1. Behauptung: KI-Codebasen verschlechtern sich schnell, wenn niemand hinschaut

Abbildung 1: Mehr Duplizierung, weniger Refactoring: die Wand hinter der ersten Behauptung.

Bild maschinell erzeugt

Diese hält stand, jetzt mit Zahlen dahinter. GitClear hat 211 Millionen Codezeilen über den Umstieg auf KI-gestütztes Programmieren hinweg untersucht. Der Anteil kopierter Zeilen stieg von 8,3 % aller geänderten Zeilen auf 12,3 % aller geänderten Zeilen. Der Anteil refaktorierter Zeilen fiel von 25 % aller geänderten Zeilen 2021 auf unter 10 % aller geänderten Zeilen 2024. [1]

Der Code-Churn verdoppelte sich fast im selben Zeitraum, mit weniger Refactoring und mehr Duplizierung zugleich, genau die Wand aus dem verbreiteten Rat. Diese Wand ist echt.

Weitere Belege zeigen in dieselbe Richtung, eine Studie dagegen:

• Eine kontrollierte Studie fand: KI-Werkzeuge erhöhten die Bearbeitungszeit um 19 % gegenüber der Ausgangsdauer. [2]
• Eine große Jahresumfrage fand: KI-Einsatz hebt die Einzelleistung und schadet trotzdem der Lieferstabilität. [3]
• Eine Messung von 2026 fand bei KI-Code mehr Nacharbeit binnen 30 und 90 Tagen als bei menschlichem Code. [4]
• Dieselbe Messung fand bei KI-Code weniger Duplizierung als bei menschlichem Code, ein echter Punkt gegen die Wand. [4]
• Der Anteil misstrauischer Entwickler stieg von 31 % der Befragten auf 46 % der Befragten in einem Jahr. [5]

2. Behauptung: Code ist die einzige Dokumentation

Abbildung 2: Dokumentation veraltet. Der Code, den sie beschreibt, ebenso.

Bild maschinell erzeugt

Die Begründung stimmt auf den ersten Blick. Externe Dokumentation veraltet. Ein veraltetes Dokument ist schlimmer als keines: sein Inhalt stimmt nicht mehr. Eine empirische Studie belegt das im großen Maßstab. Tan, Wagner und Treude haben über 3.000 GitHub-Projekte nach veralteten Code-Verweisen durchsucht. Funktions- und Dateinamen, weiter genannt in READMEs und Wikis, im Quellcode längst gelöscht.

"Outdated documentation is a pervasive problem in software development, preventing effective use of software, and misleading users and developers alike." [6]

Die meisten untersuchten Projekte trugen irgendwann in ihrer Geschichte mindestens einen solchen veralteten Verweis.

Hier greift die Behauptung zu kurz. Der Code selbst ist gegen denselben Verfall nicht immun. Ein Kommentar in einer Funktion driftet von dem ab, was die Funktion inzwischen tatsächlich tut. Ein README driftet vom Code ab, den es beschreibt, aus demselben Grund. Nichts zwingt beide, bei einer Änderung synchron zu bleiben. Das externe Dokument zu streichen entfernt den eigentlichen Fehlermodus nicht. Es verschiebt den veralteten Text nur eine Datei näher an die falsch beschriebene Logik.

Unser eigenes Repository führt absichtlich einen schriftlichen Datensatz. Eine maschinenlesbare Spezifikationsdatei je Inhalt nennt die eine Kernbehauptung und jede Quelle hinter einer Zahl darin. Was wir diesem Datensatz nicht schenken, ist Vertrauen von Haus aus. Ein Spec-Drift-Gate liest bei jedem Push die Spezifikation. Es liest bei jedem Push auch den Beitrag, den sie beschreibt. Das Gate lässt den Build scheitern, sobald beide auseinanderlaufen. Das ist eine andere Antwort auf dieselbe Frage der Behauptung. Eine Maschine prüft diesen Datensatz bei jedem einzelnen Mal gegen den Code und jede Abweichung fällt sofort auf, anders als bei den 3.000 untersuchten Projekten.

Die Behauptung greift auch in der breiteren Literatur zu kurz:

• Widersprüchliche Code-Kommentare stecken etwa 1,5 mal häufiger in einer fehlereinführenden Änderung. [7]
• Selbst die meistzitierte Quelle für "Code als Dokumentation" lehnt darin das Wort "einzige" ab. [8]
• Verbraucher-getriebene Verträge erzwingen eine schriftliche Abmachung bei jedem einzelnen Build gegen den echten Code. [9]
• Googles eigener Styleguide nennt ungepflegte Dokumentation tot. Tote Dokumentation führt Ingenieure aktiv in die Irre. [10]

3. Behauptung: eine verpflichtende Aufräumrunde alle zwei Wochen

Abbildung 3: Ein Kalenderdatum ist keine Kontrolle.

Bild maschinell erzeugt

Wir haben zuerst eine nahe Verwandte der vierzehntägigen Runde ausprobiert. Sie war sorgfältiger als eine Kalendergewohnheit. Eine von Hand ausgewählte Teilmenge unserer eigenen automatischen Prüfungen lief lokal vor einem Push, gewählt von einem Menschen. Zweimal kam diese Teilmenge grün zurück. Der volle Satz an Prüfungen, auf derselben Änderung gelaufen, schlug beide Male rot aus. Keine Nachlässigkeit. Das Register war schlicht über das hinausgewachsen, was ein Mensch beim Wählen einer Teilmenge verlässlich im Kopf behält.

Auch dieses Wachstum ist kein Zufall. Ward Cunningham hat die Schulden-Metapher 1992 genau für diese Dynamik eingeführt: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite" [11]. Ein fester Zwei-Wochen-Abstand ist eine Entscheidung. Die Zinsen laufen nach Kalender auf, statt beim Entstehen abgetragen zu werden. Unser eigener Fall zeigt, was diese Verzögerung kostet: zwei echte Lücken öffneten sich genau in den Tagen zwischen einer handgesteuerten Prüfung und der nächsten Prüfung.

Also ist die Kontrolle aus dem Gedächtnis eines Menschen herausgewandert. Sie ist in den Merge selbst gewandert. Das Register, gegen das wir aktuell prüfen, führt 43 automatische Prüfungen. Ein Git-Hook lässt bei jedem Push den vollen Satz laufen. Eine rote Prüfung blockiert sofort den Push. Eine rote Prüfung kommt nicht auf eine Liste für die nächste Runde. Sie wird sofort repariert, noch vor dem Merge. Kein Fehler bleibt zwei Wochen unrepariert liegen.

Die Forschung zu beiden Hälften dieses Mechanismus stimmt zu:

• Projekte mit laufender Integration lieferten Versionen mehr als doppelt so oft aus wie Projekte ohne sie. [12]
• Die Trefferquote in einer kontrollierten Wachaufgabe sank deutlich, je länger die Wache dauerte. [13]
• Schulden wachsen schneller statt langsamer, wenn automatische Tests fehlen, fand eine spätere Arbeit zu Cunninghams eigener Metapher. [14]
• Die eigene Definition des Fachgebiets für laufende Integration ist ein Build und ein Testlauf bei jedem Commit. [15]
• Über 2,6 Millionen echte Builds hinweg fing eine zusätzliche automatische Prüfung 10 % mehr Fehlschläge. [16]

4. Behauptung: schrittweise reparieren, jede Datei etwas sauberer hinterlassen

Abbildung 4: Kleine Reparaturen, sofort genäht.

Bild maschinell erzeugt

Diese Behauptung hält auch in unserem Repository, mit einer Ergänzung. Wir haben dieselbe Regel selbst in eigenen Worten festgehalten:

"wir brauchen eine regel, dass bei roten gates das repariert und nicht einfach aufgehört wird." [17]

Ein Befund ist Arbeit für die laufende Änderung, nie eine Notiz für später und genau dieser Zusatz macht den Unterschied zur verbreiteten Fassung der Behauptung. Die Gewohnheit hängt nicht an einem Menschen, der sich entscheidet, eine Datei sauberer zu hinterlassen. Ein rotes Gate blockiert den Merge. Erst die Reparatur öffnet ihn wieder.

Die Behauptung hat alte, gut geprüfte Gesellschaft:

• Ein kompletter Neubau von null war der schwerste Fehler einer Firma, urteilte eine berühmte Fallstudie. [18]
• Prüfer finden 70 bis 90 % der Fehler, wenn eine Änderung unter 400 Zeilen bleibt. [19]
• Kleinere Code-Änderungen bekommen messbar wirksamere Prüfungen als große. [20]

5. Behauptung: schlank bleiben, nur ausliefern, was sauber funktioniert

Abbildung 5: Weniger, aber besser.

Bild maschinell erzeugt

Hier braucht es keine Korrektur. Weniger bewegliche Teile scheitern seltener. Ein Register mit 43 Prüfungen funktioniert nur so, jede einzelne Prüfung testet eine enge Aufgabe gut. Wir stimmen zu. Die Idee ist alt:

• Schreibe Programme, die eine Sache tun und sie gut tun, sagte die Unix-Philosophie 1978. [21]
• Baue etwas erst, wenn es wirklich gebraucht wird, nie für eine bloss erwartete Zukunft. [22]
• Einfachheit ist die wichtigste Erwägung eines Entwurfs, urteilte ein klassischer Aufsatz über Software. [23]

6. Behauptung: KI-Programmieren liefert die zehnfache Leistung eines Menschen

Abbildung 6: Zehnfach und zehn Prozent, auf zwei verschiedenen Skalen gemessen.

Bild maschinell erzeugt

Diese Behauptung übersteht die Prüfung nicht. Ihr Ursprung ist echt und dokumentiert, nicht reine Internet-Folklore.

"I'm less interested in that question than when a coder becomes 10 times more productive. I think that can happen this year, or next year." [24]

Das sagt der eigene Geschäftsführer eines führenden KI-Labors über Programmierleistung. Gemessene Studien liegen weit darunter.

• Eine Unternehmensberatung hat echte Entwicklungsteams gemessen und fand Effizienzgewinne von rund 10 bis 15 % der Leistung, nicht das Zehnfache. [25]
• Eine Studie zur Entwicklerproduktivität über mehr als 400 Firmen fand einen Anstieg des Pull-Request-Durchsatzes um unter 8 % seiner vorherigen Rate. [26]
• Unser eigener früherer Befund passt ins selbe Bild: eine kontrollierte Studie fand, KI-Werkzeuge erhöhten die Bearbeitungszeit um 19 % gegenüber der Ausgangsdauer, eine Verlangsamung, keine Beschleunigung. [2]

Eine Zehnfach-Behauptung und eine Messung von unter 8 % beschreiben zwei verschiedene Welten. Nur eine davon stammt aus einer wiederholten, unabhängigen Messung.

7. Behauptung: der Agent, der den Code schreibt, soll ihn nicht auch selbst freigeben

Abbildung 7: Ein zweites, getrenntes Augenpaar.

Bild maschinell erzeugt

Diese hält und trifft die Form unseres eigenen Prüfregisters. Eine von Menschen geschriebene Prüfung lebt ausserhalb des Agenten, den sie beobachtet.

"Code review functions as the final checkpoint before production, and that checkpoint can't be trusted when the same model both produces the code and signs off on it." [27]

Der Mechanismus hinter dieser Behauptung ist gemessen, nicht nur behauptet.

• Code bestand die Prüfung neun bis siebzehn Prozentpunkte häufiger, wenn die Prüfinstanz aus derselben Modellfamilie wie der Schreiber stammte, fand eine Herstellermessung. [27]
• Sprachmodelle bewerten Ausgaben, die ihrem eigenen Stil näherstehen, höher, unabhängig davon, wer sie tatsächlich schrieb. [28]
• Selbsterkennung und Selbstbevorzugung steigen gemeinsam: ein Modell, das seine eigene Ausgabe von anderen unterscheiden kann, bewertet sie auch höher. [29]
• Das Muster ist älter als KI um Jahrzehnte. Die NASA führte unabhängige Prüfteams parallel zu den Entwicklern der Shuttle-Software genau aus diesem Grund. [30]

8. Behauptung: KI-Code trägt Sicherheitslücken mit hoher, hartnäckiger Rate in sich

Abbildung 8: Eine Zahl allein zeigt nicht die ganze Schwäche.

Bild maschinell erzeugt

Teilweise richtig. Die meistzitierte Zahl, 45 % der Fälle, stammt von einem einzigen Hersteller mit eigenem Interesse an der Antwort. Unabhängige Tests stimmen auch untereinander nicht überein.

"AI-generated code introduces security vulnerabilities in 45 percent of cases." [31]

Derselbe Hersteller hat ein Jahr später erneut gemessen und wenig Bewegung gefunden.

"Security pass rates remain stubbornly stuck at approximately 55 percent, virtually identical to where they stood two years ago." [32]

Eine frühere, unabhängige akademische Studie an einer älteren Modellgeneration landete in der Nähe.

• Rund 40 % der getesteten Ausgaben eines frühen Programmier-Assistenten trugen eine bekannte Schwachstellenklasse, fand eine begutachtete Studie. [33]

Eine weitere unabhängige Studie verkompliziert das Bild, statt es zu bestätigen.

• Eine grossangelegte Analyse von KI-Code, der bereits in echte GitHub-Projekte eingeflossen war, fand erkennbare Schwachstellen in nur etwa 12 % der Fälle. [34]

Eine Prüf-Aufgabe sucht gezielt nach Schwächen. Echter, bereits geprüfter Code ist ein anderer Test. Die Rate hängt vom gewählten Test ab.

9. Behauptung: KI-geschriebene Pull Requests tragen mehr Fehler und brauchen länger in der Prüfung

Abbildung 9: Länger warten, öfter zurück.

Bild maschinell erzeugt

Diese hält bei den Zahlen, wobei zwei der vier Quellen die Abhilfe dafür verkaufen.

• KI-geschriebene Pull Requests trugen 10,83 Befunde je Anfrage gegenüber 6,45 Befunden je rein menschlicher Anfrage, fand eine Herstellerstudie an 470 echten Pull Requests. [35]
• KI-erzeugte Pull Requests warteten 4,6 mal länger auf eine Prüfung als menschlich geschriebene, fand ein zweiter Hersteller-Vergleich. [36]
• Eine unabhängige, nicht-kommerzielle Studie an über 500.000 Code-Proben fand bei KI-Code mehr hochriskante Schwachstellen als bei menschlich geschriebenem Code. [37]
• Unser eigener früherer Befund gilt auch hier: KI-Werkzeuge fügten einer Aufgabe messbar mehr Zeit hinzu, nicht weniger. [2]

Zwei der vier Quellen verkaufen KI-Werkzeuge zur Code-Prüfung. Ohne diese beiden Quellen hält das Muster trotzdem und eine unabhängige akademische Studie zeigt in dieselbe Richtung.

10. Die Mitnahme: worauf beim Programmieren mit KI wirklich zu achten ist

Fünf der neun Behauptungen hielten sauber stand. Zwei weitere hielten mit einer echten Korrektur. Eine übersteht die Prüfung gar nicht. Die neunte Behauptung zerfällt am Eigeninteresse der eigenen Quelle und daraus eine kurze Liste für das eigene Repository:

• Achten Sie zuerst auf den Anteil, dann erst auf die Summe. Ein steigender Anteil duplizierter Zeilen und ein fallender Anteil refaktorierter Zeilen warnen früher als eine Fehlerzahl. [1]
• Lassen Sie nie eine handverlesene Teilmenge für den vollen Satz an Prüfungen stehen. Unsere stimmte zweimal mit sich selbst überein und übersah trotzdem, was das volle Register fing.
• Binden Sie die Prüfung an den Merge, nicht an ein Datum. Eine Regel, die später auslöst, kommt für mindestens eine Änderung dazwischen zu spät.
• Führen Sie eine Spezifikation, wenn Sie wollen, aber nur mit einem Gate, das sie bei jedem Push gegen den Code liest. Eine ungeprüfte Spezifikation veraltet genauso wie ein ungeprüfter Kommentar. [7]
• Reparieren Sie die kleine Sache sofort. Ein rotes Ergebnis blockiert die eine Änderung vor Ihnen, keinen künftigen Sprint.
• Fügen Sie eine Prüfung erst hinzu, wo bereits ein echter Fehlschlag passiert ist. Ein Register, das niemand erklären kann, erntet dasselbe Misstrauen, das die Eingabeseite schon hat. [5]
• Lassen Sie nie den Agenten, der den Code schrieb, die einzige Prüfinstanz sein. Selbstbevorzugung ist gemessen, nicht nur vermutet. [28]
• Behandeln Sie eine Schlagzahl von einem Hersteller als Hinweis, nicht als Urteil, bis eine unabhängige Quelle in der Nähe landet. [31]

11. Fazit

Es ging hier nie um neun Behauptungen, sondern darum, woher Vertrauen kommt. Eine Zahl ohne unabhängige Prüfung ist eine Behauptung wie jede andere, das Zehnfache genauso wie 45 % der Fälle. Unser Register klärt nicht die allgemeine Frage, ob KI hilft. Es klärt eine engere Frage, bei jedem einzelnen Push: tut der Code vor ihm, was er behauptet, egal wer oder was ihn geschrieben hat.

12. Quellen

[1] GitClear, "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones", GitClear-Forschungsbericht, 2026. https://www.gitclear.com/ai_assistant_code_quality_2025_research

[2] METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", 2025, arXiv:2507.09089. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

[3] DORA / Google Cloud, "Accelerate State of DevOps Report 2024", 2024. https://dora.dev/research/2024/dora-report/

[4] "A Large-Scale Comprehensive Measurement of AI-Generated Code in Real-World Repositories", arXiv-Preprint, 2026, arXiv:2603.27130. https://arxiv.org/abs/2603.27130

[5] Stack Overflow, "2025 Developer Survey", 2025. https://stackoverflow.co/company/press/archive/stack-overflow-2025-developer-survey/

[6] W. S. Tan, M. Wagner und C. Treude, "Detecting Outdated Code Element References in Software Repository Documentation", Empirical Software Engineering, 2023, arXiv:2212.01479. https://arxiv.org/abs/2212.01479

[7] T. Wu u. a., "Investigating the Impact of Code Comment Inconsistency on Bug Introducing", arXiv-Preprint, 2024, arXiv:2409.10781. https://arxiv.org/abs/2409.10781

[8] M. Fowler, "Code As Documentation", martinfowler.com bliki, 2005. https://martinfowler.com/bliki/CodeAsDocumentation.html

[9] M. Fowler, "Consumer-Driven Contracts: A Service Evolution Pattern", martinfowler.com, 2006. https://martinfowler.com/articles/consumerDrivenContracts.html

[10] Google, "Documentation Best Practices", Google Style Guide, 2026. https://google.github.io/styleguide/docguide/best_practices.html

[11] W. Cunningham, "The WyCash Portfolio Management System", Addendum to the Proceedings of OOPSLA '92, ACM SIGPLAN OOPS Messenger, Bd. 4, Nr. 2, S. 29 bis 30, 1992. https://c2.com/doc/oopsla92.html

[12] M. Hilton, T. Tunnell, K. Huang, D. Marinov und D. Dig, "Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects", ASE 2016, S. 426 bis 437. https://mir.cs.illinois.edu/marinov/publications/HiltonETAL16ContinuousIntegration.pdf

[13] R. A. Grier, J. S. Warm, W. N. Dember, G. Matthews, T. L. Galinsky, J. L. Szalma und R. Parasuraman, "The Vigilance Decrement Reflects Limitations in Effortful Attention, Not Mindlessness", Human Factors, 45(3), 2003, S. 349 bis 359. https://sciences.ucf.edu/psychology/perl/wp-content/uploads/sites/29/2013/01/Grier-et-al-2003-vigilance-is-effortful-not-mindless.pdf

[14] P. Kruchten, R. L. Nord und I. Ozkaya, "Technical Debt: From Metaphor to Theory and Practice", IEEE Software, 29(6), 2012, S. 18 bis 21. https://www.sei.cmu.edu/documents/360/2012_019_001_58818.pdf

[15] DORA / Google Cloud, "Continuous Integration", Capability-Seite, dora.dev, 2026. https://dora.dev/capabilities/continuous-integration/

[16] M. Beller, G. Gousios und A. Zaidman, "Oops, My Tests Broke the Build: An Explorative Analysis of Travis CI with GitHub", MSR 2017, S. 356 bis 367. https://research.tudelft.nl/en/publications/oops-my-tests-broke-the-build-an-explorative-analysis-of-travis-c

[17] "wir brauchen eine regel, dass bei roten gates das repariert und nicht einfach aufgehört wird", Hausregel A13, AGENTS.md (dieses Repository), Owner-Entscheidung 2026-08-08. https://github.com/betteryieldsgmbh/marketing/blob/main/AGENTS.md

[18] J. Spolsky, "Things You Should Never Do, Part I", Joel on Software, 2000. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

[19] J. Cohen / SmartBear Software, "Best Practices for Peer Code Review", 2026, zusammenfassend zur Cisco-Code-Review-Studie (rund 2.500 Reviews, 3,2 Mio. LOC). https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

[20] G. Kudrjavets und A. Rastogi, "Does Code Review Speed Matter for Practitioners?", arXiv-Preprint, 2023, arXiv:2311.02489. https://arxiv.org/abs/2311.02489

[21] M. D. McIlroy, "UNIX Time-Sharing System: Foreword", The Bell System Technical Journal, 57(6), 1978. https://inigomedina.co/library/work/mcilroy-unix-foreword

[22] R. Jeffries, "You're NOT gonna need it!", ronjeffries.com, 2026. https://ronjeffries.com/xprog/articles/practices/pracnotneed/

[23] R. P. Gabriel, "The Rise of Worse Is Better", aus Lisp: Good News, Bad News, How to Win Big, dreamsongs.com, 2026. https://www.dreamsongs.com/RiseOfWorseIsBetter.html

[24] S. Altman, Aussage im Varun Mayya Podcast, zitiert in "AI Could Make Coders 10x Productive This Year: OpenAI CEO Sam Altman", OfficeChai, 2025. https://officechai.com/ai/ai-could-make-coders-10x-productive-this-year-openai-ceo-sam-altman/

[25] Bain and Company, "Beyond Code Generation: More Efficient Software Development", Technology Report 2024, 2024. https://www.bain.com/insights/beyond-code-generation-more-efficient-software-development-tech-report-2024/

[26] J. Reock, "AI productivity gains are 10%, not 10x", DX Research, 2026. https://getdx.com/blog/ai-productivity-gains-are-10-percent-not-10x/

[27] Y. Xu und L. Ye, "AI-Written Code Needs Independent Review", CodeRabbit-Blog, 2026. https://www.coderabbit.ai/blog/code-review-needs-independence

[28] K. Wataoka, T. Takahashi und R. Ri, "Self-Preference Bias in LLM-as-a-Judge", arXiv-Preprint, 2024, arXiv:2410.21819. https://arxiv.org/abs/2410.21819

[29] A. Panickssery, S. R. Bowman und S. Feng, "LLM Evaluators Recognize and Favor Their Own Generations", arXiv-Preprint, 2024, arXiv:2404.13076. https://arxiv.org/abs/2404.13076

[30] National Research Council, "An Assessment of Space Shuttle Flight Software Development Processes", National Academies Press, Kap. 2, 1993. https://www.nationalacademies.org/read/2222/chapter/4

[31] Veracode, "2025 GenAI Code Security Report", 2025. Kommerzielle Quelle: Veracode verkauft Sicherheitsprüf-Werkzeuge fuer Anwendungen. https://www.veracode.com/blog/genai-code-security-report/

[32] Veracode, "Spring 2026 GenAI Code Security Update", 2026. Dasselbe kommerzielle Interesse wie [31]. https://www.veracode.com/blog/spring-2026-genai-code-security/

[33] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt und R. Karri, "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions", IEEE S&P 2022, 2022, arXiv:2108.09293. https://arxiv.org/abs/2108.09293

[34] M. Schreiber und P. Tippe, "Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories", arXiv-Preprint, 2025, arXiv:2510.26103. https://arxiv.org/abs/2510.26103

[35] D. Loker, "State of AI vs Human Code Generation Report", CodeRabbit, 2025. Kommerzielle Quelle: CodeRabbit verkauft KI-Werkzeuge zur Code-Prüfung. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report

[36] Opsera, "2026 AI Coding Impact Benchmark Report", 2026. Kommerzielle Quelle: Opsera verkauft KI- und DevOps-Aufsichtswerkzeuge fuer Code. https://opsera.ai/newsroom/new-opsera-report-reveals-how-ai-is-transforming-software-delivery-and-driving-business-outcomes/

[37] D. Cotroneo, C. Improta und P. Liguori, "Human-Written vs. AI-Generated Code: A Large-Scale Study of Defects, Vulnerabilities, and Complexity", arXiv-Preprint, 2025, arXiv:2508.21634. https://arxiv.org/abs/2508.21634