Stand: Juni 2026

KI-Werkzeuge erzeugen Code schneller. Ob Teams dadurch auch schneller Software ausliefern und warten, ist weniger klar. Studien aus den Jahren 2025 und 2026 zeigen ein wiederkehrendes Muster: Der kurzfristige Durchsatz steigt, während Review, Integration und Wartung mehr Arbeit verursachen können. Wie belastbar dieser Befund ist, hängt allerdings stark von Studiendesign, Aufgabengröße und Codebasis ab.

Die Studien deuten nicht auf einen allgemeinen Qualitätsverlust hin. Sie legen nahe, dass die günstige Erzeugung von Code den Druck auf nachgelagerte Qualitätsmechanismen erhöht.

Seit Mitte 2025 ist die Studienlage dicht genug für ein Zwischenfazit. Mehrere große empirische Arbeiten, Hersteller-Reports und der jährliche DORA-Report liefern Zahlen. Ein guter Teil der Quellen stammt allerdings von Anbietern, die Werkzeuge zur Qualitätssicherung verkaufen, darunter GitClear, CodeRabbit, Qodo und Faros. Viele Untersuchungen sind korrelativ, etliche betrachten Open-Source-Projekte statt produktiver Codebasen. Zudem verändern sich die Modelle schnell: „KI-Code” von Anfang 2024 und Mitte 2025 sind nur eingeschränkt vergleichbar. Die folgenden Befunde sollten vor diesem Hintergrund gelesen werden.

Geschwindigkeit auf Kosten der Wartbarkeit

Eine der methodisch anspruchsvolleren Arbeiten kommt von einer Gruppe an der Carnegie Mellon University. In Speed at the Cost of Quality (He, Miller, Agarwal, Kästner, Vasilescu, November 2025) verglichen die Autoren 807 GitHub-Projekte, die den KI-Editor Cursor nutzen, mit einer nach Ähnlichkeit gematchten Kontrollgruppe. Das Difference-in-Differences-Design stützt unter seinen Modellannahmen eine kausale Interpretation, geht also über eine einfache Korrelation hinaus.

Das Ergebnis beschreibt einen Zielkonflikt. Die Cursor-Einführung führt zu einem statistisch signifikanten, großen, aber vorübergehenden Anstieg der Entwicklungsgeschwindigkeit. Parallel dazu steigen die Warnungen der statischen Code-Analyse und die Codekomplexität deutlich an, und zwar dauerhaft. Konkret berichten die Autoren langfristig rund 30 Prozent mehr Static-Analysis-Warnungen und etwa 41 Prozent mehr Komplexität. Der anfängliche Schub (im ersten Monat ein Vielfaches an Codezeilen und spürbar mehr Commits) ebbt bis etwa zum dritten Monat auf das Ausgangsniveau ab, während die Komplexität bleibt. Die wachsenden Warnungen und die höhere Komplexität sind laut Panel-Analyse sogar selbst ein wesentlicher Treiber der späteren Verlangsamung.

Eine Folgearbeit derselben Gruppe (Januar 2026) trennt autonome Agenten von editorbasierten Assistenten. Die Geschwindigkeitsgewinne fallen demnach vor allem dort groß aus, wo ein Agent das erste KI-Werkzeug im Projekt ist; wo bereits ein Assistent im Einsatz war, bleibt der Effekt klein. Die Qualitätssignale verschlechtern sich dagegen über alle Konstellationen hinweg, mit rund 18 Prozent mehr Warnungen und etwa 39 Prozent mehr kognitiver Komplexität.

Die Last verschiebt sich nach hinten

Der Geschwindigkeitsgewinn kann Arbeit in spätere Entwicklungsphasen verlagern. Darauf weist eine Telemetrie-Auswertung von Faros AI über 22.000 Entwickler hin. Die mediane Zeit im Pull-Request-Review stieg um 441 Prozent, 31 Prozent mehr Pull Requests wurden ganz ohne Review gemergt, die durchschnittliche PR-Größe wuchs um 51,3 Prozent, die Bugs pro Entwickler um 54 Prozent und die Incidents pro Pull Request um 242,7 Prozent. Faros bezeichnet dieses Muster als „Acceleration Whiplash”. Die Auswertung zeigt große Veränderungen, kann sie aufgrund ihres Designs aber nicht eindeutig der KI-Nutzung zuschreiben.

Das passt zum DORA-Report 2025 von Google, auf den wir später noch zurückkommen. Schon hier wichtig: Während sich der Zusammenhang zwischen KI-Nutzung und Durchsatz gegenüber 2024 ins Positive gedreht hat, bleibt die Stabilität der Auslieferung weiterhin negativ mit der KI-Nutzung korreliert. Mehr Tempo trifft auf instabilere Releases, sobald die Sicherungsmechanismen nicht mitwachsen.

Die Mechanismen: weniger Refactoring, mehr Duplikate

Woran liegt der Komplexitätsanstieg konkret? Den meistzitierten Datenpunkt liefert GitClear mit einer Auswertung von 211 Millionen geänderten Codezeilen aus den Jahren 2020 bis 2024. Der Anteil verschobener, also umstrukturierter Zeilen sank von 25 Prozent (2021) auf unter 10 Prozent (2024), während kopierte Zeilen von 8,3 auf 12,3 Prozent zunahmen. Die Häufigkeit duplizierter Codeblöcke schoss 2024 deutlich nach oben. Das ist relevant, weil geklonte Blöcke mit messbar mehr Fehlern einhergehen.

Die diagnostizierte Ursache ist strukturell: Bei begrenztem Kontextfenster schlägt ein Modell eher einen neuen Block vor, als eine bereits existierende Funktion zu finden und wiederzuverwenden. GitClear-Chef Bill Harding vergleicht KI-generierten Code mit einer Aushilfskraft, die ihre Arbeit nicht durchdacht in das bestehende Projekt einfügt.

In dieselbe Richtung zeigt eine empirische Wartungsstudie (Mai 2026). Sie fasst mehrere Vorarbeiten zusammen: Kravchuk-Kirilyuk et al. fanden, dass KI-Code zwar oberflächlich modulare Strukturen nachahmt, dabei aber Prinzipien wie Kapselung verletzt und versteckte Abhängigkeiten einführt. Sankhe et al. berichten 31,4 Prozent mehr Produktivität, aber zugleich 23,7 Prozent mehr Sicherheitslücken und mehr Duplikate. Die Studie selbst stellt fest, dass an agentengenerierten Dateien rund 83 Prozent der späteren Wartung von Menschen geleistet wird, überwiegend in Form von Erweiterungen statt Fehlerkorrekturen. Die eigentliche Aufräumarbeit nach der Generierung ist bisher kaum gemessen.

Einfache Funktionen, aber schlechte Einpassung

Die These, KI schreibe grundsätzlich aufgeblähten Code, wird von den vorliegenden Daten nicht gestützt. Die Ergebnisse unterscheiden sich deutlich danach, ob einzelne Funktionen oder ganze Pull Requests betrachtet werden.

Auf Funktionsebene ist KI-Code eher kürzer und einfacher als menschlicher. Die Large-Scale-Studie Human-Written vs. AI-Generated Code (Cotroneo, Improta, Liguori) wertete über 500.000 Codebeispiele in Python und Java aus und kommt zu einem klaren Bild: KI-generierter Code ist im Schnitt simpler und repetitiver, menschlicher Code weist eine höhere strukturelle Komplexität pro Funktion auf. Wo KI tatsächlich mehr Text produziert, sind es längere, beschreibende Bezeichner und mehr Kommentare, nicht mehr Logik.

Auf Ebene der Codebasis kehrt sich das Bild um. Die Anzahl der Codezeilen ist hierbei nicht das Problem, sondern die Passung. Der CodeRabbit-Report (Dezember 2025) untersuchte 470 Pull Requests, davon 320 mit KI-Beteiligung und 150 rein menschlich. KI-PRs enthielten im Schnitt 10,83 Probleme gegenüber 6,45 bei menschlichen, also etwa das 1,7-Fache. Der größte Einzelunterschied lag bei der Lesbarkeit: KI-Code wirkt in sich konsistent, verletzt aber lokale Muster der Codebasis bei Benennung, Klarheit und Struktur. Lesbarkeitsprobleme traten gut dreimal so häufig auf. Dazu kommen ausgelassene Null-Checks, fehlende frühe Returns und lückenhafte Fehlerbehandlung, also genau die Dinge, die in Produktion zu Ausfällen führen. Überflüssige Ein- und Ausgabeoperationen waren rund achtmal häufiger.

Zusammengenommen beschreiben die Studien zwei verschiedene Ebenen. Einzelne KI-generierte Funktionen sind häufig kurz, gut benannt und ausführlich kommentiert. Bei der Integration in eine gewachsene Codebasis entstehen dagegen eher Duplikate, redundante Abstraktionen und Abweichungen von lokalen Konventionen.

Gegenbefunde und methodische Grenzen

Nicht alle Untersuchungen kommen zu einem Qualitätsverlust.

Eine kontrollierte akademische Studie kommt zu einem günstigeren Ergebnis. Molison et al. prüften in Is LLM-Generated Code More Maintainable & Reliable than Human-Written Code? (ESEM 2025) mit SonarQube standardisierte Python-Aufgaben dreier Schwierigkeitsgrade. LLM-Code hatte insgesamt weniger Bugs und ließ sich mit geringerem Aufwand korrigieren; Fine-Tuning reduzierte zusätzlich schwere Befunde. Bei anspruchsvollen Wettbewerbsaufgaben führte der LLM-Code allerdings mitunter strukturelle Probleme ein, die im menschlichen Code fehlten. Der scheinbare Widerspruch zu pessimistischeren Studien dürfte teilweise auf die unterschiedlichen Untersuchungsgegenstände zurückgehen: isolierte Aufgaben auf der einen, Änderungen an gewachsenen Codebasen auf der anderen Seite. Direkt vergleichbar sind die Ergebnisse deshalb nicht.

Auch der bereits erwähnte DORA-Report 2025 zeichnet ein differenziertes Bild. Dort hatte KI 2024 den Durchsatz noch negativ beeinflusst; 2025 dreht sich das Vorzeichen. Bei 90 Prozent Verbreitung zeigt sich nun ein positiver Zusammenhang von KI-Nutzung mit Durchsatz und Produktqualität. DORA beschreibt KI als Verstärker vorhandener Stärken und Schwächen. Negativ bleibt die Stabilität, besonders dort, wo automatisiertes Testen, reife Versionskontrolle und schnelle Feedback-Schleifen fehlen. Die organisatorischen Voraussetzungen haben damit erheblichen Einfluss auf die beobachtete Qualität.

Hinzu kommen methodische Einwände. Rob Bowley, der den CMU-Befund grundsätzlich teilt, weist auf Grenzen hin: Untersucht wurden nur Open-Source-Projekte, die sich nicht ohne Weiteres mit produktiven Codebasen vergleichen lassen. Die Kontrollgruppe ist außerdem nicht garantiert KI-frei, weil auch dort Copilot oder Claude Code im Spiel sein können. Die GitClear-Daten sind korrelativ und stammen teils von eigenen Kunden; die KI-Nutzung wird inferiert, nicht gemessen. Keine der großen Studien trennt KI-Autorschaft sauber von allen relevanten Störfaktoren.

Wie relevant ist das wirklich?

Die Befunde sprechen für eine reale Verlagerung von Aufwand: Schneller erzeugter Code kann später zusätzliche Arbeit in Review, Bugfixing und Betrieb verursachen. Wie stark dieser Effekt ausfällt, hängt offenbar auch von der Organisation ab. Teams mit guten Tests, klaren Reviews und stabilen Plattformen können eine höhere Änderungsrate besser abfedern. Werkzeughersteller verweisen zusätzlich auf Guardrails, Messung und automatisierte Qualitätssicherung, haben jedoch ein wirtschaftliches Interesse an dieser Interpretation.

Besonders riskant erscheint KI-Code bei großen, kontextabhängigen und schlecht abgesicherten Aufgaben. Für die Bewertung reicht es deshalb nicht, nur die Nutzung eines KI-Werkzeugs zu erfassen. Ebenso wichtig sind Aufgabentyp, Qualitätssicherung und der spätere Aufwand für die Änderung.

Was Teams daraus ableiten sollten

Teams sollten festlegen, bei welchen Änderungen KI die Änderungsrate erhöhen darf, ohne Review, Tests und Architekturentscheidungen zu überlasten. Drei Prinzipien helfen bei dieser Einordnung.

KI-Einsatz nach Risiko staffeln. Kleine, isolierte Änderungen, Tests, Refactorings mit engem Scope und gut beschriebene Hilfsfunktionen sind ein anderes Feld als neue Querschnittsabstraktionen, Datenmigrationen, Sicherheitslogik oder Änderungen an zentralen Domänenmodellen. Eine gemeinsame Erfolgsquote für all diese Aufgaben verdeckt die riskanten Fälle.

Kontext explizit machen und Änderungen klein halten. Ein Agent kann lokale Muster nur dann zuverlässig treffen, wenn Namenskonventionen, Architekturgrenzen, Error-Handling, Teststil und Review-Erwartungen nicht bloß mündlich existieren. Kurze Projektregeln, linternahe Checks, Beispieltests und Review-Checklisten schaffen dafür eine belastbarere Grundlage als ein einzelner Prompt.

Ebenso wichtig ist die Größe der Änderungen. Ein Pull Request, der eine fachliche Änderung, mehrere Aufräumarbeiten und KI-generierte Randfälle bündelt, ist schwer zu prüfen, auch wenn jeder einzelne Teil akzeptabel aussieht. Kleinere Einheiten mit klarer Absicht begrenzen den Review-Aufwand und erleichtern die Fehlersuche.

Nachgelagerte Kosten messen. Die Nutzungsquote oder die Geschwindigkeit der Codeerzeugung sagt wenig über den Gesamtnutzen aus. Aussagekräftiger ist, wie oft KI-Änderungen nach dem Review umgebaut werden, welche Incidents mit großen generierten Änderungen zusammenhängen und welche Dateien kurz nach Agentenarbeit erneut angefasst werden. Diese Rückkopplung zeigt, bei welchen Aufgaben KI tatsächlich Zeit spart.

Dabei muss KI nicht auf das Erzeugen von Code beschränkt bleiben. Sie kann alternative Implementierungen vergleichen, Risiken in einem Diff suchen, Tests gegen Anforderungen prüfen, tote Abstraktionen finden oder bestehende Konventionen aus dem Repository extrahieren. Solche Aufgaben erzeugen keine zusätzliche Codefläche und können dennoch den Review unterstützen.

KI kann Schreibarbeit beschleunigen. Die Verantwortung für Architektur, Review und Betrieb bleibt beim Team und sollte sich in den Regeln für den Werkzeugeinsatz widerspiegeln.

Fazit

KI senkt die Kosten, Code zu erzeugen. Sie senkt nicht automatisch die Kosten, ihn zu verstehen und langfristig zu betreiben. Teams sollten ihren KI-Einsatz deshalb nicht an erzeugten Zeilen oder kurzfristigem Durchsatz bewerten, sondern an Review-Aufwand, späteren Änderungen, Fehlern und Komplexität. Gerade für diese nachgelagerten Kosten ist die bisherige Studienlage noch dünn.

Weiterlesen

Sie setzen KI in der Entwicklung ein und möchten den Tempogewinn nicht in Wartungsschulden umschlagen lassen? Wir helfen dabei, Review, Tests und Qualitätssicherung so aufzustellen, dass KI-gestütztes Coding im Team verlässlich funktioniert. Sprechen Sie uns an, wir freuen uns auf den Austausch.

You May Also Enjoy