How Uber Transforms AI Programming into a Scalable Software Factory
Uber’s engineering blog reveals how the company embeds AI agents across the entire software lifecycle—covering code review, CI fixes, alert triage and routine maintenance—by defining a four‑layer agent model, breaking cost into six variables, and applying Pareto‑efficient model routing to keep usage growth from exploding the bill while delivering measurable productivity gains.
Why massive usage growth didn’t blow up the bill
Official data show that from February to mid‑August 2026, weekly active users of Uber’s Agent products grew 7× and weekly Agent requests grew 9.4×, yet overall AI spend remained stable after April. Because workload, model mix and model versions changed month‑to‑month, Uber performed a fixed‑model comparison: from February to July, cost per 1,000 model requests fell 34% and cost per session fell 52% relative to the June peak.
1. Defining the software factory: four layers of Agent usage
Uber organizes AI usage into four ascending layers, with higher layers giving tighter control over cost, quality and model choice:
Interactive sessions : engineers collaborate with an Agent directly in a terminal or IDE.
Skill and work mode : high‑frequency operations, tool calls and common steps are packaged as reusable capabilities.
Hosted Agent : the system automatically initiates work for a defined engineering task while preserving a human review and escalation path.
Software factory : the above capabilities are placed in a unified runtime that centrally manages models, tools, permissions, environments, evaluation and cost.
The goal is not to remove developers from the process but to turn “one engineer opening a chat window” into “multiple well‑defined, observable automation units”.
2. Don’t just ask the model price: split total cost into six variables
Uber models total AI spend as a product of six factors:
Total spend = Users × Sessions per user × Rounds per session × Requests per round × Tokens per request × Token price
The first two factors (adoption and participation) naturally grow; the real optimization targets are the middle three factors and the token price. Inefficient Agent work—extra searches, retries, or unnecessary context—often costs more than the user’s original query.
Uber tracks a full suite of metrics (requests per user, cost per thousand requests, token counts, cost per thousand sessions, cache hit rates, model‑wise cost breakdowns, etc.) to feed short‑ and long‑term forecasting and planning.
3. Model selection based on Pareto efficiency
Instead of picking the strongest model, Uber chooses the Pareto‑optimal point that balances task cost, output quality and model reliability. Each hosted Agent follows four steps:
Build a benchmark using real work for that Agent.
Run multiple models—including frontier and open‑weight models—in a unified harness.
Select the current Pareto‑optimal model and re‑run as models evolve.
Aggregate performance and continue testing dynamic routing strategies.
For the AI code‑review tool uReview , Uber created a benchmark with real PRs containing known defects, classified them as easy, medium or hard, and recorded precision, recall, F1, per‑review cost, latency, timeouts and noise. After switching to a Pareto‑optimal model, uReview’s F1 improved and per‑PR cost dropped significantly.
Uber also built the internal Uber SWE Benchmark using thousands of real PRs from its monorepo to evaluate frontier and open‑weight models across various SDLC tasks.
Default models reshape cost structure
Token price does not change per setting, but tokens are allocated to different models. The two biggest levers are the primary model at session start and the default model for sub‑Agents. Sub‑Agents handle well‑bounded, deterministic tasks and therefore use cheaper models while retaining human oversight.
Uber’s rule: Put expensive inference on the “decision‑how‑to‑split” step and delegate bulk execution to a cheaper, sufficiently capable model.
4. Every round re‑transmits history: token/request optimization is more basic than imagined
Each Agent round typically re‑sends the full conversation history, project context and tool results. Reducing payload size per round compounds savings over session length.
Uber sets two default values to cut tokens:
400 K automatic compression : even if a model supports a 1 M token context, compression triggers at 400 K tokens to balance performance, cache bursts and duplicate input cost.
Default “Medium” reasoning effort : the output token count (including internal reasoning) is billed at a multiplier above the input token count; “Medium” offers a cost‑quality trade‑off for large workloads.
Prompt cache: shorter TTL isn’t always cheaper
Prefix‑cache hits reduce input token cost to 0.1×, but cache writes cost more: a 5‑minute cache is 1.25× the standard input price, a 1‑hour cache is 2×. Different vendors offer different TTLs (Anthropic: 5 min/1 h, OpenAI: 30 min).
Because engineers often idle interactive sessions for >5 minutes, Uber extended the interactive session TTL to 1 hour while keeping sub‑Agent TTL at 5 minutes.
5. More MCP tools mean a thicker “tool spec” in the Agent’s initial context
Uber’s MCP gateway consolidates >1,000 internal and third‑party SaaS tools. Loading all tool schemas for every session would add 50 K–70 K tokens per prompt and be retransmitted each round.
Uber mitigates this with two complementary approaches:
CLI tool resolution : the model executes shell commands; the CLI dynamically resolves and runs the tool only when invoked, keeping the 1,000+ tool definitions out of the session context.
Tool search : the model first searches the tool directory and loads only the needed definitions, reducing token load and preserving selection accuracy.
Code‑Mode: keep “chatty tool protocols” in a subprocess
If a tool can be called via shell, the model can script batch actions. For example, a SQL query normally requires 2–5 polling rounds, each adding model rounds and context. Code‑Mode runs the entire loop in an automated Python subprocess, returning only a summary to the model.
In a side‑by‑side test of five identical SQL queries, Code‑Mode cut token usage by >50% and, for batch operations, reduced model rounds by >90%.
Third‑party SaaS MCP: full‑function exposure inflates schema
A workspace suite bundling 49 tools contributes ~22 K tokens of schema; other products add 34–46 tools each. After loading two or three servers, the Agent’s pre‑loaded schema can exceed the size of the file being edited.
Uber exposes third‑party SaaS tools through the unified gateway as CLI commands and writes dedicated Code‑Mode skills for each server, packaging common flows.
6. An agent lacking context fails slowly and expensively
“An ungrounded agent fails slowly rather than cheaply.” Without relevant information, an Agent keeps searching, issuing extra requests and spawning sub‑Agents, inflating context and cost until time and money run out.
Uber built an AI Context Graph with 24 M nodes, 80 M edges, 86 node types and 117 edge types, ingesting data from >30 internal systems (services, teams, incident logs, PRs, architecture docs, deployments, datasets, etc.). Any Agent can query it in natural language.
When the graph is available, the same prompt is answered correctly in 38 seconds; without it, the Agent spends 20 minutes, spawns two sub‑Agents, makes three errors and incorrectly declares the dataset unqueryable.
7. Don’t only look at month‑end bills: embed cost into every development decision
Uber surfaces cost information in real time through several mechanisms:
Status‑bar real‑time counter : shows current harness and user spend.
Harness pool : all interactive harnesses share a consumption tier; hosted Agents have a separate tier.
Slack alerts : notify at 50%, 80% and 100% of expected spend.
Fast approval : manager confirmation for tier increases, applied quickly.
Cost‑check skill & hints : dashboards display cost breakdowns and efficiency suggestions.
The status bar can answer “how much was spent” but not “why it was expensive”. Uber therefore embeds a session‑analysis dashboard that automatically identifies 16 anti‑patterns (e.g., sub‑optimal model routing, context window bloat, cache expiry inefficiency, oversized initialization) and provides financial impact and remediation advice.
8. Next steps: turn hosted Agents into a self‑improving team
Expand the hosted Agent team: each new Agent gets a target metric, a benchmark, and a Pareto‑optimal model.
Dynamic model routing: broaden benchmark coverage across languages, codebases and Agent modalities.
Deeper context‑graph integration: give more autonomous Agents direct graph query ability.
Upgrade session analysis to real‑time developer guidance: move from batch anti‑pattern discovery to continuous trace monitoring and personalized efficiency tips.
Continuous skill improvement: capture papercuts during Agent execution and auto‑generate skill updates from collected traces.
The article also references the “Agentic SDLC at Uber” talk by Uday Kiran Medisetty and Adam Huda (≈18 min 25 s).
One diagram: what the factory actually closes
My judgment: the barrier is not model count but measurable operational discipline
Uber’s infrastructure—billions of lines of code, thousands of tables, a massive graph, unified MCP gateway, real PR benchmarks and extensive platform resources—is hard for most teams to replicate. However, the most valuable parts do not depend on that scale. Smaller teams should first turn high‑frequency tasks into real benchmarks, clean up per‑round payloads, and host clearly bounded processes before attempting large‑scale tool or graph investments.
Risks include outdated or mis‑scoped graph relationships leading to wrong answers, cost alerts being used merely to cut spend and thereby suppress necessary reasoning depth, and weak default models without upgrade paths causing “cheap” to be mistaken for “efficient”.
Ultimately, a software factory is a set of disciplined automation units, each with a clear goal, real benchmark, quality metric, cost attribution, observable trace and human escalation path. When an organization continuously turns real work into measurable data and feeds that back into routing, context, skills and runtime, it builds a factory that gets more stable the more it runs.
Acknowledgements
Thanks to the core members who built the Software Factory and to the leadership team for guidance.
Sources
Official article: https://www.uber.com/us/en/blog/efficient-software-factory/
Official entry: https://x.com/UberEng/status/2093444169037762840
Official talk: https://www.youtube.com/watch?v=17-YSUHo6Lk
Author: Uday Kiran Medisetty
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Design Hub
Periodically delivers AI‑assisted design tips and the latest design news, covering industrial, architectural, graphic, and UX design. A concise, all‑round source of updates to boost your creative work.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
