Key Takeaways
- Over 70% of PRs are handled by local and cloud agents, with agents acting as the first line of development
- Automation runs at scale: more than 3,600 agent skills execute over 30,000 times per day
- Between February and mid-August 2026, weekly users grew 7x and agent requests grew 9.4x
Analysis
Table of Contents
- Key Takeaways
- What “Software Factory” Really Means
- The Numbers Behind the Scale
- Why Costs Stayed Flat in Agent-Based Development
- Design Considerations for Large-Scale Codebases
- Risks and Limits of Agent-Based Development
- Practical Application Points
- What to Try Right Now
- Frequently Asked Questions
- Reference Source
Agent-based development is now automatically handling over 70% of pull requests across Uber’s codebase. This is not simple code autocompletion—agents running both locally and in the cloud act as the first line of PR work. The operational metrics Uber has published put concrete numbers behind this shift.
The reason this case caught my attention is that it is less a “tool that writes code for you” and more an operating system that runs the entire PR pipeline. How Uber operates its software factory reveals both the scale and the cost structure of agent-based development at the same time.
What “Software Factory” Really Means
Uber calls its development system a “software factory.” The core idea is not a single agent, but a building-block design in which role-specific agents are stacked together. PR creation, review, merge candidates, and post-merge monitoring are all closed loops inside the agents. Humans are left with only the final gatekeeping role.
The Numbers Behind the Scale
More than 3,600 agent skills run over 30,000 times per day. From February through mid-August 2026, weekly users grew 7x and agent requests grew 9.4x. Over 70% of PRs are now handled by agents as the first pass.
| Metric | Value |
|---|---|
| Daily skill executions | Over 30,000 |
| Share of PRs handled by agents | Over 70% |
| Weekly user growth (Feb–Aug) | 7x |
| Agent request growth | 9.4x |
| Active skills | Over 3,600 |
| Cost curve (since April) | Remains flat |
Despite this explosive growth, the cost curve flattened after April. Usage and cost have been decoupled on the graph.
Why Costs Stayed Flat in Agent-Based Development
What Uber did to control costs is not a single trick. Around-the-clock optimization runs on every front: caching, routing, mixing of small and large models, and per-request token reduction. For practitioners, the most meaningful point is that cost was designed not to scale proportionally with usage.
The real issue in agent-based development is not model performance but how this decoupling structure is operated. The same pattern is observed repeatedly in real-world tooling contexts as well.
Design Considerations for Large-Scale Codebases
Running agents across an environment like Uber’s mix of monoliths and microservices requires three prerequisites. Codebase indexing and search infrastructure must be fast enough; PR-level permissions and accountability boundaries must be organized to a level that can be delegated to agents; and the human gate for final merge decisions must be unambiguous.
If any one of these is missing, the gains of automation turn into a net negative.
Risks and Limits of Agent-Based Development
Organizations that let agent-based development handle over 70% of their PRs take on new risks: the potential for security policies to be bypassed, ambiguity in accountability, and the paradox of “humans re-reviewing code produced by agent-based development.” Uber’s case shows what is possible, but what to control on top of it is something each organization has to answer for itself.
This multi-agent behavior is not unrelated to the spontaneous swarm patterns observed in the agent ecosystem.
Practical Application Points
- Codify which PR stages are delegated to agents and which remain human-gated.
- Plot cost and usage on the same graph to find the inflection point.
- Operate an internal standard for the agent skill catalog.
What to Try Right Now
- Pick 5 PRs from this week and note which stages could be replaced by agents.
- Plot usage and cost on one graph and mark an inflection point like April.
- Draft an initial agent skill catalog with no more than 10 items.
- Put together a one-page document for PR merge permissions and accountability matrix.
Frequently Asked Questions
Why can cost be decoupled from usage in agent-based development?
When optimizations such as caching, routing, and model mixing are applied continuously, per-token cost falls. In the Uber case, costs staying flat even as usage grew 9.4x is the result of this decoupling structure.
Which stages does Uber’s 70% PR automation cover?
It goes well beyond simple code generation, broadly covering PR creation, review, and merge candidate generation. The key assumption is that humans keep the final gate.
Can small and mid-sized organizations adopt agent-based development?
Yes. However, codebase indexing infrastructure and PR gate design must be prepared first for the automation to be meaningful. Starting at 10–20% rather than aiming for 70% out of the gate is more realistic.
What is the biggest risk as agent dependency grows?
Security policy bypass, ambiguity in accountability, and the cost of having humans re-verify agent outputs. If these three are not managed together, the gains of automation erode quickly.
Reference Source
This article was written after reviewing the following source: geeknews — How to Operate a Software Factory at Uber’s Scale Efficiently
Expert Commentary (AI)
LLM Systems Engineer
What the usage-cost decoupling proves: the battleground in agent development is the inference platform, not the model
The decoupling of usage growth from the cost curve is the most honest metric for measuring the maturity of an agent operations platform, and the combination of caching, model routing, and token reduction is the canonical composition of LLM inference optimization. If costs stayed flat even as requests grew 9.4x, it is highly likely that cache hit rates and small-model delegation ratios have reached a substantial level—results at the platform level that cannot be achieved through one-off prompt tuning. However, as small-model delegation increases, silent degradation in PR creation and review quality becomes more likely, and without quality-weighted metrics such as acceptance rate, rollback rate, and post-merge defect rate, it is impossible to tell whether cost savings are cannibalizing quality. Managing the freshness of skill and context caches in a rapidly changing large codebase is also a practical challenge; if this breaks down, optimization gains return as rework costs. Even so, layering an orchestration layer on top of heterogeneous models to control unit economics is a direction that is likely to become standard infrastructure, like CI/CD.
Software Engineering Expert
Delegating 70% of PRs to agents is promising, but without accountability and verification structures complete, the bottleneck has been moved rather than removed
A structure in which agents take the first line from PR creation through review, merge candidates, and post-merge monitoring while humans hold the final gate is a natural next stage of evolution for modern development organizations where code review is the bottleneck. Running a skill catalog as an internal standard to prevent tool fragmentation and codifying delegation scope in stages is a valid organizational control mechanism. However, once 70% of PRs pass through agents, the human role shifts from code understanding to output auditing, and the risk of reviews becoming ritualized through automation bias grows. A structure in which humans re-verify agent outputs does not eliminate the bottleneck; it moves the bottleneck into verification capability. If per-skill rollback rates and post-merge defect tracking are not performed in parallel, automation rates will rise while quality accountability blurs. Security policy bypass and accountability issues cannot be resolved without institutional mechanisms such as agent identifier signing, PR-level permission matrices, and audit logs, so adopting organizations should complete gate design before pursuing automation rates.
Critical Analyst
The 70% automation and cost-flattening numbers are, before they are a technical achievement, likely a polished corporate narrative whose key question is who defined the terms
The biggest beneficiary of this metric release is Uber itself. In a single announcement, it can simultaneously secure a growth narrative without headcount expansion, employer branding amid AI-era hiring uncertainty, and a price-negotiation card with model providers backed by massive volume. The “70% of PRs handled by agents” figure has not had its definition and denominator disclosed—if low-difficulty PRs such as dependency upgrades, formatting, and minor cleanups were heavily included, the measured rate could be far higher than the real development automation rate. “Costs flat since April” also does not reveal how much platform build-out labor and infrastructure depreciation are included, so the picture could be reproduced not by pure efficiency but by accounting reclassification of costs. Set against the recent industry pattern of large tech companies lining up to release AI productivity figures, this case reads as preemptive positioning against peer pressure. What we should really pay attention to is not the 70% number but whether third-party verification exists to audit it.
Underlying Scenarios
- Possibility of a strategic disclosure as a workforce narrative — As large tech companies’ timing of AI productivity disclosures tends to overlap with workforce planning or earnings cycles, the chart of “costs flat despite 7x user growth” can easily function as justification for growth without hiring.
- Possibility of favorable metric definition design — If low-difficulty automated PRs are heavily included in the denominator of “PRs handled by agents,” the 70% can be reproduced as an inflated automation rate, and with definitions and measurement criteria non-public, room remains to read it that way.
Leave a Reply