Warum schnelleres Coding nicht automatisch schnellere Delivery bedeutet

Die Studien messen verschiedene Dinge

Studien zur Entwicklerproduktivität scheinen sich oft zu widersprechen. Der Grund: Die Zahlen in den Schlagzeilen beantworten unterschiedliche Fragen.

Die Aufgabenzeit gibt an, wie lange eine Person für eine abgegrenzte Aufgabe braucht. Selbst berichtete Zeitersparnis erfasst, was die Leute wahrnehmen. Der PR-Durchsatz zählt akzeptierte Änderungen, die CI-Aktivität zählt Versuche, Arbeit zu integrieren, und der Main-Branch-Erfolg zeigt, ob diese Versuche durchgehen. Ob Kundinnen und Kunden früher Wert bekommen haben, verrät einer Organisation keine dieser Größen für sich allein.

Vergleichbar wird eine Zahl erst, wenn Population, Aufgabe, Messfenster und Qualitätsgrenze danebenstehen.

Was METR herausfand und was sich seitdem geändert hat

In METRs randomisierter Studie von Anfang 2025 brauchten 16 erfahrene Open-Source-Entwickler:innen 19 Prozent länger, wenn sie die damals verfügbaren Produkte nutzen konnten. Sie hatten mit einem Tempogewinn gerechnet und glaubten auch nach getaner Arbeit noch, schneller gewesen zu sein.

Das Umfeld spielt eine Rolle. Die Entwickler:innen arbeiteten in gewachsenen Repositories, die sie gut kannten, und die Aufgaben verlangten genau den Kontext, den kleine Coding-Benchmarks meist herausnehmen.

Danach setzte METR eine größere Folgestudie mit neueren Produkten auf. Im Februar 2026 berichtete METR, dass das neue Design keine verlässliche Schätzung der aktuellen Geschwindigkeit mehr hergab. Immer öfter lehnten Entwickler:innen Aufgaben ab, die keine Agenten zuließen, und parallel arbeitende Agenten machten die Zeitmessung schwieriger. Die Rohdaten deuteten auf eine Verbesserung, deren Größe METR aber für schwach belegt hielt.

Ehrlich gelesen gehören beide Ergebnisse dazu. Frühe Produkte haben diese Gruppe von Spezialist:innen in einem realistischen Umfeld gebremst. Neuere Produkte wirken nützlicher, doch wie groß der Effekt heute ist, lässt sich mit derselben Methode nur schwer bestimmen.

Das Delivery-System kann lokale Gewinne schlucken

Für DORAs Forschung von 2025 ist KI-gestützte Entwicklung ein Verstärker des Systems, in dem sie läuft. Teams brauchen nach wie vor eine gesunde Plattform, klare Regeln, den Blick auf die Nutzer und verlässliches Feedback. Schneller geschriebener Code bringt wenig, wenn die Arbeit danach auf Review, Integration, eine Produktentscheidung oder ein Release-Fenster wartet.

CircleCIs Telemetrie von 2026 zeigt, wo sich die Arbeit weiter hinten im Prozess staut. In mehr als 28 Millionen Workflows lag die durchschnittliche Aktivität 59 Prozent über dem Vorjahr. Beim Median-Team wuchs die Aktivität auf Feature-Branches, während der Durchsatz auf dem Main-Branch zurückging. Die Erfolgsrate auf dem Main-Branch lag bei 70,8 Prozent, so niedrig wie seit fünf Jahren nicht in diesem Datensatz.

Bei der Spitzengruppe sah es anders aus: Änderungsvolumen und Main-Branch-Durchsatz wuchsen gemeinsam. Der Bericht verbindet das mit Validierungs- und Wiederherstellungskapazität, die mit der Generierung mithielt.

Adoption ist noch kein Ergebnis

In seiner Unternehmensstichprobe aus dem ersten Quartal 2026 meldet DX eine Branchen-Adoption von 93 Prozent. Bei dieser Quote sagt der Vergleich von Nutzer:innen und Nichtnutzer:innen wenig. Aufschlussreicher ist, was sich in einem Team verändert, je tiefer die Nutzung geht.

DX fand einen ungleichmäßigen Durchsatz und eine schwankende Qualität. Einige Teams legten zu, andere hatten mehr Fehler oder schlechter wartbaren Code. Die selbst berichtete Zeitersparnis war größer als die Veränderung, die sich über die Zeit im PR-Durchsatz zeigte.

An einem Adoptionsziel lässt sich ablesen, dass ein Produkt im Haus ist. Ob die Organisation schneller oder mit mehr Vertrauen liefert, belegt es nicht.

Ein Messset, das einer Prüfung standhält

Fangt beim Wertstrom an, nicht bei der Produktlizenz, und haltet eine Ausgangslage fest, bevor ihr am System etwas ändert.

Stellt die Durchlaufzeit von der Idee bis zu den ersten Nutzer:innen neben Review-Zeit, Nacharbeit, Fehlerrate und Wiederherstellungszeit. Nehmt das Vertrauen der Entwickler:innen hinzu: Ein System kann gesund aussehen, während die Menschen darin Verständnis verlieren. Das geschäftliche Ergebnis benennt ihr getrennt.

Die Messgrößen sollen zeigen, wo Arbeit wartet und ob der Engpass weitergezogen ist. Damit kommt ihr weiter als mit der Suche nach dem einen universellen Produktivitätsmultiplikator.

Zwei Frühindikatoren aus einem Praxisinterview

In einem Praxisinterview (öffnet in einem neuen Tab) schlägt Patrick Debois zwei Frühindikatoren für Teams vor, die Coding-Agenten einsetzen. Der erste ist die Zahl der menschlichen Eingriffe, die ein Team noch braucht, bis der Agent das Richtige tut. Je besser Harness, Kontext und Leitlinien werden, desto kleiner sollte sie werden. Schlüsselt sie nach Risiko oder Art der Änderung auf, denn eine risikoreiche Migration und eine kleine Textkorrektur brauchen unterschiedlich viele Eingriffe, und ein Durchschnitt über alles verdeckt das Muster. Der zweite ist, wie weit geteilter Kontext, Skills und Harness-Komponenten übernommen und wiederverwendet werden. Breitet sich das Setup eines Teams aus und nutzen andere es weiter, verzinst sich die Investition. Fängt jedes Team bei null an, bleibt dieser Effekt aus.

Keiner der beiden ist ein Ergebnis, und keiner eignet sich allein als Zielgröße. Macht man Eingriffe zur Zielgröße, kann ein Team ungeprüftes Risiko ausliefern. Erzwingt man Wiederverwendung, können sich Teams auf das falsche Muster festlegen. Lest beide zusammen mit den Größen von oben: Fluss, Review, Nacharbeit, Fehlerrate, Wiederherstellung, Vertrauen, Kosten und Geschäftsergebnis. Debois’ Bericht zeigt, wohin man schauen sollte. Es ist die Sicht eines einzelnen Praktikers und kein unabhängiger Beleg dafür, dass diese Signale Delivery vorhersagen.