Zum Inhalt springen

Wissensbasis

Impact messen

Agentic Engineering messt ihr mit KI-Metriken wie Adoption, KI-gestütztem Anteil und Ausgaben, gepaart mit Delivery-Metriken von vor KI wie Throughput und Change Failure Rate. KI-Metriken zeigen, was passiert. Kernmetriken zeigen, ob es wirkt.

Verfasst von

Aktualisiert:

Einstieg 2

Unsere Position. Wir messen Impact, nicht Nutzung. Eine Änderung zählt erst, wenn sie in Produktion läuft und Kund:innen sie nutzen, dafür zahlen oder sagen, dass sie geholfen hat (öffnet in einem neuen Tab). Gemergte Pull Requests sind Output. Ein Messwert ohne schriftlich festgelegte rote Linie ist Dekoration (öffnet in einem neuen Tab). Wir lesen vier Kennzahlen pro Team gegen eine Baseline vom Start: die DORA-Kennzahlen, wobei die Durchlaufzeit bei uns von der erfassten Idee bis zu den ersten Nutzer:innen läuft statt vom Commit bis zur Produktion; die Rework Rate, also den Anteil der Änderungen, die neu gemacht werden, bevor sie bei den Nutzer:innen ankommen; die Nutzung, also den Anteil der Zielnutzer:innen, die das Ausgelieferte nach 30 Tagen aktiv nutzen; und die Kosten pro Änderung.

Aktivitätsmetriken lassen sich leicht erheben und leicht manipulieren. Ein Team, das Nutzung oder KI-geschriebenen Code zählt, erfährt, wie beschäftigt es ist. Ob die Delivery besser geworden ist, erfährt es so nicht.

Wie messt ihr den Impact von KI, ohne euch selbst zu täuschen?

Unternehmen, die ernsthaft messen, sind sich einig: Sie stellen KI-spezifische Metriken neben die Engineering-Kernmetriken aus der Zeit vor KI. KI-Metriken wie Adoption, Anteil KI-gestützter PRs und Ausgaben zeigen, was passiert. Kernmetriken wie PR-Throughput, Change Failure Rate, Change Confidence und Wartbarkeit zeigen, ob es funktioniert. Wer Geschwindigkeit und Qualität gemeinsam verfolgt, hält jede Metrik ehrlich (The Pragmatic Engineer - How tech companies measure the impact of AI on software development (öffnet in einem neuen Tab)). Der Bedarf ist verbreitet: Im AI Impact Report 2025 von LeadDev nannten 60 % von 880 befragten Führungskräften fehlende klare Metriken als ihre größte KI-Herausforderung (The Pragmatic Engineer - How tech companies measure the impact of AI on software development (öffnet in einem neuen Tab)).

Eine nützliche Taxonomie trennt Aktivitätsmetriken von Outcome-Metriken. Aktivitätsmetriken wie Nutzung oder der Anteil KI-generierten Codes haben wenig Informationswert und laden zum Schönrechnen ein. Outcome-Metriken wie Deployment-Frequenz und Change Failure Rate messen, was sich im System tatsächlich ändert. Ein:e Entwickler:in könnte an einem Tag 100 Pull Requests mergen und trotzdem nur einen Deploy im Monat ausliefern. Die Einheit der Delivery ist das Team, nicht die einzelne Person (zum DX AI-assisted Engineering Report (öffnet in einem neuen Tab)).

Den Anteil von “KI-Code” zu verfolgen, ist selbst ein Anti-Pattern, sobald KI Entwickler:innen ergänzt statt ersetzt (Refactoring - How Engineering Teams use AI (öffnet in einem neuen Tab)). DX gliedert die Messung in Nutzung, Wirkung und Kosten. Es empfiehlt, Telemetrie mit Erfahrungsdaten zu kombinieren, weil sich Change Confidence nicht aus Systemdaten ablesen lässt (DX AI Impact Report). Einst beliebte Metriken wie die Acceptance Rate von Vorschlägen sind weitgehend aufgegeben. Sie messen den Moment des Vorschlags und übersehen Reverts, Bugs und Wartbarkeit (The Pragmatic Engineer - How tech companies measure the impact of AI on software development (öffnet in einem neuen Tab)).

Amazons Engineering-Leitung zog im Oktober 2026 in einem Memo an ihre Engineers die Grenze zwischen Messgröße und Zielvorgabe. Input-Metriken wie Token-Verbrauch und Adoption von KI-Tools nennt das Memo grundlegend fehlerhaft, ebenso Throughput-Metriken wie Code-Änderungen und Reviews. Sie sind von den Outcomes entkoppelt. Als Zielvorgabe treiben sie laut Memo Kosten und Komplexität. Wer Token maximiert, arbeitet gegen Sparsamkeit, und wer Codezeilen zählt, arbeitet gegen Vereinfachung. Zugleich berichtet das Memo, dass diese Inputs gut mit den relevanten Outcomes korrelieren, und erwartet das noch für einige Zeit. Deshalb erlaubt es sie als Messgröße, die mit Urteilsvermögen genutzt wird. Eine Korrelationszahl veröffentlicht das Memo nicht, die Korrelation bleibt also Amazons eigene, unbezifferte Behauptung. Praktisch rät es, die Ränder der Adoptionsverteilung zu lesen statt des Durchschnitts. Am 10. Perzentil findet ihr die Teams, die KI nicht wirksam nutzen, und lernt den Grund. Am 90. Perzentil prüft ihr, ob die stärksten Nutzer:innen entsprechend mehr geliefert haben (Amazon - An update from Amazon engineering leadership on the role of the developer in the age of AI (öffnet in einem neuen Tab), Oktober 2026).

Wie messen Unternehmen den Impact von KI in der Praxis?

Die Praxis einzelner Unternehmen zeigt, wie das konkret aussieht.

  • Dropbox paart Adoption- und CSAT-Metriken mit Core-4-Outcomes. Regelmäßige KI-Nutzer:innen mergen 20 % mehr PRs und senken zugleich die Change Failure Rate.
  • Microsoft verfolgt “bad developer days” als Echtzeit-Signal für Reibung.
  • Glassdoor misst A/B-Tests pro Monat als Innovations-Outcome. Je Tool verfolgt es eine Auslastungsrate (“percentage capacity worked”), um Plateaus zu erkennen.
  • Webflow fand die größten Einsparungen bei Entwickler:innen mit mehr als drei Jahren Betriebszugehörigkeit, bei rund 20 % mehr PR-Throughput.
  • Shopify betreibt ein KI-Leaderboard, das seine größten Token-Verbraucher:innen feiert.
  • Monzo schaltete das standardmäßige Copilot Code Review ab, weil es für viel LLM-Nutzung wenig Wert brachte. Bei Migrationen misst Monzo 40-60 % Aufwandsersparnis.

Quelle aller Beispiele: The Pragmatic Engineer - How tech companies measure the impact of AI on software development (öffnet in einem neuen Tab).

Booking.com wertete segmentierte Kohortendaten von 3.500 Engineers aus. Tägliche Nutzer:innen hatten 16 % mehr Code-Throughput, Teams mit vollständiger KI-Adoption 30 % mehr Throughput. Danach lenkte Booking.com das Enablement auf die Segmente mit dem geringsten Nutzen (Tiatra - How Booking.com measures the impact of AI on developer productivity (öffnet in einem neuen Tab)). Intercom ging bei der Automatisierung am weitesten. Ein automatisiertes Code-Approval-System aus Backtesting und menschlichem Labeling genehmigt 17,6 % der Änderungen ohne menschliche Beteiligung. Es ist auf sichere und einfache PRs ausgerichtet. Intercom hält es für vereinbar mit einer Zertifizierung nach SOC 2, ISO 27001 und HIPAA (Intercom-Talk - Doubling engineering throughput (öffnet in einem neuen Tab)).

Amazon hebt die Messung eine Ebene höher und übersetzt den gesamten Delivery-Prozess in Ökonomie. Die Metrik Cost to Serve Software (CTS-SW) erfasst die Gesamtkosten, um eine Einheit Software zu liefern. Sie sank 2024 im Jahresvergleich um 15,9 %, getrieben von Verbesserungen der Developer Experience. Dazu kommen seit 2022 18,3 % mehr wöchentliche Deployments pro Builder, 30,4 % weniger menschliche Eingriffe pro Deployment und 32,5 % weniger incidentbezogene Tickets pro Deployment. Was als ausgelieferte Einheit zählt, hängt von der Architektur ab: Deployments bei Microservices, abgeschlossene PRs bei Monolithen und Mobile-Apps. Das Framework lehnt reine Velocity-Maße und die Rechnung mit “minutes saved” ausdrücklich ab. Beide sind manipulierbar und vom Geschäftswert entkoppelt (Amazon Cost to Serve Software (CTS-SW); Amazon - Business value of developer experience improvements (öffnet in einem neuen Tab), Juli 2025). Grundsätzlich gilt: PRs sind Output, keine Outcomes. Jede einzelne Metrik, die zum Ziel wird, taugt nicht mehr als Messgröße (KI-Produktivitätsstudien).

Wie messt ihr, was KI kostet?

Kosten werden zu einer eigenen, vollwertigen Säule der Messung. Das Deployment bei Tata 1mg kostete $30-34 pro Engineer und Monat, rund 1-2 % der Engineering-Kosten. LLM-API-Aufrufe machten 91,5 % der Gesamtausgaben aus (Produktionsstudie - Intuition to Evidence: Measuring AI’s True Impact on Developer Productivity (öffnet in einem neuen Tab)). Pragmatic Engineer befragte im April 2026 über 900 Engineers. Unternehmen budgetieren demnach rund $100-200 pro Engineer und Monat für Top-Tier-Pläne. Etwa 30 % der Befragten stoßen an Nutzungslimits. Regional teilt sich das Bild: Unternehmen in UK und EU prüfen Ausgaben genau, US-Unternehmen investieren zuerst und messen später. Einige EU-Firmen schulen neue Mitarbeitende inzwischen in Modellökonomie, etwa wann Claude Sonnet reicht und wann es Opus braucht (The impact of AI on software engineers in 2026 (öffnet in einem neuen Tab), April 2026).

Token-Ausgaben von Entwickler:innen und von Produktions-Agents brauchen getrennte Bücher. Den Verbrauch der Entwickler:innen verfolgt ihr von jedem Prompt oder jeder Session über das Work Item und den Merge bis zum Deployment. Bei Produktions-Agents teilt ihr die Ausgaben durch abgeschlossene Business-Tasks statt durch Developer-Aktivität. So bleiben Experimentierkosten und Unit Economics in Produktion getrennt (WeAreDevelopers - AI Wrote the Code. Now What? (öffnet in einem neuen Tab), Juli 2026, Vendor-Talk von Harness).

Ausgaben setzen sich nicht linear in Ergebnisse um. Telemetrie aus Stanford zeigt nur eine lose Korrelation zwischen Token-Volumen und Gewinnen. Um die Marke von 10 Millionen Token pro Monat liegt ein “death valley”, in dem starke Nutzung schlechter abschneidet als moderate. Die Qualität der Nutzung zählt mehr als ihr Volumen. Stanfords Reifegradleiter für KI-Praktiken reicht von 0 bis 4: von individueller Nutzung über geteilte Team-Prompts und Regeln bis zu agentischer Orchestrierung. Die Stufe lässt sich aus der Git-Historie ablesen (Stanford - Talk zur Messung des KI-ROI (öffnet in einem neuen Tab)). Für die Agent-Ära empfiehlt das Whitepaper von DX, Agents als Erweiterung des Teams zu messen. Das Whitepaper empfiehlt außerdem, jede:n Entwickler:in zunehmend als Lead eines kleinen Agent-Teams zu betrachten. Produktionscode misst ihr getrennt von wegwerfbaren KI-Prototypen. Das Whitepaper nennt außerdem Intercom, das die Adoption fast verdoppelte, bei 41 % mehr KI-getriebener Zeitersparnis. Block (über 4.000 Engineers) steuert seinen Agent goose mit dem Framework (DX - Measuring AI code assistants and agents (öffnet in einem neuen Tab), Vendor-Methodik).

Wie verfolgt ihr das Änderungsrisiko, wenn Agents Code schreiben?

Auch das Änderungsrisiko muss mit der Arbeit mitwandern. Berechnet es nach jeder Delivery-Stufe neu, aus Code-Herkunft, Zustand des Repositorys, Incidents, Testnachweisen und der Unabhängigkeit der Reviewer:innen. Messt die Lead Time des Outer Loop für jede Stufe einzeln und daneben die gesamte Cycle Time. So kann ein schnellerer Generierungsschritt keinen langsameren Review-, Verifikations- oder Deploy-Schritt verdecken (WeAreDevelopers - AI Wrote the Code. Now What? (öffnet in einem neuen Tab), Juli 2026, Vendor-Talk von Harness).

Verwandte Seiten

Quellen

Artikel

Talks und Videos