Coding Agents und Produktivität: Was die METR-Studien tatsächlich zeigen

Ausgangslage

Produktivitätsangaben zu Coding Agents werden häufig wie Produkteigenschaften behandelt: ein Prozentwert, der sich vom Benchmark direkt auf ein Entwicklungsteam übertragen lasse. Die METR-Veröffentlichungen zeigen das Gegenteil. Sie sind vor allem deshalb aufschlussreich, weil sich an ihnen beobachten lässt, wie ein sauberer früher Befund durch neue Werkzeuge, andere Nutzungsmuster und schwierigere Stichproben neu eingeordnet werden muss.

Die zentrale Frage lautet deshalb nicht, ob KI Softwareentwicklung generell beschleunigt. Eine belastbare Entscheidung braucht eine engere Frage: Welche Aufgaben erledigt ein bestimmtes Team mit einem definierten Werkzeug unter kontrollierten Qualitätsanforderungen schneller oder besser?

Der frühe randomisierte Befund

METR untersuchte Anfang 2025 erfahrene Open-Source-Entwickler, die an ihnen vertrauten Repositories arbeiteten. 246 reale Aufgaben wurden zufällig einer Arbeit mit oder ohne frühe KI-Werkzeuge zugeordnet. Im gemessenen Setting benötigten die Entwickler mit KI im Mittel 19 Prozent mehr Zeit. Gleichzeitig erwarteten sie vorab eine Beschleunigung und schätzten ihre Arbeit auch nach Abschluss schneller ein, als sie tatsächlich war.

Das Ergebnis ist fachlich relevant, aber eng begrenzt. Es betrifft erfahrene Maintainer, vertraute Codebases, bestimmte Aufgaben und Werkzeuge aus einer frühen Entwicklungsphase. Es beweist weder, dass Coding Agents grundsätzlich bremsen, noch dass subjektive Einschätzungen wertlos sind. Es zeigt, dass wahrgenommene Leichtigkeit und gemessene Durchlaufzeit auseinanderfallen können.

Für die betriebliche Praxis folgt daraus ein einfacher Grundsatz: Akzeptanzmessung ersetzt keine Leistungsmessung. Ein Werkzeug kann sich angenehm anfühlen, mehr Code produzieren und dennoch zusätzliche Prüf-, Korrektur- oder Koordinationszeit verursachen.

Warum spätere Ergebnisse schwieriger wurden

METR versuchte die Untersuchung mit neueren Werkzeugen fortzusetzen. Die spätere Auswertung weist jedoch ausdrücklich auf Selektionsprobleme hin. Teilnehmende konnten stärker selbst entscheiden, wann sie KI einsetzen. Wer ein Werkzeug bereits produktiv beherrscht oder von seinem Nutzen überzeugt ist, wählt es häufiger. Parallel arbeitende Agenten erschweren außerdem die Zuordnung von Arbeitszeit: Ein Entwickler kann warten, prüfen, eine zweite Aufgabe beginnen oder mehrere Agenten koordinieren.

Im Frontier Risk Report von Mai 2026 beschreibt METR für öffentliche Agenten aus Ende 2025 einen kleinen positiven Produktivitätseffekt in einer Größenordnung von ungefähr vier bis zwanzig Prozent. Zugleich wird erläutert, warum auch dieser Bereich wahrscheinlich nicht die volle Wirkung abbildet und warum Selbstberichte deutlich höhere, aber unsicherere Werte ergeben.

Die beiden Befunde widersprechen sich daher nicht zwangsläufig. Sie beschreiben unterschiedliche Werkzeugstände und Messbedingungen. Genau diese zeitliche und methodische Einordnung fehlt, wenn nur die Zahl von minus 19 Prozent oder nur eine spätere Beschleunigung zitiert wird.

Was überhaupt als Produktivität zählt

Durchlaufzeit ist eine wichtige, aber unvollständige Größe. Für Software Delivery sind mindestens drei Ebenen zu unterscheiden:

1. Aufgabenebene: Bearbeitungszeit, Wartezeit, Zahl der Iterationen und Anteil erfolgreich abgeschlossener Aufgaben.
2. Qualitätsebene: Defekte, Review-Aufwand, Testabdeckung, Sicherheitsbefunde, Verständlichkeit und spätere Nacharbeit.
3. Systemebene: Deployment-Frequenz, Change Failure Rate, Wiederherstellungszeit, Arbeitsfluss und Belastung anderer Rollen.

Eine lokale Beschleunigung kann die Systemleistung verschlechtern. Mehr Pull Requests helfen nicht, wenn Reviews zum Engpass werden. Kürzere Implementierungszeit ist kein Gewinn, wenn schwer erkennbare Fehler erst im Betrieb auffallen. Umgekehrt kann ein Agent auch dann nützlich sein, wenn eine einzelne Aufgabe nicht schneller endet, aber bessere Tests, Dokumentation oder Alternativen entstehen.

Der OpenAI-Audit von SWE-Bench Pro illustriert ein verwandtes Problem. Nach der veröffentlichten Prüfung waren rund 30 Prozent der untersuchten Aufgaben beschädigt oder nicht zuverlässig auswertbar. Unter anderem wurden unzureichende Tests, unklare Anforderungen und irreführende Aufgabenbeschreibungen genannt. Ein präzise berechneter Score bleibt wertlos, wenn das Messinstrument nicht das erfasst, was die Organisation entscheiden möchte.

Ein belastbares internes Evaluationsdesign

Aus unserer Sicht sollte ein Unternehmen keine allgemeine Agentenquote suchen, sondern eine wiederholbare lokale Messung aufbauen.

1. Aufgabenklassen vorab definieren

Geeignet sind wiederkehrende, ausreichend vergleichbare Aufgaben: kleine Fehlerkorrekturen, Testergänzungen, Migrationen, Dokumentation oder klar geschnittene Features. Explorative Architekturarbeit sollte separat betrachtet werden. Die Klassifikation muss vor der Messung stehen, sonst werden erfolgreiche Fälle nachträglich bevorzugt.

2. Baseline und Qualitätsgrenzen festlegen

Vor dem Agenteneinsatz braucht es historische oder kontrolliert erhobene Vergleichsdaten. Akzeptanzkriterien, Tests, Security Checks und Review-Regeln bleiben identisch. Nicht bestandene Qualitätsgrenzen dürfen nicht durch kürzere Bearbeitungszeit kompensiert werden.

3. Gesamte aktive Arbeit erfassen

Zur Arbeitszeit gehören Prompting, Kontextaufbereitung, Warten, Prüfung, Korrektur und verworfene Versuche. Bei parallelen Agenten sollte zusätzlich die Kalenderzeit bis zur verwertbaren Änderung erfasst werden. Beide Größen beantworten unterschiedliche Fragen.

4. Ergebnis und Nebenwirkungen gemeinsam entscheiden

Eine Einführung ist gerechtfertigt, wenn sich der gewünschte Effekt über mehrere Aufgabenklassen stabil zeigt, die Qualitätsgrenzen halten und keine untragbare Last in Review oder Betrieb entsteht. Das Ergebnis kann auch selektiv sein: etwa Einsatz für Tests und Migrationen, aber nicht für sicherheitskritische Kernlogik.

Schlussfolgerung

Die METR-Reihe ist kein Urteil für oder gegen Coding Agents. Ihr Wert liegt in der methodischen Lektion: Produktivität ist kontextabhängig, subjektive Wahrnehmung kann irren, und ein sauberer Befund altert, wenn sich Werkzeuge und Nutzung verändern. Für Entscheider folgt daraus keine abwartende Haltung, sondern eine präzisere Form des Handelns: klein anfangen, Messregeln vorher festlegen, Qualität als harte Grenze behandeln und Ergebnisse regelmäßig neu prüfen.