Das überraschendste Ergebnis der jüngsten KI-Produktivitätsforschung ist nicht, dass Coding-Assistenten Entwickler langsamer machen können. Es ist, dass die Entwickler es nicht bemerken.
In METRs randomisierter kontrollierter Studie wurde bei 16 erfahrenen Open-Source-Entwicklern, die an 246 realen Aufgaben in ihren eigenen Repositories arbeiteten, eine 19-prozentige Verlangsamung gemessen. Dies ist ein vorläufiges Zwischenergebnis einer laufenden Forschungsreihe mit kleiner Stichprobe und spezifischem Aufgabenkontext (vertraute Codebases). Die Teilnehmer hatten zuvor eine 24-prozentige Beschleunigung vorhergesagt und glaubten auch im Nachhinein noch, 20 Prozent schneller gewesen zu sein. Die Kluft zwischen Wahrnehmung und Messung: 39 bis 44 Prozentpunkte.
Das ist kein Zufall. Es hat eine Struktur. Die Kluft zwischen Selbsteinschätzung und Messung ist kein isoliertes Phänomen, sondern systematisch reproduzierbar und in bekannten kognitiven und methodischen Faktoren verwurzelt.
Die strukturelle Wahrnehmungslücke
Das Studiendesign verdient einen genaueren Blick. Ein echtes RCT, randomisierte Zuordnung, Bildschirmaufzeichnung, reale Aufgaben in vertrauten Codebases, keine synthetischen Benchmarks. Und dennoch aktualisierten die Entwickler ihre Überzeugungen nicht, selbst nachdem sie messbar langsamere Aufgaben abgeschlossen hatten. Die subjektive Produktivitätswahrnehmung hatte sich vollständig von der objektiven Leistung entkoppelt. Die Autoren von METR weisen darauf hin, dass ein Teil der Verlangsamung darauf zurückzuführen sein könnte, dass Entwickler Zeit mit dem Formulieren von Prompts, dem Bewerten von Vorschlägen und dem Debuggen von generiertem Code verbrachten. Dieser Overhead bleibt in der subjektiven Wahrnehmung unsichtbar, weil er sich wie aktive Arbeit anfühlt, nicht wie Leerlauf.
Dies ist kein isolierter Befund. Laut einer Umfrage von Panto, einem kommerziellen KI-Tool-Anbieter, dessen Daten aus seiner eigenen Nutzerbasis stammen, berichten 74 Prozent der Entwickler, sich mit KI-Tools produktiver zu fühlen. Kontrollierte Messungen bestätigen jedoch regelmäßig keine vergleichbaren Gewinne, insbesondere nicht für erfahrene Entwickler, die an komplexen Codebases arbeiten. Die Kluft zwischen Wahrnehmung und Messung ist kein methodisches Artefakt. Sie ist eine strukturelle Eigenschaft der menschlichen Bewertung KI-unterstützter Arbeit.
Automation Bias verstärkt das Problem. Eine Metaanalyse der California Management Review über 74 Studien ergab, dass automatisierte Systeme mit hoher, aber nicht perfekter Genauigkeit systematisch Übervertrauen erzeugen. Laut dieser Analyse steigen Begehungsfehler um 12 Prozent und die Anomalieerkennung verlangsamt sich. Auf KI-Coding-Tools übertragen: Entwickler übersehen wahrscheinlich mehr Fehler im generierten Output, gerade weil die Genauigkeitsrate hoch genug ist, um die Wachsamkeit zu untergraben.
Warum versagt die Selbsteinschätzung so konsistent? KI-Tools reduzieren den wahrgenommenen kognitiven Aufwand durch Boilerplate-Generierung und Autovervollständigung. Das erzeugt ein subjektives Flow-Erlebnis, das Entwickler als Geschwindigkeit interpretieren. Anthropics Studie zur Kompetenzentwicklung, deren detaillierte Ergebnisse im Abschnitt "Die unsichtbare Schuld" ausführlicher besprochen werden, enthüllt den Mechanismus: Entwickler, die stark an KI delegierten, schnitten bei Verständnistests unter 40 Prozent ab. Genau der Mechanismus, der sich produktiv anfühlt, nämlich reduziertes kognitives Engagement, verschlechtert die Fähigkeit, die eigene Leistung zu bewerten. Für jede Organisation bedeutet das: Eine KI-Produktivitätsbewertung auf Basis von Selbstberichten überschätzt systematisch den Nutzen.
Individuelle Gewinne, systemische Stagnation
Wenn die Selbsteinschätzung einzelner Entwickler schon unzuverlässig ist, was passiert dann auf Teamebene? Telemetriedaten von über 10.000 Entwickler-Workflows liefern eine ernüchternde Antwort.
Faros AIs Produktivitätsstudie zeichnet ein paradoxes Bild: Einzelne Entwickler mit KI-Unterstützung mergen 98 Prozent mehr Pull Requests und schließen 21 Prozent mehr Tasks ab. Doch die DORA-Metriken (Deployment Frequency, Lead Time for Changes, Change Failure Rate und Time to Restore Service), die vier Kernindikatoren der Software-Delivery-Performance, bleiben auf Organisationsebene flach. Flache DORA-Metriken bei steigendem individuellem Output sind das Zeichen eines Systemengpasses, nicht eines Produktivitätsgewinns. Mehr individueller Output übersetzt sich nicht in höheren organisatorischen Durchsatz.
Die Erklärung liegt in einer Engpassverschiebung. KI beschleunigt die Codegenerierung, erzeugt aber eine überwältigende Review-Last im nachgelagerten Prozess. Die PR-Review-Zeit steigt bei Teams mit hoher KI-Adoption um 91 Prozent laut Faros AI, getrieben durch einen 154-prozentigen Anstieg der durchschnittlichen PR-Größe. Größere PRs erhöhen die kognitive Belastung für Reviewer überproportional. Jede Einheit KI-generierter Leistung erfordert mehr menschliche Bewertungszeit, als sie einspart.
Die Fertigungsanalogie ist treffend: Ein schnellerer Produktionsschritt vor einem manuellen Qualitätsprüfungsschritt erhöht nicht den Gesamtdurchsatz. Er erzeugt einen Rückstau halbfertiger Produkte. Laut Faros AI bleibt die Deployment-Frequenz selbst bei 98 Prozent mehr Merges unverändert.
Ein erschwerender Faktor: GitClears Langzeitanalyse verzeichnet einen fast 30-prozentigen Rückgang der Peer-Review-Beteiligung parallel zur steigenden KI-Adoption, obwohl das Commit-Volumen um 55 Prozent gestiegen ist. Mehr Output bei weniger Review produziert unkontrollierte Qualitätserosion. Der individuelle ROI von 4:1 (laut Index.dev: 150 Dollar eingesparte Entwicklerzeit gegenüber 37,50 Dollar pro zusätzlichem PR) bricht zusammen, wenn man den Review-Overhead, eine 1,7-fache Fehlerrate laut Sonar und verdoppelten Code-Churn einrechnet.
Technische Schulden in beispiellosem Tempo
Das Problem flacher Systemmetriken wird durch die Qualität des generierten Codes selbst verschärft. Mehr Code bedeutet auch: mehr technische Schulden, in einem nie dagewesenen Tempo.
Sonars Developer Survey 2026 mit über 1.100 Entwicklern ergab: KI-generierter Code enthält 1,7-mal mehr Gesamtprobleme als menschlich geschriebener Code. Logikfehler sind 1,75-mal höher, Wartbarkeitsprobleme 1,64-mal, Sicherheitslücken 1,57-mal. Eine auf der IEEE ISSRE 2025 vorgestellte Studie mit 500.000 Code-Samples und Ox Securitys Analyse von 300 Open-Source-Projekten werden gemeinsam von InfoQ referenziert: KI- und menschlicher Code haben grundlegend verschiedene Defektprofile. Sie versagen auf kategorisch unterschiedliche Weise.
Ox Securitys Analyse identifizierte 10 wiederkehrende Anti-Patterns, die in 80 bis 100 Prozent des KI-generierten Codes auftreten:
- Exzessives Kommentieren (90-100 Prozent)
- Lehrbuchmuster ohne kontextuelle Anpassung (80-90 Prozent)
- Refactoring-Resistenz (80-90 Prozent)
- Überspezifikation für unwahrscheinliche Randfälle (80-90 Prozent)
- Duplizierte Bugs über Generierungssitzungen hinweg (80-90 Prozent)
Der Titel ihres Reports, "Army of Juniors", trifft den Punkt: KI produziert funktional kompetenten Code, dem die architektonische Weisheit erfahrener Ingenieure fehlt. Besonders deutlich wird dies in der Unfähigkeit, technische Entscheidungen im Kontext des Gesamtsystems zu treffen. KI-generierter Code löst das unmittelbare Problem, ignoriert aber Nebenwirkungen auf Nachbarsysteme, bestehende Abstraktionen und langfristige Wartungskosten.
GitClears Fünfjahresanalyse von 211 Millionen Zeilen zeigt die strukturelle Konsequenz: KI-intensive Repositories weisen ein 34 Prozent höheres kumulatives Refactoring-Defizit auf. "Moved Code", ein Proxy für gesundes Refactoring, ist auf nahezu null gefallen. Copy-Paste-Code hat zum ersten Mal 2024 refaktorierten Code übertroffen, ein Wendepunkt im Code-Evolutionsverhalten. Codebases wachsen durch Akkumulation statt durch Konsolidierung; jedes neue Feature fügt Schichten hinzu, anstatt bestehende Strukturen zu verbessern. Laut Addy Osmani haben bis 2026 bereits 75 Prozent der Technologie-Entscheidungsträger moderate bis schwerwiegende Konsequenzen aus diesen angehäuften Schulden.
Die unsichtbare Schuld: Kompetenzen und Urteilsvermögen
Jenseits der technischen Schulden akkumuliert sich eine weitere, weniger sichtbare Schuld bei den Entwicklern selbst. Ihre Fähigkeiten und ihr Urteilsvermögen verändern sich parallel zur Tool-Nutzung.
Der stärkste direkte Beleg stammt aus Anthropics 52-Personen-RCT, dokumentiert als Sekundärquelle bei InfoQ: Junior-Entwickler mit KI-Unterstützung schnitten bei Verständnistests 17 Prozent schlechter ab (50 vs. 67 Prozent). Nicht alle KI-Nutzung war gleich schädlich: Wer stark delegierte, fiel unter 40 Prozent. Wer KI strategisch für konzeptionelle Fragen nutzte, lag über 65 Prozent. Wie KI genutzt wird, bestimmt das Ergebnis weit mehr als ob sie genutzt wird.
Die Studie identifizierte eine gefährliche Rückkopplungsschleife: Mehr Delegation verschlechtert die Überwachungsfähigkeit, was wiederum die Abhängigkeit von KI für Aufgaben erhöht, die der Entwickler nicht mehr selbstständig bewältigen kann. Die Zeitersparnis war vernachlässigbar, etwa zwei Minuten pro Aufgabe. Ein schlechter Tausch für nachhaltigen Kompetenzverlust.
Die Parallele zur Automation Complacency in der Luftfahrt ist keine Metapher: Piloten, die sich jahrelang auf den Autopiloten verlassen, verlieren nachweislich manuelle Flugfähigkeiten. Die Softwareentwicklung folgt derselben Dynamik, nur ohne die regulatorischen Gegenmaßnahmen, die die Luftfahrt längst implementiert hat.
Junior-Entwickler tragen das höchste Risiko, da sie gleichzeitig die intensivsten KI-Nutzer und die am stärksten von kognitivem Offloading während formativer Lernphasen Betroffenen sind. Laut Addy Osmani erzielen Juniors Produktivitätsgewinne von 35 bis 39 Prozent gegenüber 8 bis 16 Prozent für Seniors. Diese Geschwindigkeitsgewinne gehen möglicherweise direkt auf Kosten des architektonischen Urteilsvermögens und der Debugging-Intuition, die Senior Engineering definieren. Organisationen, die auf Junior-Geschwindigkeit optimieren, schwächen möglicherweise ihre langfristige Engineering-Pipeline und werden den Schaden erst bemerken, wenn die aktuelle Generation in Rollen hineinwächst, die mehr verlangen, als sie mitbringen.
Was tatsächlich funktioniert
Keines dieser Ergebnisse bedeutet, dass KI-Tools nutzlos sind. Sie bedeuten, dass pauschale Produktivitätsversprechen der Realität nicht standhalten und dass es auf den Kontext ankommt.
Senoritätslinie und Aufgabeneignung
Produktivitätseffekte divergieren scharf entlang der Senoritätslinie. Kontrollierte Studien zeigen 35 bis 39 Prozent Gewinne für Juniors laut Addy Osmani, aber nur 8 bis 16 Prozent für erfahrene Entwickler. Im Extremfall: METRs RCT ergab eine 19-prozentige Verlangsamung für Experten, die in ihren eigenen Repositories arbeiteten, ein Ergebnis einer Stichprobe von 16 Entwicklern in einem spezifischen Kontext, das nicht ohne Weiteres verallgemeinert werden sollte. Seniors besitzen bereits die Mustererkennung und das Kontextwissen, das KI bereitstellt. Für Juniors füllt KI echte Wissenslücken. Für Experten übersteigt der Bewertungsaufwand den Generierungsvorteil.
Forschung zeigt klare Eignungsgrenzen. Laut Pantos eigener Umfrage unter seiner Nutzerbasis arbeiten Entwickler bei Routineaufgaben 51 Prozent schneller, mit bis zu 81 Prozent Zeitersparnis bei CRUD-Operationen und API-Integration. KI stößt an ihre Grenzen bei neuartiger Algorithmenentwicklung, komplexer Geschäftslogik, Architekturentscheidungen und sicherheitskritischen Implementierungen. Die Grenze verläuft nicht zwischen KI und Nicht-KI, sondern zwischen Aufgaben, bei denen Fehlerkosten niedrig sind, und solchen, bei denen sie katastrophal sein können.
Messen, nicht schätzen
Die 39-44-Prozentpunkte-Kluft zwischen Wahrnehmung und Realität disqualifiziert Selbsteinschätzung als Entscheidungsgrundlage. Wer wirklich wissen will, ob KI-Tools einen Unterschied machen, muss DORA-Metriken, Review-Zeiten und Fehlerraten verfolgen, nicht die Stimmung der Entwickler. Der folgende Code berechnet die durchschnittliche PR Cycle Time (Zeit von PR-Erstellung bis Merge) und PR-Größe, beides nützliche Proxies für Review-Engpässe, aber zu unterscheiden von der DORA Lead Time, die ab dem initialen Commit zählt:
# Calculate PR Cycle Time and PR size from GitHub data
# Prerequisites: GitHub CLI (gh) and jq installed
gh pr list \
--state merged \
--limit 100 \
--json number,createdAt,mergedAt,additions,deletions \
| jq '[.[] | {
pr: .number,
cycle_time_h: ((.mergedAt | fromdateiso8601) - (.createdAt | fromdateiso8601)) / 3600,
pr_size: (.additions + .deletions)
}] | {
avg_cycle_time_h: (map(.cycle_time_h) | add / length),
avg_pr_size: (map(.pr_size) | add / length)
}'
Das Ergebnis zeigt, wie lange PRs durchschnittlich offen bleiben und wie groß sie typischerweise sind. Wer einen Trend erkennt - wachsende PR-Größen bei stabiler oder sinkender Merge-Frequenz - steht vor dem Review-Engpass-Muster, das Faros AI über 10.000 Entwickler-Workflows dokumentierte.
Governance als Voraussetzung
Laut DevOps.com erzielen Unternehmen mit Governance-Investitionen deutlich bessere KI-Ergebnisse als Teams ohne strukturierte Frameworks. Governance bedeutet hier: proaktive Skalierung der Review-Kapazität, Einführung KI-spezifischer Qualitätsmetriken und bewusste Schaffung von Lernräumen für Junior-Entwickler ohne KI-Delegation. Teams, die KI als Pair-Programming-Partner nutzen, mit aktivem Code-Review und bewusster Auseinandersetzung mit dem generierten Output, berichten durchweg bessere Ergebnisse als solche, die KI-Output direkt und ungeprüft übernehmen. Die Art der Interaktion bestimmt das Ergebnis: KI als Denkpartner statt als Ghostwriter. Strukturierte agentenbasierte Entwicklungs-Workflows mit Multi-Agent-Pipelines und Quality Gates sind ein konkreter Ansatz, diese Art von Governance skalierbar umzusetzen.
Fazit für Entscheidungsträger
KI-Coding-Tools sind weder nutzlos noch das pauschale Produktivitätswunder, als das sie vermarktet werden. Ihr Wert hängt davon ab, wer sie nutzt, wofür und mit welcher organisatorischen Infrastruktur. Wer das ignoriert, akkumuliert technische und menschliche Schulden, die sich bereits heute in steigenden Wartungskosten, wachsenden Review-Rückständen und erodierenden Engineering-Kompetenzen manifestieren. Die entscheidende Frage ist nicht, ob diese Konsequenzen eintreten, sondern ob Ihre Organisation sie früh genug erkennt, um den Kurs zu korrigieren, bevor das Ausmaß des Problems eine sinnvolle Korrektur prohibitiv teuer macht.