KI-Produktivität: Die 19 Prozent von METR sind überholt

Die meistzitierte Zahl zur KI-Produktivität ist überholt. METR mass 2025 an 16 erfahrenen Open-Source-Entwicklern 19 Prozent mehr Zeitbedarf mit KI-Werkzeugen. Die Nachfolgestudie derselben Organisation, ab August 2025 mit 57 Entwickelnden, misst 18 Prozent weniger Zeit bei denselben Personen. Beide Intervalle sind so breit, dass gesichert davon nichts ist.

Warum die 19-Prozent-Zahl heute falsch zitiert wird

Die 19 Prozent stammen aus einer randomisierten Studie von METR, Februar bis Juni 2025: 16 erfahrene Entwickler, 246 Issues in ihren eigenen Repositories mit im Schnitt über 22’000 Sternen. Werkzeug war überwiegend Cursor Pro mit Claude 3.5 und 3.7 Sonnet.

Der Befund war unbequem und wurde deshalb viel zitiert: Die Entwickler erwarteten vorher 24 Prozent Beschleunigung, glaubten nachher an 20 Prozent Beschleunigung, und waren gemessen 19 Prozent langsamer.

METR hat die Untersuchung fortgesetzt. Die Aktualisierung vom 24. Februar 2026 berichtet eine zweite Studie ab August 2025: 57 Entwickelnde, davon 10 aus der Originalstudie und 47 neu, 143 Repositories, über 800 Aufgaben. Alle Werte in derselben Metrik, Zeitbedarf mit KI gegenüber ohne, ein Minus bedeutet weniger Zeit:

Das Ergebnis hat sich nicht abgeschwächt, es hat das Vorzeichen gewechselt. Wichtiger ist der Unterschied in den Intervallen: Das der Originalstudie schliesst die Null aus, die beiden neuen schliessen sie ein. Belegt ist damit weder Verlangsamung noch Beschleunigung.

METR misstraut dem eigenen Ergebnis, und begründet das sauber

METR schreibt selbst, die Daten taugten nicht als Produktivitätsmass. Wörtlich zur Selektionsverzerrung: «Because of the selection effects in our experiment, our data is only very weak evidence for the size of this increase.» Und zum zentralen Schätzwert: «we believe it is likely a bad proxy for the real productivity impact.»

Der Grund dafür ist die interessanteste Stelle der ganzen Debatte. METR senkte die Vergütung von 150 auf 50 Dollar pro Stunde. Damit veränderte sich, wer überhaupt mitmacht und welche Aufgaben eingereicht werden.

«30% to 50% of developers told us that they were choosing not to submit some tasks because they did not want to do them without AI», heisst es im Bericht. Ein Teilnehmer im Originalton: «I avoid issues like AI can finish things in just 2 hours, but I have to spend 20 hours.»

Genau dort bricht die Messbarkeit. Wer die Aufgaben aussortiert, bei denen KI am meisten hilft, misst systematisch zu tief. METR räumt ein, dass die Ergebnisse den wahren Effekt wahrscheinlich unterschätzen. Dazu kommt: Manche Teilnehmenden liessen mehrere Agenten parallel laufen, was die Zeitmessung entwertet.

Wenn Sie gerade einen Business Case für KI-Werkzeuge schreiben und merken, dass Ihnen die belastbare Zahl fehlt: Das liegt nicht an Ihrer Recherche. Eine halbe Stunde mit jemandem, der die Primärquellen gelesen hat, ist an dieser Stelle billiger als eine weitere Woche Suche.

Die Gegenzahl aus dem anderen Lager stammt von 2022

Die berühmten 55 Prozent Beschleunigung sind eine Anbieterzahl aus dem Jahr 2022. GitHub Next veröffentlichte sie am 7. September 2022, gemeinsam mit dem Office of the Chief Economist von Microsoft. 95 Entwickelnde, zufällig in zwei Gruppen geteilt, eine einzige Aufgabe: einen HTTP-Server in JavaScript schreiben.

Die Copilot-Gruppe brauchte 1 Stunde 11 Minuten, die Kontrollgruppe 2 Stunden 41 Minuten. Das Konfidenzintervall reicht von 21 bis 89 Prozent.

Drei Dinge daran sollte man kennen, bevor man die Zahl in eine Präsentation setzt. Sie stammt vom Hersteller des getesteten Werkzeugs. Sie misst eine abgeschlossene Laboraufgabe ohne bestehende Codebasis, ohne Review und ohne Betrieb. Und sie ist vier Jahre alt, aus einer Zeit vor agentischen Werkzeugen.

Wer welche Zahl erhoben hat, und wer sie bezahlt hat

Die folgende Gegenüberstellung ordnet die sechs Zahlen, die in dieser Debatte tatsächlich zirkulieren, nach Herkunft, Finanzierung und Haltbarkeit. Stand aller Abrufe: 20. August 2026.

Die Finanzierungsspalte ist keine Höflichkeit. DORA ist ein Programm von Google Cloud, und Google verkauft mit Gemini, Jules und Antigravity konkurrierende Werkzeuge. Das macht die Methodik nicht schlecht, sie geniesst zu Recht Ansehen. Aber ein Report, der Firmen hilft, KI-Budgets zu verteidigen, hat einen Absender mit Interesse an KI-Budgets.

Der Verstärker-Befund ist die belastbarste Aussage der Forschung

Die stabilste Erkenntnis lautet, dass KI-Werkzeuge vorhandene Engineering-Reife verstärken statt sie zu ersetzen. DORA formuliert es im State of DevOps 2025 so: «AI acts as an amplifier, but the greatest returns come from focusing on the underlying sociotechnical systems.»

Zwei akademische Arbeiten aus 2026 zeigen denselben Mechanismus von unten. Die Untersuchung «Safer Builders, Risky Maintainers» von Ferdous, Banik, Chowdhury und Shamim verglich 7’191 agentenerzeugte Pull Requests mit 1’402 menschlichen aus Python-Repositories und erkannte Breaking Changes über eine AST-Analyse.

Beim Neubau brechen Agenten seltener die Kompatibilität als Menschen. Bei Wartungsarbeiten kehrt sich das um. Die Autoren beschreiben zusätzlich eine «Confidence Trap»: Auch Pull Requests mit hohem Selbstvertrauens-Score des Agenten enthalten Breaking Changes. Der Score taugt nicht als Review-Filter.

Die zweite Arbeit, «(Im)Paired Programming» von Balepur und Kollegen, liess 54 Studierende eine Website bauen, mit einem Agenten oder mit einem Chatbot, und prüfte danach das Verständnis über Verständnisfragen und über eine Erweiterungsaufgabe ohne Agent. Befund: Agenten helfen beim Fertigwerden und schaden dem Verständnis, und ausgerechnet die bequemen Interaktionsformen, Copy-Paste-Prompts und automatisch akzeptierte Edits, korrelieren mit dem schlechtesten Verständnis. Die Einschränkung gehört dazu: 54 Studierende sind kein Engineering-Team.

Warum das die Verstärkerthese stützt: In beiden Arbeiten entscheidet nicht das Werkzeug, sondern wo und wie es eingesetzt wird. Dieselbe Beobachtung aus der Praxisseite, ohne Zahlen, steht in KI schreibt den Code, wer schreibt die Architektur.

Was die Spannweite für eine Kapazitätsplanung bedeutet

Das Konfidenzintervall der Zweitstudie ist zu breit, um damit zu budgetieren. Rechnen wir es einmal in Schweizer Franken durch, damit die Grössenordnung sichtbar wird.

Modellrechnung, keine Erhebung: ein Team von zehn Entwickelnden, 1’800 Arbeitsstunden pro Person und Jahr, also 18’000 Stunden. Als Stundensatz nehmen wir CHF 160, den Mittelwert aus dem publizierten Rechenbeispiel von gryps.ch für Softwareentwicklung in der Deutschschweiz (abgerufen 20. August 2026). Die Jahreskapazität entspricht damit CHF 2’880’000.

Zwischen den beiden Intervallgrenzen liegen CHF 1’353’600. Mit einer solchen Bandbreite plant niemand ein Budget, und das ist die ehrliche Auskunft der Forschung, nicht ihr Versagen.

Die Rechnung überträgt METRs Werte bewusst grob auf eine Jahreskapazität. METR hat Issue-artige Aufgaben in reifen Open-Source-Repositories gemessen, keine vollständigen Arbeitsjahre mit Meetings, Betrieb und Incidents. Wer die Zahlen eins zu eins auf sein Team überträgt, macht denselben Fehler wie die Lager, die er kritisiert.

Messen Sie stattdessen Ihre eigene Basislinie

Die brauchbarste Reaktion auf eine unklare Studienlage ist eine eigene Vorher-Messung. Zwei Kennzahlen genügen für den Anfang, und beide liegen bereits in Ihrem Repository.

Erstens ein Proxy für die Change Failure Rate, aus dem Git-Log über 90 Tage:

# Alle Commits der letzten 90 Tage
git log --since="90 days ago" --no-merges --oneline | wc -l

# Davon Reverts und Hotfixes
git log --since="90 days ago" --no-merges --oneline \
  --grep="^Revert" --grep="^hotfix" --grep="^fix!" -i | wc -l

Zweitens die Grösse der Änderungen pro Autor, um agentenerzeugte und menschliche Pull Requests zu trennen:

gh pr list --state merged --limit 200 \
  --json number,author,additions,deletions,mergedAt \
  --jq '.[] | [.author.login, .additions + .deletions] | @tsv'

Erheben Sie beides einen Monat vor dem Rollout und drei Monate danach. Diese zwei Zahlen sagen mehr über Ihr Team aus als jede Studie in diesem Beitrag. Wie Sie die Entscheidungen dahinter festhalten, damit die Messung in einem Jahr noch interpretierbar ist, steht in Architekturentscheidungen dokumentieren.

Was es im August 2026 nicht gibt

Drei häufig erwartete Quellen existieren zum Zeitpunkt dieses Beitrags nicht, und wer sie zitiert, zitiert etwas Erfundenes.

• Keinen State-of-DevOps-Report 2026. dora.dev/research führt 2025 als jüngsten Eintrag. Neu ist nur ein Zwischenprodukt, der «ROI of AI-assisted Software Development report», zuletzt aktualisiert am 22. April 2026, samt ROI-Rechner.
• Keine Stack Overflow Developer Survey 2026. Das Archiv listet 2011 bis 2025. Die 2025er Ausgabe bleibt der Stand.
• Keinen Technology Radar Vol. 35. Vol. 34 vom April 2026 ist die aktuelle Ausgabe, mit «Putting coding agents on a leash» als einem der vier Themen.

Wovon wir abraten

Wir raten von drei Dingen ab, und das erste betrifft die Zahlen in diesem Beitrag selbst. Erstens: einen ROI-Business-Case auf einen Punktschätzer stützen, gleich aus welchem Lager. Die belastbare Aussage der Forschung ist eine Bandbreite, kein Wert.

Zweitens: den Confidence-Score eines Agenten als Review-Filter benutzen. Die Confidence Trap aus «Safer Builders, Risky Maintainers» ist genau dieser Fehler, empirisch belegt. Staffeln Sie die Review-Tiefe stattdessen nach Aufgabentyp. Neubau darf lockerer laufen, Refactoring und Wartung brauchen strenge Kontrolle.

Drittens: Auto-Accept als Standardeinstellung. Nach «(Im)Paired Programming» ist es die Interaktionsform mit dem schlechtesten Verständnisergebnis.

Wo unsere Empfehlung nicht passt: bei Wegwerf-Prototypen und Spikes. Wer eine Woche lang eine Machbarkeit prüft und den Code danach löscht, braucht keine gestaffelte Review-Tiefe. Der Aufwand lohnt sich ab dem Moment, in dem jemand den Code in einem Jahr noch lesen muss.

Und ein Schweizer Detail, das in der internationalen Debatte untergeht: Die methodisch sauberste Arbeit zu Kontextdateien für Coding-Agenten kommt von der ETH Zürich. Gloaguen, Mündler, Müller, Raychev und Vechev zeigten im Februar 2026, revidiert im Juni, dass AGENTS.md-Dateien die Erfolgsrate generell nicht verbessern, die Inferenzkosten aber um über 20 Prozent erhöhen. Drei der Autoren sind mit LogicStar AG in Zürich verbunden, Martin Vechev leitet an der ETH das Secure, Reliable and Intelligent Systems Lab.

Häufige Fragen

Stimmt es, dass KI Entwickler 19 Prozent langsamer macht?

Das war der Befund einer METR-Studie von Februar bis Juni 2025 mit 16 erfahrenen Open-Source-Entwicklern. Die Nachfolgestudie derselben Organisation, ab August 2025 mit 57 Entwickelnden und über 800 Aufgaben, misst das Gegenteil: 18 Prozent weniger Zeitbedarf bei den wiederkehrenden Teilnehmenden. Wer die 19 Prozent heute als Beleg anführt, zitiert den überholten Stand.

Woher kommt die Zahl «55 Prozent schneller»?

Aus einer Untersuchung von GitHub Next und dem Office of the Chief Economist von Microsoft, publiziert am 7. September 2022. 95 Entwickelnde schrieben einen HTTP-Server in JavaScript, mit oder ohne Copilot. Es ist eine Anbieterzahl aus dem Jahr 2022, gemessen an einer einzelnen Laboraufgabe ohne bestehende Codebasis, ohne Review und ohne Betrieb.

Welche Aussage der Forschung ist am belastbarsten?

Der Verstärker-Befund. DORA formuliert im State of DevOps 2025, KI wirke als Verstärker und die grössten Erträge entstünden durch Arbeit an den zugrunde liegenden soziotechnischen Systemen. Zwei akademische Arbeiten aus 2026 zeigen denselben Mechanismus im Detail: Der Effekt hängt vom Aufgabentyp und von der Arbeitsweise ab, nicht vom Werkzeug.

Warum ist der Produktivitätseffekt so schwer zu messen?

Weil die Teilnehmenden die Messung beeinflussen. Als METR die Vergütung von 150 auf 50 Dollar pro Stunde senkte, gaben 30 bis 50 Prozent der Entwickelnden an, bestimmte Aufgaben nicht einzureichen, weil sie diese nicht ohne KI erledigen wollten. Wer genau die Aufgaben aussortiert, bei denen KI am meisten hilft, misst systematisch zu tief.

Was misst man im eigenen Team stattdessen?

Zwei Kennzahlen aus dem eigenen Repository, je einmal vor und drei Monate nach der Einführung: die Rate an Reverts und Hotfixes über 90 Tage als Proxy für die Change Failure Rate, und die Änderungsgrösse pro Autor, um agentenerzeugte von menschlichen Pull Requests zu trennen. Beide sind mit git log und gh pr list in wenigen Minuten erhoben.

Legen wir Ihre Zahlen daneben

Bringen Sie Ihre Git-Historie und die Frage mit, die Ihr Management Ihnen gestellt hat. Wir erheben die Basislinie gemeinsam und sagen Ihnen, welche der zitierten Studien auf Ihren Fall überhaupt zutrifft und welche nicht.

Termin buchen oder schreiben Sie uns. Womit wir Teams beim Einsatz dieser Werkzeuge begleiten, steht unter Künstliche Intelligenz & Machine Learning.