Was ein Coding-Agent wirklich kostet: Token, Strom und Rework als Delivery-KPI

Die Kostenstelle hat sich verschoben, die Kennzahl nicht

In der klassischen Delivery-Planung ist die Kosteneinheit der Personentag. Ein Team hat eine Kapazität, die Kapazität hat einen Preis, und aus beidem entsteht eine Planung, die der Controller versteht. Diese Rechnung hat drei Jahrzehnte funktioniert, weil die dominante Kostenart die Arbeitszeit war. Werkzeuge kosteten Lizenzgebühren, Infrastruktur kostete Abschreibung — beides planbar, beides weitgehend unabhängig davon, wie intensiv an einem bestimmten Tag gearbeitet wurde.

Coding-Agenten brechen diese Logik auf. Ihre Kosten entstehen nicht pro Kopf und Monat, sondern pro Anfrage, pro verarbeitetem Kontext, pro Iteration. Ein Entwickler, der einen Agenten fünfmal über dieselbe Codebasis laufen lässt, bis das Ergebnis passt, erzeugt fünfmal Kosten — bei unverändertem Personentag. Die Kostenkurve löst sich von der Kapazitätskurve, und genau an dieser Stelle verliert die Personentagsplanung ihre Aussagekraft.

Das ist keine Randnotiz für die Buchhaltung. Es ist eine Steuerungsfrage: Wer nicht weiß, was eine Änderung kostet, kann nicht entscheiden, ob sie sich lohnt. Die Disziplin, die diese Frage beantwortet, existiert bereits und heißt FinOps — die Praxis, finanzielle Verantwortung in variable Ausgabenmodelle zu bringen. Das FinOps Framework der FinOps Foundation beschreibt sie in den drei Phasen Inform, Optimize und Operate. heise online hat die Disziplin am 14.09.2026 unter dem Titel Kurz erklärt: Wie FinOps Kosten steuert für ein breiteres Publikum eingeordnet.

Wie FinOps als Governance-Disziplin in die Delivery-Steuerung gehört, ist in Cost of Delivery: Warum FinOps jetzt auch Ihr Thema ist beschrieben. Dieser Beitrag setzt eine Ebene tiefer an: bei den drei konkreten Kennzahlen, mit denen Sie Agentenkosten an Delivery-Ergebnisse koppeln — und bei der Frage, woher die Daten dafür kommen.

Warum der Personentag als Bezugsgröße nicht mehr trägt

Der Personentag misst Aufwand, nicht Ergebnis. Solange Aufwand und Ergebnis eng gekoppelt waren, war das unschädlich: Mehr Aufwand bedeutete in der Regel mehr gelieferte Funktionalität. Coding-Agenten entkoppeln beides in zwei Richtungen gleichzeitig. Nach oben, weil ein Agent in Minuten produzieren kann, wofür ein Team Tage gebraucht hätte. Nach unten, weil ein Agent Änderungen erzeugen kann, die durch Review, Test und Produktion laufen und dort wieder zurückgenommen werden müssen.

Die zweite Richtung ist die teurere und die unsichtbarere. Ein zurückgenommener Commit erscheint in keiner Kapazitätsplanung als Verlust — die Zeit wurde ja gebucht, der Agent hat geliefert, der Sprint ist abgeschlossen. Die Kosten entstehen stromabwärts: in der Review-Zeit anderer Entwickler, in Incident-Behebung, in der Nacharbeit. Delivery-Organisationen, die diesen Anteil nicht messen, halten einen Produktivitätsgewinn für gesichert, der teilweise nur eine Verlagerung ist.

Hinzu kommt eine Kostenart, die in klassischen Delivery-Rechnungen schlicht nicht vorkam: Energie. heise online hat am 16.09.2026 unter Klimafaktor KI: Warum Agenten wie Claude Code echte Stromfresser sind beschrieben, dass agentische Arbeitsweisen — viele Iterationen über großen Kontext — energetisch deutlich anders zu bewerten sind als eine einzelne Modellabfrage. Für Organisationen mit Nachhaltigkeitszielen ist das keine akademische Frage, sondern eine, die früher oder später berichtspflichtig wird.

Die Konsequenz ist nicht, Agenten zu meiden. Die Konsequenz ist, die Bezugsgröße zu wechseln: weg vom Aufwand, hin zur gelieferten Änderung.

Kennzahl 1: Kosten je gemergtem Pull Request

Die erste Kennzahl bindet Verbrauch an ein Ergebnis, das bereits sauber definiert und in jedem Repository erfasst ist: den gemergten Pull Request. Die Formel ist bewusst simpel — Agentenkosten eines Zeitraums geteilt durch die Zahl der in diesem Zeitraum gemergten Pull Requests, betrachtet je Team oder je Wertstrom, nicht je Person.

Der Nenner ist absichtlich der gemergte, nicht der geöffnete Pull Request. Ein geöffneter PR ist eine Absichtserklärung, ein gemergter ist eine Lieferung. Damit fließen abgebrochene Agentenläufe und verworfene Vorschläge in den Zähler, aber nicht in den Nenner — und genau das ist gewollt: Ein Team, das fünf Anläufe für eine Änderung braucht, soll das in der Kennzahl sehen.

Die Aussagekraft entsteht nicht aus dem absoluten Wert, sondern aus dem Verlauf und dem Vergleich. Ein steigender Wert bei gleichbleibendem Output bedeutet, dass mehr Iterationen für dasselbe Ergebnis nötig sind — ein Hinweis auf unklare Anforderungen, schlechte Kontextqualität oder einen Anwendungsfall, für den das gewählte Modell nicht passt. Ein fallender Wert bei steigender Änderungsrate ist der Beleg, den ein Delivery-Lead dem CFO schuldet.

Wichtig ist die Abgrenzung nach unten: Diese Kennzahl misst Kosten je Lieferung, nicht Wert je Lieferung. Ein Pull Request, der ein wertloses Feature liefert, ist billig und trotzdem Verschwendung. Die Kennzahl ersetzt Priorisierung nicht — sie macht sie bezahlbar vergleichbar.

Kennzahl 2: Rework-Anteil agentengenerierter Änderungen

Die zweite Kennzahl ist der eigentliche Härtetest, und sie hat den Vorteil, dass es für sie bereits einen etablierten Bezugsrahmen gibt. Das DORA-Programm führt die Deployment Rework Rate als Kennzahl für Änderungen, die kurz nach dem Deployment korrigiert werden müssen. Die vier klassischen Kennzahlen sind bei DORA dokumentiert; wie die fünfte Metrik funktioniert und warum sie durch KI-generierten Code an Bedeutung gewinnt, ist in Deployment Rework Rate: die fünfte DORA-Metrik ausführlich beschrieben.

Der Zusatz für Agentenkosten besteht darin, den Rework-Anteil nach Herkunft der Änderung aufzuschlüsseln: agentengeneriert gegenüber manuell geschrieben. Die Fragestellung lautet nicht, ob Agenten Fehler machen — das tun Menschen auch. Sie lautet, ob der Rework-Anteil agentengenerierter Änderungen systematisch über dem manueller Änderungen liegt, und ob sich dieser Abstand über die Zeit schließt oder öffnet.

Öffnet er sich, ist das ein belastbares Signal dafür, dass die Geschwindigkeitsgewinne stromabwärts wieder aufgezehrt werden. Schließt er sich, ist das ein Beleg dafür, dass die Organisation gelernt hat, Agenten einzusetzen. Beides sind Steuerungsinformationen, die eine reine Kostenbetrachtung nicht liefert.

Die methodische Fallgrube liegt in der Zuordnung: Wer agentengenerierte Änderungen nicht bereits beim Entstehen markiert, kann sie im Nachhinein nicht sauber trennen. Die Markierung gehört deshalb in den Arbeitsablauf, nicht in eine spätere Auswertung — als Konvention im Commit-Trailer oder als Label am Pull Request, gesetzt beim Erstellen.

Kennzahl 3: Kosten je Wertstrom statt je Werkzeug

Die dritte Kennzahl beantwortet die Frage, die in Budgetgesprächen tatsächlich gestellt wird: Was kostet uns dieses Produkt? Nicht: Was kosten uns Coding-Agenten? Die zweite Frage führt regelmäßig zu einer Werkzeugdiskussion, die am Kern vorbeigeht, weil sie eine Kostenart isoliert betrachtet, statt sie ins Verhältnis zum Ergebnis zu setzen.

Praktisch bedeutet das, Agentenkosten derselben Kostenstelle zuzuordnen wie Cloud-Ressourcen, Lizenzen und Personalkosten des jeweiligen Wertstroms. Die FinOps-Phase Inform beschreibt genau diesen Schritt: Sichtbarkeit und Kostenzuordnung als Voraussetzung jeder Steuerung. Erst wenn Agentenkosten im selben Bericht stehen wie die übrigen Kosten des Wertstroms, wird die relevante Frage entscheidbar — ob der Anteil am Gesamtaufwand in einem vertretbaren Verhältnis zum gelieferten Ergebnis steht.

Diese Zuordnung deckt außerdem einen Effekt auf, den eine Werkzeugbetrachtung verbirgt: Agentenkosten ersetzen in der Regel keine Personalkosten eins zu eins, sondern treten zunächst hinzu. Ob daraus ein Effizienzgewinn wird, entscheidet sich daran, ob Kapazität tatsächlich umgewidmet wird — eine Führungsentscheidung, keine Werkzeugeigenschaft.

Für die Portfolio-Sicht darauf eignet sich eine strukturierte Erfassung je Initiative; das Project-Portfolio-Template bildet Budget-, Risiko- und Abhängigkeitssicht in einem Raster ab, in das sich die Kostenzuordnung je Wertstrom direkt einhängen lässt.

Woher die Daten kommen — ohne neues Tooling

Der häufigste Einwand gegen zusätzliche Kennzahlen lautet, es fehle die Datengrundlage. Für diese drei Kennzahlen trifft das in den meisten Organisationen nicht zu. Alle benötigten Rohdaten liegen bereits vor, sie sind nur nicht zusammengeführt.

Der Zähler kommt aus der Abrechnung des Anbieters, idealerweise nach Projekt oder Schlüssel getrennt. Die Zahl der gemergten Pull Requests kommt aus der Plattform-API von GitHub, GitLab oder Azure DevOps. Die Rework-Zuordnung kommt aus Commit-Metadaten in Verbindung mit Deployment-Zeitstempeln, die in jeder CI/CD-Pipeline ohnehin protokolliert werden. Die Kostenzuordnung je Wertstrom kommt aus derselben Tag- oder Label-Struktur, die für Cloud-Kosten bereits existiert.

Der Aufwand liegt nicht in der Beschaffung, sondern in der Konvention: eine einheitliche Kennzeichnung für Herkunft und Wertstrom, konsequent gesetzt. Wer damit beginnt, sollte nicht auf Vollständigkeit warten. Eine grob zutreffende Sicht, wöchentlich verfügbar und im bestehenden Delivery-Review besprochen, steuert besser als eine perfekte Auswertung, die vierteljährlich erscheint und niemanden erreicht.

Ebenso wichtig ist, wo die Zahlen landen: im bestehenden Delivery-Review, neben Deployment Frequency und Change Failure Rate. Ein separater KI-Kostenbericht erzeugt eine separate Diskussion — und damit genau die Trennung zwischen technischer und wirtschaftlicher Entscheidung, die FinOps auflösen soll.

Drei Gates, bevor ein Agent in den Produktivpfad darf

Kennzahlen allein ändern kein Verhalten. Damit die Messung wirksam wird, braucht sie Entscheidungspunkte, an denen sie etwas auslöst. Drei Gates haben sich als praktikabel erwiesen, weil sie an bestehende Prozesse andocken statt neue zu schaffen.

Das erste Gate ist die Herkunftskennzeichnung: Kein agentengenerierter Beitrag gelangt ohne Kennzeichnung in den Hauptzweig. Ohne diese Grundlage sind die Kennzahlen zwei und drei nicht bildbar, und die Nachvollziehbarkeit fehlt auch dort, wo sie aus Compliance-Gründen gebraucht wird.

Das zweite Gate ist ein Kostendach je Wertstrom mit definierter Eskalation. Nicht als Sperre, die Arbeit blockiert, sondern als Schwelle, an der eine Entscheidung fällig wird — vergleichbar mit einem Budgetalarm in der Cloud-Kostensteuerung.

Das dritte Gate ist ein Rework-Schwellenwert: Überschreitet der Rework-Anteil agentengenerierter Änderungen den manueller Änderungen dauerhaft und deutlich, wird der Einsatz für diesen Anwendungsfall überprüft — nicht der Agent abgeschafft, sondern der Zuschnitt korrigiert. Wie reif die eigene Delivery-Organisation für solche Gates ist, lässt sich mit dem kostenlosen DevOps-Reifegrad-Check in wenigen Minuten einordnen; die vollständige Bestandsaufnahme über alle Dimensionen liefert das Delivery-Audit-Template.

Fazit: eine Bezugsgröße, drei Kennzahlen, ein Review

Coding-Agenten sind kein Werkzeugthema, sondern eine Veränderung der Kostenstruktur von Delivery. Wer sie mit den Kennzahlen des Personentagsmodells steuert, misst die falsche Größe und wird die Wirkung weder belegen noch begrenzen können.

Der Umstieg ist kleiner, als er klingt. Eine Herkunftskennzeichnung am Commit, drei Kennzahlen aus vorhandenen Daten, ein bestehendes Review als Ort der Besprechung. Kein neues Gremium, kein neues Werkzeug, keine neue Bürokratie — sondern dieselbe Steuerungslogik, die für Lead Time und Change Failure Rate längst etabliert ist, angewandt auf eine Kostenart, die es vor drei Jahren noch nicht gab.

Der Maßstab bleibt dabei derselbe wie in der übrigen Delivery-Steuerung: Eine Kennzahl ist erst dann nützlich, wenn jemand aufgrund ihres Verlaufs etwas anders macht. Wer die drei Werte erhebt, aber keine Gates daran knüpft, hat ein Reporting gebaut, keine Steuerung.