KIberblick
Inhaltsverzeichnis

Grundlagen

KI-Produktivität: Warum die Zahlen trügen

Mehr Tasks, aber Reviews dauern doppelt so lang. Die METR- und Faros-Studien zeigen, wo der echte Engpass liegt und was KI-Review-Tools heute können.

25. März 202610 Min. Lesezeit

"KI macht Entwickler 19 % langsamer"

Diese Schlagzeile ging Anfang 2025 durch die Tech-Welt. Die Forschungsorganisation METR hatte erfahrene Open-Source-Entwickler bei ihrer täglichen Arbeit gemessen und ein überraschendes Ergebnis gefunden: Mit KI-Tools brauchten sie im Schnitt 19 % länger für ihre Aufgaben. Und das, obwohl die Entwickler selbst eine Beschleunigung von 24 % erwartet hatten.

Die Studie wurde peer-reviewed veröffentlicht und ist methodisch solide. Die Stichprobe bestand aus erfahrenen Entwicklern (Median: 10 Jahre Open-Source-Erfahrung), die an ihren eigenen Projekten arbeiteten. Keine Studenten, keine künstlichen Aufgaben.

Für KI-Skeptiker war das ein Fest. Für KI-Enthusiasten ein Ärgernis. Aber die interessantere Geschichte steckt in dem, was danach passierte.

Der Replikationsversuch scheitert - aber nicht wie erwartet

Ende 2025 versuchte METR, die Studie zu wiederholen. 57 Entwickler, 143 Repositories, über 800 Aufgaben, $50/Stunde Vergütung. Zufällige Zuweisung: Mal mit KI, mal ohne. Alles nach Lehrbuch.

Die Rohergebnisse: Der Slowdown war deutlich kleiner als in der ersten Studie. Entwickler aus der Originalstudie waren noch 18 % langsamer mit KI. Neu rekrutierte Entwickler nur noch 4 %. Aber die Forscher trauen ihren eigenen Zahlen nicht mehr. Und ihre Begründung ist aufschlussreicher als jedes Ergebnis.

Warum die Messung nicht mehr funktioniert

METR beschreibt drei fundamentale Probleme:

1. Entwickler weigern sich, ohne KI zu arbeiten. 30-50 % der Teilnehmer haben bewusst Aufgaben vermieden, bei denen KI besonders stark helfen würde. Der Grund: Wenn das Los auf "ohne KI" fällt, wollten sie diese Aufgabe nicht ohne Unterstützung machen. Ein Developer hat keine einzige Aufgabe ohne KI abgeschlossen.

METR schreibt dazu: "Ein wachsender Anteil der Entwickler sagt, dass sie nicht mal die Hälfte ihrer Arbeit ohne KI machen wollen - obwohl unsere Studie $50 pro Stunde zahlt."

2. Agentic Tools machen Zeitmessung sinnlos. Wenn Claude Code oder Codex im Hintergrund arbeiten, tun Entwickler in der Zwischenzeit andere Dinge. Wie misst du die "Arbeitszeit" an einer Aufgabe, wenn ein Agent sie bearbeitet während du E-Mails liest?

3. Die Aufgaben ändern sich. Entwickler passen ihre Aufgabenwahl an KI-Stärken an. Sie nehmen andere Aufgaben an, wenn sie wissen, dass KI verfügbar ist. Damit vergleichst du nicht mehr "gleiche Aufgabe mit vs. ohne KI", sondern "unterschiedliche Aufgaben".

Was das für die Praxis bedeutet

Die METR-Studie zeigt nicht, dass KI Entwickler langsamer macht. Sie zeigt, dass die Frage falsch gestellt ist.

KI-Tools verändern nicht nur die Geschwindigkeit, sondern die Art der Arbeit selbst:

  • Andere Aufgaben werden möglich. Entwickler nehmen Refactorings an, die sie ohne KI nicht angefasst hätten. Die Aufgabe dauert vielleicht länger als ein Quick-Fix, aber das Ergebnis ist besser.
  • Die Qualität ändert sich. Mehrere Teilnehmer lieferten mit KI umfangreichere Tests und bessere Dokumentation. Das kostet Zeit, ist aber kein Produktivitätsverlust.
  • Der Workflow ändert sich. Mit agentenbasierten Tools wird Entwicklung asynchron. Du startest einen Agent, arbeitest an etwas anderem, prüfst das Ergebnis. "Wie lange hat die Aufgabe gedauert?" wird zur philosophischen Frage.

Der Engpass verschiebt sich: Das Review-Bottleneck

METR misst einzelne Entwickler. Aber was passiert auf Team-Ebene? Faros AI hat Telemetrie-Daten von über 10.000 Entwicklern aus 1.255 Teams ausgewertet und ein klares Muster gefunden:

  • Entwickler in Teams mit hoher KI-Nutzung erledigen 21 % mehr Tasks
  • Sie mergen 98 % mehr Pull Requests
  • Die Review-Zeit steigt um 91 %
  • Die durchschnittliche PR-Größe wächst um 154 %

Das Problem ist nicht, dass KI-Code schlechter ist. Das Problem ist simpler: Es kommt mehr Code an, als Menschen reviewen können. Die PRs sind größer, es gibt mehr davon, und die Review-Kapazität im Team bleibt gleich.

Addy Osmani von Google nennt das "Comprehension Debt": die Lücke zwischen dem Code, den ein System enthält, und dem Code, den ein Mensch versteht. KI generiert 5-7x schneller als Entwickler absorbieren können.

Warum das trotzdem kein Grund zur Panik ist

Coding macht nur 20-30 % der gesamten Softwareentwicklungs-Pipeline aus. Review ist ein noch kleinerer Teil. Das heißt: Selbst wenn KI das Coding auf null reduziert, wird der Gesamtprozess nur 20-30 % schneller, weil Review, Testing und Release die Taktgeber sind.

Die 91 % längere Review-Zeit relativiert sich außerdem, wenn man bedenkt, dass die PRs 154 % größer sind. Größere PRs brauchen natürlich länger. Die Lösung ist nicht nur schnelleres Review, sondern auch besser geschnittene PRs.

KI-Review-Tools: Wo stehen wir?

Wenn KI das Coding beschleunigt und der Engpass beim Review liegt, dann ist die logische Frage: Kann KI auch beim Review helfen? Die kurze Antwort: Ja, aber die Tools holen noch auf.

Was heute funktioniert:

Mehrere Tools bieten automatisiertes PR-Review an. GitHub Copilot Code Review hat seit dem Start im April 2025 über 60 Millionen Reviews durchgeführt, mit 10-fachem Wachstum in einem Jahr. CodeRabbit, Greptile und Qodo sind spezialisierte Alternativen.

Die Bug-Erkennungsraten liegen je nach Tool zwischen 44 % und 82 %. Die Tools können Style-Probleme finden, offensichtliche Bugs erkennen, PR-Zusammenfassungen generieren und One-Click-Fixes vorschlagen. Manche generieren sogar automatisch Tests.

Was noch fehlt:

Die Tools behandeln PRs als isolierte Code-Änderungen. Aber die wichtigste Frage im Review ist oft: "Warum machen wir das so?" Das erfordert Kontext über das Business, die Architektur und die Team-Entscheidungen, den kein Tool heute zuverlässig liefert. Wenn hier Review Tools einem die Aufgabe abnehmen beim Review die Konzentration auf das "Was" zu legen und beim "Wie" vielleicht noch auf schwierige Randfälle zu achten, dann bringt das auch Geschwindigkeit, da der Kopf weniger Dinge parallel machen muss.

Konkrete Schwächen:

  • Copilot lernt nicht aus den Review-Patterns deines Teams, jedes PR startet bei null
  • Security-Schwachstellen werden kaum erkannt, in einem Benchmark fand Copilot null von mehreren bekannten Lücken
  • False Positives sind ein Problem: Greptile meldet 11 pro Benchmark-Durchlauf, CodeRabbit nur 2
  • 96 % der Entwickler vertrauen der funktionalen Korrektheit von KI-generiertem Code nicht vollständig

CodeRabbit hat es auf den Punkt gebracht: "2025 war das Jahr der KI-Geschwindigkeit. 2026 wird das Jahr der KI-Qualität."

Die Adoptionszahlen sprechen eine eigene Sprache

Während die Forschung streitet, ob KI Entwickler schneller oder langsamer macht, haben die Entwickler selbst längst entschieden: 84 % nutzen KI-Tools oder planen es (Stack Overflow Developer Survey 2025, 49.009 Teilnehmer). 51 % nutzen KI-Tools täglich. JetBrains kommt in einer eigenen Erhebung auf 85 %.

Der Anteil von KI-generiertem Code in der Produktion liegt bei etwa 27 % (GitClear, Februar 2026). GitHub berichtet, dass Copilot-Nutzer im Schnitt 46 % ihres Codes über KI generieren, bei Java sogar 61 %.

Die Business-Zahlen sind ebenfalls klar: Entwickler sparen im Schnitt 3-4 Stunden pro Woche, 20 % berichten von einem ganzen eingesparten Arbeitstag. Jeder investierte Dollar bringt im Schnitt 3,70 $ zurück, bei Spitzenreitern bis zu 10,30 $.

Die Trust-Gap: Mehr Nutzung, weniger Vertrauen

Gleichzeitig sinkt das Vertrauen. 2024 sagten noch 40 % der Entwickler, sie vertrauen KI-generiertem Code. 2025 sind es nur noch 29 %. 46 % sagen aktiv, dass sie den Ergebnissen misstrauen, ein Anstieg von 31 % im Vorjahr.

66 % der Entwickler kämpfen mit Lösungen, die "fast richtig, aber nicht ganz" sind (mehr dazu in unserem Artikel KI-Code: Fast richtig reicht nicht). 45 % sagen, dass das Debugging von KI-Code länger dauert als es selbst zu schreiben.

Das ergibt ein paradoxes Bild: Die Adoption steigt, das Vertrauen sinkt. Entwickler nutzen KI mehr, aber mit wachsender Skepsis. Das ist kein Widerspruch, es zeigt, dass Teams realistischer werden. KI-Tools werden nicht als Wunderwaffe eingesetzt, sondern als Werkzeug mit bekannten Grenzen.

Die unbequeme Wahrheit über Produktivitätsmessung

Wenn jemand dir erzählt, KI mache Entwickler "X % schneller" oder "Y % langsamer", frag nach der Methodik. Die ehrlichste Antwort der besten Forscher auf diesem Gebiet ist aktuell: "Wir wissen es nicht genau, und es wird schwieriger, es zu messen."

Das heißt nicht, dass KI-Tools nutzlos sind. Es heißt, dass simple Metriken wie "Zeit pro Aufgabe" die Realität nicht abbilden. Das Gesamtbild: KI verschiebt den Engpass vom Schreiben zum Prüfen. Das ist kein Scheitern, sondern ein normaler Reifeprozess. Die Review-Tools werden besser, aber sie brauchen noch Zeit, um den Menschen wirklich effektiv zu unterstützen.

Wer KI-Produktivität in seinem Team messen will, sollte breiter schauen:

  • Welche Aufgaben werden jetzt angegangen, die vorher liegen blieben?
  • Wie hat sich die Code-Qualität verändert (Reviews, Bug-Rate)?
  • Wo liegt der aktuelle Engpass in eurer Pipeline?
  • Wie fühlt sich die Arbeit an? (Ja, das ist eine valide Metrik)

Quellen