KI-Produktivitätsstudien: METR, Stanford, DORA, Multitudes
Keine einzelne Zahl zur KI-Produktivität hält. METR maß erfahrene Entwickler:innen in vertrauten Repositories 19% langsamer. Stanford fand einen Median-Gewinn nahe 10%, der mit wachsenden Aufgaben und Codebasen schrumpft. DORA sieht KI als Verstärker des bestehenden Systems, und Multitudes knüpft Gewinne an Lernzeit.
Verfasst von
-
Benedikt Stemmildt Gründer & Co-CEO
Aktualisiert:
Belege 7
Unsere Position. Für uns ist Nutzung kein ROI. Ein Team kann das Tool intensiv nutzen und trotzdem nicht schneller liefern, denn der Bottleneck war nie das Tippen. Deshalb messen wir das gelieferte Ergebnis statt der Tool-Nutzung (Usage is not ROI (öffnet in einem neuen Tab)).
Vier Studien stützen diese Position aus verschiedenen Richtungen, weil jede etwas anderes zählt. METR maß in einem kontrollierten Versuch die Zeit bis zum Abschluss von Aufgaben. Stanford maß den Output über einen großen Datensatz von Entwickler:innen, DORA befragte Teams, und Multitudes kombinierte Umfragen, Interviews und Telemetrie.
Wurden erfahrene Entwickler:innen in METRs Versuch mit KI schneller?
METR führte eine randomisierte kontrollierte Studie mit 16 erfahrenen Open-Source-Entwickler:innen durch, die in gut bekannten Repositories arbeiteten. Mit KI-Tools vom Stand Anfang 2025 brauchten die Teilnehmenden 19% länger für ihre Aufgaben. Trotzdem erwarteten sie, dass die Tools sie schneller machen. METR beschreibt das Ergebnis als Momentaufnahme der Fähigkeiten von Anfang 2025 in einem relevanten Setting. Ein allgemeines Gesetz für alle Entwickler:innen oder Aufgaben sei es nicht (METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (öffnet in einem neuen Tab)).
Für die Messung liefert die Studie zwei nützliche Punkte. Die gefühlte Geschwindigkeit kann von der gemessenen Bearbeitungszeit abweichen. Realistische Arbeit in einer vertrauten Codebasis kann außerdem ein anderes Ergebnis liefern als in sich geschlossene Coding-Benchmarks.
Wo zeigen sich KI-Gewinne in den Daten aus Stanford?
Stanford-Forschung aus zwei öffentlichen Talks berichtet über einen großen Datensatz von Entwickler:innen einen Median-Produktivitätsgewinn um 10%. Die berichteten Gewinne sinken, wenn Komplexität der Aufgabe und Größe der Codebasis steigen. Die Sauberkeit der Codebasis korreliert dabei stärker mit der Produktivität als der Token-Verbrauch (Stanford-Talk zur Produktivitätsforschung im Software Engineering (öffnet in einem neuen Tab)).
Ein viermonatiger Vergleich im Unternehmenskontext zeigt, warum Output Guardrails für Qualität braucht. Die Zahl der Pull Requests stieg, während die Codequalität sank und das Rework zunahm. Der effektive Output blieb dadurch weitgehend flach (Stanford-Talk zur Messung von KI-ROI (öffnet in einem neuen Tab)). Diese Ergebnisse sprechen dafür, Delivery und Rework gemeinsam zu messen, statt generierten Code oder Pull-Request-Zahlen als Produktivität zu werten.
Was meint DORA mit KI als Verstärker?
Der DORA-Report zu KI-gestützter Entwicklung beschreibt KI als Verstärker bestehender Stärken und Schwächen einer Organisation. Der Report empfiehlt, das zugrunde liegende System zu verbessern und Ergebnisse der Software Delivery zu messen statt allein die Adoption (DORA, State of AI-assisted Software Development 2025 (öffnet in einem neuen Tab)).
Reife wird damit zur Bedingung, nicht zur Garantie. Schnellere Generierung kann Bottlenecks in Review, Testing und Deploy sichtbar machen, die schon vorher bestanden.
Wovon hängt die KI-Adoption laut Multitudes ab?
Multitudes kombinierte Umfrageantworten, Interviews und Telemetrie, um zu erforschen, wie sich Engineering-Organisationen an KI anpassen. Die öffentlichen Ergebnisse betonen Zeit zum Lernen, Unterstützung durch Kolleg:innen sowie Änderungen an Codebasis und Entwicklungsprozess. Die Forschung zeigt außerdem eine Lücke zwischen den gewünschten Ergebnissen und den Kennzahlen, die Organisationen nutzen (Multitudes-Forschung (öffnet in einem neuen Tab)).
Die Evidenz spricht dafür, Adoption als organisatorische Veränderung mit ausdrücklicher Lernzeit zu behandeln. Eine Lizenz oder ein Nutzungsziel belegt noch keine Produktivität.
Wie lest ihr die Studien zusammen?
- Vergleicht Gleiches mit Gleichem: Abschluss von Aufgaben, Delivery-Durchsatz, Qualität und selbst berichtete Zeitersparnis beantworten verschiedene Fragen.
- Stellt Output-Kennzahlen neben Rework, Review-Zeit, Defekte und Stabilität der Delivery.
- Nennt neben jeder Zahl Population, Art der Aufgabe und Messzeitraum.
- Behandelt Berichte von Anbietern und Praktiker:innen als Hinweis auf eine Richtung, solange ihre Methoden und Daten nicht öffentlich sind.
Verwandte Seiten
- DX AI Impact Report: KI-gestützte Entwicklung im Benchmark: der quartalsweise Benchmark, der Adoption und PR-Durchsatz in mehr als 400 Unternehmen gegenüberstellt.
- Der DORA-Report zu KI-gestützter Entwicklung: die Verstärker-These vollständig, und die Telemetrie, die ihr widerspricht.
- Amazon Cost to Serve Software (CTS-SW): die Ergebniskennzahl eines Unternehmens, die Delivery bepreist, statt eingesparte Minuten zu zählen.
- KI-Produktivität: Evidenz und Qualität: was die Zahlen für Codequalität und Rework bedeuten.
- Impact messen: wie ihr die Ergebnismessung aufbaut, die diese Studien verlangen.