Just a few months ago, a headline about Uber captured better than many reports the moment artificial intelligence is going through inside companies: the firm appears to have burned through its annual AI budget ahead of schedule because of the massive adoption of AI-assisted coding tools. The headline is powerful because it brings together two realities that now coexist in tension: on the one hand, the sense that AI multiplies productivity; on the other, the realization that this productivity is not free and that, if it is not governed properly, it can send operating costs soaring at a disturbing speed.

That is, in fact, the core of the problem many organizations are only beginning to face. They have learned how to incorporate generative models into their workflows, but they have not yet learned how to think about them economically. They understand the promise, they sense the return, and they experiment with enthusiasm, but they still tend to budget for these tools as if they were traditional software. They are not. As use cases grow and functional dependence on AI increases, what comes into play is no longer just output quality, but the sustainability of its cost in the short, medium, and long term.

That is why the important debate is not whether AI pays off or not. The relevant question is another one: how to design an AI-powered work architecture that is useful, scalable, and still economically manageable. That is where Uber’s case becomes interesting, not so much because of the spectacle of the headline, but because of the deeper lesson it reveals.

Uber as a symptom of a changing model

Uber is a major technology company in mobility, delivery, and digital services, with a corporate structure made up of tens of thousands of employees worldwide. When an organization of that size decides to bring AI tools into the core of its technical operations, it is not running a lab test: it is altering the way it produces, develops, and makes decisions.

The adoption of AI-assisted coding tools grew very quickly inside the company until it reached thousands of software engineers using them every day. At the same time, the use of these tools did not remain limited to anecdotal or experimental tasks, but became integrated into recurring development processes. When this kind of adoption takes place at scale, cost stops depending on how many people have access to a tool and starts depending on how intensely that tool is used.

That nuance is essential. The problem is not that Uber used AI, but that its effective adoption exceeded the mental model with which the budget had probably been designed. If a company calculates spending in terms of licenses or seats, but the real cost depends on the volume of tokens consumed, the length of processed context, and the number of calls executed by agents, misalignment will eventually appear. And when the tool works well, that misalignment accelerates even further. In reality, what UBER is doing is selling a success story, let’s not kid ourselves.

Why an LLM cannot be managed like conventional software

For years, companies have learned to live with a relatively predictable software ecosystem. They contract tools, assign users, negotiate licenses, and work with reasonably stable monthly or annual costs. That model has worked well for CRMs, ERPs, creative tools, office resources, collaboration platforms, and most of the usual corporate productivity solutions.

Generative AI, by contrast, breaks that logic. Here, companies do not pay only for access to a platform, but for each inference process, for every fragment of processed context, and for every output generated. Put very simply: they are not just paying to enter the tool, but every time they make it think, read, calculate, or write.

This difference is decisive because it introduces three sources of budget pressure. The first is the size of the model and the context window: the more information loaded into each query, the more resources are consumed. The second is the shift from the simple conversational assistant to agents that operate more autonomously, chaining actions, consulting sources, and executing complex processes. The third is the extreme variability of use: two people working with the same tool can generate radically different monthly costs depending on the nature of what they ask from it.

From a financial point of view, this looks less like buying office software and more like managing computing infrastructure. Companies need to think in terms of usage peaks, operational efficiency, workloads, and consumption limits. It is a different budgeting culture, and the sooner organizations assume that, the better.

When productivity also makes operations more expensive

The idea that we are becoming dependent on AI describes a fairly tangible reality, one that is no longer denied in offices and meeting rooms. When a tool reduces friction, shortens deadlines, and raises output capacity, teams incorporate it into their routine with surprising speed. At first, it is a punctual help; shortly afterward, it becomes a central piece of the way work gets done. It creates dependence, and anyone who has already logged enough hours working hand in hand with LLMs knows that going back to how we worked four or five years ago feels mentally impossible.

This is happening both in large corporations and in mid-sized companies. Writing, summarizing, analyzing, coding, documenting, researching, or preparing deliverables are all activities that can now be accelerated significantly with AI. What is often underestimated is that every perceived gain in productivity tends to generate more use, and more use means more consumption of computational resources.

In that sense, Uber’s case is useful because it puts an uncomfortable truth on the table: a tool’s success can also become a cost problem. When technology is good enough that teams use it for almost everything, the issue stops being adoption and becomes governance. That is where many companies have not yet arrived, but they are heading there downhill and without brakes. The problem will surface, and they will have to deal with it sooner rather than later.

Budgets can no longer be built by counting users alone

If a company wants to scale its use of AI, it has to learn how to budget differently. The relevant unit of measure is no longer just the number of users, but the volume of tokens consumed and the type of workload being executed. A short query does not cost the same as a process that analyzes extensive documentation, goes through several intermediate steps, and generates a complex response. Asking for a markdown file is not the same as asking for a PDF, to illustrate the point with a very concrete example.

This forces organizations to work with new and varied scenarios. They need to distinguish between light and intensive use, between one-off flows and recurring automations, between simple assistants and agents capable of orchestrating multiple actions. This way of thinking is still new to many organizations, but it is essential if they want to prevent a successful pilot from turning into an expensive operational mess that is hard to sustain. Anyone who feels entitled to throw the first stone is probably also revealing that they do not really have many flight hours wrestling with AI models.

The situation also forces companies to review the mix of models they use. Not every task needs the best model available or the largest context window. In many cases, a significant portion of cost comes from having oversized the solution. Once the most powerful model becomes the default option for everything, the budget begins to erode without the organization always getting a proportional return.

Usage efficiency: where a large share of margin is decided

A considerable part of the extra cost associated with AI does not come so much from the technology itself as from poor design decisions. In companies, it is common to prioritize getting a process to work quickly and proving that the use case is viable. The problem is that once the system is already running, not enough time is often devoted to optimizing it.

That is an understandable mistake, but it is an expensive one. Many routine tasks can work perfectly well with cheaper models, narrower context, and simpler flows. And yet, teams often operate at maximum power by default, as if every request required the highest possible level of sophistication. That inertia is comfortable and often feels great, but it is usually inefficient.

Designing intelligent usage patterns means, among other things, reserving the most demanding models for the cases that truly require them, limiting context when it does not add clear value, and reusing intermediate results whenever possible. It also means organizing documentation better, defining projects more clearly, and building environments in which the tool does not have to rediscover the same knowledge over and over again. When this is done well, costs do not just fall: system coherence and work quality improve too.

Without visibility into consumption, there is no real control

Another common mistake is to think that AI spending can be reviewed with the same calm as other software expenses. It cannot. Usage variability can be so high that what looks like a minor change in a workflow can double or triple consumption in just a few hours.

That is why real-time monitoring is not a luxury but a necessity. Companies that want to operate with AI in a mature way need dashboards that make it possible to see cost per user, per team, per project, and even per agent. Not out of an obsession with control, but because without visibility it becomes very difficult to correct deviations before they turn into real problems.

That monitoring should be accompanied by concrete limits. Spending caps, consumption alerts, periodic audits of prompts, workflow reviews, and clear oversight of which processes are generating value and which are simply consuming resources. AI can be highly profitable, but only when an organization knows how to distinguish between intensive use and intelligent use.

A challenge that does not belong only to the big players 

This challenge may be even more relevant in mid-sized or smaller companies. A large corporation can absorb a major budget deviation more easily because it has more financial muscle, more room for error, and more capacity to absorb the economic cost of expensive learning processes. In smaller organizations, by contrast, poor cost sizing can directly affect the profitability of a service, the margin of a project, or the viability of an entire line of work.

The risks, in essence, are the same. It is easy to underestimate what happens when a pilot becomes a real deployment. It is also common for teams, once they discover the practical usefulness of AI, to increase usage organically and continuously. On top of that comes another difficulty: models evolve very quickly, their capabilities change, usage patterns shift, and the cost profile can vary in very little time.

That is why any company that wants to integrate AI seriously needs something more than enthusiasm and attractive tools. It needs operational judgment, follow-up discipline, and a realistic understanding of what it costs to produce with artificial intelligence once it stops being a trial and becomes work infrastructure.

The underlying lesson is clear. Implementing AI in a company is not only about opening accounts, trying models, and celebrating the first productivity gains. It is about understanding that every automated process, every deployed agent, and every added layer of intelligence also expands the need to govern consumption more effectively. In this field, tokens are not a technical detail: they are a central business variable.