Wie messe ich den positiven Effekt von Agenten? Meine Metriken für die Agenten-Performance

In den vorherigen Posts dieser Serie habe ich beschrieben, warum ich Vibe Coding für komplexe Projekte verlassen habe (Post 11), wie Planungs- und Implementierungsagenten zusammenspielen (Post 12 und Post 13), wie ein konkreter Durchlauf aussieht (Post 15) und wie ich die Agenten in Claude Code und Copilot anlege (Post 16) sowie über MCPs erweitere (Post 17).

Eine Frage habe ich dabei bisher konsequent umschifft – obwohl sie sich nach jedem dieser Posts förmlich aufdrängt: Woher weiß ich eigentlich, dass dieses ganze Setup tatsächlich besser ist als ein einfacher Prompt?

In diesem Post versuche ich, ehrlich darauf zu antworten – und vorzustellen, welches Framework dabei hilft, die Frage von „Ich fühle mich produktiver" zu „Ich kann es belegen" zu verschieben.

Das Problem mit dem Bauchgefühl

Nach mehreren Monaten mit dem Agenten-Workflow habe ich einen klaren Eindruck: Es funktioniert. Weniger Architekturbrüche, weniger Duplikation, weniger Tage, die ich damit verbringe, KI-generierte Spaghetti zu entwirren. Wenn mich jemand fragt, würde ich ohne zu zögern sagen: ja, der Aufwand zahlt sich aus.

Das Problem an dieser Antwort ist nur: Sie ist genau das, was ich bei anderen kritisch sehe – ein subjektives Gefühl. Und die Forschung warnt sehr explizit davor, sich auf solche Eindrücke zu verlassen. Eine viel zitierte randomisierte Studie von METR hat gezeigt, dass erfahrene Open-Source-Entwickler nach dem Einsatz von KI-Assistenten glaubten, 20 % schneller geworden zu sein – tatsächlich waren sie 19 % langsamer. Die Diskrepanz zwischen wahrgenommener und gemessener Produktivität ist also nicht klein, sondern systematisch.

Genauso problematisch sind Aktivitätsmetriken: Anzahl der Commits, Zeilen akzeptierter Vorschläge, Token-Verbrauch. Sie messen, wie viel passiert – nicht, ob das Richtige passiert. Ein Agenten-Workflow, der dreimal so viele Vorschläge generiert wie ein direkter Prompt, sieht in dieser Logik produktiver aus – auch wenn er am Ende dieselbe Lösung in dreifacher Zeit produziert hat.

Was die Forschung über echte Messung sagt

Wer das Thema ernst nehmen will, kommt um einen Blick in die jüngere Forschungsliteratur nicht herum. Drei Arbeiten waren für mein eigenes Verständnis besonders prägend.

Die Studie „Measuring AI's True Impact on Developer Productivity" (2025) untersucht über Monate hinweg, wie sich die Akzeptanzraten von KI-Vorschlägen entwickeln. Das vielleicht spannendste Ergebnis: Junior-Entwickler erzielen prozentual deutlich höhere Produktivitätsgewinne als Senioren. Wer ein Team einführt, kann sich also nicht auf eine pauschale Wirkung verlassen – die Effekte sind ungleich verteilt, und sie schwanken über Zeit. Akzeptanzraten als Einzelmetrik sind kaum aussagekräftig, weil sie nichts darüber sagen, ob die akzeptierten Vorschläge auch langfristig im Code bleiben.

Das Paper „The State of Generative AI in Software Development" (2026) analysiert den gesamten Software Development Life Cycle und kommt zu einer Zahl, die mich besonders aufhorchen ließ: Die reine Code-Generierung deckt nur etwa 10–15 % der Entwicklungszeit ab. Anders gesagt: Selbst wenn ein KI-Tool das Tippen vollständig ersetzen würde, bliebe der Großteil des Software-Engineerings unberührt – Architektur, Verstehen, Review, Debugging, Kommunikation. Wer KI-Wirkung nur über Code-Output misst, misst das falsche Stück Kuchen. Die Autoren warnen außerdem ausdrücklich vor Skill Erosion und technologischen Schulden, wenn dieser Großteil nicht ebenfalls bewusst gestaltet wird.

Die empirische Synthese „AI-Assisted Software Engineering Productivity" (2026) zieht daraus einen klaren Schluss: KI-Wirkung ist kein Prompt-Thema, sondern ein Systemproblem. Sauberes Messen funktioniert nur, wenn man drei Datenquellen kombiniert – Telemetrie aus den Tools, Pull-Request-Daten aus der Versionskontrolle und strukturierte Surveys der Entwickler. Jede einzelne Quelle für sich liefert ein verzerrtes Bild.

Das deckt sich mit meiner eigenen Erfahrung: Token-Statistiken aus Claude Code sagen mir, was passiert ist – aber nicht, ob es nützlich war. Commit-Logs zeigen Ergebnisse, aber nicht den Aufwand, den ich danach in Reviews investiert habe. Mein eigenes Bauchgefühl ist konsistent, aber wie oben gezeigt: nicht verlässlich. Erst die Triangulation dieser drei Sichtweisen ergibt ein Bild, dem ich trauen würde.

Das DX AI Measurement Framework als roter Faden

Diese Triangulation gibt es bereits als ausgearbeitetes Framework. Das DX AI Measurement Framework wurde von DX in Zusammenarbeit mit Forschenden von GitHub, Atlassian und Booking.com entwickelt und hat sich in der Industrie als pragmatischer Standard etabliert. Es teilt die Messung der KI-Wirkung in drei Dimensionen – und genau diese Aufteilung hilft mir, die Frage „Wie messe ich das?" überhaupt erst greifbar zu machen.

Dimension 1: Utilization – wird das Werkzeug überhaupt genutzt?

Die erste Dimension klingt trivial, ist es aber nicht. Sie misst, ob die KI-Tools überhaupt aktiv im Einsatz sind – über Aktivitätsraten (wer nutzt was, wie oft) und Acceptance Rates (welcher Anteil der Vorschläge wird tatsächlich übernommen). In Teams ist das ein wichtiger Indikator, um „Schatten-IT" und ungenutzte Lizenzen zu erkennen.

Für mein Solo-Setup ist die Aktivitätsrate praktisch irrelevant – ich bin der einzige Nutzer, und meine Aktivität sehe ich an meinem Kontostand. Die Acceptance Rate hingegen ist auch solo spürbar: Wie oft übernehme ich eine Agenten-Ausgabe so, wie sie kommt? Wie oft muss ich an einem HITL-Checkpoint nachsteuern? Wenn ich an drei von vier Use Cases korrigieren muss, deutet das nicht auf ein KI-Problem hin, sondern auf ein Agenten-Definitions-Problem – ein Hinweis, den der Blick auf die rohen Akzeptanzraten direkt liefert.

Dimension 2: Impact – die echte Bewegung im System

Die zweite Dimension ist die interessanteste – und die schwerste zu messen. Hier kombiniert das Framework zwei etablierte Modelle: DORA für die technische Lieferperformance und SPACE für die menschliche Seite der Entwicklungsarbeit.

DORA: die operative Lieferkette

DORA steht für DevOps Research and Assessment und stammt aus einer mehrjährigen Forschung von Google Cloud. Die vier DORA-Metriken sind der Industriestandard für operative Exzellenz und konzentrieren sich rein auf die technische Performance der Software-Lieferkette: Wie stabil und wie schnell läuft sie?

In der Praxis kommen zwei weitere abgeleitete Größen dazu, die im DX-Framework eine zentrale Rolle spielen: die Cycle Time (vom Beginn der Arbeit bis zum Merge) und die Pull-Request-Review-Time (kurz: PR Review Time, also die Zeit, die eine Code-Änderung im Review verbringt, bevor sie zusammengeführt wird).

SPACE: das ganzheitliche Gegengewicht

SPACE wurde von Forschenden bei GitHub, Microsoft und der University of Victoria entwickelt – als bewusstes Gegengewicht zu rein quantitativen Modellen. Der Grundgedanke: Produktivität besteht nicht nur aus Code-Zeilen, sondern ist multidimensional. SPACE soll helfen, „Developer Burnout" zu vermeiden und auch qualitative Faktoren sichtbar zu machen.

Warum beide zusammen erst ein ehrliches Bild ergeben

Der entscheidende Hinweis aus dem Framework: Wer nur auf eine einzelne DORA-Metrik schaut, läuft in eine Falle. Wenn die Code-Erstellung schneller wird, aber die PR-Review-Zeit gleichzeitig steigt, ist das kein Produktivitätsgewinn – sondern eine Verlagerung von Aufwand. Aus „Ich schreibe schneller" wird „Mein Kollege reviewt länger". Erst wenn beide Metriken zusammen betrachtet werden, lässt sich überhaupt eine Aussage über echten Nutzen treffen. Genauso wichtig: die Defect Density, also wie viele Bugs es trotz schnellerer Lieferung in die Produktion schaffen.

Im Diagramm: Die fallende Linie ist die Cycle Time, die steigende die PR-Review-Zeit. Wer nur auf die erste Kurve schaut, jubelt – wer beide zusammen sieht, erkennt die Verlagerung.

SPACE ergänzt das um eine Dimension, die reine Systemdaten nicht liefern: Cognitive Load. Hat die KI dem Entwickler tatsächlich Last abgenommen – etwa Boilerplate, Standard-Tests, repetitive Refactorings? Oder hat sie nur die Art der Last verschoben, sodass aus dem Tippen ein Dauer-Review wird? Genau dieses Phänomen, den „Inverted Loop", habe ich im Post über die Strategen schon beschrieben – das DX-Framework liefert mit Cognitive-Load-Surveys das Werkzeug, um es überhaupt sichtbar zu machen.

Wo mein Workflow auf diese Modelle einzahlt

Wenn ich mein Agenten-Setup gegen DORA und SPACE halte, wird greifbar, was es eigentlich tut – und was nicht:

• DORA-Sicht: Der Developer-Agent aus Post 13 und der Walkthrough aus Post 15 zielen auf die Cycle Time. Aus „vager Wunsch" wird in unter einer Stunde ein Feature, weil die Zerlegung in atomare Schritte die Implementierungsphase massiv verkürzt – ohne die Change Failure Rate zu erhöhen, weil jeder Schritt einen lauffähigen Build hinterlässt.
• SPACE-Sicht: Der Solution Architect aus Post 12 senkt vor allem Efficiency & Flow im Sinne der kognitiven Last. Die schwere Denkarbeit – Architektur prüfen, bestehende Muster finden, Schichten sauber halten – verlagert sich aus meinem Kopf in ein strukturiertes Lösungskonzept, das ich nur noch reviewen muss.

Das ist der Punkt, den ich an diesem Workflow am wichtigsten finde – und der in einer rein DORA-getriebenen Messung verloren ginge: Es geht nicht nur darum, schneller Code zu produzieren. Es geht darum, das System als Ganzes gesünder zu machen.

Dimension 3: Cost – Tokens, Lizenzen und reale Stunden

Die dritte Dimension ist die nüchternste, aber für mich solo die greifbarste. KI-Tools kosten Geld – sei es als Lizenz, als API-Verbrauch oder als Token-Volumen in einem mehrstufigen Agenten-Workflow. Das DX-Framework empfiehlt, diese Kosten den realen Zeitersparnissen aus Dimension 2 gegenüberzustellen, um einen tatsächlichen Return on Investment zu errechnen.

In der Praxis ist das nicht trivial. Mein Workflow mit Business Analyst, Solution Architect, Realisierungsplan-Agent und Developer-Agent verbraucht spürbar mehr Tokens als ein direkter Prompt – das ist die Kehrseite der Zerlegung, die ich im Post über die Macher beschrieben habe. Diese Kosten muss ich gegen die Stunden rechnen, die ich nicht mehr in Refactorings nach Architekturbrüchen stecke. Im Solo-Projekt ist das eine Bilanz im Kopf. In einem Team wäre es eine Tabelle mit klaren Zahlen – und ehrlich gesagt: ich glaube, viele Setups würden bei dieser Tabelle weniger gut aussehen, als ihre Befürworter annehmen.

Ein ehrlicher Punkt: Was ich tatsächlich messe – und was nicht

Ich will hier nicht so tun, als hätte ich das DX-Framework für meine Single-Dev-Projekte vollständig implementiert. Das wäre für ein Solo-Vorhaben Overkill, und es wäre auch unehrlich.

Was ich tatsächlich pragmatisch erhebe, sind drei einfache Proxies, die mir helfen, Tendenzen zu erkennen – ohne den Anspruch wissenschaftlicher Rigorosität:

1. Korrekturzeit pro Checkpoint: Wie viele Minuten brauche ich an den HITL-Punkten in Phase 1–3, um Use Case, Konzept und Plan zu reviewen und ggf. zu korrigieren? Das ist der direkteste Indikator dafür, wie gut meine Agenten justiert sind. Sinkt die Zeit über mehrere Features, lerne ich entweder besser zu prompten – oder die Agenten-Definitionen wachsen mit. Beides ist gut.
2. Anzahl der Rework-Commits nach „fertigen" Features: Wie oft musste ich nach einem abgeschlossenen Feature noch nachbessern, weil etwas in Produktion nicht passte? Das ist meine inoffizielle Defect Density. Diese Zahl liegt aktuell deutlich niedriger als in der Zeit vor dem Agenten-Workflow – aber ich habe sie nicht systematisch erhoben, sondern nur subjektiv beobachtet.
3. Subjektive Frustrationsfreiheit: Nicht wissenschaftlich, aber für mich relevant. Komme ich abends aus einer Coding-Session mit dem Gefühl, etwas vorangebracht zu haben – oder mit dem Gefühl, Symptome bekämpft zu haben? Das ist mein persönlicher Proxy für die SPACE-Dimension der Zufriedenheit.

Was mir bewusst fehlt: kontrollierte Vergleichsläufe. Ich habe noch nie dasselbe Feature einmal mit Agenten-Workflow und einmal mit direktem Prompt gebaut, um die Zeiten und Ergebnisse direkt zu vergleichen. Das wäre der saubere Weg – aber realistisch wird das in einem Solo-Projekt nicht passieren, weil der Aufwand für die zweite Implementierung höher ist als der erwartbare Erkenntnisgewinn.

Genau deshalb sind die wissenschaftlichen Studien aus dem Anfang dieses Posts so wertvoll: Sie ersetzen mein fehlendes A/B-Testing durch belastbare Daten aus kontrollierten Vergleichen, die andere für mich gemacht haben.

Was das für ein Team bedeuten würde

Im Solo-Projekt komme ich mit den drei pragmatischen Proxies gut zurecht. In einem Team wäre die Messlatte nicht verhandelbar – nicht weil ich misstrauisch wäre, sondern weil die Wirkungen sich vervielfältigen und gleichzeitig unschärfer werden.

Ein Team braucht zusätzlich mindestens drei Dinge: PR-Tagging, um nachvollziehbar zu machen, welche Codeabschnitte KI-gestützt entstanden sind. Klare Governance für die Agenten: Welche werden eingesetzt, wie sind sie definiert, welche Rules gelten? Und vor allem: das HITL-Prinzip als verbindliche Regel, wie ich es im Post über die Strategen beschrieben habe. Ohne diese drei Voraussetzungen lässt sich Wirkung nicht messen – weil man nicht weiß, was man misst.

Fazit

Wer KI-Agenten ernst nimmt, muss ihre Wirkung ernst messen. Sonst bleibt es Bauchgefühl in beide Richtungen – Begeisterung wie Skepsis.

Das DX AI Measurement Framework ist dafür kein Selbstzweck, sondern eine Sprache, um über AI-Wirkung präzise zu sprechen. Die drei Dimensionen Utilization, Impact und Cost machen sichtbar, was sonst im Bauchgefühl versinkt: dass Schnelligkeit ohne Qualität keine Produktivität ist, dass Akzeptanzraten ohne Defect Density wenig aussagen, und dass Kosten ohne Zeitersparnis nur Ausgaben sind.

Für meine Solo-Projekte ist die Messlatte pragmatisch – drei einfache Proxies und der ehrliche Blick in jede Coding-Session. In einem Team wäre sie nicht verhandelbar. Beides hat seinen Platz. Wichtig ist mir am Ende nur: dass ich aufhöre, „Ich fühle mich produktiver" mit „Es funktioniert" zu verwechseln.