LLMs beschleunigen dein Team. Nur an der falschen Stelle.

Thomas
Thomas

Warum die Messfrage nicht bei deinen Entwicklern anfängt, sondern bei der Work-Feedback Loop.

Irgendwann kommt die Frage. Meistens von jemandem, der das Budget freigegeben hat.

Wir haben jetzt LLM-Lizenzen für alle, wie viel schneller sind wir geworden?

Und dann fängt das Elend an. Jemand schlägt Codezeilen vor. Jemand anderes lacht, und danach schlägt jemand Commits vor, was dasselbe in schlechter Verkleidung ist. Am Ende landet man bei einer Zahl, die niemand glaubt, aber alle akzeptieren, weil eine schlechte Zahl immer noch besser aussieht als keine.

Meine These ist unbequemer als „Codezeilen sind Quatsch“. Wir haben die Effizienz von Entwicklungsteams noch nie gemessen. Wir haben immer nur Zeit gemessen und Produktivität dazu gesagt. Das war lange kein Problem, weil die Zeit, die wir gemessen haben, tatsächlich der Engpass war. LLMs zerstören diese Bequemlichkeit, weil sie genau an der einen Stelle ansetzen, die wir am besten messen können, und ausgerechnet dort am wenigsten bewirken.

Was wir vor LLMs gemessen haben

Die Geschichte der Produktivitätsmessung in der Softwareentwicklung ist eine Geschichte von Ersatzhandlungen.

Am Anfang standen Codezeilen. Die Logik war die der Fertigung: Output ist zählbar, also zähl ihn. Maurice Halstead baute daraus 1977 mit Elements of Software Science sogar ein ganzes Rechenwerk, das aus Operatoren und Operanden Aufwand, Fehlerzahl und Implementierungszeit ableiten sollte. Die Kritik kam schnell und war vernichtend. Die Übereinstimmung zwischen berechneter und tatsächlicher Programmlänge war ein mathematisches Artefakt, keine empirische Bestätigung.

Die schönste Widerlegung kam aber nicht aus der Forschung, sondern aus dem Apple-Lisa-Team. Im Februar 1982 führte das Management ein Wochenformular ein, in das jeder Ingenieur seine geschriebenen Codezeilen eintragen sollte. Bill Atkinson hatte gerade die Region-Engine von QuickDraw neu geschrieben. Sechsmal schneller, rund 2.000 Zeilen kürzer. Er trug ein: minus 2000. Ein paar Wochen später hörte das Management auf, ihm das Formular zu schicken.

Danach kam die Ära der Abstraktion. Allan Albrecht stellte 1979 bei IBM die Function Points vor, um Funktionsumfang sprachunabhängig zu messen. Barry Boehm kalibrierte 1981 mit COCOMO ein Regressionsmodell an 63 Projekten, dessen entscheidender Eingabewert die geschätzte Anzahl Codezeilen war. Also genau die Größe, die man am Projektanfang am wenigsten kennt. Und in den späten Neunzigern erfanden die XP-Leute Story Points, weil niemand akzeptieren wollte, dass ein Idealtag in Wirklichkeit drei Kalendertage dauert. Ron Jeffries hat sich dafür 2019 öffentlich entschuldigt: er habe Story Points womöglich erfunden, und falls ja, tue es ihm inzwischen leid.

Parallel dazu lief die ehrliche Fraktion. Martin Fowler schrieb 2003 den Satz, an dem sich das ganze Feld immer noch abarbeitet: Wir können Produktivität nicht messen, weil wir Output nicht messen können. Und Tom DeMarco, der 1982 mit „You can't control what you can't measure“ die meistzitierte Rechtfertigung für Software-Metriken überhaupt geliefert hatte, widerrief 2009 in der IEEE Software. Ob sein Rat damals richtig war, ob er heute noch gelte, und ob er noch an die Notwendigkeit von Metriken glaube? Seine Antwort: nein, nein und nein.

Übrig blieben zwei Dinge, die tatsächlich funktionieren. DORA mit inzwischen fünf Metriken, und die vier Flow-Metriken aus dem Kanban Guide. Change Lead Time, Deployment Frequency, Failed Deployment Recovery Time, Change Fail Rate, Rework Rate. Work in Progress, Throughput, Work Item Age, Cycle Time.

Von diesen neun Größen misst keine einzige, wie viel jemand produziert hat. Sechs sind Zeiten oder Frequenzen, der Rest sind Fehlerquoten und ein Bestand.

Warum ausgerechnet DORA funktioniert

DORA misst keine Produktivität. DORA misst Kopplung. Deshalb hat es gut ein Jahrzehnt überlebt, während Function Points und Velocity zu Gaming-Spielwiesen verkommen sind.

In der Work-Feedback Loop zerfällt die Feedback Response Time in drei Teile: die Zeit, bis ein Signal sichtbar wird, die Zeit, bis eine verbindliche Entscheidung fällt, und die Zeit, bis diese Entscheidung wirksam wird. Change Lead Time ist eine Teilmessung des dritten Blocks. Deployment Frequency ist die Frequenz, mit der Arbeit überhaupt reale Wirkung erzeugen kann, also die Taktrate, mit der Lernsignale entstehen dürfen. Change Fail Rate und Rework Rate sind die Sicherheitsseite derselben Kopplung.

Deshalb funktionieren diese Metriken. Sie sagen nichts über Leistung und alles über Reaktionsfähigkeit. Und deshalb warnt DORA in der eigenen Dokumentation ausdrücklich davor, sie zu Zielen zu machen, Teams damit zu vergleichen oder eine einzelne davon herauszugreifen. Goodhart hatte das 1975 in der Geldpolitik schon durchexerziert. Jede beobachtete statistische Regelmäßigkeit bricht zusammen, sobald man Druck darauf ausübt, um zu steuern.

Damit ist die Messfrage für LLMs eigentlich schon beantwortet, bevor irgendjemand sie stellt. Zu messen ist die Kopplung, nicht der Tastendruck.

Wo LLMs tatsächlich ansetzen

Brian Houck hat untersucht, wie Entwickler ihre Arbeitswoche tatsächlich verbringen. Aktives Schreiben von Code macht je nach Erhebung zwischen 11 und 14 Prozent aus. Der Rest verteilt sich auf Design, Review, Debugging, Lernen, Meetings, Planung, Dokumentation und Abstimmung.

Ein LLM greift primär in diese 14 Prozent ein. Das ist nicht wenig, aber es ist eben ein Anteil eines Anteils. Denn die Umsetzungszeit, in der das Codeschreiben steckt, ist selbst nur ein Drittel der Feedback Response Time. Und die Feedback Response Time ist das, was über die Lernfähigkeit des Systems entscheidet.

Wer hier eine Verzehnfachung erwartet, rechnet nicht falsch. Er rechnet gar nicht.

Die Zahlen, die niemand gern liest

Es gibt inzwischen eine Studie, die das so sauber zeigt, dass man sie eigentlich nicht mehr diskutieren müsste. Mert Demirer, Leon Musolff und Liyuan Yang haben für das NBER über 100.000 GitHub-Entwickler ausgewertet und mit Microsoft-Telemetrie zur tatsächlichen Tool-Nutzung verknüpft. Beide erstgenannten Autoren arbeiten als bezahlte Research Consultants für Microsoft, das ist offengelegt, und es macht das Ergebnis nur interessanter.

Der kumulative Effekt aller LLM-Werkzeuge zerfällt entlang der Produktionskette:

Gemessen anEffekt
Codezeilen17,3-fach
Berührte Dateien3,9-fach
Commits2,8-fach
Pull Requests2,5-fach
Berührte Repositories1,5-fach
Releases1,3-fach

Lies diese Tabelle noch einmal von unten nach oben. Was du siehst, ist kein Messfehler, sondern exakt der Gradient von interner Aktivität zu realer Wirkung.

Die Work-Feedback Loop kennt nur eine Sorte Arbeit: die, die Wirkung in der Realität erzeugt. Alles davor ist interne Aktivität, egal wie fleißig sie aussieht. Codezeilen sind keine Work, Commits auch nicht, und ein Pull Request schon gar nicht. Erst das Release erzeugt eine Wirkung, an der überhaupt ein Signal entstehen kann. Und genau dort bleiben von der Verzehnfachung noch 30 Prozent übrig.

Die Autoren erklären das mit einer Substitutionselastizität von 0,25 zwischen der beschleunigten Vorstufe und dem menschlichen Aufwand danach. Übersetzt: das sind Komplemente, keine Substitute. Selbst unbegrenzte Automatisierung am Anfang der Kette liefert nur endliche Gewinne am Ende.

Die Praxiszahlen passen dazu. DX hat 16 Monate lang über 400 Organisationen mit jeweils mehr als 100 Entwicklern und hoher LLM-Nutzung im Zeitverlauf begleitet. Die Nutzung stieg im Schnitt um 65 Prozent, der Pull-Request-Durchsatz im Median um rund 8 Prozent, wobei die meisten Firmen zwischen 5 und 15 landen. Aus derselben Auswertung stammt ein Begriff, den ich sehr gelungen finde: false velocity. Organisationen optimieren darauf, zu demonstrieren, wie viel schneller sie geworden sind, ohne je zu prüfen, ob die Roadmap tatsächlich schneller wird.

Bleibt die Selbstwahrnehmung, und hier wird es sportlich. METR hat 2025 ein randomisiertes Experiment mit 16 erfahrenen Open-Source-Entwicklern an 246 echten Issues in ihren eigenen Repositories durchgeführt. Vorher erwarteten die Entwickler 24 Prozent Zeitersparnis. Hinterher schätzten sie, sie hätten 20 Prozent gespart. Gemessen wurden 19 Prozent mehr Zeit. Eine Fehleinschätzung von rund 40 Prozentpunkten, bei Leuten, die genau wussten, dass sie gerade gemessen werden.

Diese Zahl darfst du allerdings nicht in die Gegenwart verlängern, und METR selbst tut das auch nicht. In der zweiten Runde ab Ende 2025 drehte sich das Vorzeichen, die Rohdaten zeigen jetzt einen Speedup von 18 Prozent bei den Wiederholern und 4 Prozent bei den Neuen. METR hält beides für eine Untergrenze und hat das Design im Februar 2026 trotzdem eingestampft. Der Grund ist bemerkenswert: zwischen 30 und 50 Prozent der Teilnehmer reichten Aufgaben bewusst nicht ein, weil sie sie nicht ohne LLM bearbeiten wollten. Ein Entwickler erledigte keine einzige Aufgabe in der Kontrollbedingung. Randomisierte Experimente auf Task-Ebene sterben gerade an der Adoption, die sie messen sollen.

Übrig bleibt die Wahrnehmungslücke selbst, und die ist der eigentliche Befund. Wer den Effekt von LLMs per Umfrage erhebt, misst nicht den Effekt. Er misst, was Leute glauben.

Der Engpass verschwindet nicht, er wandert

Der interessanteste Befund kommt aus einer Firma, bei der es funktioniert hat.

Hao He, Yegor Denisov-Blanch, Bogdan Vasilescu und Kollegen haben 802 Entwickler und 196.212 Pull Requests über zwei Jahre verfolgt. Die Firma hatte ein explizites Mandat ausgegeben, die gemergten Pull Requests pro Entwickler zu verdoppeln. Im April 2026 lag der Wert beim 2,09-Fachen der Ausgangsbasis. Das ist einer der größten je in einem echten Feldeinsatz dokumentierten Zuwächse.

Was in derselben Studie steht: die Review-Last pro Reviewer hat sich ebenfalls verdoppelt, und automatisiertes Review hat menschliches Review überholt. Merge- und Revert-Raten blieben dabei stabil, die Qualität ist also nicht sichtbar eingebrochen. Die Autoren beanspruchen ausdrücklich keine saubere Kausalattribution, es ist eine Firma, und eine ausgesprochen LLM-affine dazu.

Was die Studie zeigt, ist trotzdem entscheidend, und DORA nennt es Verification Tax. Die Zeit, die vorne beim Schreiben eingespart wird, taucht hinten beim Prüfen wieder auf. Im Modell gesprochen sinkt die Umsetzungszeit an einer Stelle und steigt an einer anderen. Nach der Engpasslogik ändert das am Gesamtsystem erst einmal gar nichts.

Und selbst wenn du diesen Engpass löst, wartet der nächste. Wenn dein Team drei Wochen auf eine verbindliche Priorisierungsentscheidung wartet, ist es vollkommen egal, ob der Code danach in zwei Stunden oder zwei Tagen steht. Entscheidungs-Latenz interessiert sich nicht für dein Tooling. Und die Kapitalfrequenz, also der Takt, in dem Budget überhaupt umgelenkt werden kann, erst recht nicht.

Was du also gekauft hast, ist eine höhere Work-Geschwindigkeit bei unveränderter Feedback-Geschwindigkeit. In der Diagnose-Matrix ist das keine Verbesserung, sondern eine Bewegung in Richtung Actionism, also hohe Aktivität bei niedriger Lernrate.

Der DORA-Report von 2025 formuliert das mit knapp 5.000 Befragten empirisch. LLMs sind ein Verstärker. Sie reparieren kein Team, sie verstärken das, was ohnehin da ist. Höhere Adoption korreliert inzwischen mit besserem Durchsatz und gleichzeitig mit höherer Instabilität. Wer eine unterbrochene Rückkopplung hatte, hat sie jetzt schneller.

Was du stattdessen misst

Messbar ist das alles. Nur nicht dort, wo die meisten suchen.

Zuerst eine Regel, an der du nicht vorbeikommst: niemals im Querschnitt vergleichen. Also nie LLM-Nutzer gegen Nicht-Nutzer. GitClear hat gezeigt, warum. Intensive LLM-Nutzer produzieren das Vier- bis Zehnfache der Nicht-Nutzer. Misst man dieselben Leute aber gegen ihr eigenes früheres Ich, bleiben rund 25 Prozent übrig. Der Rest ist Selektion, denn die Guten haben es zuerst adoptiert.

Du misst also im Zeitverlauf gegen deine eigene Baseline. Und weil eine Baseline rückwirkend schwer zu erfinden ist, ist der Zeitpunkt für den Start immer jetzt.

Gemessen wird die Feedback Response Time, zerlegt in ihre drei Teile:

KomponenteWas du misstWoherBerührt ein LLM das?
SignalzeitZeit vom Release bis valides Nutzungs- oder Marktsignal vorliegtAnalytics, Support, Vertrieb, BetriebsdatenNein
EntscheidungszeitZeit vom sichtbaren Signal bis zur verbindlichen PriorisierungsentscheidungBoard-Historie, Protokolle, TicketständeNein
UmsetzungszeitCycle Time von Entscheidung bis Produktion, getrennt nach Development und ReviewJira, Git, Deployment-PipelineNur im Development-Anteil

Sobald du die drei Blöcke einzeln vor dir liegen hast, brauchst du über den Effekt von LLMs nicht mehr zu spekulieren, weil du siehst, in welchem Block er überhaupt auftauchen kann. Diese Trennung ist der ganze Trick.

Dazu kommen drei Gegenmetriken, ohne die die Messung wertlos ist. Change Fail Rate und Rework Rate, weil Geschwindigkeit ohne Stabilität keine Kapazität ist, sondern verschobene Kosten. Die Durchlaufzeit im Review getrennt von der im Development, weil du sonst nicht mitbekommst, dass der Engpass nur gewandert ist. Und der Anteil an Code, der innerhalb von zwei Wochen wieder angefasst wird, weil das der billigste verfügbare Indikator dafür ist, ob die Geschwindigkeit echt war oder ob ihr gerade nur zweimal dasselbe baut.

Ein Rechenbeispiel

Nimm ein Team mit einer Feedback Response Time von 42 Tagen. Vierzehn Tage, bis belastbare Nutzungsdaten vorliegen. Einundzwanzig Tage bis zur verbindlichen Entscheidung, weil zwei Gremien beteiligt sind. Sieben Tage Umsetzung, davon zwei Tage tatsächliches Entwickeln.

Jetzt kommt das LLM und halbiert die reine Entwicklungszeit. Ein gesparter Tag von 42. Die Lernfähigkeit des Systems verbessert sich um 2,4 Prozent.

Im selben Zeitraum steigt die Review-Last, und die Change Fail Rate klettert von 5 auf 6 Prozent. Rechnet man den Aufwand für die zusätzlichen Fehlschläge dagegen, landet man bei null oder darunter.

Das ist keine Polemik gegen LLMs, sondern schlichte Engpasslogik. In diesem Team liegen 35 der 42 Tage in Signal- und Entscheidungszeit. Wer dort einen einzigen Tag herausholt, schlägt jedes Coding-Tool der Welt.

Und deshalb lohnt sich die Messung selbst dann, wenn dir der Effekt von LLMs herzlich egal ist: sie zeigt dir, wo dein Engpass wirklich sitzt, und die meisten Organisationen erfahren das zum ersten Mal, wenn sie diese Rechnung aufmachen und feststellen, dass die Entwickler nie das Problem waren.

Was du nicht misst

Codezeilen, Commits, Pull-Request-Zahlen, Akzeptanzraten von Vorschlägen, Tokenverbrauch, Anzahl der Agent-Tasks, Adoptionsquoten. Nichts davon ist ein Ergebnis, das ist Diagnosekontext, mit dem du Bewegungen in den echten Metriken interpretierst. Eine Adoptionsquote von 90 Prozent beweist nur, dass 90 Prozent es benutzen.

Ebenso wenig misst du Einzelpersonen, und du vergleichst keine Teams miteinander. Das gilt für DORA seit einem Jahrzehnt und wird durch LLMs nicht besser, sondern schlechter, weil dieselbe Zahl jetzt aus völlig unterschiedlichen Mensch-Maschine-Konstellationen entstehen kann. Eine Merge-Rate von 95 Prozent bedeutet entweder hervorragende Qualität oder erschöpfte Reviewer. Die Zahl allein sagt es dir nicht.

Und rechne mit einem Einbruch, bevor etwas besser wird. DORA beschreibt das als J-Kurve aus Lernkurve, Verification Tax und der Anpassung nachgelagerter Prozesse. Wer diesen Dip als Scheitern liest, zieht das Budget genau im falschen Moment.

Fazit

Die Frage „Wie viel schneller sind wir durch LLMs geworden?“ ist strukturell dieselbe Frage wie „Sind wir eigentlich agil?“. Beide klingen nach Messung und sind in Wahrheit Etikettenfragen. Beide lassen sich beantworten, ohne dass sich irgendetwas ändert.

Die Frage, die trägt, lautet anders. Ist die Kopplung zwischen unserer Arbeit und der Realität schneller und zuverlässiger geworden?

Wenn deine Entwickler doppelt so viel Code produzieren und deine Feedback Response Time steht bei 42 Tagen wie im Jahr davor, dann hast du keine Beschleunigung gekauft. Du hast Actionism gekauft, in besserer Auflösung.

Miss also die drei Zeiten, gegen dich selbst und nicht gegen andere, und schau, welcher Block der größte ist. Mehr ist es nicht.

Diskussion gern auf Mastodon unter @nobsagile. Kontakt.

Quellen

Falls du hier gerade nickst: genau solche Sachen nehme ich mir in NBA Kompakt vor – ein Thema pro Folge, fünf bis zehn Minuten, jede Woche. Wenn du das im Ohr statt im Feed willst: hier abonnieren.

Auch interessant