DORA-Metriken für Coding Agents: Warum SPACE und DX Core 4 nicht reichen

Sechs Monate nach dem Rollout sind drei Plätze leer. Der Senior aus dem Review-Team. Die Tech-Lead aus dem Backend. Und der Reviewer, der bei Architekturfragen die härteste Hand hatte. In derselben Woche steht auf dem Engineering-Dashboard: Deployment Frequency plus vierzig Prozent, Lead Time halbiert, Pull Requests pro Entwickler verdoppelt. Welche Zahl ist die richtige?

Keine allein. Und keines der populären Frameworks beantwortet die Frage, ohne dass man es vorher angepasst hat. DORA, SPACE und DX Core 4 wurden nicht für agentische Coding-Systeme entworfen. Sie messen, was sie immer gemessen haben. Was der Agent daran verändert, sehen sie nur indirekt. Und was er direkt beeinflussen kann, wird er maximieren. Tragfähig sind darum nur die Metriken, die außerhalb seiner direkten Reichweite liegen: Outcomes, nicht Outputs.

Kurz gefasst: Keines der drei Frameworks zeigt allein, ob ein Coding Agent dem Team wirklich hilft. Aussagekräftig wird die Messung erst mit vier Gegenmetriken in drei Spannungsfeldern: Flow, Qualität und Developer Experience. Gemessen wird auf Team-Ebene, gegen eine Baseline und mit Quellenzuordnung pro Change. Acceptance Rate, Lines of Code und PRs pro Entwickler gehören nicht in den Erfolgsbericht. Diffs per Engineer nur aggregiert, nie isoliert und nie im Performance-Review.

Im Praxisplan für KI-Coding-Agents steht das Thema zwischen Tooling und Compliance. Wer den Engpass-Post über den verschobenen Review-Stau gelesen hat, kennt die Diagnose. Dieser Text liefert die Verschreibung.

Begriffsklärung: DORA meint in diesem Artikel nicht den europäischen Digital Operational Resilience Act für Finanzunternehmen, sondern DevOps Research and Assessment, das Metrik-Framework zur Software-Delivery-Performance. SPACE ist ein Forschungsframework, um Entwicklerproduktivität in fünf Dimensionen zu messen. DX Core 4 ist ein kommerziell geprägtes Produktivitätsframework von DX, das DORA- und SPACE-Ideen in vier Dimensionen bündelt. Weiterführend: DORA-Metriken, SPACE-Paper, DX Core 4.

DORA, SPACE und DX Core 4: drei Frameworks, drei Lücken

Die DORA-Metriken messen die Lieferleistung der DevOps-Pipeline heute über fünf Größen: Deployment Frequency, Lead Time for Changes, Change Failure Rate, Failed Deployment Recovery Time und Deployment Rework Rate. Die fünfte kam 2024 dazu, weil Change Failure Rate allein zeigt, dass es brennt, aber nicht, wie oft das Team danach nachfassen muss. Der 2025er Report stützt sich auf knapp 5.000 Befragte und über 100 Stunden qualitativer Daten. Harvey und DeBellis bringen es im Google-Cloud-Blog auf eine Formel, die seitdem zitiert wird: „AI doesn't fix a team; it amplifies what's already there."

Eine kausale Zuschreibung zwischen KI-Einsatz und Outcomes leistet DORA nicht, sondern misst Korrelationen und Verstärker-Effekte. Ob die plus vierzig Prozent Deployment Frequency vom Agenten kommen oder von einer Trunk-Based-Umstellung im selben Quartal, sagt DORA nicht. Und den Stabilitäts-Benchmark erreichen wenige: 2025 lagen nur 7,3 Prozent der Teams unter zwei Prozent Rework Rate.

SPACE liefert keinen Metrik-Katalog, sondern fünf Dimensionen, in denen sich Produktivität sinnvoll messen lässt: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow. Sechs Autorinnen und Autoren (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler), erschienen in ACM Queue, März 2021. Zentrale Empfehlung des Papers: mindestens drei Dimensionen gleichzeitig, davon mindestens eine wahrnehmungsbasierte Messung (im Original perceptual measure). SPACE warnt ausdrücklich davor, jede einzelne dieser Metriken zum Ziel zu machen. Das ist Feature und Bug. Feature: verhindert Tunnelblick. Der Nachteil: Wer ein konkretes Dashboard braucht, muss es selbst ableiten.

DX Core 4 ist ein neuerer Versuch, die Vorgänger zu vereinen. Im Dezember 2024 von Abi Noda veröffentlicht, mit Forsgren, Storey und Zimmermann als Beiräten. Atlassian hat die Übernahme von DX im September 2025 angekündigt und am 11. November 2025 vollzogen, Transaktionsvolumen rund eine Milliarde US-Dollar. Vier Dimensionen: Speed, Effectiveness, Quality, Impact. Die Speed-Metrik heißt „Diffs per Engineer" und ist die umstrittenste Wahl im Framework. DX selbst schreibt, dass diese Zahl niemals auf Individualebene oder in Performance-Reviews verwendet werden darf. Will Larson nennt sie eine „extremely hard metric to evaluate in isolation". Ben Lloyd Pearson dokumentiert auf Dev Interrupted, wie Teams sie gamen: kleinere PRs, häufiger gemerged, ohne dass die echte Liefermenge steigt. Die Speed-Metrik produziert dann ihre eigene Inflation, sauber gezählt. DX hat 2026 nachgereicht und ein eigenes Erweiterungs-Framework für KI veröffentlicht: utilization, impact, cost. Damit wird die Zuordnungslücke anerkannt, nicht geschlossen.

Die drei Frameworks scheitern also nicht an falschen Metriken, sondern an derselben Lücke: Sie messen Wirkung, aber nicht Herkunft.

Das Prinzip, das jeden Rollout regiert

Sobald eine Kennzahl eine Organisation steuert, verändert sie das Verhalten, das sie messen soll. Marilyn Strathern hat das 1997 auf den Satz gebracht, der heute meist Goodhart zugeschrieben wird: „Sobald eine Metrik zum Ziel wird, hört sie auf, ein gutes Maß zu sein." Für einen Coding-Agent-Rollout heißt das: jede Kachel im Dashboard wird zum Anreiz, sobald jemand sie liest. Teams mit Agenten optimieren dann schneller auf das, was gemessen wird, auch wenn die Zahl ohne Kontext kaum belastbar ist.

Coding Agents beschleunigen die Mechanik. Sie zähmen sie nicht.

Acceptance Rate ist die Zahl, die durch jede Verkaufsfolie wandert, weil sie bequem aussieht: Vorschlag angezeigt, Vorschlag akzeptiert, Fortschritt behauptet. Genau deshalb ist sie gefährlich. GitHub führt die Code Completion Acceptance Rate zwar weiterhin in den Copilot Usage Metrics, definiert sie aber nur als Anteil akzeptierter Vorschläge: ein Relevanzsignal, kein Erfolgsmaß. GitHubs eigene Modell-Evaluation zeigt zudem, wie leicht die Zahl kippt: höhere Latenz kann eine höhere Acceptance Rate erzeugen, weil Nutzer weniger Vorschläge sehen. Und im 2026er Usage-Metrics-Dashboard verweist GitHub ausdrücklich darauf, über Acceptance Rates hinaus zu messen. Selbst eine hohe Acceptance Rate heißt am Ende nur, dass jemand Tab gedrückt hat.

PRs pro Entwickler ist die nächste Falle. Der Agent skaliert die Zahl, das System dahinter nicht. Mehr PRs heißen mehr Review-Last, keine zusätzliche Wertschöpfung. Der Bericht zeigt Throughput, die Queue zeigt Stau.

„Lines of Code generated" hat Dijkstra 1988 in EWD 1036 prägnant formuliert: Codezeilen werden ausgegeben, nicht produziert. Die Zahl gehört in keinen Bericht.

Genau darum fallen Acceptance Rate, PR-Zahl und generierte Codezeilen als Erfolgsmetriken aus. Sie messen Agentenaktivität, nicht Systemwirkung.

Entwicklerproduktivität messen: das Vier-Metriken-Set

Was bleibt, wenn man die drei Frameworks ernst nimmt und für KI anpasst: vier Metriken in drei Dimensionen. Jede hat eine Gegenmetrik im selben Set. Das ist kein Forschungsframework, sondern ein operatives Kontrollset für Rollouts. Die Spannung zwischen den vier Metriken ist beabsichtigt: sobald eine auf rot steht, hält der Rollout an, auch wenn die anderen drei grün sind.

Change Failure Rate

Aus DORA. Prozentsatz der Deployments, die in der Produktion zu einem Incident führen. Nicht Staging. Produktion. In vielen DORA-Benchmark-Darstellungen liegt die beste Gruppe etwa bei fünf Prozent; die konkrete Schwelle schwankt je nach Reportjahr und Definition. Bis fünfzehn Prozent gelten je nach Quelle noch als gesund. Warum CFR und nicht Deployment Frequency? Weil der Agent die Frequenz direkt treiben kann; CFR kann er nicht treiben, ohne das zu verschlechtern, was zählt. Evidenzebene: Industry-Research mit veröffentlichter Methodik.

Rework Rate oder 14-Tage-Churn

Zwei verwandte Metriken. Als Kernmetrik eine davon, je nach operativer Messbarkeit.

Variante A · Deployment Rework Rate nach DORA: Anteil der Deployments, die ungeplante Folgearbeit nach Produktionsproblemen verursachen. DORA hat sie 2024 als fünfte Software-Delivery-Metrik aufgenommen und 2025 erstmals mit Benchmarks unterlegt (siehe oben: nur 7,3 Prozent der Teams unter zwei Prozent).

Variante B · 14-Tage-Code-Churn als Proxy, wenn die Deployment-Pipeline diese Zuordnung nicht hergibt: Anteil der Codezeilen, die innerhalb von zwei Wochen nach Commit wieder geändert oder ersetzt werden. GitClear misst diese Variante anhand von 211 Millionen Codezeilen und berichtet einen Anstieg von 3,1 Prozent (2020) auf 5,7 Prozent (2024). Die Zahl korreliert mit dem KI-Adoptions-Fenster, eine kausale Zuschreibung zu KI-geschriebenem Code leistet GitClear nicht (das Tool kann Zeilen nicht maschinell gegen menschlich auseinanderhalten).

Beide Maße betrachten dasselbe Phänomen auf unterschiedlichen Ebenen: einmal Pipeline, einmal Repository. Evidenzebene: Industry-Research und methodisch dokumentierte Vendor-Telemetrie.

Median PR Review Time

Aus der Faros-Telemetrie. Die Metrik folgt direkt aus dem Engpass-Argument. Faros berichtet je nach Auswertungsschnitt zwei Zahlen: plus 91 Prozent mehr Review Time im 2025er Report (über 10.000 Entwickler und 1.255 Teams) und plus 441,5 Prozent Median Time in Review im 2026er Acceleration-Whiplash-Material. Zwei unterschiedliche Schnitte, beide ohne unabhängige Validierung, beide in dieselbe Richtung. Steigt die Review-Zeit nach einem Rollout deutlich, ist der Rollout erklärungspflichtig. Ohne Gegenbeleg ist er nicht skalierungsreif, egal was die Deployment-Frequency-Kachel anzeigt. Evidenzebene: Vendor-Telemetrie mit Sample-Beschreibung, ohne unabhängige Validierung.

Drei-Fragen-Puls für Developer Experience

Kein validierter Index, sondern ein bewusst kleines Frühwarnsystem. Der Developer Experience Index von DX ist ein 14-Fragen-Likert auf der DX-Plattform und sinnvoll für Häuser, die diese Plattform lizenziert haben. Für alle anderen reichen drei Fragen, monatlich, anonym, ausschließlich auf Team-Ebene, mit Teilnahmequote von mindestens 70 Prozent und keiner Auswertung unter sechs Antworten: Hilft mir der Agent mehr, als er mich stört? Verstehe ich den Code, den ich merge? Hat der Agent meine Arbeit in den letzten 30 Tagen verbessert oder verschlechtert? Trend zählt mehr als Einzelwert. Die Anthropic-Studie von Shen und Tamkin (Januar 2026) zeigt, warum die zweite Frage zählt: in einem RCT mit 52 Junior-Entwicklern schnitten die KI-unterstützten Teilnehmer im Comprehension-Test rund 17 Prozent schlechter ab. Sekundärberichte greifen die Zahl auf, teils unpräzise als „17 Punkte"; Anthropic selbst betont stärker die Nutzungsmuster als den Rohwert. Evidenzebene: Framework-Inspiration und Forschung zur Skill-Formation.

Review Time misst Flow, CFR und Rework Rate sichern Stabilität und Qualität, der Drei-Fragen-Puls schützt die Developer Experience. Wenn die ersten drei grün stehen und der Puls rot ist, hält der Rollout an. Wenn der Puls grün ist und die Rework Rate steigt, ebenso. Rot heißt dabei nicht Tagesausschlag, sondern anhaltende Verschlechterung im 30-Tage-Fenster gegenüber einer Baseline aus 30 bis 60 Tagen vor dem Rollout. Schwellen werden relativ zur eigenen Team-Varianz gesetzt, nicht aus fremden Benchmarks übernommen. Vier Metriken, nicht dreißig. SPACE empfiehlt mindestens drei Dimensionen, das ist die Untergrenze, nicht der Auftrag. Wer ein Dashboard mit dreißig Kacheln baut, hat ein Messsystem oder ein Problem. Meist beides.

Ampel: Go, Hold, Stop

Die vier Metriken brauchen eine Entscheidungsregel, sonst werden sie zu Dashboard-Folklore. Ein Rollout gilt nur dann als erfolgreich, wenn die drei harten Liefermetriken (CFR, Rework Rate, Review Time) stabil oder besser werden und der Puls nicht fällt. Eine einzelne grüne Kachel zählt nicht.

Wer trotz Hold weiter skaliert, kauft den Stop teurer. Wer beim ersten gelben Kästchen sofort stoppt, hat keine Entscheidungsregel, sondern Schreckreaktion. Die Ampel ist ein 30-Tage-Fenster, kein Tagesbarometer.

Die Zuordnungslücke, die kein Framework von Haus aus schließt

Ohne Quellenzuordnung pro Change bleibt unklar, was der Agent zum Ergebnis beigetragen hat. DORA, SPACE und Core 4 erfassen den Output, nicht die Quelle, und keines der drei leistet diese Zuordnung von Haus aus. Zwei praktische Optionen, beide mit Mängeln.

Commit-Trailer

Was einem Standard am nächsten kommt, ist Assisted-by: AGENT:MODEL als Policy des Linux-Kernels, übernommen von Fedora und LLVM. Anthropics Claude Code schreibt standardmäßig Co-Authored-By: Claude; der offene Feature Request #36105 bewegt sich in Richtung Assisted-by:. Cursor verzichtet auf Trailer und gleicht stattdessen Commits serverseitig per Signature-Matching ab. Trailer sind self-reported, also verzerrt, aber billig. Sie funktionieren in disziplinierten Teams. Sobald Druck entsteht, die Zahlen schön aussehen zu lassen, scheitern sie.

Session-Telemetrie

Claude Code Analytics, Cursor Admin Dashboard, GitHub Copilot Usage Metrics API. GitHub hat die Legacy-Copilot-Metrics-Endpunkte zum 2. April 2026 auslaufen lassen und unter der API-Version 2026-03-10 neue Usage-Metrics-Endpunkte dokumentiert. Diese Daten lassen sich aggregieren, mit der Git-Historie zusammenführen und sind präziser als jeder Trailer. Dazu kommt das Betriebsrat-Gespräch: Copilot-Logs sind regelmäßig mitbestimmungspflichtig nach § 87 Abs. 1 Nr. 6 BetrVG, sobald sie zur Verhaltens- oder Leistungskontrolle geeignet sind. Der Bitkom-Leitfaden vom Februar 2026 zeigt, was die Betriebsrats-Einbindung praktisch verlangt. Wer das überspringt, baut ein Messsystem, das später wieder rausfliegt. Den vollen Sachverhalt behandelt der Betriebsrat-Post.

In den ersten drei Monaten eines Rollouts reichen Commit-Trailer und eine grobe Segmentierung (KI-intensives Team gegen Vergleichsteam). Danach, wenn ernsthaft gemessen werden soll, braucht es Session-Telemetrie. Alles davor bleibt belastbarer Frühindikator, aber kein ROI-Nachweis.

Sechs Tabus für ein belastbares Messsystem

1. Keine Individualmessung. Niemals. Sobald Performance-Reviews an Metriken hängen, gilt Stratherns Satz doppelt.
2. Keine Lines of Code. „Lines of Code generated" gehören in kein Dashboard, auch nicht als Nebenmetrik; die Zahl ist leicht manipulierbar, und Dijkstra hat 1988 prägnant begründet, warum.
3. Keine Teamvergleiche ohne identische Definitionen. „Deployment" bedeutet in Team A etwas anderes als in Team B; solange die Definition nicht gleich ist, sind DORA-Zahlen nicht vergleichbar.
4. Keine Acceptance Rate als Erfolgsmaß. Orosz und Tacho dokumentieren in der Pragmatic-Engineer-Auswertung (September 2025), dass Google, GitHub, Microsoft, Dropbox und Monzo diese Zahl heute kaum noch tracken.
5. Keine Vendor-Benchmarks ohne Methodikprüfung. Das gilt auch für die Faros-Zahlen, die dieser Artikel nutzt: kein Signifikanztest, keine Repräsentativitätsaussage, kein Kontrolldesign.
6. Keine Messung ohne Baseline. Wer erst mit Agenten anfängt zu messen, hat keinen Referenzpunkt; alle Zahlen sind dann Hintergrundrauschen.

Das Vier-Metriken-Set beantwortet nicht den finanziellen ROI. Es beantwortet die Vorfrage, ohne die jede ROI-Rechnung im Nebel landet: Hat der Rollout das System verbessert oder nur Arbeit verschoben? Erst wenn diese Antwort belastbar ist, lohnt sich die Rechnung gegen Tool-Lizenz, Enablement und Review-Mehraufwand.

Was übrig bleibt, ist überschaubar: vier Gegenmetriken neben den DORA-Metriken auf Team-Ebene, klar markiertes Evidenzgewicht, Quellenzuordnung pro Change, Baseline aus der Zeit vor dem Rollout. Alles, was darüber hinausgeht, muss einen konkreten Steuerungszweck haben. Sonst ist es Theater. Wenn das eigene Engineering-Dashboard heute näher am Theater steht als an dieser Liste, lohnt eine Stunde Review-Audit mehr als die nächste Vendor-Demo.