Die 10%-Mauer: Warum KI-Produktivität stagniert

DX befragte 121.000 Entwickler in 450 Unternehmen. 92,6 % nutzen KI-Programmierassistenten mindestens monatlich. KI-generierter Code macht inzwischen 26,9 % der in Produktion übernommenen Merges aus. Entwickler berichten von einer Zeitersparnis von rund vier Stunden pro Woche.¹ Die Produktivität hat die 10-%-Marke nicht überschritten.

Diese Zahl ist seit drei aufeinanderfolgenden Quartalen unverändert.^{1 2} Die Adoption stieg. Das Code-Volumen stieg. Die Tools verbesserten sich. Die Produktivitätsgewinne nicht. Laura Tacho, CTO bei DX, brachte es auf den Punkt: „Das ist wirklich ein Management-Problem. Der Hype hat es so klingen lassen, als würde sich das bloße Ausprobieren von KI automatisch auszahlen.”³

Der DORA-Bericht 2025 deckte die Divergenz auf. Organisationen mit starken Engineering-Praktiken erlebten, wie KI ihre bestehenden Stärken verstärkte. Organisationen mit schwachen Praktiken erlebten, wie KI ihre bestehenden Dysfunktionen verstärkte. Dieselben Tools. Entgegengesetzte Ergebnisse. Der Bericht 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 Modell-Problem. Sie ist ein Infrastruktur-Problem. 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 Ausgabetor, und Context Is Architecture erklärt das Kontextinjektionssystem. Der folgende Beitrag erklärt, warum diese Systeme existieren.

Zusammenfassung

121.000 befragte Entwickler, 92,6 % Adoption, Produktivität bei 10 % festgefahren. Drei Ursachen erklären die Obergrenze: Kontexthunger (die KI rät ohne Projektwissen), Verifikationsvakuum (Code wird schneller ausgeliefert, als sich Reviews anpassen können) und Governance-Lücke (KI umgeht Standards, die Menschen durchsetzen). DORA stellte fest, dass KI je nach umgebender Infrastruktur sowohl Stärken als auch Dysfunktionen verstärkt.⁴ Der Durchbruch erfordert Infrastruktur um die KI herum, nicht bessere KI. Dieser Beitrag dokumentiert einen N=1-Versuch, diese Infrastruktur aufzubauen, mit konkreten Zahlen aus einem System mit 84 Hooks, 43 Skills und 19 Agents.

Was die Umfrage zeigt

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

Die Adoptionsgeschichte ist eindeutig. KI-Programmierassistenten erreichten nahezu universelle Verbreitung. DX maß 92,6 % monatliche Nutzung und etwa 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 bei 24.534 Entwicklern in 194 Ländern.⁷ Die Adoptionsobergrenze ist nahe.

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 führte nicht zu zusätzlichem Output.^{1 2} Laura Tacho identifizierte die Rechnung: Entwickler verbringen etwa 20 % ihrer Zeit mit Code-Schreiben. Eine 10%ige Verbesserung bei 20 % des Arbeitstags ergibt insgesamt eine 2%ige Verbesserung. „Tippgeschwindigkeit war nie der Engpass.”⁸

Die entscheidende Zeile ist die letzte. DORAs Bericht 2024 befragte 39.000 Fachleute und stellte fest, dass bei jedem Anstieg der KI-Adoption um 25 % der Lieferdurchsatz schätzungsweise um 1,5 % und die Lieferstabilität um 7,2 % sank.⁵ Der DORA-Bericht 2025 stellte fest, dass sich die Beziehung zwischen KI und Durchsatz von der 2024 beobachteten negativen Korrelation zu einer positiven wandelte, die Lieferstabilität jedoch weiterhin negativ mit KI-Adoption assoziiert blieb.⁴ KI-Adoption 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 bei 246 realen Repository-Issues 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 %, aber das Ergebnis war statistisch nicht signifikant (95 %-KI überschritt Null).¹⁰

McKinsey fand Steigerungen von 35–50 % bei einfachen Aufgaben, aber weniger als 10 % bei hochkomplexen Aufgaben, und Junior-Entwickler waren bei einer Studie mit 40 eigenen Entwicklern mit KI 7–10 % langsamer.¹¹ Das Muster: KI beschleunigt die Teile der Entwicklung, die nie der Engpass waren.

Die Unternehmen, die den Durchbruch schafften, verwendeten keine besseren Modelle. Sie bauten Infrastruktur, die auffing, was die Modelle übersahen.

Warum die Mauer existiert

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

Kontexthunger

KI-Programmierassistenten arbeiten mit dem Code, der in der aktuellen Datei sichtbar ist, und dem Kontext, der in das Promptfenster passt. Sie kennen Ihre Architekturentscheidungen, Ihre API-Verträge, Ihre Deployment-Einschränkungen oder die Namenskonventionen Ihres Teams nicht – 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.

Das Verhalten ist kein Halluzinationsproblem im Sinne der Modellsicherheit. Das Modell funktioniert genau wie vorgesehen: Es prognostiziert wahrscheinlichen Code auf Basis des verfügbaren Kontexts. Das Problem ist, dass der verfügbare Kontext das meiste ausschließt, was für Korrektheit in einer bestimmten Codebasis wichtig ist.

Verifikationsvakuum

KI generiert Code schneller, als bestehende Review-Prozesse absorbieren können. Faros stellte fest, dass KI-unterstützte PRs 91 % länger zur Überprüfung 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 anfälligen Code gegenüber 7 % der Kontrollgruppe. Teilnehmer mit KI-Unterstützung glaubten häufiger, sicheren Code geschrieben zu haben, obwohl dies nicht der Fall war.¹³ Die Kombination aus schnellerer Ausgabe und höherem falschem Selbstvertrauen 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 zur Vor-KI-Basislinie voraussichtlich verdoppeln würde.¹⁴ Der Volumenanstieg 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 reparieren.⁶

Governance-Lücke

KI-generierter Code umgeht die Governance-Mechanismen, die menschliche Entwickler verinnerlicht haben. Ein erfahrener Entwickler weiß, dass er den Styleguide 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.

Die McKinsey-Forscher führten die Verlangsamung bei Junior-Entwicklern auf die Kluft zwischen generiertem Code und organisatorischem Kontext zurück. Junior-Entwicklern fehlt das Urteilsvermögen, um zu bewerten, ob KI-Ausgaben Standards entsprechen, 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 Hilfsprogramm eines Entwicklers dupliziert das bestehende Modul eines anderen Entwicklers. Zwei KI-generierte Endpunkte verwenden unterschiedliche Fehlerformate für dieselbe API. KI-erstellte 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. Organisationen mit starken Praktiken erlebten, wie KI ihre Stärken verstärkte. Organisationen mit schwachen Praktiken erlebten, wie KI ihre Dysfunktionen verstärkte.⁴ Die Variable zwischen ihnen ist nicht, welche KI sie verwenden. Es ist die Infrastruktur um die KI herum.

Jede Ursache lässt sich einem Infrastrukturfix zuordnen. Die folgende Tabelle zeigt die Kette von Problem zu Lösung, mit einer konkreten Implementierung aus einem System, das ich gebaut und in den Begleitartikeln dokumentiert habe. Das Beispiel ist ein einzelner Versuch mit konkreten Zahlen, kein universelles Rezept.

Kontextinjektion begegnet dem Kontexthunger, indem sichergestellt wird, dass das Modell bei jedem Prompt projektspezifische Informationen erhält. Ein Dispatcher-Hook löst neun sequenzielle Handler aus, die das aktuelle Datum, den Git-Branch, das Arbeitsverzeichnis, Projektkonventionen, aktiven Aufgabenkontext und Architektureinschränkungen injizieren. Das Modell erhält 200–400 Token Kontextverankerung, bevor es die Anfrage des Benutzers verarbeitet. Gemessene Latenz: 200 ms insgesamt für alle neun Hooks. Das Modell hört auf, Dateipfade zu raten, weil es die tatsächlichen Pfade erhalten hat.¹⁵

Unabhängige Verifikation begegnet dem Vakuum, indem Menschen bei Routineprüfungen aus dem Verifikationsengpass entfernt werden. Die autonome Entwicklungsschleife (dokumentiert in Anatomy of a Claw) generiert Code, führt die vollständige Testsuite aus und übermittelt die Ergebnisse an drei Review-Agents, die unabhängig voneinander arbeiten. Der Implementierungs-Agent überprüft niemals seine eigene Ausgabe. Die Trennung spiegelt das Ergebnis wider, dass die KI-unterstützte Gruppe in der Stanford-Studie bei unsicherem Code selbstsicherer war: Selbstverifikation ist unzuverlässig, unabhängig davon, ob der Autor Mensch oder KI ist.¹³

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

Das kombinierte System liefert messbare Ergebnisse in seiner eigenen 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 ausgeführt wird.¹⁵ Diese Zahlen beschreiben die Infrastruktur eines einzelnen Entwicklers. Sie können nicht beweisen, dass der Ansatz verallgemeinerbar ist. Sie können zeigen, 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 Urteils-Hooks, die entscheiden, ob etwas geschehen sollte, 44 Automatisierungs-Hooks, die vorbestimmte Aktionen ausführen, und 5 Hilfs-Hooks (Dispatcher, Zustandsverwaltung). Das Governance-Verhältnis beträgt 4:5. Am Anfang lag es bei 1:6.¹⁵

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

Die Verschiebung hin zu Urteils-Hooks zeigt, woher weitere Gewinne kommen.

McKinseys Umfrage 2025 unter fast 300 börsennotierten Unternehmen ergab, dass die leistungsstärksten Unternehmen Produktivitätsverbesserungen von 16–30 % und Qualitätsverbesserungen von 31–45 % verzeichneten.¹⁶ Diese Organisationen hatten eine Entwickler-Adoption von 80–100 % kombiniert mit organisatorischer Integration. Der entscheidende Faktor war nicht die Adoptionsrate (die durchgängig mit 10 % Gewinnen korreliert), sondern die Infrastruktur und Prozesse, die um diese Adoption herum aufgebaut wurden.

Laura Tachos Formulierung trifft auch hier zu: „Ich bin skeptisch gegenüber dem Versprechen jeder Technologie, die Leistung zu verbessern, ohne diese zugrundeliegenden Einschränkungen zu adressieren.”³ Die zugrundeliegenden Einschränkungen sind Urteilseinschränkungen. Erfüllt dieser Code unsere Standards? Bricht diese Änderung etwas Nachgelagertes? Enthält diese Ausgabe eine Fabrikation? Automatisierungs-Hooks können diese Fragen nicht beantworten. Urteils-Hooks können es – unvollkommen –, indem sie die Kriterien kodifizieren, die erfahrene Entwickler im Kopf anwenden.

Das Verhältnis hat noch keine Parität erreicht. Das System automatisiert immer noch mehr, als es steuert. Das Ungleichgewicht ist selbst eine Diagnose: Jede Orchestrierungsschicht, in der Automatisierungs-Hooks Urteils-Hooks zahlenmäßig übertreffen, hat Verbesserungspotenzial.

Was Sie tatsächlich bauen müssen

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

Einen Kontextinjektions-Hook. Fünf Zeilen Bash, die das aktuelle Datum, den Branch und das Arbeitsverzeichnis in jeden KI-Prompt injizieren. Die Injektion eliminiert eine ganze Kategorie von Halluzinationen: Das Modell erfindet keine Dateipfade und Branch-Namen mehr, weil es die echten 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 nach Absicherungssprache durchsuchen. Wenn der Agent „sollte funktionieren” sagt, statt Testausgaben zu zitieren, blockiert das Gate. Das Gate adressiert das Verifikationsvakuum am günstigsten möglichen 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. Einen 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 Kontext-Hook. 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 Evolution vom Vibe Coding zum Agentic Engineering: „Agents orchestrieren, die [die Arbeit] erledigen, und als Aufsicht agieren.”¹⁷ Die drei oben genannten Hooks sind die minimale tragfähige Aufsicht. Sie werden keine 30 % Gewinne erzeugen. Sie werden Sie von 10 % in Richtung 15 % bewegen, und jeder hinzugefügte Hook zeigt die nächste Einschränkung auf, die es wert ist, adressiert zu werden.

Die Mauer ist real. Sie ist auch spezifisch. Kontexthunger, Verifikationsvakuum und Governance-Lücke sind Engineering-Probleme mit Engineering-Lösungen. Die Modelle werden sich weiter verbessern. Die Mauer wird bei 10 % bleiben – für jedes Team, das KI als Code-Generator behandelt, statt als System, das Infrastruktur zur Steuerung seiner Ausgaben benötigt.

Kernaussagen

Für einzelne Entwickler. Beginnen Sie mit einem Kontextinjektions-Hook. Fünf Zeilen Bash, die Datum, Branch und Arbeitsverzeichnis injizieren, eliminieren eine ganze Kategorie von KI-Halluzinationen. Die Mauer beginnt zu brechen, wenn das Modell Ihre tatsächlichen Dateipfade kennt, statt sie zu erraten.

Für Teamleiter. Messen Sie Ihr Governance-Verhältnis: Wie viele Ihrer KI-Hooks verifizieren Ausgaben im Vergleich zu denen, die Aufgaben automatisieren? Wenn Automatisierungs-Hooks Urteils-Hooks zahlenmäßig übertreffen, erfasst Ihr Team nur die ersten 10 %. DXs Daten bestätigen, dass die vier eingesparten Stunden pro Woche aus Code-Generierung stammen – Aufgaben, die bereits der schnellste Teil des Entwicklungszyklus waren.¹

Für Plattform-Ingenieure. Bauen Sie die Verifikationsschicht, bevor Sie die KI-Adoption skalieren. DORA stellte fest, dass Organisationen, die KI ohne Engineering-Infrastruktur einsetzten, mit zunehmender Adoption steigende Instabilität erlebten.^{4 5} Die drei Ursachen lassen sich drei Infrastrukturlösungen zuordnen. Beginnen Sie mit derjenigen, die in Ihrer Pipeline die größte Reibung verursacht.

Quellen