Es gibt inzwischen Ingenieure bei einigen der größten Softwareunternehmen der Welt, die sich Gedanken darüber machen, ob sie genug KI verbrauchen. Nicht ob sie das richtige Problem lösen, nicht ob ihr Code hält, sondern ob ihr Token-Verbrauch auf dem internen Dashboard hoch genug aussieht. Einer bringt es gegenüber The Pragmatic Engineer auf den Satz: Er achte darauf, nicht als jemand zu gelten, „der zu wenig KI nutzt", und schäme sich nicht zu sagen, dass er dafür Tokenmaxxing betreibe[1].
Das Phänomen hat einen Namen und eine Definition: Tokenmaxxing ist die Praxis, den eigenen KI-Verbrauch zu maximieren, insbesondere durch autonome Agenten, wobei „ultrahohe KI-Nutzung als Produktivitätssignal behandelt wird, unabhängig vom Output"[2]. Unternehmen bauen Dashboards, die Token-Verbrauch und den Anteil KI-generierten Codes tracken; bei Meta kursiert ein internes Leaderboard, das die größten KI-Nutzer des Hauses listet[1].
Wer gerade ein solches Dashboard baut, wird das Folgende ungern lesen: Die Evidenz spricht ziemlich einhellig dagegen. Tokenmaxxing ist kein neues Messproblem, sondern ein sehr altes in neuem Gewand, und die Alternative ist keine Raketenwissenschaft, sondern das, was gute Engineering-Organisationen ohnehin tun: Ergebnisse messen statt Aufwand. Man könnte es Valuemaxxing nennen. Dieser Beitrag zeigt, warum die Input-Messung scheitert, was sie kostet und was an ihre Stelle gehört.
Ein alter Messfehler in neuem Gewand
Die Softwareindustrie hat diese Debatte schon einmal geführt. Wer Produktivität in geschriebenen Codezeilen maß, bekam mehr Codezeilen, aber nicht mehr funktionierende Software. Genau dorthin führt der Weg zurück: Tokenmaxxing ist „die Rückkehr in die Ära vor DORA, in die Ära des Lines-of-Code-Messens"[3]. Nur dass die Codezeile heute nichts mehr kostet außer Strom, während jeder Token auf einer API-Rechnung erscheint.
Der Mechanismus des Scheiterns ist derselbe wie damals, verschärft um die Kostenkomponente. The Pragmatic Engineer formuliert es deutlich: Es gebe kaum rationale Gründe, warum es für irgendein Unternehmen Sinn ergebe, Tokenmaxxing zu incentivieren. Es erhöhe die KI-Ausgaben erheblich, bei wenig bis keinem Gegenwert, denn die Zahl der Tokens, die ein Entwickler erzeugt, lasse sich mühelos künstlich in die Höhe treiben, und wenn diese Metrik gemessen werde, würden Entwickler genau das auch tun, mit einer massiven KI-Rechnung als Begleiterscheinung[1]. Das ist Goodharts Gesetz mit Preisschild: Sobald die Kennzahl zum Ziel wird, hört sie auf, etwas zu messen, und beginnt, Geld zu verbrennen.
Selbst die nüchterne Begriffsdokumentation hält fest, dass die Praxis „zusätzliche Token-Kosten, Burnout oder tatsächlich mehr aufgeblähten Code niedrigerer Qualität erzeugen kann"[4]. Der Grundfehler ist immer derselbe: Ein Input, ob Codezeilen, Arbeitsstunden oder Tokens, wird als Stellvertreter für einen Output behandelt, also für funktionierende Software und gelöste Geschäftsprobleme. Entwickler, deren Token-Verbrauch gemessen wird, optimieren den Token-Verbrauch. Ob der erzeugte Code jemals ausgeliefert wird, funktioniert oder das richtige Problem löst, taucht in der Kennzahl nicht auf.
Die Rechnung geht bisher nicht auf
Man könnte einwenden: Wenn KI-Tools die Entwicklung wirklich beschleunigen, ist hoher Verbrauch eben doch ein Signal. Das Problem ist, dass die ökonomische Bilanz diese Lesart bislang nicht stützt.
Auf der Kostenseite tauschen Organisationen, die auf Output-Volumen optimieren, planbare Personalkosten gegen volatile, wachsende API-Ausgaben. Die Analyse von The Innovation Dispatch spitzt es zu: Diese Jagd nach Code-Output verwandelt Engineering-Teams „in KI-Konsumzentren mit hohen Kosten"[5]. Gleichzeitig verdoppeln sich interne KI-Produktivitätsbudgets im Jahresvergleich, und manche Unternehmen planen, weniger einzustellen, um mehr für KI-Tools auszugeben[6].
Auf der Ertragsseite steht dem wenig Belegbares gegenüber. Laut der im Branchen-Benchmark zitierten Gartner-CIO-Umfrage können viele Engineering-Verantwortliche den ROI ihrer KI-Investitionen nicht beziffern; sie erreichen bestenfalls die Gewinnschwelle oder zahlen drauf[7]. Das ist bemerkenswert: Eine Technologie, deren Produktivitätswirkung so offensichtlich sein soll, dass man ihren Verbrauch zur Kennzahl erhebt, entzieht sich zugleich hartnäckig dem Nachweis in der Gewinn-und-Verlust-Rechnung.
Der Zusammenhang zwischen beiden Befunden ist kein Zufall. Wer Token-Verbrauch und generierte Codezeilen misst, hat keinerlei Sicht darauf, ob dieser Output in ausgelieferte Features, kürzere Durchlaufzeiten oder bessere Geschäftsergebnisse übersetzt[6]. Organisationen, die vor dem KI-Rollout nicht artikuliert haben, was für sie Engineering-Performance überhaupt bedeutet, finden es anschließend fast unmöglich, den KI-Effekt jenseits von Oberflächenmetriken wie Codezeilen oder Akzeptanzrate zu messen[6]. Die Messlücke ist nicht die Folge des KI-Einsatzes, sie ist die Voraussetzung dafür, dass Tokenmaxxing als Kennzahl überhaupt plausibel wirken kann.
Schneller liefern, öfter zurückrollen
Zur Kostenfrage kommt die Qualitätsfrage, und hier ist die Datenlage ernüchternder, als die Tool-Anbieter sie darstellen.
Der DORA State of DevOps Report 2025 zeigt ein Muster, das jeder kennt, der schon einmal Geschwindigkeit ohne Governance skaliert hat: Teams mit KI-Coding-Tools steigerten ihre Deployment-Frequenz, aber parallel stieg ihre Change Failure Rate[8]. Mehr Durchsatz, mehr Fehlschläge, und als Ursache identifizieren die dokumentierten Fälle nicht schlechtere Ingenieursleistung, sondern ein Missverhältnis zwischen der Geschwindigkeit der Code-Generierung und der menschlichen Review-Kapazität[8].
Dasselbe Signal sendet die Code Turnover Rate, also der Anteil des Codes, der kurz nach dem Merge wieder revertiert, gelöscht oder substanziell umgeschrieben wird: KI-generierter Code weist höhere Turnover-Raten auf als von Menschen geschriebener[9]. Ein Teil des vermeintlichen Produktivitätsgewinns ist also Arbeit, die doppelt gemacht wird, einmal von der Maschine und einmal von dem Menschen, der hinterherräumt. Entwickler selbst beschreiben das Grundproblem präzise; ihre häufigste Klage über KI-Tools lautet, die Lösung sei „fast richtig, aber nicht ganz", und nur eine Minderheit vertraut dem Output in hohem Maße[10]. In akademischen Benchmarks kompilierte nur ein kleiner Teil des KI-generierten Codes überhaupt, mehrheitlich scheiterte er an unbekannten Symbolen[11].
Daraus entsteht der eigentliche Engpass der KI-beschleunigten Entwicklung, und er liegt nicht beim Schreiben. Wenn KI-Tools den Code-Output erhöhen, wächst die Review-Last proportional mit, aber die Review-Kapazität skaliert nicht im gleichen Tempo[7]. Teams verbringen wachsende Anteile ihrer Sprints wartend, auf Reviews und auf CI-Pipelines[8]. Wer in dieser Lage den Token-Verbrauch weiter nach oben incentiviert, vergrößert exakt die Halde, vor der die eigentliche Wertschöpfung im Stau steht. Man misst den Zufluss und feiert ihn, während der Abfluss verstopft.
Die Rolle des Entwicklers verschiebt sich
Unter der Metrik-Debatte liegt eine tiefere Verschiebung, und wer sie versteht, versteht auch, warum Input-Metriken gerade jetzt so in die Irre führen.
Wenn KI mehr von der Code-Generierung übernimmt, wandert die Rolle des Entwicklers in Richtung Orchestrierung und Spezifikation[7]. Microsoft beobachtet zugleich ein neues Phänomen: Rollen, die bisher nicht programmierten, beginnen Code zu schreiben, weil die kognitive Einstiegshürde deutlich gesunken ist[12]. Das klingt nach Demokratisierung, und ist es teilweise auch. Aber es erzeugt ein Paradox: Je billiger das Erzeugen von Code wird, desto teurer und wichtiger wird das Urteil darüber, ob dieser Code stimmt.
Denn das Vertrauensproblem ist real und begründet. Entwickler geben offen zu, KI-generiertem Code nicht voll zu vertrauen, und genau diese Lücke erzeugt ein neues Betriebsmodell: KI erhöht die Implementierungsgeschwindigkeit, während erfahrene Ingenieure als Architektur-Autoritäten und Validierungsinstanzen kritischer werden[13]. KI erledigt repetitive, klar umrissene Arbeit effektiv, tut sich aber schwer mit komplexen Architekturentscheidungen, sicherheitskritischem Code und System-Design[13]. Und in der Praxis verbringen Entwickler oft mehr Zeit damit, KI-generierten Code nachzujustieren, als das Stück von Hand neu zu schreiben[14].
Der Unterschied zwischen Teams, die davon profitieren, und Teams, die dafür bezahlen, liegt in der Struktur. Leistungsstarke Teams behandeln KI als Beschleunigungsschicht innerhalb erfahrener, architektengeführter Workflows, mit klaren Nutzungsrichtlinien, Validierungs-Checkpoints und Einschränkungen für KI-Code in sicherheitskritischen Modulen. Schwächere Implementierungen nutzen KI ad hoc, ohne Systemgrenzen und Review-Workflows, gewinnen anfangs Tempo und bezahlen es später mit Defekten, Sicherheitslücken und Design-Inkonsistenzen, deren Korrektur deutlich teurer ist[13].
Vor diesem Hintergrund wird klar, was Tokenmaxxing eigentlich prämiert: die Tätigkeit, die gerade zur Massenware wird. Die beste Zusammenfassung stammt wieder von The Pragmatic Engineer: Die besten Entwickler sind nicht notwendigerweise die, die den meisten Code schreiben, sondern die, die harte Probleme für das Geschäft schnell und zuverlässig lösen, mit oder ohne Code[1].
Was stattdessen messen: Valuemaxxing in der Praxis
Für die Alternative muss niemand ein neues Framework erfinden. Die Werkzeuge existieren, sie müssen nur als System benutzt werden.
Die DORA-Metriken, also Deployment-Frequenz, Lead Time, Change Failure Rate und Time to Restore, bleiben auch für die Bewertung des KI-Effekts relevant, und das SPACE-Framework ergänzt die qualitative Dimension von Zufriedenheit bis Effizienz; das bestätigt niemand Geringeres als DORA-Mitschöpferin Nicole Forsgren[15]. Entscheidend ist der Systemgedanke: DORA-Metriken waren nie dafür gedacht, individuelle Entwicklerleistung zu bewerten. Sie funktionieren als Verbund, denn wer eine einzelne Kennzahl manipuliert, bringt die anderen zum Ausschlagen[3]. Genau diese Selbstkorrektur fehlt der einsamen Token-Kennzahl.
Für den KI-Anteil der Arbeit heißt das konkret: Ergebnisse statt Zurechnung. Verbinden Sie KI-generierten Code mit tatsächlichen Outcomes, mit Cycle Time, Revert Rate, Durchsatz und Review-Last[16]. Zwei Kennzahlen verdienen dabei besondere Aufmerksamkeit. Die Code Turnover Rate ist der direkteste Qualitätsindikator für KI-Code, weil sie misst, wie viel davon kurz nach dem Merge wieder verschwindet[9]. Und die Change Failure Rate ist das führende Signal dafür, dass KI-Durchsatz der Review-Governance davonläuft[8].
Der Rest ist Organisationsarbeit. Definieren Sie, was Engineering-Performance für Ihr Haus bedeutet, bevor Sie den KI-Einsatz skalieren, sonst messen Sie hinterher zwangsläufig Oberflächenmetriken[6]. Skalieren Sie Review-Kapazität proportional zur Generierungsgeschwindigkeit, statt den Engpass zu ignorieren[7]. Und rechnen Sie den ROI ehrlich, inklusive API-Kosten, Nacharbeit und Review-Investitionen, gegen tatsächliche Lieferergebnisse statt gegen Code-Volumen[5].
Wie ein Dashboard aussehen könnte, das Wert misst
An dieser Stelle kommt verlässlich die praktische Frage: Schön, aber was bauen wir jetzt auf den Bildschirm? Und lässt sich daraus nicht ein Score machen? Vorweg: Ein einzelner Score ist genau die Vereinfachung, vor der dieser Beitrag warnt, und auch ein gut gebauter Score wird zur Zielscheibe, sobald er Beförderungen beeinflusst. Wenn es trotzdem eine Zahl sein soll, weil Geschäftsführungen nun einmal eine Zahl wollen, dann unter zwei Regeln: Der Score koppelt Tempo-Metriken immer an Qualitäts-Metriken, damit die Manipulation einer Kennzahl die anderen ausschlagen lässt[3]. Und er wird nie ohne seine Komponenten angezeigt.
Die Zutaten liefern zwei Quellen. GitHub kennt die Liefer- und Qualitätsseite: Merges und Deployments, die Zeitspanne vom geöffneten Pull Request bis zum Merge, Reverts und Hotfixes, Review-Latenzen. Die Agent-Telemetrie und die API-Abrechnung kennen die KI-Seite: welcher Anteil des gemergten Codes von Agenten stammt, wie lange dieser Code überlebt und was er gekostet hat. Zusammengeführt ergibt das ein kompaktes Kennzahlen-Set:
| Kennzahl | Quelle | Gut ist | Rolle im Score |
|---|---|---|---|
| Deployment-Frequenz | GitHub (Merges, Deploys) | höher | Delivery |
| Lead Time (PR bis Merge) | GitHub | niedriger | Delivery |
| Change Failure Rate | GitHub (Reverts, Rollbacks, Hotfixes) | niedriger | Qualität und Deckel |
| Code-Turnover nach 30 Tagen, KI vs. Mensch | GitHub plus Agent-Telemetrie | niedriger | Qualität |
| Review-Latenz auf KI-Pull-Requests | GitHub plus Agent-Telemetrie | niedriger | Qualität |
| KI-Kosten je gemergtem Change | API-Abrechnung geteilt durch Merges | niedriger | Effizienz |
| KI-Anteil am gemergten Code | Agent-Telemetrie | neutral | Nur Kontext, ohne Score-Wirkung |
Zwei Dinge fallen auf. Der Token-Verbrauch taucht nirgends auf, nicht einmal als Effizienz-Nenner; gezählt wird, was ankommt, nicht was verbraucht wird[16]. Und der KI-Anteil am Code ist bewusst neutral: Er ist Kontext, den man kennen will, aber weder Ziel noch Verdienst.
Aus diesen Bausteinen lässt sich ein bewusst einfacher Score bauen. Jede Kennzahl wird dabei nicht absolut bewertet, sondern relativ zur eigenen Baseline der letzten 90 Tage, denn interessant ist die Richtung, nicht der Branchenvergleich:
norm(x) = x relativ zur 90-Tage-Baseline des Teams,
begrenzt auf 0,5 bis 1,5 und skaliert auf 0 bis 1
Delivery = Mittel aus norm(Deployment-Frequenz) und norm(1 / Lead Time)
Qualität = Mittel aus norm(1 / CFR), norm(1 / Turnover), norm(1 / Review-Latenz)
Effizienz = norm(gemergte Changes je Euro KI-Ausgaben)
Value Score = 100 × (0,4 × Delivery + 0,4 × Qualität + 0,2 × Effizienz)
Governance-Deckel: Liegt die Change Failure Rate mehr als 20 % über
der Baseline, ist der Score bei 60 gedeckelt, egal wie gut der Rest aussieht.
Der Deckel ist der wichtigste Teil der Formel. Er übersetzt den zentralen Befund des DORA-Reports, dass steigender Durchsatz bei steigender Fehlerrate kein Fortschritt ist, in eine harte Regel: Kein Team kann sich über Tempo einen guten Score verdienen, während die Qualität wegläuft[8]. Die Gewichte sind Startwerte, keine Wahrheit; wichtig ist nur, dass Delivery und Qualität gleich schwer wiegen.
So könnte die vereinfachte Ansicht aussehen, mit fiktiven Zahlen:
ENGINEERING VALUE SCORE Team-Ansicht, rollierende 90 Tage
──────────────────────────────────────────────────────────────────
Score 78 / 100 (+4 ggü. Vorquartal) Governance-Deckel: aus
Delivery 0,82 · Qualität 0,74 · Effizienz 0,71
──────────────────────────────────────────────────────────────────
Deployment-Frequenz 12 / Woche ▲ Baseline 9
Lead Time PR bis Merge 26 h ▼ Baseline 31 h
Change Failure Rate 8,1 % ▲! Baseline 6,9 %
Code-Turnover 30 Tage KI 19 % ▲! Mensch 9 %
Review-Latenz KI-PRs 9 h ▲ Mensch-PRs 6 h
KI-Kosten je Change 4,10 € ▼ Baseline 5,60 €
──────────────────────────────────────────────────────────────────
Kontext: KI-Anteil am gemergten Code 46 % (ohne Score-Wirkung)
▲! = Warnsignal: Durchsatz wächst schneller als die Governance
Gelesen wird das wie ein Cockpit, nicht wie ein Zeugnis. Der Score oben ist der Gesprächseinstieg, die Zeilen darunter sind das Gespräch. In diesem fiktiven Team würde man sofort sehen: Das Tempo stimmt, die Kosten sinken, aber die beiden Warnsignale erzählen die bekannte Geschichte, KI-Code verschwindet doppelt so schnell wieder wie menschlicher[9], und die Fehlerrate zieht an, während die Frequenz steigt. Die richtige Reaktion wäre nicht, den Score zu feiern, sondern Review-Kapazität aufzubauen, bevor weiter skaliert wird[7].
Ein letzter Vorbehalt gehört dazu: Auch dieser Score altert. Baselines verschieben sich, Teams lernen seine Mechanik, und spätestens dann braucht er Pflege wie jedes andere Messinstrument. Wer ihn als Wahrheit behandelt statt als komprimierte Zusammenfassung von sechs ehrlichen Kennzahlen, hat nur ein neues Tokenmaxxing gebaut, nur mit umgekehrtem Vorzeichen.
Was die Evidenz nicht hergibt
Auch hier gehört zur Redlichkeit, die Grenzen des Befunds zu benennen. Tokenmaxxing ist als Phänomen jung, es entstand in den Jahren 2024 und 2025. Begutachtete Langzeitforschung dazu existiert praktisch nicht; die beste verfügbare Evidenz stammt aus Branchenreports, Plattformdaten und Praktikerberichten, und mehrere zentrale Aussagen stützen sich auf einzelne Quellen. Das ist eine dünnere Basis, als man sie sich für eine so weitreichende Organisationsfrage wünschen würde.
Zudem ist denkbar, dass einzelne Organisationen mit starker Governance echte Produktivitätsgewinne erzielen, die Kosten und Qualitätsrisiken übersteigen. Die Evidenz legt nahe, dass genau diese Governance die Voraussetzung dafür ist, nicht der hohe Verbrauch[13]. Aber das Gesamtbild über viele Organisationen hinweg fehlt, und die Werkzeuge, die Kostenstrukturen und die Praktiken ändern sich schnell. Wer heute misst, sollte bereit sein, morgen nachzujustieren, und Produktivitätsversprechen ohne Daten aus dem eigenen Haus grundsätzlich als Hypothese behandeln, nicht als Befund.
Was Entscheider daraus machen sollten
Erstens: Bauen Sie keine Token-Dashboards und keine Leaderboards. Was Sie messen, wird manipuliert, und bei dieser Kennzahl bezahlen Sie die Manipulation zusätzlich in API-Kosten[1]. Wenn Sie bereits solche Dashboards haben, sind sie ein guter Kandidat für den nächsten Frühjahrsputz.
Zweitens: Legen Sie fest, was Erfolg bedeutet, bevor Sie KI-Nutzung skalieren. DORA als System, SPACE als Ergänzung, dazu Cycle Time, Revert Rate und Review-Last für den KI-Anteil[15][16]. Eine Organisation, die nicht sagen kann, was „besser" heißt, wird jede KI-Investition an der falschen Stelle rechtfertigen.
Drittens: Behandeln Sie die Review-Kapazität als das, was sie ist, der Engpass des Systems. Steigende Change Failure Rate bei steigender Deployment-Frequenz ist das Signal, Governance und Review-Prozesse auszubauen, bevor noch mehr Code erzeugt wird[8].
Viertens: Ziehen Sie Grenzen für KI-Code in sicherheitskritischen Modulen und setzen Sie Validierungs-Checkpoints, wie es die leistungsstarken Teams tun[13]. Und investieren Sie in Senior-Kapazität: Je mehr Code die Maschine schreibt, desto wertvoller wird der Mensch, der beurteilen kann, ob er stimmt.
Fünftens: Verlangen Sie Evidenz. Ein großer Teil des KI-Produktivitätsdiskurses beruht auf Anekdoten und Anbieterversprechen. Messen Sie Outcomes in der eigenen Organisation, rechnen Sie die vollständigen Kosten, und misstrauen Sie jeder Kennzahl, die Aufwand als Leistung verkauft.
Die Pointe der ganzen Debatte ist am Ende beruhigend altmodisch: Die besten Entwickler waren nie die mit den meisten Codezeilen, und sie sind auch nicht die mit den meisten Tokens. Es sind die, die harte Probleme schnell und zuverlässig lösen, mit oder ohne Code[1]. Eine Kennzahl, die das nicht abbildet, misst nicht Produktivität, sondern Betriebsamkeit.
