Zum Inhalt springen

Wissensbasis

Qualitäts- und Produktivitätsmetriken

Mit Agentic Coding schaden Volumenmetriken wie Codezeilen oder Pull Requests, weil, wer Volumen belohnt, das Review mit ungeprüftem Output flutet. Tragfähig bleiben First-Pass-Akzeptanz, Rework-Rate und die DORA-Delivery-Metriken, für Agent-Änderungen gegen die menschliche Baseline gelesen.

Verfasst von

Aktualisiert:

Agentic Engineering 5

Unsere Position. Wir zählen eine Änderung, sobald sie in Produktion läuft (öffnet in einem neuen Tab) und Kund:innen sie nutzen, dafür zahlen oder uns sagen, dass sie geholfen hat. Gemergte Pull Requests sind Output. KI steigert die Produktivität stark und ändert am Wert nichts (öffnet in einem neuen Tab). Deshalb messen wir, was in Produktion ankommt und was dort bricht.

Jede Kennzahl unten lesen wir gegen eine Baseline. Das sind die eigenen Zahlen des Teams vor der Einführung oder, bei Agent-Änderungen, die Change Failure Rate menschlicher Änderungen. Wird eine Metrik zum Ziel, optimiert das Team sie, und sie misst die Fähigkeit dahinter nicht mehr.

Welche Metriken bedeuten mit KI noch etwas?

Codezeilen oder Pull Requests zu zählen war schon immer ein schwacher Proxy. Mit Agentic Coding wird es schädlich. Thoughtworks führt Coding-Durchsatz als Produktivitätsmaß im Ring Caution. Wer Volumen belohnt, flutet das Review mit unzureichend geprüftem Output. Wiederholtes Hin und Her mit Reviewer:innen verlängert die Cycle Time. Und der Restaufwand, generierten Code an die Konventionen des Teams anzupassen, bleibt unsichtbar (Thoughtworks Technology Radar Vol 34, April 2026 (öffnet in einem neuen Tab)).

An die Stelle des Durchsatzes tritt die First-Pass-Acceptance-Rate: wie oft KI-Output mit minimalem Rework brauchbar ist. Eine niedrige Rate legt versteckten Aufwand offen, und ihr könnt etwas dagegen tun. Bessere Priming-Dokumente und Design-Gespräche heben sie mit der Zeit. Sie hängt auch mit Delivery-Ergebnissen zusammen: Niedrige Akzeptanz treibt die Change Failure Rate hoch, wiederholte Iteration verlängert die Lead Time.

Die Metriken des DORA-Programms bleiben das tragfähige Rückgrat. Die Ausgabe 2025 ergänzt eine fünfte, die Rework-Rate. Sie misst den Anteil der Delivery-Pipeline, den ungeplante Fixes an bereits als fertig gemeldeter Arbeit verbrauchen. Steigt sie, warnt sie früh: Die KI-gestützte Geschwindigkeit erkauft dann Instabilität statt Durchsatz (Thoughtworks Technology Radar Vol 34, April 2026 (öffnet in einem neuen Tab)).

Für die Zusammenarbeit zwischen Mensch und Agent empfiehlt Thoughtworks, die Qualität auf Teamebene zu messen statt nur die Geschwindigkeit:

  • First-Pass-Akzeptanz
  • Iterationszyklen pro Aufgabe
  • Rework nach dem Merge
  • fehlgeschlagene Builds
  • Review-Last

Kürzere Feedback-Zyklen und weniger fehlgeschlagene Builds zeigen tatsächlich an, dass die Arbeit mit einem Agent wirkt. Der DORA-Report 2025 kommt von der Adoptionsseite zum selben Schluss. Fast alle setzen KI ein, deshalb taugt die Nutzungsquote nicht als Kennzahl. Die Messung muss bestehende DORA- und DX-Baselines mit KI-spezifischen Signalen kombinieren, um zu zeigen, ob sich Ergebnisse verbessern (DORA-Report zu KI-gestützter Entwicklung).

DORA warnt auch vor einem subtileren Fehler. Die vier zentralen Delivery-Metriken direkt zum Ziel zu machen, ist eine bekannte Falle. Teams optimieren dann die Zahl statt der Fähigkeit dahinter und verlieren das Ergebnis. Tragfähig ist, die Fähigkeiten aufzubauen, die die Metriken nur messen: Versionskontrolle, Continuous Integration, kleine Batches, lose Kopplung. Unter KI wiegt das schwerer. DORAs frühe Befunde zeigen, dass die Zufriedenheit der Entwickler:innen steigt, während die Delivery-Performance fällt. Mehr Bugs erreichen Produktion, die Codequalität sinkt. Gerade die Kennzahl, die dem Team am meisten schmeicheln würde, führt also in die Irre: das Gefühl, produktiv zu sein (WeAreDevelopers-Talk 2025 zu DORA und moderner Softwareentwicklung (öffnet in einem neuen Tab)).

Für Agent-generierte Änderungen schlägt die Continuous-Delivery-Community vier Kennzahlen vor, jede gegen die menschliche Baseline gelesen:

  • Agent-Deploys werden markiert. Ihre Rollback- und Incident-Raten vergleicht ihr über 30-Tage-Fenster. Das Ziel liegt bei oder unter der Change Failure Rate menschlicher Änderungen.
  • Die Review-Zeit für Agent-Änderungen sollte der für menschliche Änderungen entsprechen. Ein viel schnelleres Review deutet auf Durchwinken hin, nicht auf Effizienz.
  • Die Testabdeckung in Agent-geschriebenen Dateien sollte über der Baseline des Teams liegen.
  • Jede Agent-Änderung sollte ihren vollständigen Artefaktsatz mitbringen: Intent, Testspezifikation, Feature-Beschreibung und Herkunft wie Agent-Identität und Prompt. Ein monatliches Audit prüft diesen Satz gegen ein Ziel von 100%.

Dieselbe Seite führt die Fehlschläge bei der Einführung auf zwei Lücken zurück: einen übersprungenen Delivery-Vertrag pro Änderung und fehlende Durchsetzung in der Pipeline (MinimumCD.org and DojoConsortium.org - Pitfalls and Metrics (öffnet in einem neuen Tab), Stand September 2026).

Bekommt KI-mitverfasster Code mehr Review-Befunde?

CodeRabbit, ein Anbieter für Code-Review, hat eine Beobachtungsstudie zu 470 Open-Source-Pull-Requests veröffentlicht. 320 davon stufte CodeRabbit anhand von Commit- und Inhaltssignalen als KI-mitverfasst ein. Die übrigen 150 ohne solche Signale galten als rein menschlich. Die Studie wendete eine strukturierte Taxonomie für Review-Befunde an und normalisierte die Befundraten (CodeRabbit - State of AI vs Human Code Generation Report (öffnet in einem neuen Tab), 17. Dezember 2025). Lest sie als Beobachtungsstudie eines Anbieters zu automatisierten Review-Befunden. Niemand hat diese Befunde unabhängig bewertet, und sie belegen keine Qualität in Produktion.

Die berichtete Lücke: 10,83 automatisierte Review-Befunde pro als KI markiertem Pull Request gegenüber 6,45 pro als menschlich markiertem, insgesamt etwa 1,68x. Die als KI markierte Seite verschiebt sich dabei nicht gleichmäßig. Unter den als KI markierten Pull Requests gibt es mehr Fälle mit besonders vielen Befunden. Das Profil nach Kategorien ist ungleich. Lesbarkeit, Geschäftslogik, Formatierungskonsistenz und Fehlerbehandlung wiegen auf der als KI markierten Seite am schwersten. Bei Rechtschreibung und Testbarkeit schnitten die als KI markierten Pull Requests besser ab (CodeRabbit-Report, 17. Dezember 2025 (öffnet in einem neuen Tab)). Keine Befundkategorie trat nur bei KI auf. Der Report behauptet einen Unterschied in der Häufigkeit, nicht in der Art.

Die praktische Lesart stützt teilweise CodeRabbits eigene Produktkategorie. Richtet die Aufmerksamkeit im Review auf lokale Geschäftsregeln, Ausnahmepfade, Nebenläufigkeit und Reihenfolge von Abhängigkeiten, Konfiguration, Credentials und I/O. Deterministische Gates für Policy, Tests und Security bleiben bestehen.

Die Einschränkungen begrenzen die Aussage eng:

  • Die Urheberschaft ist aus expliziten Signalen abgeleitet. Die als menschlich markierten Pull Requests können also selbst KI enthalten.
  • Die Stichprobe umfasst nur Open-Source-Nutzer:innen von CodeRabbit.
  • Der Anbieter besitzt die Taxonomie und den Reviewer und verkauft die Abhilfe.
  • Es gibt keinen rohen, reproduzierbaren Datensatz und keine unabhängige menschliche Bewertung.
  • Es fehlen Kontrollen für Größe des Pull Requests, Sprache, Repository, Autor:in, Aufgabe und Komplexität.

Die Studie zählt die Befunde eines automatisierten Reviewers und misst damit Review-Last. Ohne diese Kontrollen kann sie nicht zeigen, dass KI-Autorschaft die Qualität senkt (CodeRabbit-Report, 17. Dezember 2025 (öffnet in einem neuen Tab)).

Verwandte Seiten

Quellen

Delivery-Praxis

Qualitätsforschung