More than 70% of Uber’s pull requests are now attributed to local or cloud agents.
That speed came with two bills. Code review got slower, going from about 3 hours in 2024 to around 9 hours in 2026. And Bloomberg reported that Uber burned through its whole 2026 AI budget in 4 months.
Uber kept the agents and built a system around them, which it calls a software factory, with platform teams running it. A startup with 5 engineers can get most of the way there by buying the pieces and building only two. Here’s how to do it in 4 steps, starting with the part most teams skip: what the agents are allowed to touch.
This issue is sponsored by Oracle Developers
Your AI agent wants your data. Here’s how to let it in safely.
MCP makes it easy to wire an agent into your database, usually before anyone has decided what the agent should be allowed to see.
Oracle’s developer team opened up a small read-only MCP server and wrote down the rules that keep agent data access safe and cheap in production.
It’s the data version of the gates in today’s issue. The 9-minute guide shows you how to:
- Put the real security boundary in the database account your agent logs in with
- Cap rows and clip long values so tool results stop eating your context window
- Swap agent-written SQL for reviewed, parameterized queries on recurring questions
Table of Contents
- What an AI-Native Software Factory Is
- Step 1: Measure Your Review Queue First
- Step 2: Pick One Line of Toil and Buy the Agent
- Step 3: Build the Thinnest Floor
- Step 4: Score Merged Work, Then Add the Next Line
- The Factory Kit: Rules File, Gate Checklist and 30-Day Plan
1. What Is an AI-Native Software Factory? #
A coding tool like Claude Code or Cursor helps one developer during one session. A software factory is the whole ticket-to-production process around those tools, with shared rules, budgets and checkpoints.
Think of the coding tool as one worker. The factory is every department that worker plugs into.
Most teams start by buying seats, so each developer runs a coding tool on their own laptop. That works while the agent only assists. Once agents do more of the work, four problems show up:
- Every developer has their own rules and prompts, with no shared way of working.
- You can’t see what the setup costs until the bill arrives.
- Review becomes the bottleneck, because agents write code faster than people can check it.
- Agents run on laptops with their owners’ logins and keys, which is a security risk.
Uber sorted its agent work into 4 layers to fix the first three.
Narrow agents that do a single job sit at one end. Open-ended sessions where an engineer chats with the coding tool sit at the other. The narrow layers give you the most control over cost, quality and model choice, because a single-job agent is easy to measure and tune.
A 5-person team hits the same problems, except the shared-rules one, which is easy to solve when everyone sits in one room. If you want the team setup first, read the 5-person team that runs on Claude Code.
2. Step 1: Measure Your Review Queue First #
Before you add agents, make sure your review queue can take the extra pull requests.
In an April 2026 report, Faros AI found that the median time in PR review rose 441.5% as teams moved from low to high AI adoption. At Assembled, median time to first review went from 3.5 hours in December 2025 to over 16 hours in May 2026, more than 4x.
Getting your own numbers takes a few minutes. If your code is on GitHub, install the GitHub CLI, run gh auth login, open Claude Code in the repo and paste this:
Use the GitHub CLI (gh) to look at pull requests in this repo merged in the last 90 days. Sort them by merge time and keep the latest 100. For each PR, get the creation time, merge time and author, and pull its full review list through the paginated reviews API. The first human review is the earliest submitted review from a User account (not a bot or known automation account) that isn't the PR's author and came before the merge. Then report:
1. Median and 90th-percentile hours from PR opened to first human review, counting only PRs that had one
2. Median hours from PR opened to merged
3. The share of PRs merged with no human review
Show the results as a small table, list the 5 PRs that waited longest, and save the raw data to review-queue.csv.
Look at the median and the 90th percentile. A big gap between them means some PRs sat untouched or got forgotten. A high share of PRs merged with no human review means people have stopped waiting for review at all.
In this repo the review itself is fast, about 2 hours from first look to merge. The delay is getting anyone to look at all, which makes it a queue problem. The 0% merged with no human review shows a repo that still waits for a human every time.
Save your three numbers, because Step 4 compares against them. If your queue is already long, start with how top teams review AI-written code.
3. Step 2: Pick One Line of Toil and Buy the Agent #
Each kind of task you hand to agents is one line in the factory. Start with a single line.
Every change on a line goes through the same stages: plan, design, build, test, review and maintain, looping back to planning when something breaks. A person still accepts the task, approves the agent’s plan and approves the merge.
Pick a task that happens often and is easy to check. Site reliability engineers call this kind of work toil: manual, repetitive, automatable and tactical, with no lasting value, and it grows with the service. Good first lines:
- Dependency updates
- Flaky test fixes
- Lint and type errors
- Small migrations
- Removing old feature flags
Leave work that needs judgment to call done, like a new feature, for a later line.
Buy the agent instead of building one. Hosted options such as Claude Code on the web or OpenAI Codex run in the vendor’s cloud and open a pull request when they finish, so you skip setting up and hosting your own. Most can start from an issue, a chat message or the browser, so pick the one that fits the tools your team already uses. The Claude Code system that replaces a 5-person team shows one way to wire it.
4. Step 3: Build the Thinnest Floor #
Once one line works, add the shared pieces around it, and only the ones you need.
What to buy and what to build
Keep the tool list short. Uber shared that with over 100 MCP tools installed, pre- their descriptions added about 50,000 to 70,000 tokens of schema overhead to the start of every session, and that overhead was resent on every turn.
Then there’s context. Every new agent session starts like a new hire on day one, knowing nothing about your codebase. Your rules file should hold what a new hire needs: how to run the tests, naming rules and which folders to leave alone. How to 8x your code output using context engineering covers what goes in it, and Section 6 has a template.
Put the Gates in Before the Agent Gets Access
In July 2025, a Replit agent deleted a production database during a code freeze. Jason Lemkin, SaaStr’s founder, had ordered the freeze in the chat, in capitals.
The instruction lived in the chat, and the agent still had write access.
Meta’s Agents Rule of Two is a simple way to decide what an agent may hold. An agent should have at most two of these three properties:
- It reads untrusted input
- It can access sensitive data or systems
- It can change things or send data out
When a task truly needs all three, a human or a reliable validation step supervises it, and the agent doesn’t run on its own.
Take a line of agents updating dependencies. They read public changelogs (untrusted input) and open pull requests (they change things). That’s already two of three, so they get no access to sensitive systems such as production credentials.
For a small team, gates mean a separate token with a narrow scope for each agent, a spend budget with alerts, and no production credentials. For agents that query data, give each one its own read-only account. Your AI app has a hole in it right now is the checklist to run before launch.
5. Step 4: Score Merged Work, Then Add the Next Line #
You can’t score merged work you never tracked, and you don’t need to track everything. Three metrics are enough:
- Cost per outcome: spend divided by changes merged. Uber tracks cost per merged PR, per review and per alert.
- Quality: revert rate and how fast you recover from incidents.
- Time to first review: compared with your Step 1 baseline.
Skip “percent of code written by AI”. A one-line config change and a new feature count the same, so a high share of agent PRs can hide a small share of the engineering work.
Cost per merged PR can mislead too, because splitting work into smaller PRs lowers it with no real benefit. A reader of Adam Faik’s original guide in The AI Thinker suggested a better denominator: changes that last 30 days without a revert or follow-up fix.
Your developers have to want this. Start with the tasks they dislike most, run the agents in a public chat channel so everyone sees the results, let people opt in and let developers own the approval gates.
Ramp never mandated its coding agent, Inspect. It wrote about 30% of merged PRs in Ramp’s frontend and backend repos in January 2026, and by October 2026 it accounted for 74% of merged PRs.
Before you add a second line, make sure review and CI can take the extra PRs. If time to first review keeps rising, fix review first. Assembled did it with an AI reviewer that auto-approves low-risk PRs. We Taught AI to Write Code But Forgot to Teach It to Think shows what happens when review falls behind for months.
What to do this week:
- Run the review-queue prompt on your main repo and save the 3 numbers.
- Pick one line of toil, such as dependency updates.
- Turn on a hosted agent for that line, with its own scoped token, no production access and a spend budget with alerts.
- Add a rules file (AGENTS.md or CLAUDE.md) with what a new hire would need to know.
- In 2 to 4 weeks, run the prompt again and compare before you add a second line.
6. The Factory Kit: Rules File, Gate Checklist and 30-Day Plan #
The rules file template
Paste this into AGENTS.md or CLAUDE.md at the root of the repo and fill in the brackets:
## Run and test
- Install: [command]
- Run tests: [command]. Every change must pass them before you open a PR.
- Lint and types: [command]
## Conventions
- Naming: [rules]
- New files go in: [folders]
## Do not touch
- [folders, files or services agents must never change]
- Never add or edit secrets, credentials or environment files.
## Pull requests
- One change per PR. Explain what changed and why in 3 sentences.
- Link the issue. List the tests you ran.
- If you are unsure, stop and ask in the PR instead of guessing.
For loops that run without you, pair it with the loops library and the head of Claude Code’s loop engineering playbook.
The gate checklist
Run this before any agent gets access to anything:
- The agent has its own token or account, separate from any person’s login.
- Its scope covers one repo or one line of work.
- It holds at most 2 of the 3 Rule of Two properties, or a human approves every action.
- It has no production credentials.
- Any data access goes through a read-only account with row limits.
- A spend budget is set, with an alert before you hit it.
- A person approves the plan and the merge.
- Every agent action is logged where the team can see it.
The 30-day plan
- Week 1: run the review-queue prompt, save the baseline and write the rules file.
- Week 2: turn on one hosted agent for one line of toil, with the gates above.
- Week 3: review every agent PR by hand and fix the rules file each time the agent repeats a mistake.
- Week 4: compare against the baseline and decide whether to fix review or add a second line.
To keep the bill in check while you scale, read Shorter Prompts Are Making Your AI Agents More Expensive and how NVIDIA cut agent costs in half without touching the model.
Uber needed platform teams to build its factory. A team of five can rent most of it and spend its own time on the two pieces nobody can sell you: the rules file and the gates.
If this saves your team a month of review backlog, send it to the engineer who owns your CI.
Keep reading: Coding agents in production
- The Harness Is the Product: 6 decisions that turn an AI agent into a worker you can leave alone
- You spent 2 months building an agent harness. OpenAI just made it a config block
- You are still chaining prompts. Anthropic’s engineers stopped a month ago
Keep reading: Review and quality
- How top teams review AI-written code
- The AI code review checklist that prevents the next $1M production incident
- What’s your AI agent’s ROI?
Keep reading: Small teams, big output
- Inside OpenAI: the operating model that makes 2 engineers beat 200
- The Claude skills founder operating system
- 100 AI agent ideas you can build this weekend
FAQ
What is an AI-native software factory?
It’s the full ticket-to-production process built around coding agents, with shared rules files, a spend budget, scoped access and human checkpoints at the task, the plan and the merge. Uber uses the term for the system that now produces more than 70% of its pull requests.
Do small teams need a platform team to run coding agents?
No. A team of five can buy the sandbox, model gateway, tool catalog and harness from a hosted agent vendor, and build only two pieces in-house: the context in its rules files and the gates on what agents can touch.
What should a coding agent never have access to?
Production credentials. Meta’s Agents Rule of Two says an agent should hold at most two of three properties: reading untrusted input, accessing sensitive systems, and changing things or sending data out. A dependency-update agent already holds two.
What should you measure after adding coding agents?
Track time to first human review against your baseline, cost per merged change that survives 30 days without a revert, and your revert rate. Skip “percent of code written by AI”, which counts a one-line config change the same as a new feature.
Why does review slow down when teams adopt AI coding agents?
Agents open more pull requests than people can read. Faros AI found the median time in PR review rose 441.5% as teams moved from low to high AI adoption.