ROI für Coding Agents: Das CFO-taugliche Modell

Ein CTO geht in die Q2-Budgetsitzung mit einer Folie. Oben steht: 30 Prozent Produktivitätsgewinn durch Coding Agents, 2,1 Millionen Euro rechnerische Ersparnis pro Jahr. Unten ein Logo eines bekannten Anbieters und drei Bullet Points. Der CFO hört sich das an, nimmt einen Schluck Kaffee, stellt eine Frage. „Wie sind Sie auf die 30 Prozent gekommen?"

Drei Minuten später ist die Folie raus. Nicht weil der CFO gegen KI wäre, sondern weil eine multiplikative Rechnung mit einer einzigen umstrittenen Speedup-Zahl keiner ernsthaften Prüfung standhält. Die Vendor-Mathematik, die in fast jedem ROI-Deck steht, ist an drei Stellen gleichzeitig falsch. Wer einen Business Case bauen will, der CFO-Gespräch, Procurement und Betriebsrat übersteht, braucht ein anderes Modell: fünf Variablen statt einer Zahl, und einen Hebel, den der Engineering-Lead tatsächlich beeinflussen kann.

Wer diese Diskussion neben Rollout, Tooling und Compliance einordnen will, findet im Coding-Agents-Leitfaden für Investitionsentscheidungen den breiteren Rahmen.

Begriffsklärung vorab: Mit Coding Agents sind hier Werkzeuge gemeint, die eigenständig Kontext abrufen, Dateien ändern, Tests ausführen und PR-fähige Änderungen vorbereiten: Claude Code, Copilot Agent Mode, Cursor-Agent und vergleichbare Systeme. Ein großer Teil der heutigen Evidenz stammt allerdings aus Studien zu Inline-Completion und Assistant-Workflows. Diese Studien dienen deshalb als konservative Annäherung, nicht als direkte Messung von Agent-Effekten.

Warum einfache ROI-Formeln scheitern

Die Rechnung, die in jeder Sales-Folie steht, lautet so: Anzahl Entwickler mal Stundensatz mal Speedup mal Zeit. Für 100 Entwickler, 500 Euro Tagessatz und 20 Prozent Beschleunigung kommen rund 2,5 Millionen Euro Ersparnis pro Jahr heraus. Der CFO sieht die Zahl. Daraus folgen drei Fragen.

Wo kommt der Speedup her? Die Folie verweist auf eine GitHub-Lab-Studie von 2022 mit 55 Prozent Beschleunigung. Diese Studie war ein kontrollierter Lab-Task, ein JavaScript-HTTP-Server, n=95. Kein Produktionscode. Reale Feldexperimente liefern andere Zahlen. Paradis und Kollegen haben 2024 bei Google intern gemessen, n=96, und kommen auf rund 21 Prozent Zeitersparnis mit weitem Konfidenzintervall. Cui und Kollegen haben in drei Feldexperimenten bei Microsoft, Accenture und einem anonymen Fortune-100-Elektronikkonzern, n=4.867, 26,08 Prozent mehr abgeschlossene Tasks gemessen. METR hat im Juli 2025 eine randomisiert kontrollierte Studie (RCT) mit erfahrenen Open-Source-Maintainern veröffentlicht und 19 Prozent langsamer gemessen. METR hat den Befund im Februar 2026 selbst nachjustiert: Die Richtung bleibt erkennbar, die Größenordnung in heutigen Setups ist unsicher. Die ehrliche Antwort: Der Speedup existiert, hängt aber stark vom Task-Typ, der Reife der Codebasis und der Erfahrung des Teams ab.

Ist der Speedup kostenlos? Nein. Die Seat-Kosten sind die kleinste Position. Tokenverbrauch, Enablement, Review-Aufwand, Security-Scanning und Plattformbetrieb sind die teuren Posten.

Kommt der Speedup bei der Auslieferung an? Das ist die Frage, die der DORA-Report seit 2024 stellt: Schlägt schneller geschriebener Code auch auf Deployment Frequency, Lead Time und Change Failure Rate durch? Oder bleibt er in der Review-Warteschlange liegen? Die Antwort darauf entscheidet, wie viel von einem Brutto-Speedup beim Geschäftsergebnis ankommt.

Die 30-Prozent-Zahl stimmt in einer bestimmten Lesart. Vollständig ist sie nicht.

Und selbst wenn sie stimmt, ist sie noch kein Business Case. Eine Stunde, die ein Entwickler nicht mit Tippen verbringt, verschwindet nicht automatisch aus der Kostenrechnung. Sie wird zuerst frei. Finanzielle Wirkung entsteht erst, wenn diese Kapazität in weniger Fremdleistung, kürzere Lead Time, mehr ausgelieferte Änderungen, geringeren Rework oder schnelleren Backlog-Abbau übersetzt wird.

Die fünf Variablen eines belastbaren Modells

Ein Modell, das beim CFO besteht, hat fünf Variablen. Jede davon hat eine Bandbreite, jede eine Evidenzschicht. Drei Werte (Brutto-Speedup, Conversion Factor, Risiko-Aufschlag) sind Modellannahmen mit Bandbreite, keine empirischen Konstanten. Zwei (Tool-Kosten, indirekte Kosten) lassen sich pro Organisation präzisieren.

Variable 1 · Brutto-Speedup auf den Code-Schreib-Anteil

Der Brutto-Speedup beschreibt, um wie viel ein Coding Agent die reine Tippzeit verkürzt. Die Studienlage spannt einen weiten Korridor: METR misst minus 19 Prozent für erfahrene Entwickler auf reifen Open-Source-Repositories, Paradis bei Google intern plus 21 Prozent, Cui und Kollegen in drei Feldexperimenten plus 26 Prozent. Für ein gemischtes Team in einer nicht-trivialen Enterprise-Codebasis ist eine Annahme von 10 bis 20 Prozent realistisch.

Entscheidend ist eine zweite Größe, die in Vendor-Folien meist unterschlagen wird: Der Speedup wirkt nur auf den Anteil, den Code-Schreiben tatsächlich ausmacht. Bei Senior-Entwicklern sind das typischerweise 25 bis 35 Prozent des Arbeitstags, bei Juniors etwas mehr. Der Rest geht für Spezifikation, Review, Tests, Integration und Abstimmung drauf, und genau dort schöpft der Agent kaum Zeit.

Variable 2 · Direkte Tool-Kosten

Die Seat-Preise stehen offen im Web. Stand Mai 2026 ruft Anthropic für Claude Team Premium 100 US-Dollar pro Seat und Monat bei jährlicher Abrechnung auf, 125 US-Dollar bei monatlicher; Team Premium ist dabei für das Team-Setup gedacht, nicht für einzelne Power-User auf Claude Max. Enterprise läuft über Custom Pricing mit kombinierten Seat- und nutzungsbasierten Komponenten. GitHub Copilot Business kostet 19 US-Dollar pro Nutzer und Monat, Enterprise 39 US-Dollar, und ab 1. Juni 2026 läuft die Abrechnung über AI Credits mit Overage-Logik.

So weit das Listenpreis-Bild. In realen Setups landen Engineering-Organisationen bei 150 bis 250 US-Dollar pro Entwickler und Monat all-in, sobald der Agent ernsthaft im Workflow steht; Anthropic dokumentiert genau diese Spannweite über Enterprise-Deployments hinweg. Aufs Jahr gerechnet bewegen sich die direkten Tool-Kosten damit zwischen rund 400 Euro (Copilot Business als Standardlizenz) und 2.500 Euro oder mehr (Claude-zentrierter agentischer Workflow mit hohem Token-Verbrauch). Wie diese Mehrkosten durch Premium-Requests, AI Credits, Heavy-User-Verlagerung auf Max-Pläne und Nutzungspuffer entstehen, zerlegt der Beitrag zu Claude-Code- und Copilot-Preisen 2026.

Auch das obere Ende bleibt ein kleiner Bruchteil der Personalkosten eines Senior-Entwicklers. An dieser Position kippt die Rechnung also nicht, auch wenn sie im Einkauf regelmäßig um ein Mehrfaches unterschätzt wird. Was den Business Case dominiert, sind Conversion, Enablement und Risiko, nicht der Seat-Preis. TCO erklärt den Eintrittspreis. ROI erklärt, ob sich der Eintritt lohnt.

Variable 3 · Indirekte Kosten

Das ist der blinde Fleck im Vendor-Modell. Drei Posten gehören hierher, die in Sales-Decks praktisch nie auftauchen. Erstens die Anlaufphase: In den ersten Monaten stehen Output und Review-Kadenz unter Druck, weil das Team das neue Werkzeug erst kalibrieren muss. Die genaue Dauer ist nicht primär belegbar, aber drei bis sechs Monate sind eine vorsichtige Größenordnung. Zweitens der laufende Plattformbetrieb mit Sicherheits-Reviews der Agent-Werkzeuge, Logging, Governance und Zugriffsmanagement. Drittens Schulung und Change Management.

Eine beispielhafte TCO-Schätzung des Developer-Intelligence-Anbieters DX nennt für ein 100-Entwickler-Team rund 40.000 US-Dollar an direkten Lizenzkosten gegen rund 66.000 US-Dollar all-in, sobald Training, Admin, Security und Change Management eingerechnet werden. Das ist Vendor-Framework, keine unabhängige Telemetrie; als Startpunkt für eine eigene TCO-Struktur brauchbar, als Beleg für reale Kosten nicht.

Variable 4 · Downstream-Conversion-Faktor

Hier zeigt das Vendor-Modell die größten Lücken. Der 2024er DORA-Report auf Basis von über 39.000 Befragten meldet zwar positive Befunde zu individueller Produktivität, Codequalität, Dokumentationsqualität und Review-Geschwindigkeit. Im selben Report sinkt aber pro 25 Prozent mehr KI-Adoption die Delivery-Stabilität um 7,2 Prozent und der Delivery-Throughput um 1,5 Prozent. Das ist Korrelation, keine Kausalität, aber das Muster ist auffällig genug, dass der 2025er DORA-Report eigens darauf zurückkommt. Nathen Harvey und Derek DeBellis bringen den Befund auf eine Formel: „AI doesn't fix a team; it amplifies what's already there."

Eine oft übersehene Vorbedingung liegt noch vor dem eigentlichen Workflow: Kontextzugriff. Ein Agent, der nur die geöffnete Datei sieht, arbeitet anders als ein Agent, der Ticket, Tests, Architekturregeln, Security-Policies und relevante Repo-Historie nutzen darf. Datenschutz, Betriebsrat und Plattformarchitektur entscheiden damit nicht nur über Risiko, sondern über Produktivität. Ohne Kontextzugriff entsteht Autocomplete-ROI, kein Agent-ROI.

Daneben benennt DORA sieben Foundational Capabilities, die mitentscheiden, ob die Effekte durchschlagen: klar kommunizierte KI-Strategie, gesunde Datenökosysteme, intern zugängliche Daten, robuste Versionskontrolle, Arbeit in kleinen Batches, Nutzerzentrierung und qualitativ gute interne Plattformen. Teams mit diesen Fundamenten sehen die Gewinne in der Auslieferung, Teams ohne sie sehen sie verpuffen. Die Telemetrie des Engineering-Intelligence-Anbieters Faros AI über rund 22.000 Entwickler in 4.000 Teams stützt das Bild: plus 51,3 Prozent PR-Größe, plus 441,5 Prozent mediane Review-Zeit und plus 31,3 Prozent ungereviewte Merges in Phasen hoher KI-Adoption. Faros ist Selbstauskunft auf Telemetrie-Basis, keine kontrollierte Studie, aber die Richtung passt zur DORA-Diagnose.

Daraus ergibt sich für das Modell eine Zwei-Pfad-Annahme: Ohne solide Fundamente schlagen 30 bis 50 Prozent eines Brutto-Speedups auf die tatsächliche Auslieferung durch, mit Fundamenten 60 bis 80 Prozent. Das sind CFO-taugliche Szenariobandbreiten, keine direkt aus den Studien ableitbaren Effektgrößen. Im Pilot müssen sie gegen eigene Delivery-Daten kalibriert werden.

Variable 5 · Risiko-Aufschlag

KI-generierter Code bringt mehr Review- und Security-Arbeit mit sich. Strittig ist nur, wie viel mehr. Der AppSec-Anbieter Apiiro wirbt bei Fortune-50-Unternehmen mit einem Zehnfachen an Security-Findings in KI-generiertem Code; das ist ein Vendor-Claim mit kommerziellem Interesse, keine kontrollierte Studie. Contrast Security bestreitet die Größenordnung, nicht die Richtung.

Verlässlicher sind zwei jüngere Quellen. Veracode 2025 hat über 100 Modelle an 80 Tasks getestet und 45 Prozent Failure Rate auf Secure-Coding-Benchmarks gemessen, in Java sogar über 70 Prozent. Eine kleinere Analyse des Code-Review-Anbieters CodeRabbit von 470 Open-Source-PRs hat 1,7-fach mehr Issues und bis zu 2,74-fach mehr Security-Issues in KI-mitgeschriebenem Code gefunden. Der stärkste Anker für den tatsächlichen Review-Mehraufwand bleibt die Stack-Overflow-Umfrage 2025: 66 Prozent der Befragten nennen „KI-Lösungen, die fast richtig sind, aber nicht ganz" als Hauptfrustration.

Als Modellannahme bewegen sich diese Befunde in einem Korridor von drei bis zehn Prozent zusätzlichem AppSec- und Review-Aufwand, im ersten Jahr meist am oberen Ende, danach abhängig von Automatisierung, Policies und Teamreife. Anders als die Anlaufphase kehrt diese Position jährlich wieder.

Fünf Variablen statt einer. So unterscheidet sich eine Sales-Folie von einer belastbaren Zahl.

Das Modell in einer Formel

Bevor die Beispielrechnung folgt, die Struktur in einer Zeile, damit klar ist, was jährlich wiederkehrt und was einmalig anfällt:

Netto-Wertbeitrag Jahr 1 = Brutto-Kapazitätswert × Conversion Factor − Tool-Lizenzen − einmaliges Enablement − wiederkehrende Plattform- und Security-Kosten − Risiko-Aufschlag

Netto-Wertbeitrag Jahr 2 = Brutto-Kapazitätswert × Conversion Factor − Tool-Lizenzen − wiederkehrende Plattform- und Security-Kosten − Risiko-Aufschlag

Die Formel zeigt den Netto-Wertbeitrag in Euro. Der eigentliche ROI als Verhältnis ergibt sich erst durch Division: Netto-Wertbeitrag geteilt durch die Gesamtkosten desselben Jahres.

Enablement ist die einzige Position, die im zweiten Jahr entfällt. Alles andere bleibt.

Eine Beispielrechnung für ein 50-köpfiges Engineering-Team

Annahmen: 50 Entwickler in einem deutschen Mittelständler. Personalvollkosten 130.000 Euro pro Kopf, Personalbudget 6,5 Millionen Euro. Brutto-Speedup-Annahme 18 Prozent auf einen Code-Schreib-Anteil von 30 Prozent: nominaler Brutto-Kapazitätswert 351.000 Euro pro Jahr. Dieser Wert ist noch keine Einsparung. Er ist die Obergrenze dessen, was überhaupt in Delivery-Wirkung übersetzt werden kann. Tool-Stack auf Copilot-Enterprise-Niveau: rund 22.000 Euro Listenpreis (50 × 39 US-Dollar × 12 Monate bei grober Umrechnung), dazu rund 8.000 Euro Puffer für zusätzliche AI-Credit-Nutzung nach dem 1.-Juni-Modell, in Summe 30.000 Euro. Bei Claude-zentriertem agentischen Workflow würde allein die Toolposition auf 60.000 bis 120.000 Euro steigen. Enablement, Review und Security müssten separat neu bewertet werden.

Die Kostenannahmen sind bewusst konservativ.

Das Diagramm zeigt den Kipppunkt: Nicht das Tool trennt die Pfade, sondern die Konversion. Wer die Modellannahmen schärft (höhere Brutto-Speedups, niedrigere Plattformkosten in größeren Organisationen), bewegt das Ergebnis im Rahmen, den die Konversion zieht.

Wie Teams den Conversion Factor erhöhen

Was trennt 40 Prozent von 70 Prozent Conversion? Vier Hebel, keiner davon das Tool selbst.

Batch-Disziplin

Faros misst plus 51,3 Prozent PR-Größe in KI-intensiven Teams. Größere PRs verlängern die Review-Zeit nicht linear, sondern überproportional. Ein Change-Budget von höchstens drei Dateien und rund 80 geänderten Zeilen für agent-getriebene PRs ist die einfachste Gegenmaßnahme. Sie senkt die Review-Last und macht Fehler sichtbar, bevor sie in Produktion landen. Diese Grenze ist keine Stilregel. Sie ist eine finanzielle Kontrollmaßnahme: Sie erhöht den Conversion Factor und senkt zugleich den Risiko-Aufschlag.

Review-Kapazität als Plan, nicht als Restgröße

Wenn die Generation-Kapazität steigt und Review-Kapazität gleich bleibt, landet der Gewinn in der Warteschlange. Das ist die Diagnose aus dem Beitrag zum Engpass im Pull Request. Wer den Rollout plant, ohne Review-Kapazität in dieselbe Planung zu schreiben, baut sich den Stau selbst.

Testdisziplin und Versionskontrolle

Zwei der sieben DORA-Capabilities heißen working in small batches und strong version control practices. Das sind keine neuen Ideen. Sie sind nur jetzt der Hebel, der den Conversion Factor definiert. Vor dem KI-Rollout waren das Hygiene-Themen. Nach dem KI-Rollout sind sie die Bedingung dafür, dass die Investition Geld einspielt.

Training und Steuerung des Agents

METR und eine Anthropic-Studie zur Skill-Formation deuten in dieselbe Richtung. Anthropic vergleicht KI-Gruppe und Hand-Coding-Gruppe und findet 17 Prozentpunkte Unterschied im Code-Verständnis-Quiz. Die Studie stammt vom Tool-Anbieter, also ist Skepsis angebracht. Die Botschaft hält trotzdem: Eine Lizenz ohne Workflow-Training ist eine Zeile im Budget, kein Gewinn in der Bilanz.

Der Conversion Factor ist der am stärksten steuerbare Hebel in diesem Modell. Die anderen Variablen sind entweder marktgegeben (Tool-Preise) oder organisationsspezifisch und nur über längere Strukturarbeit veränderbar.

Was in die CFO-Vorlage gehört

Vier Regeln, die aus diesem Modell auf den Tisch gehören.

Regel 1: Zwei Szenarien, nicht eine Zahl. Rechnen Sie Worst Case mit 40 Prozent Conversion, Base Case mit 55 Prozent, Best Case mit 70 Prozent. CFOs akzeptieren Bandbreiten, nicht Versprechen. Die Bandbreite ist der Beweis, dass das Engineering die Unsicherheit verstanden hat.

Regel 2: Trennen Sie Kostenersparnis, Kapazitätswert und Enablement-Investition. Die isolierten Tool-Kosten wären selbst bei 40 Prozent Conversion gedeckt, weil sie klein sind. Die Gesamtrechnung kippt erst durch Enablement, Plattformbetrieb und Risikoaufschlag. Wenn der Headcount gleich bleibt, entsteht keine direkte Personalkostenersparnis. Der Business Case muss deshalb zeigen, wohin die freigesetzte Kapazität fließt: weniger externe Entwicklung, kürzere Lead Time, mehr regulatorische Arbeit, geringerer Rework oder schnellerer Backlog-Abbau. Kostenersparnis, Kapazitätswert und Enablement-Investition gehören als getrennte Positionen in den Business Case.

Regel 3: Definieren Sie Downstream-Metriken vor dem Rollout. Entwicklerproduktivität messen Sie nicht über PRs pro Woche oder akzeptierte Copilot-Vorschläge, sondern über Change Failure Rate, Lead Time for Changes, Failed Deployment Recovery Time und Rework Rate. Der CFO wird in sechs Monaten nachrechnen. Sorgen Sie dafür, dass dieselbe Metrik gemessen wird wie beim Business Case. Sonst gibt es keinen Vergleich, nur Eindrücke. Welche Metriken den Rollout aushalten, steht ausführlich im Beitrag zu DORA-Metriken für Coding Agents. Der Conversion Factor gehört nicht nur ins Spreadsheet, sondern in den monatlichen Rollout-Review: realisierte Delivery-Wirkung geteilt durch nominalen Brutto-Kapazitätswert. Diese Zahl ist keine exakte Wissenschaft. Sie ist ein Frühwarnsystem. Wenn PR-Größe, Review-Wartezeit und Change Failure Rate steigen, während Lead Time und ausgelieferte Änderungen nicht besser werden, verpufft der Brutto-Speedup im System.

Regel 4: Machen Sie den Conversion Factor zum Thema des KI-Rollouts im Unternehmen. Eine Lizenz zu kaufen ist leicht. Eine DORA-Capability aufzubauen dauert Monate und bindet Senior-Zeit. Das ist die Arbeit, die den Business Case real macht. Wer das nicht in den Plan schreibt, hat keinen Plan, sondern eine Bestellung.

Was die Zahlen für die Q2-Sitzung bedeuten

Die ehrliche ROI-Rechnung für Coding Agents fällt nicht pessimistisch aus, nur präziser. Unter günstigen Bedingungen (Conversion Factor im oberen Drittel, saubere Ausführung) kann der Return im zweiten Jahr deutlich positiv werden und über drei Jahre die Investition tragen. Ohne Conversion-Arbeit bleibt die Rechnung schnell bei Null oder darunter, in mehreren Modellrechnungen auch über drei Jahre hinweg. Die Frage ist also nicht, ob investiert wird, sondern wie viel Arbeit in den Conversion Factor fließt.

Von den vier Hebeln sind zwei organisatorische Arbeit: Review-Architektur und DORA-Capabilities gehören in den Rollout-Plan, nicht in den Schulungskalender. Die anderen zwei sind handwerklich: Batch-Disziplin und die Steuerung des Agents im Alltag lassen sich trainieren. Der Intensivkurs Coding Agents meistern deckt diese praktische Schicht ab.