Uber-COO sagt, es werde immer schwieriger, die Ausgaben für tokenmaxxing zu rechtfertigen
(businessinsider.com)- Der COO von Uber meint, es werde immer schwieriger zu rechtfertigen, ob die KI-Ausgaben tatsächlich Ergebnisse in Höhe der investierten Kosten liefern
- Die interne Debatte nahm zu, nachdem Ubers CTO offengelegt hatte, dass das Budget für Claude Code im Jahr 2026 bereits aufgebraucht sei
- Ein Zusammenhang, wonach mehr Token-Nutzung proportional zu mehr nützlichen Consumer-Features führt, ist bislang nicht bestätigt
- Ubers CEO erklärte, das Unternehmen verlangsame das Hiring, um die KI-Investitionen auszugleichen
- Anders als der tokenmaxxing-Trend bei Big Tech nahm Duolingo nach Reaktionen der Mitarbeitenden eine Entscheidung zurück, die KI-Nutzung in Leistungsbewertungen aufzunehmen
Das Problem, KI-Kosten intern bei Uber zu rechtfertigen
- Ubers Chief Operating Officer Andrew Macdonald meint, dass es innerhalb des Unternehmens immer schwieriger werde, KI-Kosten zu rechtfertigen
- In einem am Samstag veröffentlichten Rapid Response-Interview sagte er, dass KI nicht die Wirkung erziele, die den Ausgaben des Unternehmens entspreche
- Die interne Diskussion wurde intensiver, nachdem Uber-CTO Praveen Neppalli Naga im April in einem Interview mit The Information gesagt hatte, Uber habe sein Budget für Claude Code im Jahr 2026 bereits vollständig aufgebraucht
- Diese Aussage führte zu einer Situation, die Macdonald als einen „Moment, in dem einem der Kopf platzt“ beschrieb; intern wurde dabei über den Trade-off zwischen dem Verbrauch von AI-Tokens und der Größe der Belegschaft diskutiert
Fehlender Zusammenhang zwischen Token-Nutzung und Produkterfolg
- Nach Gesprächen mit leitenden Engineering-Verantwortlichen bei Uber kam Macdonald zu dem Schluss, dass mehr Token-Nutzung nicht zu einem proportionalen Anstieg nützlicher Consumer-Features führt
- Mit der Aussage „Dieser Zusammenhang existiert noch nicht“ meinte er, dass zwar möglicherweise mehr Features veröffentlicht werden, es aber schwer sei, bestimmte Kennzahlen direkt mit der Schlussfolgerung zu verknüpfen, dass man „jetzt tatsächlich 25 % mehr nützliche Consumer-Features baut“
- Je schwerer sich KI-Ausgaben direkt mit Ergebnissen verknüpfen lassen, desto schwieriger wird es, die Trade-off-Kosten zu rechtfertigen
- CEO Dara Khosrowshahi sagte Anfang dieses Monats bei der Vorlage der Geschäftszahlen, dass Uber das Hiring verlangsame, um die KI-Investitionen auszugleichen
Für Nutzer wirkt es kostenlos, aber das Unternehmen trägt die Kosten
- Macdonald meint, dass KI kostenlos wirken könne, wenn Nutzer sich einfach „interessante Anwendungsfälle“ ausdenken, ohne selbst dafür zu zahlen
- Letztlich zahlt jedoch das Unternehmen die Kosten
- Die Ausweitung der KI-Nutzung wird nicht nur als Produktivitätsexperiment betrachtet, sondern als Kostenstruktur, die Budgets und Personaleinsatz beeinflusst
Ein anderer Verlauf als Big Techs tokenmaxxing
- Big Tech treibt tokenmaxxing, also den möglichst umfassenden Einsatz von KI, stark voran, und einige Unternehmen beziehen die KI-Nutzung von Mitarbeitenden in Bewertungen ein
- Meta, Google, JPMorgan werden als Unternehmen genannt, die KI-Nutzung mit Leistungsbewertungen, Zielen, Gehaltserhöhungen und Beförderungen verknüpfen
- Umgekehrt beginnen manche Unternehmen, sich von einem Ansatz zurückzuziehen, der die KI-Nutzung um ihrer selbst willen forciert
- Duolingo nahm die Entscheidung zurück, KI-Nutzung in Leistungsbewertungen aufzunehmen, nachdem Mitarbeitende gefragt hatten, ob sie „KI nur nutzen sollen, um KI zu nutzen“
- Duolingo-CEO Luis von Ahn sagte in einem Podcast-Interview im April, es habe sich eher so angefühlt, als drücke man in manchen Fällen etwas durch, das nicht passe, statt echte Verantwortung für Ergebnisse einzufordern
1 Kommentare
Hacker-News-Kommentare
In den Jahren 2007 bis 2009, als Google seine Rechenzentren massiv ausbaute, gab es vor allem außerhalb der Arbeitszeit viel ungenutzte Kapazität
Jede Ingenieurin und jeder Ingenieur konnte beliebig viele Jobs mit Priorität 0 laufen lassen; sobald wichtigere Aufgaben Ressourcen brauchten, wurden diese zuerst beendet
Es gab viele nächtliche MapReduce-Experimente, und zeitweise wurden sogar interne Dienste mit Priorität 0 betrieben und liefen dadurch praktisch „kostenlos“
Mit wachsender Nutzung wurden solche Dienste jedoch immer instabiler, und am Ende musste man entweder den Ressourceneinsatz rechtfertigen oder das Ganze verkleinern, was meiner Meinung nach eine gute Entwicklung war
Für den Einsatz von AI-Tokens wäre ein ähnliches Modell sinnvoll. Große Tech-Unternehmen könnten eigene LLM-Rechenzentren betreiben, den internen Bedarf bedienen und freie Kapazitäten außerhalb der Arbeitszeit für Experimente von Mitarbeitenden öffnen
Im Arbeitsalltag sollte man weniger die absolute Zahl der Tokens als vielmehr die Token-Effizienz fördern. Wenn viele Tokens für Automatisierung eingesetzt werden, die jede Woche mehrere Stunden menschlicher Arbeit spart, ist das sinnvoll; wenn man dagegen viele Tokens verbraucht, um einen einfachen Frontend-Bug zu debuggen, den man auch per Hand beheben könnte, und trotzdem 4 Stunden braucht, ist das Verschwendung
https://developers.openai.com/api/docs/guides/batch
Für Dinge wie spezifikationsgetriebene Entwicklung, bei denen Menschen nicht ständig im Loop sind, sondern nur über dem Loop kontrollieren, ist dieser Ansatz viel natürlicher, aber zumindest meiner Erfahrung mit Google-Frontends nach habe ich bisher kaum gute Unterstützung dafür gesehen
Was gerade passiert, war für viele ziemlich offensichtlich. Es ist, als würde man einem neuen Süchtigen, den man absichtlich abhängig machen wollte, sagen, er solle doch bitte etwas vorsichtiger konsumieren — das wird wahrscheinlich nicht besonders gut funktionieren
Ich nutze AI nicht gern und finde auch nicht, dass sie mir besonders hilft
Aber meine Firma zwingt uns zur Nutzung und verfolgt die Kennzahlen, also werfe ich jeden Tag sinnlose Kleinarbeit darauf, damit es so aussieht, als hätte ich sie verwendet
Selbst wenn ich dadurch mehr Probleme erzeuge als löse, gelte ich in den Metriken trotzdem als jemand, der AI nutzt
Wenn irgendein Unternehmen ankündigt, den Token-Verbrauch als Signal für die Leistung von Mitarbeitenden zu verwenden, ist das für mich fast schon ein Warnsignal, diese Firma zu meiden
Ein Unternehmen mit guter technischer Führung sollte das nicht als auch nur annähernd vernünftige Idee behandeln
Aber wenn man 500 Dollar an AI-Tokens unproduktiv verbrennt, gilt man im Unternehmen sarkastisch als Top-AI-Adopter
In manchen Firmen wird Entwicklern sogar gesagt, man wolle künftig keine einzige Codezeile mehr sehen, die sie selbst geschrieben haben
Aus Sicht von Führungskräften klingt das vermutlich so: Wenn die besten 20 % der Mitarbeitenden mit LLMs 80 % des Codes erzeugen und das Unternehmen trotzdem weiterläuft, kann man die unteren 80 % der Entwickler abbauen und Kosten sparen
Die Verwendung des Token-Verbrauchs in Mitarbeiterbewertungen ist nur eines davon
Unter dem gewaltigen Fusionsreaktor am Himmel gibt es nur wenig wirklich Neues
In James Gleicks „The Information“ habe ich über eine Art Tokenmaxxing in der Telegrafie gelesen
Für Telegramme wurde pro Zeichen abgerechnet, daher gab es einen großen Markt für Codebücher, mit denen sich die Zahl der zu sendenden Zeichen reduzieren ließ. Kompression war gleichbedeutend mit Geld, und die Telegrafengesellschaften mochten das nicht, mussten es aber akzeptieren
Diese Telegrafencode-Industrie begann schon früh in der Kommerzialisierung der Telegrafie und hielt bis in die 1920er Jahre an
Allerdings hatte das auch Kosten. Die Codes reduzierten Redundanz stark, und schon sehr kleine Fehler konnten zu großen Missverständnissen führen
Wie Gleick beschreibt, war das genau das Gegenteil davon, wie afrikanische Trommelsprache Redundanz hinzufügt, um die Beziehung zwischen Rhythmus und der von den Trommeln nachgeahmten Sprache zu stärken
Also würde derjenige gewinnen, der die meisten Tokens oder die höchsten Kosten verursacht, und nicht der Programmierer, der Funktionen ausgeliefert hat
Das Beschriebene kommt eher Token-Minimierung als Tokenmaxxing nahe
Das habe ich mich schon vor LLMs immer beim Software-Stack gefragt, und jetzt scheint es noch relevanter zu sein
Wann ist ein Unternehmen wie Uber eigentlich „fertig“? Es entwickelt seit 16 Jahren Software.
Es ist ein Unternehmen, das Fahrer und Fahrgäste zusammenbringt, und nur weil es mehr Software baut, werde ich nicht plötzlich viel eher Uber statt Bus oder Bahn nehmen.
Ist Software in 20 Jahren fertig? Oder in 80?
Dazu kommen sich verändernde Regulierungen und neue Produkte. Man muss sich nur anschauen, wann Uber Eats dazugekommen ist.
In diesen 16 Jahren gab es Covid-19, praktikables autonomes Fahren und die Partnerschaft mit Waymo.
Eine netzwerkgebundene Consumer-App kann ohne perfekte Voraussicht niemals „fertig“ sein.
Der interne Tech-Stack ist wie ein lebender Organismus, und selbst um einen äußerlich unverändert wirkenden Service am Laufen zu halten, ist enorm viel Arbeit nötig. Skalierung ist ebenfalls riesig, und Skalierung und Wartung treiben sich gegenseitig immer weiter an.
Jedes Land hat eigene Gesetze dazu, was Uber tun darf und was nicht, und das muss in Code formalisiert werden.
An manchen Orten bestellt man über die Uber-App in Wirklichkeit ein Taxi, und der Fahrpreis ist möglicherweise nicht vorab festgelegt, sondern wird pro Meile berechnet.
Dazu kommen Gesetze auf Stadtebene. Was passiert, wenn man mit Uber von Ort A, wo andere Regeln gelten, nach Ort B fährt? Ein Anwalt kennt die Antwort, aber die App muss sie umsetzen.
Und die Gesetze ändern sich ständig.
Auch die Optimierung endet nie. Geschwindigkeit, Kosten, Routen — es gibt immer etwas zu verbessern.
Als Konsument sieht man nur einen winzigen Ausschnitt der Komplexität, die solche Dienste aufbauen und betreiben müssen.
Und fast immer gibt es Bugs, die behoben werden müssen. Sehr viele Bugs.
Das ist auch ein Problem von Unternehmen mit gewaltiger Finanzierung. Der Wert von Uber basiert nicht nur auf dem, was es heute tut, sondern auf der Erwartung, dass es Konzepte wie privaten Autobesitz oder die Nutzung öffentlicher Verkehrsmittel veraltet wirken lassen wird.
Das ist übertrieben, aber weniger übertrieben, als es zunächst klingt.
Tokenmaxxing ist Unsinn. Das ist, als würde man bewusst ineffiziente SQL-/Spark-Jobs schreiben, um möglichst viel Compute, Speicher und I/O zu verbrauchen.
Man würde absichtlich Dinge wie kartesische Produkte oder extrem unausgewogene Datensätze en masse einbauen.
So etwas passiert immer, wenn eine Kennzahl zum Ziel wird. Unternehmen sollten ein Umfeld fördern, in dem AI möglichst effizient eingesetzt wird, und zuerst fragen: „Braucht diese Aufgabe wirklich einen Agenten?“
Wenn ja, muss man festlegen, welcher Agent, welches Modell und welches Inferenzniveau nötig sind.
Man sollte auch dazu anhalten, Tokens zu sparen, die Cache-Hit-Rate zu erhöhen und Informationen so zu strukturieren, dass sie mit weniger Kontext nutzbar sind. Knowledge Graphs sind dafür ziemlich gut.
Das ist ungefähr so, als würde man eine Tankstelle anzünden, um ein Rennen zu gewinnen.
Es ist einfach eine Methode, alle dazu zu bringen oder dazu zu zwingen, mit neuer Technologie zu experimentieren.
Sobald alle als AI-nutzend gelten, wird so etwas wie Tokenmaxxing natürlich verschwinden.
Ich habe viele Anwendungsfälle gesehen, bei denen fraglich war, ob überhaupt Wert entsteht, aber ich habe auch Teams gesehen, die alte Probleme mit agentischen Workflows gelöst haben, die sich vor einem Kostenprüfungsgremium kaum hätten rechtfertigen lassen.
Arbeiten wie Token-Einsparung, höhere Cache-Hit-Raten und Informationsstrukturierung für weniger Kontext werden meinem Verständnis nach in den meisten großen Tokenmaxxing-Unternehmen ohnehin separat im Hintergrund von eigenen Teams betrieben.
Ich verstehe schon, warum Unternehmen Geld in AI-unterstützte Entwicklung stecken. Aber wie sieht der gesamte Return on Investment aus? War es wirklich so viel wert wie die behaupteten Effizienzsteigerungen?
Das ist eigentlich der einzig wirklich interessante Punkt am AI-Hype, und ich verstehe nicht, warum kaum jemand darüber spricht.
Mit Claude kann man pro Tag fünf nutzlose oder schlechte Features bauen, oder in zwei Tagen ein nützliches Feature. Was wirkt sich besser auf den Return on Investment aus?
Am Beispiel wirkt die Antwort einfach, aber in der Realität ist es viel nuancierter und viel schwerer zu messen.
Deshalb entscheiden sich viele Unternehmen offenbar für den einfachen Weg, auf den Hype aufzuspringen und auf Messung zu verzichten.
Ich bin überzeugt, dass die nachhaltig maximale Verbesserung durch AI-Nutzung in der Softwareentwicklung, inklusive sauberem Betrieb bis hin zum Code Review, für einen Senior Engineer mit angemessener Erfahrung ungefähr 20 % beträgt.
Kein Token-Budget eines Engineers sollte darüber hinausgehen.
Ich glaube nicht, dass Engineers mit Tokenmaxxing wirklich produktiv sind, und ich habe keinerlei Belege dafür gesehen. Eher das Gegenteil könnte der Fall sein.
Mit dem richtigen Workflow und Wissen über die Codebasis habe ich selbst gespürt, dass ungefähr dieses Niveau bei nachhaltigem Arbeitseinsatz erreichbar ist.
AI für Engineering-Produktivität wird offenbar weithin missverstanden als Zauberknopf, der dasselbe Ergebnis schneller und billiger liefert.
Wenn man so denkt, ist es nur logisch, Mitarbeitende zu Tokenmaxxing zu zwingen. Wenn man mehr Ergebnisse schneller und billiger bekommt, warum sollte man es nicht tun?
Nuancierter betrachtet ist es so: AI hilft dabei, die Roadmap etwas schneller umzusetzen, aber dabei entsteht Tech Debt, ähnlich wie wenn man temporäre Entwickler anheuert, um Features zu bauen.
Es ist nicht einmal garantiert, dass es im Team jemanden gibt, der den neuen Code wirklich versteht.
Ebenso nimmt der Kompetenzzuwachs bei Junior-Teammitgliedern ab. Es wird schwerer, die frühere Arbitrage zwischen Kompetenz und Gehalt mitzunehmen.
Auch das Produkt kann komplexer werden. Es gibt einen Grund, warum P2-Features P2 sind; durch AI können Features mit niedrigem Grenznutzen trotzdem hineingeraten und das Produkt verkomplizieren.
Ich bin schockiert, dass überhaupt jemand dachte, Tokenmaxxing sei eine gute Idee.
AI-Maximalisten vergleichen diese Technologie gern mit Elektrizität. Man stelle sich vor, in der Frühzeit der Elektrifizierung hätten CEOs Mitarbeitende für steigenden Stromverbrauch belohnt, statt dafür, Wege zu finden, mit Elektrizität Geschäftsergebnisse zu erzielen.
Damals war es üblich, Menschen mit Anzeichen psychischer Erkrankungen in Anstalten einzuweisen, und vermutlich wäre genau das das Ende dieser Geschichte gewesen.