--- schema: "swft.publication/v1" id: "company-uber" title: "Inside Uber's AI software factory: measuring cost and quality at scale" description: "How Uber measures its AI software factory with outcome-based costs, quality guardrails, agent skills, managed workloads, and human review." summary: "Uber's public account shows how a large company can measure agent work as a system. It tracks accepted results, cost, quality, reusable skills, and managed workloads together. Google and METR add useful ways to evaluate behavior and autonomy, while every figure keeps its original evidence boundary." canonical: "https://swft.io/companies/uber-software-factory" author: "SWFT Editorial" author_type: "Organization" published: "2026-09-01" modified: "2026-09-02" kind: "case-study" section: "Companies" tags: ["Uber AI software factory", "coding agents at Uber", "cost per accepted result", "agent skills", "AI engineering metrics"] evidence_labels: ["INFERENCE", "OBS", "SELF-REPORT", "STUDY"] source_ids: ["augment-cosmos", "google-agent-behavior-taxonomy", "google-agent-proactivity", "metr-time-horizons", "ona-software-factory", "openai-symphony", "strongdm-software-factory", "uber-efficient-software-factory", "usaf-software-ecosystem", "warp-factories"] authorship_disclosure: "AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections." --- # Inside Uber's AI software factory: measuring cost and quality at scale Uber connects coding-agent adoption with reusable skills, managed workloads, quality signals, and cost and quality per completed outcome. > **Editor's note:** This evergreen company case is the complete successor to Factory Watch 001. It retains that article's Uber economics, Google agent-behavior research, METR autonomy limits, and landscape distinction while removing the numbered-issue format. > **Authorship:** AI-drafted from the cited public sources and independently checked by a second AI editorial-review agent (Codex) for source fit, claim boundaries, overlap, and reader utility. SWFT Editorial is responsible for corrections. ## Quick answer Uber's public account shows how a large company can measure agent work as a system. It tracks accepted results, cost, quality, reusable skills, and managed workloads together. Google and METR add useful ways to evaluate behavior and autonomy, while every figure keeps its original evidence boundary. 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](https://www.uber.com/us/en/blog/efficient-software-factory/), 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](https://www.uber.com/us/en/blog/efficient-software-factory/) 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: 1. Did the agent produce something the team accepted? 2. How much did the agent run cost? 3. 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](https://www.uber.com/us/en/blog/efficient-software-factory/) 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](https://research.google/pubs/towards-ai-as-a-collaborative-partner-a-taxonomy-of-ai-agent-behavior-in-software-engineering/) groups enterprise expectations around process, code quality and reliability, problem solving, and collaboration. A second paper, [Agentic Coding Needs Proactivity, Not Just Autonomy](https://research.google/pubs/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](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/) 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](/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.” ## How we know - **First-party report (SELF-REPORT)** Uber reports agent-attributed PR share, skill count and usage, adoption growth, stable spend, factory layers, cost decomposition, and quality signals. Sources: [Running a Software Factory Efficiently at Uber Scale](https://www.uber.com/us/en/blog/efficient-software-factory/). - **Analysis (INFERENCE)** SWFT generalizes Uber's outcome-based units into cost per accepted result and treats governed skill ownership as a second transferable pattern for product leaders. Sources: [Running a Software Factory Efficiently at Uber Scale](https://www.uber.com/us/en/blog/efficient-software-factory/). - **Independent study (STUDY)** Google researchers propose taxonomies for collaborative and proactive coding-agent behavior, while METR measures task-completion reliability across human-equivalent durations and states translation limits. Sources: [Towards AI as a Collaborative Partner: A Taxonomy of AI Agent Behavior in Software Engineering](https://research.google/pubs/towards-ai-as-a-collaborative-partner-a-taxonomy-of-ai-agent-behavior-in-software-engineering/); [Agentic Coding Needs Proactivity, Not Just Autonomy](https://research.google/pubs/agentic-coding-needs-proactivity-not-just-autonomy/); [Measuring AI Ability to Complete Long Tasks](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/). - **Observed artifact (OBS)** Public software-factory material spans company operations, institutional programs, commercial platforms, experiments, and open implementations. Sources: [The StrongDM Software Factory: Building Software with AI](https://www.strongdm.com/blog/the-strongdm-software-factory-building-software-with-ai); [Software Factory](https://www.software-factory.dev/); [Air Force Software Ecosystem](https://software.af.mil/); [Cosmos: A Programmable Software Factory](https://www.augmentcode.com/product/cosmos); [Introducing Warp Factories](https://www.warp.dev/blog/open-infrastructure-for-building-a-software-factory); [Symphony](https://github.com/openai/symphony). ## Sources - **First-party report (SELF-REPORT)** [Cosmos: A Programmable Software Factory](https://www.augmentcode.com/product/cosmos) — Augment Code; accessed 2026-08-31. Official product surface for a programmable factory spanning event-triggered agent work, checkpoints, delivery, monitoring, and learning loops. - **Independent study (STUDY)** [Towards AI as a Collaborative Partner: A Taxonomy of AI Agent Behavior in Software Engineering](https://research.google/pubs/towards-ai-as-a-collaborative-partner-a-taxonomy-of-ai-agent-behavior-in-software-engineering/) — Google Research; accessed 2026-08-31. Research deriving enterprise expectations for coding-agent behavior from developer rules and interviews. - **Independent study (STUDY)** [Agentic Coding Needs Proactivity, Not Just Autonomy](https://research.google/pubs/agentic-coding-needs-proactivity-not-just-autonomy/) — Google Research; accessed 2026-08-31. Research proposing reactive, scheduled, and situation-aware levels plus measures of useful proactive behavior. - **Independent study (STUDY)** [Measuring AI Ability to Complete Long Tasks](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/) — METR; published 2025-03-19; accessed 2026-08-31. Study framing agent capability as a reliability curve over task duration rather than a binary autonomy claim. - **First-party report (SELF-REPORT)** [Software Factory](https://www.software-factory.dev/) — Ona; accessed 2026-08-31. Ona's public experiment and livestream series about the inputs, steering, and operation of software factories. - **Observed artifact (OBS)** [Symphony](https://github.com/openai/symphony) — OpenAI; accessed 2026-08-31. Open-source engineering preview for turning project work into isolated agent implementation runs with proof of work and protected landing. - **First-party report (SELF-REPORT)** [The StrongDM Software Factory: Building Software with AI](https://www.strongdm.com/blog/the-strongdm-software-factory-building-software-with-ai) — StrongDM; accessed 2026-08-31. StrongDM's public account of its software-factory operating model. - **First-party report (SELF-REPORT)** [Running a Software Factory Efficiently at Uber Scale](https://www.uber.com/us/en/blog/efficient-software-factory/) — Uber Engineering; published 2026-08-27; accessed 2026-08-31. Uber's account of factory layers, adoption, token economics, managed agents, quality signals, and context infrastructure. - **First-party report (SELF-REPORT)** [Air Force Software Ecosystem](https://software.af.mil/) — United States Air Force; accessed 2026-08-31. Accessible official index of current Air Force software organizations, platforms, and DevSecOps software factories. - **First-party report (SELF-REPORT)** [Introducing Warp Factories](https://www.warp.dev/blog/open-infrastructure-for-building-a-software-factory) — Warp; published 2026-08-18; accessed 2026-08-31. Official announcement of factory-as-code infrastructure spanning intake, agents, control, evaluation, measurement, and self-improvement. ## Read next - [Software factory metrics that matter](/software-factory-metrics) - [Cloudflare's AI engineering stack: a control plane for company-wide agents](/companies/cloudflare-ai-engineering-stack) - [Methods and corrections](/methods)