Mein LinkedIn-Feed ist schon seit Wochen voll davon. Meine X-Timeline auch. Leute posten Screenshots von Token-Ausgaben, als wären es Fortschrittsberichte. Startup-Gründer prahlen damit, dass sie letzten Monat 16.000 Dollar für Claude Code ausgegeben haben und im nächsten Monat 60.000 Dollar erreichen wollen. Bestenlisten. Ranglisten. Titel wie "Token-Legende" und "KI-Gott".
Und dann, letzte Woche, erreichte es die kritische Masse. Forbes berichtete über die "Tokenmaxxing"-Bewegung im Silicon Valley, bei der Unternehmen darum wetteifern, wer die meisten KI-Token verbrennt. Jensen Huang sagte im All-In-Podcast: "Diesen 500.000-Dollar-Ingenieur werde ich am Ende des Jahres fragen: 'Wie viel hast du in Token ausgegeben? Wenn er sagt: '5.000 Dollar', werde ich etwas anderes machen. Wenn dieser 500.000-Dollar-Ingenieur nicht mindestens Token im Wert von 250.000 Dollar verbraucht hat, werde ich zutiefst beunruhigt sein."
Dann berichtete [Fortune] (https://fortune.com/2026/04/09/meta-killed-employee-ai-token-dashboard/), dass ein Meta-Mitarbeiter eine interne Rangliste namens "Claudeonomics" erstellt hatte, in der der Token-Verbrauch der über 85.000 Mitarbeiter des Unternehmens erfasst wurde. Die Top-Nutzer bekamen Titel. In einem 30-Tage-Fenster erreichte die Gesamtnutzung 60 Billionen Token. Der Spitzenbenutzer verbrauchte im Durchschnitt 281 Milliarden. Mark Zuckerberg schaffte es nicht einmal unter die Top 250. Der CTO von Meta, Andrew Bosworth, sagte unterdessen öffentlich, dass sein bester Ingenieur sein Gehalt in Token ausgibt, aber "5- bis 10-mal produktiver" arbeitet. "Das ist einfaches Geld", sagte Bosworth. "No limit."
Ich bin lange genug in der Softwarebranche, um zu wissen, was hier passiert. Es handelt sich um "Codezeilen" mit einem viel höheren Preisschild.
Wir waren schon mal hier
Im Jahr 2003 schrieb Martin Fowler [eine kurze Abhandlung darüber, warum Softwareproduktivität nicht messbar ist] (https://martinfowler.com/bliki/CannotMeasureProductivity.html), die wahrscheinlich zur Pflichtlektüre für jede technische Führungskraft gehören sollte. Sein Argument zu den Codezeilen war präzise:
"Eines meiner größten Ärgernisse sind Produktivitätsstudien, die auf Codezeilen basieren. Jeder gute Entwickler weiß, dass er den gleichen Stoff mit riesigen Unterschieden in den Codezeilen programmieren kann."
Das Problem ist offensichtlich, wenn du es laut aussprichst. LOC misst die Aktivität, nicht den Output. Zwei Entwickler können das gleiche Feature bauen: Der eine schreibt 1.200 Zeilen, der andere 80. Der prägnante Entwickler hat wahrscheinlich ein besseres System gebaut. Unter dem LOC-Regime sieht der ausführliche Entwickler produktiver aus.
Teams, die nach LOC bewertet wurden, reagierten vernünftig. Sie schrieben mehr Zeilen. Sie kopierten, anstatt zu abstrahieren. Sie vermieden Refactoring, weil das Löschen von Code ihren Zahlen schaden würde. Die Kennzahl beeinflusste ihr Verhalten, aber nicht in Richtung besserer Software. Mehr Code. Schlechtere Systeme.
Im Jahr 2023 veröffentlichte McKinsey einen Artikel, in dem behauptet wurde, die objektive Messung der Entwicklerproduktivität geknackt zu haben. [Die ausführliche Antwort von Gergely Orosz und Kent Beck (https://newsletter.pragmaticengineer.com/p/measuring-developer-productivity) wies auf den gleichen Fehler hin: Fast alle McKinsey-Kennzahlen maßen Aufwand und Output, nicht aber das Ergebnis. Kent Beck hat beobachtet, wie Facebooks interne Umfragen zur Stimmung der Entwickler von nützlichem Feedback zu Verhandlungen zwischen Managern und Ingenieuren über höhere Punktzahlen wurden. Das passiert, wenn man Anreize für eine stellvertretende Kennzahl schafft. Die Zahl verbessert sich. Die Sache, um die du dich eigentlich kümmerst, nicht.
Man sollte meinen, wir hätten daraus gelernt. Haben wir aber nicht.
Gleicher Fehler, andere Einheit
Die verführerische Logik des Tokenmaxxing läuft folgendermaßen ab. Tokenverbrauch = KI-Nutzung. Mehr KI-Nutzung = Teams nutzen KI. Also: hohe Tokenausgaben = hohe KI-Nutzung = gut.
Das ist genauso fehlerhaft wie die Messung von Codezeilen, nur mit einem Billing-Dashboard statt einem Commit-Diagramm. Und um dem Forbes-Artikel gerecht zu werden, hat der CEO von Sendbird, John Kim, genau das gesagt: "Wir haben diesen Film schon einmal gesehen." Er bezog sich damit auf die LOC-Kultur der 1990er und 2000er Jahre. Der eigentliche Indikator sei, wie viel KI-generierter Code es tatsächlich in die Produktion schafft. Token-Ausgaben "sind eher ein Gesprächsanlass". Dem stimme ich zu. Problematisch wird es, wenn der Gesprächsanlass zum wichtigsten KPI wird.
Die [GitHub-Entwicklerumfrage 2024] (https://github.blog/news-insights/research/survey-ai-wave-grows/) ergab, dass 97 % der Entwickler in Unternehmen schon einmal KI-Codierungstools bei der Arbeit eingesetzt haben. Für eine sinnvolle Einführung im Unternehmen sind jedoch klare Richtlinien, Arbeitsabläufe und messbare Ergebnisse erforderlich, die an tatsächliche Geschäftsergebnisse gebunden sind. Nicht nur Nutzung. Nicht nur Konsum.
Boris Cherny, der Ingenieur hinter Claude Code, teilte öffentlich mit, dass er während eines Arbeitsmonats überhaupt keine IDE geöffnet und mit Opus 4.5 etwa 200 PRs geschrieben hat. Das ist beeindruckend. Aber das Beeindruckende sind nicht die Token, die diese 200 PRs verbraucht haben. Sondern dass es sich um 200 echte Beiträge mit funktionierender Software handelte, die am anderen Ende zusammengeführt wurden.
Der Wert liegt in dem Ergebnis. Token sind die Energie, die dich dorthin gebracht hat, mehr nicht.
Wenn die Metrik zum Ziel wird
Es gibt ein Prinzip namens Goodhart's Law: Wenn eine Messgröße zum Ziel wird, ist sie keine gute Messgröße mehr. Die Geschichte der Softwareentwicklung ist im Grunde ein Museum für Goodharts Gesetz in Aktion.
Die Verfolgung von Token als KPI für die KI-Einführung bringt genau dieselbe Dynamik mit sich. Ingenieurteams, die am Token-Verbrauch gemessen werden, werden mehr Token verbrauchen. So funktionieren Anreize nun mal. Willst du produktiver aussehen? Führe ein paar mehr agenturische Schleifen durch. Lass das Modell lange nachdenken, bevor es eine Ausgabe erzeugt. Verpacke jede Aufgabe in eine Orchestrierungsschicht, die vier Tools aufruft, wo sonst eines reicht. Die Ausgaben für Token steigen. Der gelieferte Wert jedoch nicht.
Die Geschichte von Claudeonomics hat das fast sofort bewiesen. Fortune stellte fest, dass "einige Mitarbeiter KI-Agenten stundenlang arbeiten lassen, um ihre Token-Nutzung zu maximieren". Da haben wir es. Goodharts Gesetz in Echtzeit, und das in einem Unternehmen, das angeblich an der Spitze der KI-gesteuerten Produktivität steht. Die Bestenliste war vielleicht ein paar Wochen lang online, bevor sie abgeschaltet wurde, und die Mitarbeiter spielten bereits mit ihr, indem sie Agenten in Schleifen laufen ließen. Die Kennzahl war drei Wochen alt und hatte bereits aufgehört, das zu messen, was sie eigentlich messen sollte.
Jedem Entwickler, der das hier liest, fallen wahrscheinlich fünf Möglichkeiten ein, wie man die Token-Nutzungskennzahlen aufblähen kann, ohne dass jemand davon profitiert. Ich werde sie nicht aufzählen. Aber wenn mir fünf einfallen, können das auch die Ingenieure, die hier gemessen werden.
Andrej Karpathy bezeichnete [den aktuellen Moment in der Softwareentwicklung] (https://x.com/karpathy/status/2004607146781278521) als ein "Erdbeben der Stärke 9" für den Berufsstand. Da hat er Recht. Aber Erdbeben werden nicht an der verbrauchten Energie gemessen. Sie werden an dem gemessen, was sich bewegt.
Die Dokumentationsversion dieses Problems
Das ist nicht nur ein Problem für Ingenieurteams. Die gleiche Dynamik sehe ich im Wissensmanagement, das uns bei Rasepi viel näher liegt.
"Wir haben in diesem Quartal 400 Dokumente veröffentlicht" ist eine Zahl, die in einem Slide Deck gut klingt. Sie sagt aber nichts darüber aus, ob diese Dokumente korrekt sind, ob sie jemand gelesen hat oder ob die darin enthaltenen Informationen sechs Monate später noch stimmen. Du kannst diese Zahl mit KI und ohne jegliches Denken erreichen. Token-gestütztes Rauschen im großen Stil veröffentlicht.
Die ehrliche Kennzahl ist schwieriger zu erheben, aber viel nützlicher: Wie viel Prozent deiner Wissensbasis spiegelt tatsächlich wider, wie deine Systeme heute funktionieren? Wie viele Menschen haben mit Hilfe deiner Dokumentation eine richtige Antwort gefunden? Wie viele haben es versucht, sind gescheitert und haben stattdessen jemanden auf Slack gefragt?
Für diese Fragen gibt es noch keine hübschen Dashboards. Sie erfordern konkrete Überlegungen darüber, was die Dokumentation für dein Unternehmen leisten soll. (Nicht zufällig ist das genau das Problem, für das Rasepi entwickelt wurde. Erzwungene Verfallsdaten gibt es genau deshalb, damit Teams sich Gedanken darüber machen müssen, ob Inhalte noch gültig sind, anstatt sie hinter einer hohen Seitenzahl stillschweigend verrotten zu lassen).
Was man stattdessen verfolgen sollte
Die ehrliche Antwort auf die Frage "Lohnt sich unsere KI-Investition?" lässt sich nicht an einem Dashboard ablesen.
Du kannst dich ihr mit besseren Fragen nähern: Verbessern sich die Durchlaufzeiten? Entwickelt sich das Verhältnis von ausgelieferten Funktionen zu gemeldeten Fehlern in die richtige Richtung? Berichten die Ingenieure, dass sie mehr Zeit mit urteilsintensiver Arbeit und weniger mit Tippen verbringen? Bleibt deine Dokumentation auf dem neuesten Stand, anstatt sich wie Sedimente anzusammeln?
Diese Fragen sind bei einer API schwieriger zu beantworten. Sie erfordern, dass du dir überlegst, was du eigentlich von deinen Teams willst, und das ist zugegebenermaßen die schwierigere Arbeit. Aber genau diese Fragen sind wichtig, denn es geht um das Ergebnis und nicht um den Input.
Die Token-Ausgaben sagen dir, wie viel Rechenleistung du gekauft hast. Ob diese Rechenleistung zu etwas Nützlichem wurde, ist eine ganz andere Frage. Unternehmen, die diesen Unterschied nicht beachten, werden sehr teure Dashboards bauen, die ihnen fast nichts zeigen.
Wir haben Jahre damit verbracht, die falsche Metrik für die Entwicklerproduktivität zu optimieren. Wir haben vielleicht noch ein Quartal Zeit, bevor derselbe Fehler in jedem Bericht über die Einführung von KI im Unternehmen auftaucht. Das Fenster, um das zu vermeiden, ist offen, aber das wird nicht so bleiben.