Das 20-Prozent-Gefühl und der 19-Prozent-Befund

Fragen Sie ein Team, das AI-Coding-Tools eingeführt hat, wie es läuft — und Sie hören fast immer dieselbe Antwort: spürbar schneller. Bitten Sie um eine Zahl, landet sie meist um die zwanzig Prozent. Ich höre das in fast jedem Delivery-Review — und hatte bis letztes Jahr keine höfliche Möglichkeit, es zu überprüfen.

Dann hat jemand das Experiment sauber durchgeführt. METR, eine Forschungsgruppe für die Evaluation von AI-Fähigkeiten, nahm sechzehn erfahrene Open-Source-Maintainer und 246 echte Aufgaben aus deren eigenen Repositories — keine Übungen, ihr tatsächliches Backlog — und loste aus, bei welchen Aufgaben AI-Tools erlaubt waren. Vorab schätzten die Entwickler, AI würde sie um 24% beschleunigen. Hinterher meinten sie, es seien etwa 20% gewesen. Die Messung ergab: mit AI waren sie 19% langsamer.

Lassen Sie das kurz wirken. Das waren weder Skeptiker noch Anfänger. Sie hielten sich für schneller, während sie langsamer waren — und blieben auch im Nachhinein dabei. Wenn Ihr Adoption-Report auf Selbsteinschätzung der Entwickler beruht — und die meisten tun das —, dann ist das die Messgenauigkeit Ihres Instruments.

Beide Zahlen stimmen

Der naheliegende Einwand: Es gibt eine kontrollierte Studie mit dem gegenteiligen Ergebnis. GitHubs Experiment von 2023 mit 95 Entwicklern ergab, dass Copilot sie 55,8% schneller machte. Stimmt — beim Bau eines eigenständigen HTTP-Servers, nach klarer Spezifikation, in frischem Code, ohne wartende Reviewer und ohne Produktion, die kaputtgehen kann.

Das ist kein Fehler einer der beiden Studien. Es ist der Befund. AI-Unterstützung reagiert extrem empfindlich auf den Zuschnitt der Aufgabe: grüne Wiese, klar spezifiziert und isoliert ist das eine Regime; eingebettet in eine große, vertraute Codebasis mit impliziten Standards und einem Review-Gate das andere. Im ersten Regime leben die Demos. Im zweiten findet Ihre Delivery statt.

Kommt Ihnen das Muster bekannt vor? Die Zahlen zu AI-Scheiterquoten verhalten sich genauso — ich habe sie in einem früheren Text auseinandergenommen. Verschiedene Studien, verschiedene Messgrößen, zitiert als wäre es ein Fakt. Die Produktivitätszahlen verdienen dieselbe Disziplin wie die Scheiterquoten: erst fragen, was gemessen wurde, an welcher Arbeit, mit welcher Methode — dann darf die Zahl in den Plan.

Wohin die Zeit geht

Die interessante Frage ist nicht, ob die Tools schnell Code erzeugen — das tun sie —, sondern was mit diesem Code stromabwärts passiert. Zwei groß angelegte Signale legen nahe: Der Engpass verschwindet nicht, er wandert.

DORAs Report 2024, auf Basis von rund 39.000 Antworten, schätzt: 25 Punkte mehr AI-Nutzung gehen mit 1,5% weniger Delivery-Durchsatz und 7,2% weniger Stabilität einher. Einzelne Entwickler berichten, schneller zu sein; die Pipeline, Ende zu Ende gemessen, ist es nicht — und was ausgeliefert wird, bricht etwas öfter.

GitClear, das Jahr für Jahr Hunderte Millionen geänderter Codezeilen auswertet, meldet seit Ankunft der Assistenten stark steigende Duplikate — mehrfach so viele duplizierte Blöcke — während der Anteil verschobenen Codes, das Kennzeichen von Refactoring, sinkt. Generierter Code wird eingefügt; die Umbauarbeit, die eine Codebasis änderbar hält, findet seltener statt. Das ist Tempo heute, bezahlt aus der Wartung von morgen.

Tippen war nie der Engpass. Review, Verifikation, Integration und Ownership waren es — und ein Werkzeug, das das Tippen beschleunigt, füttert den Engpass schneller, als der Engpass abfließen kann.

Was das für Delivery-Management bedeutet

Nichts davon spricht dafür, die Tools zu verbieten. Ich nutze sie täglich, und auch diese Website ist teilweise damit gebaut. Es spricht dafür, sie wie jede andere Änderung an einem Produktivsystem zu managen — mit Instrumentierung statt Zeugenaussagen. Konkret, bevor Sie einer Beschleunigung glauben:

• Die Pipeline messen, nicht die Tastatur. Zykluszeit vom ersten Commit bis zum Merge, Länge der Review-Queue, Zeit im Review. Hilft AI, bewegen sich diese Werte. Bewegt sich nur „geschriebene Zeilen“, wurde der Engpass gefüttert, nicht entlastet.
• Den Qualitäts-Abgasstrom beobachten. Rework-Anteil, Defect-Escape-Rate, Change-Failure-Rate, Duplikat-Trend. DORAs Stabilitätsbefund sagt: Hier kommt die Rechnung an.
• Die Arbeit nach Regime trennen. Scaffolding auf der grünen Wiese, Testgenerierung und Einmalskripte liegen im Regime der 55,8%. Tiefe Eingriffe in ein gewachsenes System liegen im Regime der −19%. Eine Adoption-Policy, die beides gleich behandelt, irrt in die eine oder die andere Richtung.
• Selbstauskunft in beide Richtungen misstrauen. Die METR-Entwickler irrten ehrlich über ihr eigenes Tempo. Ihre Enthusiasten und Ihre Skeptiker werden es auch. Entschieden wird die Frage von den Pipeline-Metriken — oder sie ist nicht entschieden.

Die Offenlegung

Wie beim Text über die Scheiterquoten gilt: Ich profitiere von beiden Hälften dieser Geschichte. Macht AI Ihr Team dramatisch schneller, muss jemand die Delivery darum herum umbauen; macht es Ihre Delivery leise schlechter, muss jemand herausfinden, wo. Berater sind keine unbeteiligten Leser von Produktivitätsstatistiken — genau deshalb gehören die Zahlen geprüft statt zitiert.

Die ehrliche Zusammenfassung: Die Werkzeuge sind wirklich mächtig, das Gefühl von Geschwindigkeit ist wirklich unzuverlässig, und die einzige Version der Wahrheit, die zählt, ist die an Ihrer Pipeline gemessene — an Ihrer Arbeit, mit dokumentierter Methode.

• AI-Umsetzung
• SDLC
• Messbarkeit
• Entwicklerproduktivität