Zum Inhalt springen

Wissensbasis

KI-Produktivität: Evidenz und Qualität

Gemessene Produktivitätsgewinne durch KI beim Coden sind moderat und an Bedingungen geknüpft, eine randomisierte Studie fand sogar eine Verlangsamung. Sie hängen von Aufgabe, Codebase und Enablement ab, Selbstauskünfte übertreiben sie, und mehr Output treibt Churn, Fehler und Review-Last, solange die Quality Gates nicht mitwachsen.

Verfasst von

Aktualisiert:

Einstieg 2

Unsere Position. Productivity is not value (öffnet in einem neuen Tab): KI bläht auf, was sich leicht messen lässt, etwa Codevolumen und die Zahl der Pull Requests. Auf den Wert wirkt sie neutral.

Was solltet ihr aus der Studienlage mitnehmen?

  • Prüft den Aufgabenmix einer Studie, bevor ihr sie vergleicht. Greenfield-Arbeit mit geringer Komplexität gewinnt am meisten, Brownfield-Arbeit mit hoher Komplexität am wenigsten.
  • Prüft, wie viel Enablement die Teilnehmenden bekamen. Bei METR begann die Studie mit einem 30-minütigen Einführungs- und Onboarding-Call.
  • Lest Herstellerangaben als Marketing, bis eine kontrollierte Studie oder Telemetrie aus der Produktion sie stützt.

Wie viel schneller werden Entwickler:innen mit KI?

Belastbare Studien finden moderate und an Bedingungen geknüpfte Gewinne, eine randomisierte Studie sogar eine Verlangsamung. In der randomisierten METR-Studie arbeiteten 16 erfahrene Open-Source-Entwickler:innen mit KI auf ihren eigenen Repositories rund 19% langsamer. Vorher hatten sie rund 24% Beschleunigung erwartet, und auch danach schätzten sie noch rund 20% (METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (öffnet in einem neuen Tab)). Eine selten zitierte methodische Einschränkung: Die Teilnehmenden starteten mit einem 30-minütigen Einführungs- und Onboarding-Call samt Grundschulung in Cursor, und METR kann Lerneffekte jenseits von 50 Stunden Cursor-Nutzung nicht ausschließen (METR-Paper, Anhang G.3 (öffnet in einem neuen Tab); METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (öffnet in einem neuen Tab)).

Nachträgliche Analysen ergänzen Details (Second Thoughts - Not So Fast: AI Coding Tools Can Actually Reduce Productivity (öffnet in einem neuen Tab)):

  • Nur 39% der Cursor-Generierungen wurden akzeptiert, und selbst akzeptierten Code überarbeiteten die Entwickler:innen oft.
  • Bildschirmaufnahmen zeigen mit KI deutlich mehr Leerlauf, weil das Warten auf Tools den Flow bricht.
  • Die Robustheitsprüfungen halten: 84% der Aufnahmen mit erlaubter KI zeigen tatsächliche KI-Nutzung.

Nur eine teilnehmende Person hatte mehr als 50 Stunden Vorerfahrung mit Cursor, und sie wurde tatsächlich schneller. Allerdings hatten 56% der Teilnehmenden Cursor nie zuvor genutzt. Jemand aus dem Autorenteam lehnt die Lernkurve ausdrücklich als ausreichende Erklärung ab und nennt mindestens fünf wahrscheinliche Mitursachen (Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (öffnet in einem neuen Tab)).

Die Stanford-Studie mit über 120.000 Entwickler:innen fand einen Median-Gewinn von rund 10%. Ein Index für die Sauberkeit der Codebase korrelierte mit den Gewinnen (R² = 0,40, im Vortrag “a pretty decent correlation”, gegenüber lose 0,20 für die Token-Nutzung). In ihren Talks schlüsselt die Stanford-Gruppe die Gewinne hinter diesem Median nach Aufgabenart und Komplexität auf:

  • Greenfield, geringe Komplexität: 30-40% Gewinn
  • Greenfield, hohe Komplexität: 10-15%
  • Brownfield, geringe Komplexität: 15-20%
  • Brownfield, hohe Komplexität: 0-10%

Mit wachsender Codebase sinken die Gewinne stark. In weniger verbreiteten Sprachen wie COBOL, Haskell oder Elixir können sie sogar negativ werden. Die Selbsteinschätzung liegt um rund 30 Perzentilpunkte daneben. Dieselbe Telemetrie fand rund 10% “ghost engineers” mit praktisch keinem messbaren Output (Stanford-Talk zur Produktivitätsforschung im Software Engineering (öffnet in einem neuen Tab)).

Eine Studie von MIT, Microsoft und Princeton mit 4.867 Entwickler:innen maß 26% mehr abgeschlossene Aufgaben pro Woche. Das ist weit entfernt von den 10x aus dem Marketing, aber substanziell (From Trees to Forest: The Real Impact of AI on Developer Productivity (öffnet in einem neuen Tab)).

Wahrnehmung und Telemetrie gehen systematisch auseinander. Der DX-Benchmark für Q1 2026 über mehr als 400 Unternehmen meldet 3,9 Stunden selbst berichtete Zeitersparnis pro Woche und 27,4% KI-geschriebenen Code. Die eigene Längsschnittstudie von DX (Nov 2024 bis Feb 2026) zeigt dagegen nur 10-15% mehr PR-Durchsatz über mehr als ein Jahr. Das liegt deutlich unter dem, was die Selbstauskünfte nahelegen (DX AI Impact Report).

Das Design von Umfragen treibt die Zahlen weiter nach oben. Atlassians State of Developer Experience Survey 2025 fragte 3.500 Engineers nach gesparter Zeit über die ganze Arbeitswoche, nicht nur beim Coden. Daraufhin berichteten 99% mehr als vier Stunden Ersparnis pro Woche, 46% sogar 11 bis 20 Stunden. Dieselben Befragten verlieren nach eigener Angabe mehr als 10 Stunden pro Woche durch organisatorische Ineffizienz. 63% sagen, ihre Führungskräfte verstehen ihre Herausforderungen nicht (Atlassian-Talk zu State of Developer Experience 2025 (öffnet in einem neuen Tab)).

Die METR-Teilnehmenden zeigen denselben Effekt auf individueller Ebene. Sie erwarteten, mit KI schneller zu werden, während die gemessene Bearbeitungszeit in die Gegenrichtung lief (METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (öffnet in einem neuen Tab)). Jede Aussage, die allein auf selbst berichteter Zeitersparnis beruht, solltet ihr entsprechend abwerten.

Durchschnitte verdecken außerdem die Streuung zwischen Organisationen und einzelnen Personen. DX zeigte Qualitätsmetriken auf Unternehmensebene, die von Verbesserung bis Verschlechterung reichen. Der DORA-Report zu KI-gestützter Entwicklung beschreibt KI als Verstärker des umgebenden Engineering-Systems (DX-Talk zum KI-Strategie-Playbook (öffnet in einem neuen Tab); DORA, State of AI-assisted Software Development 2025 (öffnet in einem neuen Tab)). Die DX-Daten aus Q1 2026 schlüsseln nach Segmenten auf (DX - AI-assisted engineering impact report, Q1 2026 (öffnet in einem neuen Tab), Benchmark des Herstellers):

  • Die Adoption in der Branche erreichte 93%.
  • Engineering Manager:innen, die KI täglich nutzen, liefern 4x so viel Code wie sechs Monate zuvor.
  • Junior Engineers haben Staff+ bei der wöchentlich gesparten Zeit überholt (4,9 gegenüber 4,8 Stunden).
  • Unternehmen mit weniger als 200 Entwickler:innen hängen große Konzerne ab.

Ein einjähriger Produktionseinsatz bei 300 Engineers maß eine um 31,8% kürzere Review-Zykluszeit für PRs. Rund 40% des ausgelieferten Codes stammten dabei von KI (Produktionsstudie - Intuition to Evidence: Measuring AI’s True Impact on Developer Productivity (öffnet in einem neuen Tab)). Dahinter steht DeputyDev, das interne Tool von Tata 1mg mit sechs parallelen Review-Agenten auf Claude Sonnet. Auch hier verstärkt KI die Unterschiede innerhalb eines Unternehmens (Produktionsstudie - Intuition to Evidence: Measuring AI’s True Impact on Developer Productivity (öffnet in einem neuen Tab)):

  • Die 30 stärksten Nutzer:innen lieferten 61,3% mehr Code, die 30 schwächsten 11,4% weniger.
  • Zwischen beiden Gruppen klafft damit eine Lücke von 72,7 Prozentpunkten.
  • Junior Engineers gewannen mit +77% am meisten.
  • Automatisch übernommene KI-Vorschläge verursachten Qualitätsprobleme, deshalb schaltete das Team diese Funktion schnell ab.

Intercom setzte sich ein klares Ziel: den Engineering-Durchsatz verdoppeln, gemessen als Code-Änderungen pro Person in R&D. Das Unternehmen standardisierte auf eine einzige Agent-Plattform und stellte ein eigenes Enablement-Team auf. Die Verdopplung gelang in weniger als einem Jahr (Intercom-Talk zur Verdopplung des Engineering-Durchsatzes (öffnet in einem neuen Tab)). Die Lücke zwischen Benchmark und Realität bleibt die ständige Warnung. Modelle, die 86% der LeetCode-Aufgaben lösen, schaffen nur 26% echter Freelance-Aufträge. Deshalb begrenzt der Kontext das Ergebnis, nicht die Fähigkeit des Modells (How Engineering Teams use AI (öffnet in einem neuen Tab), März 2025).

Was kostet schnellerer Output an Qualität?

Das größte Gegengewicht auf Basis von Telemetrie liefert der Engineering-Report von Faros AI (April 2026). Er stützt sich auf zwei Jahre Daten von 22.000 Entwickler:innen und über 4.000 Teams. Die Akzeptanz von KI-generiertem Code stieg von 20% auf 60%, und der Output wuchs:

  • Epics pro Entwickler:in +66%
  • Task-Durchsatz +33,7%
  • PR-Merge-Rate +16,2%

Der Preis dafür zeigt sich nachgelagert und fällt hoch aus:

  • Code Churn bei hoher Adoption +861%
  • Verhältnis von Incidents zu PRs +242,7%
  • Bugs pro Entwickler:in +54%
  • PRs, die ganz ohne Review gemergt wurden, +31,3%
  • Median-Zeit im Review +441,5%, weil Senior Engineers die Review-Last auffangen

Auf Basis seiner Telemetrie widerspricht Faros der Reifegrad-These von DORA 2025. Laut Faros erleben auch leistungsstarke Organisationen dieselbe nachgelagerte Verschlechterung wie alle anderen (Faros AI - The AI Engineering Report 2026: The AI Acceleration Whiplash (öffnet in einem neuen Tab), April 2026; Faros verkauft die Telemetrie-Plattform, die diese Metriken sichtbar macht).

Unabhängige Zahlen zeigen in dieselbe Richtung (From Trees to Forest: The Real Impact of AI on Developer Productivity (öffnet in einem neuen Tab), August 2025):

  • Eine Stanford-Analyse fand Sicherheitslücken in 40% des KI-generierten Codes.
  • In der Umfrage von Stack Overflow 2025 misstrauen 46% der Entwickler:innen der Genauigkeit von KI, 2023 waren es 31%.
  • 66% nennen Code, der “almost right, but not quite” ist, als größten Zeitfresser.
  • Answer.AI stellte fest, dass der autonome Agent Devin nur 3 von 20 zugewiesenen Aufgaben erledigte.

Herstellerangaben liegen weit über diesen Zahlen. Cursor verspricht “10x developer productivity” bei einer Bewertung von 9 Mrd. US-Dollar. Replit beansprucht 90% des grundlegenden Codes, Amazon nennt 4.500 Jahre eingesparte Entwicklungszeit. Lest solche Angaben als Marketing (From Trees to Forest: The Real Impact of AI on Developer Productivity (öffnet in einem neuen Tab)).

Wenn die Qualität erodiert, kann der ROI sogar negativ werden. In einem Enterprise-Team mit 350 Personen maß die Stanford-Gruppe je vier Monate vor und nach der KI-Einführung. Die Zahl der PRs stieg um 14%, die Codequalität fiel gegenüber dem Branchen-Benchmark um 9%. Die Nacharbeit stieg auf das 2,5-Fache, der effektive Output änderte sich nicht nennenswert. Den echten Ausgaben für Lizenzen und Token stand also kein nennenswerter Produktivitätszuwachs gegenüber (Stanford-Talk zur Messung des KI-ROI (öffnet in einem neuen Tab)). Ihr Fazit deckt sich mit dem Konsens zur Impact-Messung: Wählt eine primäre Output-Metrik und umgebt sie mit Qualitätsmetriken als Guardrails.

Verwandte Seiten

Quellen

Artikel

Papers und Reports

Posts

Talks und Videos