Uber ist kein Unternehmen, das für vorsichtige Technologieausgaben bekannt ist. Der Konzern betreibt eine globale Vermittlungsplattform, optimiert Preise, Routen, Nachfrageprognosen und Fahrerallokation in Echtzeit. Software ist dort nicht Beiwerk, sondern Betriebssystem des Geschäfts. Umso auffälliger ist, wenn ausgerechnet Ubers President und COO Andrew Macdonald öffentlich sagt, KI-Ausgaben ließen sich zunehmend schwer rechtfertigen.
Der Satz ist nicht deshalb interessant, weil ein Manager eine Mode kritisiert. Interessant ist die Begründung: Macdonald sieht offenbar keinen belastbaren Zusammenhang zwischen steigender Nutzung von KI-Werkzeugen in der Entwicklung und klar messbaren Verbesserungen bei ausgelieferten Funktionen. Konkret geht es um wachsenden Tokenverbrauch bei Claude Code und die Frage, ob daraus mehr oder bessere Produkte für Nutzer entstehen. Nach Berichten hatte Uber sein jährliches KI-Budget bereits nach vier Monaten im Jahr 2026 ausgeschöpft. Macdonald sagte im Interview mit Rapid Response sinngemäß, die Verbindung sei noch nicht da; vielleicht werde implizit mehr ausgeliefert, aber es sei sehr schwer, eine Linie zwischen diesen Kennzahlen und etwa 25 Prozent mehr nützlichen Verbraucherfunktionen zu ziehen.
Das ist eine ungewöhnlich nüchterne Formulierung in einem Markt, der KI-Ausgaben meist über Produktivitätsversprechen verteidigt. Sie verschiebt die Debatte von Demo-Videos und internen Erfolgsmeldungen auf eine einfache operative Frage: Wer kann nachweisen, was die teuren KI-Werkzeuge tatsächlich im Entwicklungsprozess leisten?
Tokenverbrauch ist noch kein Produktivitätsnachweis
Viele Unternehmen haben KI-Coding-Werkzeuge in kurzer Zeit breit ausgerollt. Die Logik ist verständlich: Wenn Entwickler schneller Prototypen bauen, Boilerplate-Code reduzieren, Tests schreiben oder bestehende Codebasen durchsuchen können, wirkt die Ausgabe zunächst plausibel. Das Problem beginnt dort, wo Nutzung mit Wert verwechselt wird.
Tokenverbrauch ist eine Verbrauchskennzahl. Er zeigt, dass ein Modell abgefragt wurde. Er sagt nicht automatisch, ob weniger Fehler produziert wurden, ob Releases stabiler laufen, ob Wartungskosten sinken oder ob Nutzer ein besseres Produkt bekommen. Gerade in großen Engineering-Organisationen kann ein stark wachsender Verbrauch auch das Gegenteil anzeigen: viele Versuche, viel Reibung, viel Nacharbeit, schlechte Prompt-Disziplin, fehlende Wiederverwendung oder unklare Richtlinien.
Macdonalds Hinweis trifft damit einen Punkt, den viele Firmen intern kennen, aber selten offen formulieren. KI-Kosten sind oft leichter zu buchen als ihr Nutzen zuzuordnen. Cloud-Rechnungen lassen sich auf Teams, Projekte und Dienste verteilen. Bei generativen Entwicklungswerkzeugen ist die Attribution schwieriger. Ein Entwickler nutzt das Werkzeug für Recherche, Refactoring, Tests, Dokumentation, Fehlersuche oder Experimente. Am Ende steht ein Commit, ein Ticket oder auch gar nichts. Die Frage, welcher Anteil daran auf das Modell zurückgeht, bleibt unscharf.
Das Sicherheitsproblem liegt in der Unschärfe
Aus Sicherheitsperspektive ist diese Unschärfe mehr als ein Controlling-Problem. Wo Nutzung, Kosten und Ergebnisse nicht sauber verbunden sind, fehlt häufig auch die Kontrolle über Risiken. KI-Coding ist kein isoliertes Schreibwerkzeug. Es berührt Quellcode, interne Architektur, Testdaten, technische Dokumentation und Entwicklungsgewohnheiten. Selbst wenn keine sensiblen Daten absichtlich eingegeben werden, entsteht ein neuer operativer Kanal, der beobachtet, begrenzt und geprüft werden muss.
Die zentrale Frage lautet nicht nur: Was kostet ein Modellaufruf? Sondern: Wer darf welches Werkzeug in welchem Repository einsetzen? Welche Daten dürfen in Prompts landen? Werden generierte Änderungen anders geprüft als von Menschen geschriebener Code? Gibt es Regeln für Abhängigkeiten, die ein Assistent vorschlägt? Werden sicherheitsrelevante Vorschläge nachvollziehbar dokumentiert? Und wer erkennt, wenn ein Werkzeug zwar viel Aktivität erzeugt, aber die Fehlerquote oder Review-Last erhöht?
In klassischen Security-Programmen ist Messbarkeit kein Luxus. Sie entscheidet darüber, ob Kontrollen greifen. Bei KI-Werkzeugen in der Softwareentwicklung entsteht gerade eine neue Angriffs- und Fehlerfläche, ohne dass jedes Unternehmen schon passende Metriken besitzt. Wenn nur Token, Kosten und Nutzungsraten im Dashboard stehen, bleibt der Blick zu flach.
Die interne Rechnung wird härter
Uber steht mit diesem Problem nicht allein. Viele große Firmen haben KI-Budgets zunächst unter der Annahme freigegeben, dass sich Effizienzgewinne später zeigen werden. Das war in der frühen Phase politisch bequem: Wer KI nicht ausrollte, musste erklären, warum. Wer sie ausrollte, konnte auf Tempo, Lernkurven und Wettbewerbsdruck verweisen.
Diese Phase endet nicht abrupt, aber sie wird teurer. Je mehr Lizenzen, API-Nutzung und interne Integrationen anfallen, desto weniger reicht der Hinweis auf allgemeine Produktivität. Finanzabteilungen wollen belastbare Zuordnung. Sicherheitsabteilungen wollen Governance. Engineering-Leitungen wollen wissen, ob KI wirklich Durchsatz erhöht oder nur Arbeit verschiebt: vom Schreiben zum Prüfen, vom Suchen zum Korrigieren, vom Entwickeln zum Aufräumen.
Besonders heikel ist der Unterschied zwischen individueller Wahrnehmung und organisatorischem Ergebnis. Ein Entwickler kann sich mit einem KI-Assistenten schneller fühlen, ohne dass die Organisation messbar schneller ausliefert. Ein Team kann mehr Code produzieren, während Produktqualität, Review-Zeit oder Betriebslast schlechter werden. Für Plattformunternehmen wie Uber zählt am Ende nicht die Menge erzeugter Artefakte, sondern ob stabile Funktionen beim Nutzer ankommen und ob der Betrieb beherrschbar bleibt.
Claude Code als Symptom, nicht als Sonderfall
Dass in Macdonalds Aussage Claude Code genannt wird, macht die Debatte konkreter, sollte aber nicht als isolierte Kritik an einem einzelnen Werkzeug gelesen werden. Das Muster betrifft den gesamten Markt für KI-gestützte Entwicklung: Modelle werden tiefer in IDEs, Repositories, Dokumentationssysteme und Build-Prozesse eingebunden. Dadurch steigen Nutzenchancen und Kontrollbedarf gleichzeitig.
Je näher ein KI-System an produktionsrelevanten Abläufen arbeitet, desto wichtiger werden Grenzen. Unternehmen brauchen nicht nur Einkaufsrichtlinien, sondern technische Leitplanken: Logging, Kostenlimits, Zugriffsklassen, Datenfilter, Review-Pflichten und eine klare Trennung zwischen Experiment und produktionsnaher Nutzung. Ohne solche Strukturen wird aus einem Assistenzwerkzeug schnell ein Schattenprozess im Maschinenraum der Softwareentwicklung.
Das bedeutet nicht, dass KI-Coding wertlos ist. Die bessere Lesart ist strenger: Der pauschale Freifahrtschein läuft aus. Wer weiter hohe Summen ausgibt, muss zeigen, ob weniger Incidents entstehen, ob Sicherheitslücken früher gefunden werden, ob Onboarding schneller wird, ob alte Systeme besser wartbar werden oder ob Release-Zyklen tatsächlich profitieren. Das sind andere Kennzahlen als reine Modellnutzung.
Ein Warnsignal für die KI-Ökonomie
Macdonalds Aussage ist deshalb bemerkenswert, weil sie aus einem Unternehmen kommt, das datengetriebene Optimierung gewohnt ist. Wenn ein solcher Konzern Schwierigkeiten hat, den Nutzen bestimmter KI-Ausgaben sauber nachzuweisen, dürfte die Lage in weniger instrumentierten Organisationen kaum einfacher sein.
Die KI-Ökonomie steht damit vor einer unspektakulären, aber entscheidenden Prüfung. Nicht jede Ausgabe wird verschwinden. Nicht jedes Werkzeug wird gestrichen. Aber Budgets werden stärker an Nachweise gebunden. Für Anbieter von KI-Coding-Produkten ist das unbequem: Sie müssen nicht mehr nur Nutzung verkaufen, sondern belastbare Wirkung in komplexen Entwicklungsumgebungen.
Für Unternehmen ist der Punkt noch praktischer. KI im Engineering darf nicht wie ein unbegrenzter Nebenkostenposten laufen. Sie braucht dieselbe Disziplin wie Cloud-Infrastruktur, Security-Tools oder externe Dienstleister: klare Verantwortlichkeit, überprüfbare Ergebnisse, technische Kontrollen und die Bereitschaft, Nutzung einzuschränken, wenn der Nutzen nicht belegt ist.
Ubers Zweifel markieren keinen Abschied von KI. Sie markieren den Moment, in dem der interne Prüfstand wichtiger wird als das Versprechen. In der Softwareentwicklung ist das überfällig.
