Uber's AI infra, from the inside
Gergely Orosz with Uday Kiran Medisetty · 14 October 2026
Read the originalUber's engineers still review every pull request, but an AI review and a risk score come first, and Uber now tags pull requests by type instead of counting them.
Gergely Orosz of The Pragmatic Engineer, a newsletter for software engineers, interviewed Uday Kiran Medisetty, a Distinguished Engineer at Uber, the ride-hailing and delivery company. Uber's automated build and test jobs more than doubled in a year, and the company declared an internal "code red" for that system. The interview describes how Uber changed review, spending limits and measurement for work done with AI coding agents.
- Simple checks such as linting moved to the engineer's machine, where AI agents run them before opening a pull request.
- An engineer still reviews every pull request, after an AI review, screenshots or videos and a risk score have been added.
- Each engineer has a monthly spending tier for AI tools, and a manager can approve more for that month.
- Uber tags each pull request as feature, bugfix, maintenance, testing or docs, because AI agents can open many pull requests with no business impact.
A team whose AI agents open many pull requests can tag each one by type, as Uber does, to see whether feature work is rising. The account comes from Uber's own engineer and gives only the direction of change, not figures.
Tag every pull request by type, such as feature, bugfix or maintenance, and track the mix instead of the total count.
Move simple checks such as linting onto the engineer's machine, so that AI agents run them before opening a pull request.
Derived by Working Surface from the article; more in the Playbook. Source line: So Uber now tags all PRs by type: feature, bugfix, maintenance, testing, or docs.
16 October 2026: as AI agents produce more code and conversations than people can read, teams move routine checks to machines, keep people for narrower decisions and change what they count as progress.