Die 10%-Mauer: Warum KI-Produktivität stagniert und was sie durchbricht

DX befragte 121.000 Entwickler in 450 Unternehmen. 92,6 % nutzen KI-gestützte Programmierassistenten mindestens monatlich. KI-generierter Code macht mittlerweile 26,9 % der in Produktion zusammengeführten Änderungen aus. Entwickler berichten, dass sie etwa vier Stunden pro Woche einsparen.¹ Die Produktivität hat sich nicht über 10 % hinaus bewegt.

Diese Zahl ist seit drei aufeinanderfolgenden Quartalen konstant geblieben.^{1 2} Die Akzeptanz stieg. Das Codevolumen stieg. Die Tools verbesserten sich. Die Produktivitätsgewinne nicht. Laura Tacho, CTO bei DX, formulierte es direkt: „Das ist wirklich ein Managementproblem. Der Hype ließ es so klingen, als würde das bloße Ausprobieren von KI automatisch Ergebnisse bringen.”³

Der DORA-Report 2025 deckte die Divergenz auf. Organisationen mit starken Engineering-Praktiken sahen, wie KI ihre bestehenden Stärken verstärkte. Organisationen mit schwachen Praktiken sahen, wie KI ihre bestehenden Dysfunktionen verstärkte. Dieselben Tools. Gegenteilige Ergebnisse. Der Report kam zu dem Schluss: „Die primäre Rolle von KI in der Softwareentwicklung ist die eines Verstärkers. Sie vergrößert die Stärken leistungsstarker Organisationen und die Dysfunktionen schwächelnder.”⁴

Die Mauer ist kein Modellproblem. Sie ist ein Infrastrukturproblem. Bessere Modelle werden keine Mauer durchbrechen, die aus fehlender Verifikation, fehlendem Kontext und fehlender Governance besteht. Die Begleitartikel zu diesem Beitrag beschreiben die Architektur: Anatomy of a Claw erklärt die Orchestrierungsschicht, The Fabrication Firewall erklärt das Ausgabe-Gate und Context Is Architecture erklärt das Kontextinjektionssystem. Dieser Beitrag erklärt, warum diese Systeme existieren.

Zusammenfassung

121.000 befragte Entwickler. 92,6 % Akzeptanz. Produktivität stagniert bei 10 %. Die Mauer existiert, weil KI Code schneller generiert, als Organisationen ihn verifizieren, kontextualisieren oder steuern können. Drei Grundursachen: Kontexthunger (die KI halluziniert ohne projektspezifisches Wissen), Verifikationsvakuum (Code wird schneller ausgeliefert, als sich Reviewprozesse anpassen) und Governance-Lücke (KI umgeht Qualitätsstandards, die Menschen durchsetzen). Der Durchbruch erfordert Infrastruktur rund um die KI, nicht bessere KI. Die Evidenz: Organisationen, die Verifikations- und Governance-Infrastruktur aufbauten, halbierten ihre Vorfälle; Organisationen, die KI ohne Infrastruktur einführten, verdoppelten sie.^{4 5} Dies ist ein N=1-Versuch, diese Infrastruktur aufzubauen, dokumentiert mit konkreten Zahlen. Er kann keine Verallgemeinerbarkeit beweisen. Er kann zeigen, wie die andere Seite der Mauer aussieht.

Was die Umfrage zeigt

Der DX-Datensatz umfasst 4,2 Millionen Entwickler, die zwischen November 2025 und Februar 2026 beobachtet wurden, mit einem detaillierten Panel von 121.000 Entwicklern in 450 Unternehmen.¹ Die Zahlen erzählen zwei Geschichten.

Die Akzeptanzgeschichte ist eindeutig. KI-gestützte Programmierassistenten erreichten nahezu flächendeckende Verbreitung. DX maß 92,6 % monatliche Nutzung und ungefähr 75 % wöchentliche Nutzung.¹ Die Stack-Overflow-Umfrage 2025 ergab, dass 84 % der Entwickler KI-Tools nutzen oder planen, sie zu nutzen.⁶ JetBrains maß 85 % regelmäßige Nutzung unter 24.534 Entwicklern in 194 Ländern.⁷ Die Akzeptanzobergrenze ist fast erreicht.

Die Produktivitätsgeschichte stagniert. DX maß durchschnittlich vier eingesparte Stunden pro Woche, unverändert gegenüber den 3,6 Stunden des Vorquartals.^{1 2} KI-generierter Code stieg von 22 % auf 26,9 % des zusammengeführten Codes, doch das zusätzliche Volumen ließ sich nicht in zusätzlichen Output übersetzen.^{1 2} Laura Tacho identifizierte die Rechnung: Entwickler verbringen ungefähr 20 % ihrer Zeit mit dem Schreiben von Code. Eine 10%ige Verbesserung auf 20 % des Arbeitstages ergibt insgesamt eine 2%ige Verbesserung. „Tippgeschwindigkeit war nie der Engpass.”⁸

Die kritische Zeile ist die letzte. Der DORA-Report 2024 befragte 39.000 Fachleute und stellte fest, dass mit jedem 25%igen Anstieg der KI-Akzeptanz der Lieferdurchsatz um geschätzte 1,5 % und die Lieferstabilität um 7,2 % sank.⁵ Der DORA-Report 2025 ergab, dass sich der Durchsatz erholte (die Korrelation kippte von negativ zu positiv), die Stabilität jedoch weiterhin negativ blieb.⁴ KI-Akzeptanz korrelierte weiterhin mit erhöhter Instabilität, selbst als sich der Durchsatz verbesserte.

Die Divergenz ist wichtiger als die Durchschnittswerte. METR untersuchte 16 erfahrene Open-Source-Entwickler, die an 246 realen Repository-Issues arbeiteten, und stellte fest, dass sie mit KI-Tools 19 % länger brauchten als ohne.⁹ Googles randomisierte kontrollierte Studie mit 96 Ingenieuren ergab eine Geschwindigkeitsverbesserung von 21 %, doch das Ergebnis war nicht statistisch signifikant (95 % KI: Konfidenzintervall überschritt die Null).¹⁰ McKinsey fand Verbesserungen von 35–50 % bei einfachen Aufgaben, aber weniger als 10 % bei hochkomplexen Aufgaben.¹¹ Das Muster: KI beschleunigt die Teile der Entwicklung, die nie der Engpass waren.

Die Unternehmen, die die Mauer durchbrachen, nutzten keine besseren Modelle. Sie bauten Infrastruktur auf, die auffing, was die Modelle übersahen.

Warum die Mauer existiert

Drei Grundursachen erklären das Plateau. Jede wirkt unabhängig. Zusammen bilden sie eine Decke, die bessere Modelle nicht durchdringen können.

Kontexthunger

KI-gestützte Programmierassistenten operieren auf dem Code, der in der aktuellen Datei sichtbar ist, und dem Kontext, der in das Promptfenster passt. Sie kennen weder Ihre Architekturentscheidungen, noch Ihre API-Verträge, Ihre Deployment-Einschränkungen oder die Namenskonventionen Ihres Teams – es sei denn, jemand injiziert diese Informationen.

Ohne projektspezifischen Kontext rät das Modell. Es halluziniert Dateipfade, die plausiblen Konventionen folgen, aber nicht existieren. Es generiert API-Aufrufe an Endpunkte, die gängigen Mustern entsprechen, aber nicht Ihren Mustern. Es schlägt Imports aus Paketen vor, die Ihr Projekt nicht verwendet.¹²

Faros AI analysierte Telemetriedaten von 10.000 Entwicklern in 1.255 Teams und stellte fest, dass KI-unterstützte Pull Requests 154 % größer sind als nicht unterstützte.¹² Größere PRs bieten mehr Angriffsfläche für kontextabhängige Fehler. Die KI generiert Code mit Überzeugung. Der Code kompiliert. Der Code berücksichtigt nicht die Einschränkung, die auf einer Confluence-Seite dokumentiert ist, die die KI nie gesehen hat.

Dies ist kein Halluzinationsproblem im Sinne der Modellsicherheit. Das Modell funktioniert genau wie vorgesehen: Es sagt wahrscheinlichen Code anhand des verfügbaren Kontexts vorher. Das Problem ist, dass der verfügbare Kontext das meiste ausschließt, was für Korrektheit in einer spezifischen Codebasis relevant ist.

Verifikationsvakuum

KI generiert Code schneller, als bestehende Reviewprozesse ihn aufnehmen können. Faros stellte fest, dass KI-unterstützte PRs 91 % länger für das Review brauchen.¹² Entwickler erledigen 21 % mehr Aufgaben und mergen 98 % mehr Pull Requests, aber die Review-Pipeline ist auf menschliche Geschwindigkeit ausgelegt.¹²

Die Stanford-Studie zu unsicherem Code quantifizierte die Sicherheitsdimension. Forscher gaben 47 Entwicklern Programmieraufgaben mit und ohne KI-Unterstützung. Die KI-unterstützte Gruppe schrieb in vier von fünf Aufgaben häufiger unsichere Lösungen. Bei der SQL-Injection-Aufgabe schrieben 36 % der KI-Gruppe verwundbaren Code gegenüber 7 % der Kontrollgruppe. Teilnehmer mit KI-Unterstützung waren eher davon überzeugt, sicheren Code geschrieben zu haben, selbst wenn dies nicht der Fall war.¹³ Die Kombination aus schnellerem Output und höherer falscher Zuversicht erzeugt eine Verifikationslücke, die manuelles Review im großen Maßstab nicht schließen kann.

GitClear analysierte 153 Millionen geänderte Codezeilen und stellte fest, dass Code-Churn (Code, der innerhalb von zwei Wochen nach dem Schreiben umgeschrieben wird) sich 2024 im Vergleich zu den Vor-KI-Basiswerten voraussichtlich verdoppeln würde.¹⁴ Der Volumenzuwachs durch KI-Tools erzeugt Nacharbeit, die die Produktivitätsgewinne teilweise aufhebt. Die Stack-Overflow-Umfrage 2025 bestätigt die Reibung: 66 % der Entwickler berichten, dass sie mehr Zeit damit verbringen, „fast richtigen” KI-generierten Code zu korrigieren.⁶

Governance-Lücke

KI-generierter Code umgeht die Governance-Mechanismen, die menschliche Entwickler verinnerlicht haben. Ein erfahrener Entwickler weiß, dass er den Style Guide prüfen, den Linter ausführen, das Changelog aktualisieren und den Teamleiter über Architekturänderungen informieren muss. Ein KI-Assistent generiert eine Lösung, die den Prompt erfüllt. Die Lücke zwischen „kompiliert und besteht Tests” und „erfüllt organisatorische Standards” ist Governance.

McKinseys Studie von 2023 ergab, dass Junior-Entwickler mit KI 7–10 % langsamer waren, nicht schneller.¹¹ Die Forscher führten dies auf die Lücke zwischen generiertem Code und organisatorischem Kontext zurück. Junior-Entwicklern fehlt das Urteilsvermögen, um zu bewerten, ob KI-Output Standards entspricht, die sie noch nicht verinnerlicht haben. Ohne Governance-Infrastruktur, die diese Standards als automatisierte Prüfungen kodifiziert, fließt KI-Output unkontrolliert weiter.

Die Governance-Lücke potenziert sich über Teams hinweg. Das KI-generierte Utility eines Entwicklers dupliziert das bestehende Modul eines anderen. Zwei KI-generierte Endpunkte verwenden unterschiedliche Fehlerformate für dieselbe API. KI-verfasste Migrationen folgen einer anderen Namenskonvention als der Teamstandard. Jeder einzelne Verstoß ist klein. Der kumulative Effekt ist eine Codebasis, die schneller von ihren eigenen Konventionen abdriftet, als Reviews korrigieren können.

Wie die andere Seite aussieht

Das DORA-Ergebnis beschreibt zwei Populationen, die identische Tools verwenden. Die eine halbierte ihre Vorfälle. Die andere verdoppelte sie.⁴ Die Variable zwischen ihnen ist nicht, welche KI sie verwenden. Es ist die Infrastruktur rund um die KI.

Jede Grundursache entspricht einer Infrastrukturlösung. Die folgende Tabelle zeigt die Kette von Problem zu Lösung, mit einer konkreten Implementierung aus einem System, das ich erstellt und in den Begleitartikeln dokumentiert habe. Dies ist ein Versuch mit konkreten Zahlen, keine universelle Empfehlung.

Kontextinjektion adressiert den Kontexthunger, indem sichergestellt wird, dass das Modell bei jedem Prompt projektspezifische Informationen erhält. Ein Dispatcher-Hook feuert neun sequenzielle Handler, die das aktuelle Datum, den Git-Branch, das Arbeitsverzeichnis, Projektkonventionen, den aktiven Aufgabenkontext und architektonische Einschränkungen injizieren. Das Modell erhält 200–400 Token an Grundierungskontext, bevor es die Anfrage des Benutzers verarbeitet. Gemessene Latenz: 200 ms insgesamt für alle neun Hooks. Das Modell hört auf, Dateipfade zu erfinden, weil ihm die tatsächlichen Pfade mitgeteilt wurden.¹⁵

Unabhängige Verifikation adressiert das Vakuum, indem Menschen aus dem Verifikationsengpass bei Routineprüfungen entfernt werden. Die autonome Entwicklungsschleife (dokumentiert in Anatomy of a Claw) generiert Code, führt die vollständige Testsuite aus und übergibt die Ergebnisse an drei Review-Agenten, die unabhängig arbeiten. Der Implementierungsagent überprüft nie seinen eigenen Output. Dies spiegelt das Ergebnis wider, dass die KI-unterstützte Gruppe in der Stanford-Studie bei unsicherem Code zuversichtlicher war: Selbstverifikation ist unzuverlässig, egal ob der Autor Mensch oder künstlich ist.¹³

Automatisierte Governance adressiert die Lücke, indem Teamstandards als ausführbare Prüfungen kodifiziert werden. Die Fabrication Firewall klassifiziert jede ausgehende Aktion als lokal, geteilt oder extern und delegiert externe Veröffentlichungen an menschliches Review. Quality Gates blockieren Abschlussberichte, die Abschwächungssprache verwenden („sollte funktionieren”, „sieht korrekt aus”) anstatt Testausgaben und Dateipfade zu zitieren. Das System setzt Standards durch, die menschliche Entwickler anwenden würden, wenn sie die Zeit hätten, jede Zeile zu überprüfen. Bei KI-Generierungsgeschwindigkeit haben sie das nicht.

Das kombinierte System liefert messbare Ergebnisse für seine eigene Codebasis: 4.518 Code-Chunks indiziert für semantische Suche, 49.746 Vault-Chunks über 15.800 Dateien für persistenten Speicher und eine Testsuite, die automatisch vor jedem Abschluss einer Änderung läuft.¹⁵ Diese Zahlen beschreiben die Infrastruktur eines einzelnen Entwicklers. Sie können nicht beweisen, dass der Ansatz verallgemeinerbar ist. Sie können demonstrieren, dass die Mauer mit den richtigen Werkzeugen auf der anderen Seite durchlässig ist.

Das Governance-Verhältnis

Das in Anatomy of a Claw beschriebene Hook-System enthält 84 Hooks. Eine verifizierte Zählung trennt sie nach Funktion: 35 Urteilshooks, die entscheiden, ob etwas geschehen soll, und 44 Automatisierungshooks, die vorbestimmte Aktionen ausführen. Das Verhältnis beträgt 4:5. Es begann bei 1:6.¹⁵

Das Ausgangsverhältnis spiegelt wider, was die meisten Teams zuerst bauen: Automatisierung. Kontext injizieren. Metriken erfassen. Output formatieren. Nutzung protokollieren. Diese Hooks erfassen die 10 %, die jeder bekommt. Sie automatisieren die mechanischen Teile der Entwicklung, die schon vor der KI teilweise automatisiert waren. Die DX-Daten bestätigen dies: Die vier eingesparten Stunden pro Woche stammen aus Codegenerierung und Boilerplate-Reduktion – Aufgaben, die bereits der schnellste Teil des Entwicklungszyklus waren.¹

Die Verschiebung hin zu Urteilshooks spiegelt wider, woher zusätzliche Gewinne kommen.

McKinseys Umfrage von 2025 unter knapp 300 Unternehmen ergab, dass die leistungsstärksten Unternehmen Produktivitätsverbesserungen von 16–30 % und Qualitätsverbesserungen von 31–45 % verzeichneten.¹⁶ Diese Organisationen hatten eine Entwickler-Akzeptanz von 80–100 % in Kombination mit organisatorischer Integration. Der unterscheidende Faktor war nicht die Akzeptanzrate (die branchenübergreifend mit 10 % Gewinn korreliert), sondern die Infrastruktur und Prozesse, die um diese Akzeptanz herum aufgebaut wurden.

Laura Tachos Einordnung trifft auch hier zu: „Ich bin skeptisch gegenüber dem Versprechen jeder Technologie, die Leistung zu verbessern, ohne diese zugrunde liegenden Einschränkungen zu adressieren.”³ Die zugrunde liegenden Einschränkungen sind Urteilseinschränkungen. Entspricht dieser Code unseren Standards? Bricht diese Änderung etwas Nachgelagertes? Enthält dieser Output eine Erfindung? Automatisierungshooks können diese Fragen nicht beantworten. Urteilshooks können es – unvollkommen –, indem sie die Kriterien kodifizieren, die erfahrene Entwickler mental anwenden.

Das Verhältnis hat noch keine Parität erreicht. Das System automatisiert immer noch mehr, als es steuert. Das ist selbst eine Diagnose: Jede Orchestrierungsschicht, in der Automatisierungshooks Urteilshooks überzählig sind, hat Verbesserungspotenzial.

Was Sie tatsächlich bauen müssen

Das in den Begleitartikeln beschriebene System hat 84 Hooks, 43 Skills, 19 Agenten und 15.000 Zeilen Infrastruktur. Sie brauchen keine 15.000 Zeilen. Sie brauchen drei Dinge.

Einen Kontextinjektionshook. Fünf Zeilen Bash, die das aktuelle Datum, den Branch und das Arbeitsverzeichnis in jeden KI-Prompt injizieren. Das eliminiert eine ganze Kategorie von Halluzinationen: Das Modell hört auf, Dateipfade und Branchnamen zu erfinden, weil es echte hat.

#!/bin/bash
# inject-context.sh — minimum viable context injection
echo "Date: $(date +%Y-%m-%d)"
echo "Branch: $(git branch --show-current 2>/dev/null || echo 'not a git repo')"
echo "Directory: $(pwd)"

Ein Quality Gate. Fünfzehn Zeilen, die Abschlussberichte auf Abschwächungssprache durchsuchen. Wenn der Agent „sollte funktionieren” sagt, anstatt Testausgaben zu zitieren, blockiert das Gate. Das adressiert das Verifikationsvakuum am günstigsten Einstiegspunkt.¹⁵

#!/bin/bash
# quality-gate.sh — minimum viable verification
INPUT=$(cat)
HEDGES=$(echo "$INPUT" | grep -ciE '\bshould (work|pass|be fine)\b|\bprobably\b|\blooks correct\b')
if [ "$HEDGES" -gt 0 ]; then
  echo '{"decision":"block","reason":"Hedging language detected. Cite test output instead."}'
else
  echo '{"decision":"allow"}'
fi

Einen unabhängigen Test Runner. Ein Hook, der die Testsuite des Projekts nach jeder Codeänderung ausführt und laut fehlschlägt, wenn Tests brechen. Die Implementierung variiert je nach Projekt. Das Prinzip nicht: Der Agent, der Code schreibt, darf nicht der einzige Richter über diesen Code sein.

Beginnen Sie mit dem, was in Ihrem Workflow am häufigsten schiefgeht. Wenn Ihre KI Dateipfade halluziniert, bauen Sie zuerst den Kontexthook. Wenn Ihre KI ungetesteten Code ausliefert, bauen Sie zuerst den Test Runner. Wenn Ihre KI „fertig” schreibt, ohne Nachweise zu liefern, bauen Sie zuerst das Quality Gate.

Karpathy beschrieb die Entwicklung vom Vibe Coding zum Agentic Engineering: „Agenten orchestrieren, die [die Arbeit] erledigen, und als Aufsicht fungieren.”¹⁷ Die drei oben genannten Hooks sind die minimal tragfähige Aufsicht. Sie werden keine 30 % Verbesserung bringen. Sie werden Sie von 10 % in Richtung 15 % bewegen, und jeder weitere, den Sie hinzufügen, offenbart die nächste Einschränkung, die es zu adressieren lohnt.

Die Mauer ist real. Sie ist auch spezifisch. Kontexthunger, Verifikationsvakuum und Governance-Lücke sind Ingenieurprobleme mit Ingenieurlösungen. Die Modelle werden sich weiter verbessern. Die Mauer wird bei 10 % bleiben für jedes Team, das KI als Codegenerator behandelt statt als System, das Infrastruktur braucht, um seinen Output zu steuern.

Quellen