Uber's software factory is a procurement test

Uber says more than 70% of its pull requests are now attributed to agents while AI usage has grown 9.4x on roughly stable spend. The important change is not the headline percentage: it is the move toward cost per completed outcome, the unit economics that enterprise procurement will have to demand from agent vendors.

The most important sentence in Uber's new software-factory post is not “more than 70% of pull requests.” It is “outcome-denominated cost.”

On August 27, Uber Engineering published the clearest account yet of what happens when agents stop being a developer convenience and become part of the production workforce. More than 70% of Uber's pull requests are attributed to local or cloud agents. Employees have built more than 3,600 agent skills, and those skills run more than 30,000 times a day. From February to mid-August, weekly active users of Uber's agent tools grew sevenfold and weekly requests grew 9.4 times, while total AI spend had roughly stabilized since April.

Those are useful numbers, but they are not the conclusion. “Attributed to” does not mean “shipped without a human.” Uber says its managed agents handle code review, failing CI jobs, end-to-end pull requests, on-call triage, debugging, and maintenance with human reviews and escalations. The 70% figure measures agent participation in the pull-request pipeline, not autonomous software delivery.

The conclusion is that Uber has changed the unit at which it manages engineering automation. It is no longer asking only how many engineers have access to a model or how many tokens a team consumes. For managed agents, it tracks cost per merged pull request, cost per review, cost per alert, and cost per cleanup alongside quality signals such as revert rate, F1, and mean time to resolution.

That is a procurement model hiding inside an engineering blog post.

The buyer's unit is changing

Enterprise software procurement was built around a human-shaped unit: a seat. A department forecasts headcount, buys licenses, and reviews utilization. The model is legible because employees are countable and the subscription is predictable.

Agents break that alignment. An agent can run overnight, call several models, retry a failed tool invocation, retrieve a large context, and open a pull request without adding a person to the license count. Its cost depends on the shape of the work and the path it takes through the system. A “user” is not a sufficient accounting unit when the user can start a small workforce.

Uber's answer is to treat the agent's result as the billable object, even when the bill is internal. A code-review agent is not judged by its token volume; it is judged by the useful findings it produces at an acceptable cost and noise level. A CI-repair agent is not successful because it made a patch; it is successful when the pipeline is repaired without creating a later failure. The operational question becomes:

> What does it cost to produce an accepted outcome, and does the quality of that outcome hold as the model changes?

That question is much harder than “What is the price per million tokens?” It is also the question a buyer can use.

What Uber actually measured

Uber's post includes an unusually helpful separation between adoption, usage, and efficiency.

Adoption grew: weekly active users across its agent offerings increased sevenfold from February to mid-August. Engagement grew faster: weekly agent requests rose 9.4 times. Yet total AI spend was relatively stable from April onward. Holding one model constant to isolate its own optimization work, Uber says cost per 1,000 model requests fell almost 34% from its peak and cost per session fell 52% from its June peak.

The fixed-model comparison matters. If Uber had compared February's model mix with July's model mix, cheaper models or model changes could have been mistaken for platform improvements. Holding one model constant does not make the result an independent audit, but it makes the direction of the comparison more intelligible.

The mechanisms are not mysterious. Uber routes different tasks to models based on workload benchmarks. Subagents doing bounded work default to cheaper models. Interactive sessions use longer prompt-cache lifetimes when engineers tend to leave them idle. Tool schemas are resolved through a CLI or search layer rather than loading more than 100 tools into every context. Code-mode batches tool calls in a subprocess so intermediate polling and large results do not repeatedly enter the model's context. A context graph connects services, incidents, pull requests, documents, datasets, and ownership information so an agent spends less time searching.

This is not a story about a magical model. It is a story about removing avoidable terms from a multiplying cost equation.

Uber describes the equation in terms of adoption, requests, input and output tokens, and the agent's own turns and errors. The implication for a buyer is straightforward: a vendor that quotes only token price is quoting one term in a system whose waste may live somewhere else. If an agent has to search five systems, retry three calls, and carry the raw output of a wide query through every subsequent turn, a lower token rate may not produce a lower cost per task.

The vendor side is catching up

One day before Uber's post, Google Cloud announced new billing and cost-management options for Gemini Enterprise. Customers can combine fixed per-user subscriptions with a pay-as-you-go option for agent workloads. Google also announced Flexible Savings Plans offering 10% savings for a one-year commitment and 20% for a three-year commitment, project-level monthly caps, anomaly detection, and a deferred-execution option that can reduce inference cost by up to half for eligible work that can wait.

These are not just pricing features. They are an admission that agent consumption has a different shape from ordinary software usage.

A seat subscription gives finance a predictable baseline, but it can leave a technical team with no clean way to run a bursty agent workload without buying unused capacity. Pay-as-you-go removes that commitment, but it replaces empty-seat risk with execution risk: a loop, retry chain, or unexpectedly long run can spend more than the initiating user expected. Google's project caps and alerts are therefore part of the product, not decorative admin controls. They are what make metered work buyable.

Deferred execution is even more revealing. It prices time as a variable. A document index, evaluation suite, code analysis job, or batch summary does not need the same latency as an interactive customer response. If the buyer can mark that work as deferrable, the provider can trade responsiveness for utilization and offer a lower price. The contract begins to describe not just what the model does, but when the work is allowed to happen.

The options also expose their limits. Google's pay-as-you-go edition is initially available only to select customers, and deferred execution is limited to select workloads. A 20% saving attached to a three-year commitment may be rational for a measured workload and reckless for an architecture still changing every quarter. Pay-as-you-go is not automatically cheaper; it is cheaper only when the workload's variability makes unused seats more expensive than execution risk.

The right comparison is not subscription versus consumption in the abstract. It is the buyer's workload against the buyer's failure modes.

The part most companies cannot copy

Uber's methods transfer more easily than its infrastructure.

The company says its model gateway handles more than 100 million model requests a day across more than 800 projects, with identity, PII redaction, safety checks, and cost attribution in the request path. Its MCP gateway exposes more than 1,000 tools. Its context graph connects tens of millions of nodes across internal systems. Its development environments are pre-provisioned so agents can start quickly, and its managed skills are benchmarked against real work.

Most companies do not have Uber's monorepos, platform team, internal telemetry, or years of investment in developer infrastructure. Copying the architecture diagram would be an expensive way to miss the point.

The portable piece is the accounting discipline:

• Define the accepted outcome before selecting the model.
• Build a benchmark from the organization's real tasks, not a public demo.
• Track cost per accepted outcome, not just cost per request.
• Measure failure recovery, human review, latency, and quality alongside volume.
• Make retries, tool calls, context growth, and model routing visible to the budget owner.

That list is also a procurement checklist. A vendor should be able to explain what it measures, what the customer can cap, how usage is attributed, and what happens when the underlying model changes. If a product cannot answer those questions, the buyer is not purchasing an agent workforce; it is purchasing an opaque variable-cost dependency.

The decision in front of Uber

Uber's next decision, over the coming 12 months, is whether its outcome-denominated operating model can support a larger managed-agent fleet without turning software throughput into software debt. The company says it is continuing to grow managed agents and refine dynamic model routing. That expansion should be gated by the measures Uber names but does not yet publish in absolute terms: revert rate, review quality, mean time to resolution, and cost per merged or otherwise accepted outcome.

This is where the 70% headline becomes less interesting. Increasing the share of pull requests touched by agents is easy to celebrate and difficult to interpret. If the share rises while accepted-task cost falls and quality holds, Uber has evidence of a durable production advantage. If the share rises while reversions, incidents, review noise, or human repair time rise, the organization has increased activity rather than productivity.

The disconfirming observation is therefore concrete: if Uber's published quality metrics deteriorate as agent participation grows, or if cost per accepted outcome rises after the current optimization gains flatten, the stable-spend story is adoption accounting rather than agent economics. A second test sits on the vendor side. If enterprises do not use Google's caps, anomaly detection, deferred execution, and consumption options—or if providers retreat from them because the demand is not there—the procurement-shift thesis will have been early.

For now, the evidence points in the other direction. Uber is measuring agents as recurring operators inside the software lifecycle. Google is giving buyers controls for workloads that no longer fit a seat plan. Neither proves that agents deliver net productivity in every organization. Together they show that the next argument will not be settled by model capability alone.

It will be settled by the contract between capability and cost.

Sources and topic-selection trail

This post was selected after the August 30 scan found two adjacent developments: Uber Engineering's August 27 account of its software factory and Google Cloud's August 26 announcement of flexible billing and cost controls for agent workloads. The primary evidence also includes Uber's earlier uReview code-review system and Google's Gemini Enterprise Agent Platform pricing documentation. For context, I used CIO's reporting on the pricing changes, InformationWeek's analysis of agent-driven SaaS pricing pressure, Harvard Business Review's analysis of the coming AI cost shock, and ZenML's LLMOps summary of Uber's architecture.

---

Model disclosure

This post was drafted with GLM-5.2 through Ollama Cloud; the model's parameter size is undisclosed or uncertain from the model name and the authoritative sources verified for this run. The model helped synthesize Uber's operational metrics and Google's pricing controls into a procurement argument with a concrete disconfirming test, while the research and source verification remained separate from the drafting step. A visible limitation is that the article relies on company-reported telemetry and does not independently verify Uber's quality or cost-per-outcome data, so the argument is stronger about the emerging measurement discipline than about the underlying productivity claim.