G · DiagnoseExtern belegt

Randomisierte Messung von KI-Produktivitätsgewinnen

Studiendesign von METR (Joel Becker, Nate Rush, Elizabeth Barnes, David Rein): Statt zu fragen, wie viel KI bringt, wird es gemessen. Echte Aufgaben aus dem eigenen Rückstand werden vorab geschätzt, dann per Münzwurf auf KI erlaubt und KI nicht erlaubt verteilt und die Zeit erfasst. Der eigentliche Befund ist die Lücke zwischen gemessener Wirkung und geglaubter Wirkung.

Wann Sie diese Methode brauchen

Über KI-Investitionen wird auf einer Grundlage entschieden, die keine ist. In der Vorlage stehen Benchmark-Ergebnisse des Anbieters, eine Umfrage im Team und eine Prozentzahl aus einer Präsentation. Alle drei messen Zutrauen, nicht Wirkung. Wer Personalplanung, Preisannahmen oder eine Due-Diligence-These darauf stützt, rechnet mit einer Zahl, die niemand je beobachtet hat. Erschwerend kommt hinzu, dass die Selbstauskunft nicht bloß ungenau ist, sondern in die falsche Richtung zeigen kann: Betroffene können sich beschleunigt fühlen, während die Uhr das Gegenteil zeigt.

Vorgehen

  1. 1Echte, bereits vorhandene Aufgaben aus dem laufenden Rückstand sammeln, keine Benchmark- oder Demoaufgaben, und den Zuschnitt auf wenige Stunden je Aufgabe begrenzen.
  2. 2Vor der Zuteilung je Aufgabe zwei Schätzungen abgeben lassen: erwartete Dauer mit KI und erwartete Dauer ohne KI. Die Schätzung ohne KI dient zugleich als Maß für die Schwierigkeit und geht später in die Auswertung ein.
  3. 3Jede Aufgabe einzeln per Zufall der Bedingung KI erlaubt oder KI nicht erlaubt zuweisen, und zwar erst, nachdem sie beschrieben und geschätzt ist. Wird erst zugeteilt und dann zugeschnitten, misst das Verfahren nichts mehr.
  4. 4Die Bearbeitungszeit erfassen und gegen eine zweite Spur prüfen, etwa Bildschirmaufzeichnung, Werkzeugprotokolle oder Ticketzeiten, damit Einhaltung der Bedingung und Zeitangabe nicht allein auf Selbstauskunft beruhen.
  5. 5Die gemessene Differenz gegen die Vorab-Schätzung und gegen die Einschätzung nach Abschluss stellen. Diese Lücke ist das eigentliche Steuerungsergebnis, denn sie sagt, wie viel die internen KI-Berichte wert sind.
  6. 6Nur die gemessene Differenz in Wirtschaftlichkeitsrechnungen einsetzen, das Ergebnis nach Aufgabentyp und Vertrautheit mit dem Gegenstand trennen und die Messung wiederholen, weil Werkzeuge und Erfahrung sich innerhalb von Monaten verschieben.

Typische Anwendung

Ein typisches B2B-SaaS im HR-Umfeld will die Entwicklungskapazität um ein Drittel anheben und begründet das mit KI-Werkzeugen. Die Teamleitung berichtet rund 30 Prozent Zeitersparnis, der Beirat rechnet damit bereits im Personalplan. Statt die Zahl zu übernehmen, legt die Firma sechs Wochen lang alle Tickets unter vier Stunden aus dem laufenden Rückstand in das Verfahren: je Ticket zwei Vorab-Schätzungen, dann Münzwurf über die Bedingung, dann Zeiterfassung mit stichprobenweiser Gegenprüfung. Gemessen bleibt ein deutlicher Vorteil bei neuen, isolierten Modulen und kein Vorteil im gewachsenen Kern, den zwei Entwickler seit Jahren kennen. Der Personalplan wird nicht auf 30 Prozent gebaut, sondern auf den gemessenen Wert, und die Einführung geht zuerst dorthin, wo die Messung trägt. Die Lücke zwischen berichteter und gemessener Wirkung wird im Beirat protokolliert, damit die nächste Selbstauskunft anders gelesen wird.

Grenzen und Gegenindikationen

Der Befund der Ausgangsstudie ist eng: 16 Entwickler, 246 Aufgaben, gewachsene Open-Source-Projekte, in denen die Beteiligten im Schnitt fünf Jahre zu Hause sind, und Werkzeuge vom Stand Februar bis Juni 2025. Die Autoren warnen ausdrücklich vor Verallgemeinerung und halten für kleine, neue Projekte oder fremde Codebasen eine deutliche Beschleunigung für plausibel. Die Bearbeitungszeit war zudem selbst berichtet; die Bildschirmaufzeichnungen dienten der Prüfung der Einhaltung und der Tätigkeitsanalyse, nicht als primäre Uhr. Das Verfahren selbst hat drei bekannte Schwächen. Erstens braucht es viele vergleichbare Aufgaben, bei kleiner Zahl verschwindet der Effekt im Rauschen. Zweitens greift eine Auswahlverzerrung: METR berichtet für die Nachfolgeerhebung, dass 30 bis 50 Prozent der Entwickler Aufgaben gar nicht erst einreichten, von denen sie annahmen, KI würde sie schnell erledigen, und dass Teilnehmer die KI-freie Bedingung zunehmend ablehnen. Drittens wird die Zeitmessung bei agentischen Werkzeugen unsauber, weil während des Wartens an anderen Dingen gearbeitet wird. METR hat die aufgabenweise Zufallszuteilung deshalb 2026 verlassen. Außerhalb der Softwareentwicklung ist das Design nicht geprüft. Und betrieblich ist es nicht harmlos: Wer Mitarbeitenden per Los ein Werkzeug verbietet, braucht deren Zustimmung und in mitbestimmten Betrieben die Beteiligung des Betriebsrats.

Woran Sie Wirkung messen

Führen Sie zwei Größen nebeneinander: die gemessene prozentuale Zeitdifferenz zwischen den beiden Bedingungen, aufgeschlüsselt nach Aufgabentyp, und die Lücke zwischen dieser Messung und der Selbsteinschätzung der Beteiligten. Die zweite Größe sagt Ihnen, wie weit Sie Ihren eigenen KI-Berichten trauen dürfen.

Verwandte Methoden

Werkzeuge dafür

Quellen

  1. 1.Becker, Rush, Barnes, Rein: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, arXiv:2507.09089 (öffnet in neuem Tab) · arXiv (Preprint, nicht begutachtet) · 2025 · Wissenschaft und Fachliteratur · beschreibt das VerfahrenTrägt das Verfahren in allen Schritten: Entwickler liefern Listen echter Aufgaben aus ihren eigenen Repositorien, schätzen je Aufgabe die Dauer mit und ohne KI, und erst danach wird jede Aufgabe per simuliertem Münzwurf der Bedingung zugewiesen. Ausdrücklich heißt es, die Aufgaben würden vor der Zuteilung definiert. Die Auswertung erfolgt über eine log-lineare Regression, die die geschätzte Schwierigkeit einbezieht. Ergebnis: Vorab-Erwartung 24 Prozent schneller, Selbsteinschätzung nach Abschluss 20 Prozent schneller, gemessen 19 Prozent langsamer. Grenzen, die die Quelle selbst benennt: 16 Entwickler und 246 Aufgaben, die Bearbeitungszeit ist selbst berichtet und die Bildschirmaufzeichnung dient der Prüfung der Einhaltung, nicht als primäre Uhr; die Autoren warnen ausdrücklich vor Verallgemeinerung und halten Beschleunigung bei kleinen, neuen Projekten für plausibel. Es handelt sich um einen Preprint ohne Begutachtung.
  2. 2.METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (Blogfassung mit Studienaufbau) (öffnet in neuem Tab) · METR · 2025-07-10 · Praxisquelle · liefert VergleichszahlenLiefert die Randbedingungen der Erhebung, die für eine eigene Nachbildung nötig sind: 16 Entwickler aus großen, reifen Open-Source-Projekten mit im Mittel über 22.000 Sternen und über einer Million Codezeilen, 246 echte Aufgaben von je rund zwei Stunden, Vergütung 150 Dollar je Stunde, Bildschirmaufzeichnung während der Bearbeitung, primär genutzte Werkzeuge Cursor Pro mit Claude 3.5 und 3.7 Sonnet. Grenze: Es handelt sich um die Eigendarstellung der durchführenden Organisation und nicht um eine unabhängige Prüfung; die Zahlen decken sich mit dem Preprint.
  3. 3.Peng, Kalliamvakou, Cihon, Demirer: The Impact of AI on Developer Productivity, Evidence from GitHub Copilot, arXiv:2302.06590 (öffnet in neuem Tab) · arXiv (Preprint, Microsoft Research und GitHub) · 2023 · Wissenschaft und Fachliteratur · liefert den AnlassZeigt, warum der Aufgabenzuschnitt über das Ergebnis entscheidet, und begründet damit die zentrale Vorschrift dieses Verfahrens, echte Aufgaben statt Testaufgaben zu verwenden. In derselben Bauart, also einer Zufallszuteilung mit KI-Werkzeug gegen ohne, aber mit einer künstlichen, isolierten Aufgabe, nämlich einem HTTP-Server in JavaScript, waren 95 über eine Plattform angeworbene Entwickler mit Werkzeug 55,8 Prozent schneller, bei einem 95-Prozent-Intervall von 21 bis 89 Prozent. Bemerkenswert für die Methode: Hier unterschätzten die Beteiligten ihren Gewinn, sie schätzten im Mittel 35 Prozent bei gemessenen 55,8 Prozent. Die Richtung des Irrtums ist also nicht konstant, nur seine Existenz. Grenzen: Preprint der beteiligten Anbieter, eine einzige synthetische Aufgabe, angeworbene Freiberufler statt eines Betriebskontexts, kein Bezug zu gewachsenen Codebasen.
  4. 4.METR: We are Changing our Developer Productivity Experiment Design (öffnet in neuem Tab) · METR · 2026-02-24 · Praxisquelle · begrenzt das VerfahrenBegrenzt das Verfahren mit den Worten seiner Urheber. METR verlässt die aufgabenweise Zufallszuteilung und nennt die Gründe: Entwickler verweigern zunehmend die Teilnahme, weil sie nicht ohne KI arbeiten wollen; schätzungsweise 30 bis 50 Prozent reichten Aufgaben, von denen sie annahmen, KI erledige sie schnell, gar nicht erst ein; die Absenkung der Vergütung von 150 auf 50 Dollar je Stunde hat die Auswahlverzerrung vermutlich verstärkt; und bei agentischen Werkzeugen fiel es den Beteiligten schwer, die aufgewendete Zeit anzugeben, weil sie während des Wartens an anderem arbeiteten. Die Nachfolgeerhebung mit 57 Entwicklern und über 800 Aufgaben in 143 Repositorien ergab eine Verlangsamung von 18 Prozent bei den ursprünglichen und 4 Prozent bei den neu angeworbenen Entwicklern, wobei METR die eigenen Daten ausdrücklich als sehr schwachen Beleg einstuft. Grenze: eine Selbstauskunft über laufende, noch nicht veröffentlichte Arbeit.

Ursprung: METR / Becker, Rush, Barnes, Rein

← Zurück zum Katalog

Diese Methode mit KI durchgehen

ClaudeChatGPTPerplexity