Uber offers one of the clearest public accounts of AI-assisted software development at large-company scale. Its useful contribution is a way to connect agent activity with the cost and quality of completed work.
What is Uber's software factory?
Uber describes a layered internal system for helping engineers plan, write, review, and maintain software with AI agents. The system includes local coding tools, cloud agents that can work in the background, reusable agent skills, company context, quality signals, and a central way to understand usage and cost.
In Running a Software Factory Efficiently at Uber Scale, Uber reports that local or cloud agents were attributed on more than 70 percent of its pull requests. It also reports more than 3,600 agent skills and more than 30,000 skill runs each day. These figures show internal adoption. They do not tell us what share of the code an agent wrote or whether an agent caused a productivity gain.
How does Uber measure the factory?
Uber reports outcome-based units such as cost per merged pull request, code review, alert, or cleanup. That is more useful than looking at tokens alone because a cheap run can still create expensive review, rework, or recovery.
SWFT groups those units under a broader house term: cost per accepted result. A result is a reviewed code change or another unit of completed work that the team actually accepts. Including human review, rework, and recovery in that cost is SWFT's recommended extension, not a definition Uber publishes.
The company also keeps quality signals near the cost calculation. In plain language, the scorecard asks three questions together:
- Did the agent produce something the team accepted?
- How much did the agent run cost?
- Did the result meet the team's quality bar?
This is unit economics for agent work. The unit is an outcome, not a model request. Uber's public article explains the shape of its measurement system, while its internal definitions and underlying data remain private.
Why do agent skills matter?
An agent skill is a reusable instruction or tool for a recurring task. A skill can teach an agent how Uber performs a particular migration, test, investigation, or operational step. Skills turn scattered know-how into a repeatable capability that can be shared across teams.
Thousands of skills also create a product-management problem. Someone must make useful skills discoverable, keep them current, retire weak ones, and understand whether usage leads to accepted work. A skill catalog without ownership can become another pile of stale documentation.
What does stable spend show?
Uber reports sevenfold growth in weekly active users from February through mid-August 2026 while total AI spend stayed relatively stable after April. The company connects this pattern to price routing, caching, efficiency, and workload management.
The result is promising because adoption and spend moved differently. It is still a company-reported operating pattern, not a controlled experiment. Public evidence does not isolate how much came from lower model prices, better routing, changed task mix, tighter limits, or improved agent behavior.
How should a team evaluate agent behavior?
Google Research's agent-behavior taxonomy groups enterprise expectations around process, code quality and reliability, problem solving, and collaboration. A second paper, Agentic Coding Needs Proactivity, Not Just Autonomy, separates agents that react to a request, run on a schedule, or respond to a situation.
These studies give teams a vocabulary for useful behavior. A passing patch is one part of the score. An eval can also ask whether the agent followed policy, used current context, explained its work, asked for help at the right time, and avoided creating unnecessary review. The papers do not establish that every proposed behavior predicts customer value. Each company still needs realistic tasks and scoring rules for its own work.
What do autonomy time horizons prove?
METR's time-horizon research estimates the probability that a model can complete benchmark tasks that take human experts different amounts of time. METR explicitly warns that benchmark movement is difficult to translate into real-world usefulness.
A claim such as “six hours of autonomy” needs a task type, success rate, review burden, and cost. The benchmark can compare reliability under one defined method. It cannot predict whether the work fits a company's product, codebase, permissions, or quality bar.
Why does SWFT separate company cases from the wider map?
The software-factory label now appears in company operating accounts, public experiments, government programs, commercial platforms, and open implementations. Those artifacts share ideas and have different evidence boundaries. SWFT's software factory map separates the categories so a vendor product, an internal operating system, research, and an open reference implementation do not become false peers. The categories are an editorial tool rather than a market standard.
What can a product team copy?
Start with the measurement contract before scaling access:
- Define an accepted result in language the product and engineering teams share.
- Include review, rework, and recovery in the cost of that result.
- Pair the cost with a quality guardrail such as defects, rollback, or acceptance rate.
- Let every summary number lead back to a specific run and outcome.
- Treat skills as owned product capabilities with users, versions, and retirement rules.
This makes the factory legible. Leaders can see whether automation removes effort, shifts effort to reviewers, or creates work that would not otherwise have been attempted.
What remains unknown?
Uber's article is a detailed first-party operating account. It does not publish the underlying dataset, an independent quality audit, review time per change, defect rates for agent-attributed versus other work, or a controlled comparison of product outcomes. “More than 70 percent of pull requests” is an attribution measure. It should not be restated as “70 percent of Uber's code is AI-written.”