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 turbopuffer.com/v3 • @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. linear.app/pragmatic • @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. workos.com/airlock 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!

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 turbopuffer.com/v3 • @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. linear.app/pragmatic • @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. workos.com/airlock 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!

When does it still make sense to use microservices, what are mental models to keep in mind when building resilient distributed systems, and how is much of the tech world fundamentally misunderstanding AI? With @samnewman. Timestamps: 00:00 Intro 03:16 Sam’s path into tech 09:32 Thoughtworks 20:55 The rise of microservices 33:37 Are specs becoming more important than code? 45:22 Building Resilient Distributed Systems (Sam’s new book) 52:35 Three rules of distributed systems 56:16 Observability 1:02:20 Resilience tradeoffs 1:07:54 Idempotency 1:15:58 Thundering herds 1:21:03 Business context and resilience decisions 1:25:51 Resilience engineering: four concepts 1:32:42 AI and resilience 1:36:26 AI’s limitations and where to use it 1:40:06 Cognitive debt and cognitive surrender 1:45:02 Modular architecture and AI software factories 1:51:53 Resources for learning software architecture 1:55:30 Where to find Sam Brought to you by: @turbopuffer - – vector and full-text search built on object storage: fast, 10x cheaper, and extremely scalable. Under the hood, the team are rewriting the tpuf storage engine. Follow along until it hits prod: turbopuffer.com/v3 @EntireHQ - Git hosting, rebuilt for the agentic era. Entire hosts your code in-region, and is up to 89x faster than any other competitor. Mirror from GitHub with a single click – I’ve already done so. entire.io/pragmatic @AntithesisHQ - Get a free introduction to property-based testing: through a rare, live webinar hosted by @hillelogram , author of Logic for Programmers. RSVP here: pages.antithesis.com/webinar… So, what does much of the tech world misunderstand about LLMs? Sam says: “I think the tech world in general is quite naive about AI and fundamentally misunderstands what an LLM is. For example: why did the LLM delete my database? Well, because it has no concept of causality. They have no concept that if I do A, B happens. LLMs are not world models. World models have been around for a long time. They predate LLMs. So if you had the appropriate model and the appropriate inputs, world models could at least get to the point of ‘if I do X, then Y happens and I’ve been told not to do Y.’ I think we expect LLMs to do more than they actually can do, because they seem so smart. This leads us to overestimate their capabilities a bit too much. But the nature of LLMs is why all the guardrails around LLMs are really not going to be the right long-term solution.”