Uber's internal developer tools: DevPods, Model Gateway, MCP gateway tour
The Model Gateway decision from 2023 shows how a large platform avoids vendor lock-in by abstracting model access — a pattern smaller teams can copy early rather than retrofit. Engineers building internal platforms or agent infrastructure will find concrete references for MCP gateways, agent skills repos and productivity metrics. The city-as-primitive sharding design also contrasts sharply with generic cloud architectures most companies inherit.
Gergely Orosz published a guided video tour of Uber's developer tooling with long-tenured engineer Uday Kiran Medisetty, who joined before 2016. The tour covers DevPods for development environments, a Model Gateway built in 2023 that keeps all AI work model- and harness-agnostic across Anthropic, OpenAI and open models, plus an MCP gateway and an Agent Skills repo for building with AI agents. It also walks through testing and code review tooling including Bazel, Slate and Capri, the Edge Gateway with Shepherd and Wisdom, and Uber's context graph and Cortana system. Uber additionally tags pull requests by work type to measure engineering productivity beyond raw PR velocity.
What do developer tools look like inside Uber, today? They are very different from what you would see at most places. We get a rare tour with one of Uber's longest-tenured engineers, Uday Kiran Medisetty (@udaykiran) - who was at Uber already when I joined in 2016!
Timestamps:
00:00 Intro 02:48 Uday’s early days at Uber 05:40 Uber’s move to microservices 07:55 Uber’s engineering team, then and now 09:05 Developer tooling before AI 16:03 DevPods 19:28 Building for AI agents 29:27 MCP gateway 34:37 Agent Skills repo 38:46 The context graph and Cortana 47:54 PRD and ERD tool 50:45 Minion 54:46 Testing and code review with Bazel, Slate, and Capri 1:12:26 Edge Gateway, Shepherd, and Wisdom 1:21:33 The changing role of engineer and measuring productivity 1:30:40 Uday’s favorite new products
Brought to you by:
• @turbopuffer – The tpuf eng team is rebuilding their storage architecture from first principles to make search faster, cheaper, and more reliable at scale. Follow along at https://t.co/h4kBELKz20
• @linear – the product development system for teams and agents. Check out Linear Diffs: a new feature to review PRs inside of Linear, with all the context in one place. https://t.co/knIF2mcz9p
• @WorkOS – how do you deal with agents and permissions? WorkOS built Airlock, the authorization layer for AI agents. Works with Claude Code, Codex and MCP gateways. https://t.co/OzuIJ1wHtZ
Three things you probably did not know about Uber:
1. At Uber, cities are a first-class concept that go all the way down to physical infrastructure.
One reason Uber had to build a lot of its custom tooling is how the concept of cities is a “basic primitive” that needs to be handled across systems like observability, feature flagging, deployments, and even service sharding. For example, in the early days, some services had their database sharded by cities. Even today, each city is pinned to a cloud region, and can fall over to another region at any time.
2. A single AI model gateway has paid lots of dividends.
In 2023, Uber’s platform team made the decision that everything built with AI needs to be model- and harness-agnostic. They built Model Gateway to support switching between Anthropic, OpenAI, other vendor models, and now also supports open models they run.
3. Uber tags PRs by the type of work each of those PRs do.
In the past, Uber measured “PR velocity:” how long it took for a PR (or, as Uber calls it: a “diff”) to get to production. With agents, doing so makes less sense, because it’s easy to create dozens or even hundreds of PRs, and many of those PRs might have no business impact on the product.
So Uber now tags all PRs by type: feature, bugfix, maintenance, testing, or docs.
They are seeing the percentage of “feature PRs” going up, and the percentage of “maintenance PRs” going down.
I find this categorization to be a clever approach!
