Overview
This episode looks at the internal developer systems Uber has built over many years, and how those foundations now support agentic AI. Uday Kiramendisethi, one of Uber's longest-tenured engineers and a leader in its AI work, discusses platforms ranging from data storage and machine learning to developer environments, build infrastructure, AI access controls, and tool integrations.
A central theme is that AI agents need many of the same things engineers need: reliable workspaces, authenticated access to services, fast builds, clear guardrails, and integrations with the systems where work happens.
Key Takeaways
Uber's internal tooling predates the current AI wave. The conversation references systems such as Uown, M3DB, Michelangelo, Cadence, and Morpheus, which appear to cover internal ownership and operational workflows, time-series data, machine learning, workflow orchestration, and broader developer infrastructure. These systems gave Uber a base to build on rather than requiring its AI efforts to start from scratch.
Developer environments are treated as a platform problem. The "dev pod" provides cloud-based machines that can be more powerful than a developer laptop, with build caches and preinstalled tools. That reduces local setup failures and allows Uber to offer more predictable build and test times.
The same workspace model extends to agents. Rather than treating an AI agent as only a chat interface, Uber is connecting agents to controlled cloud environments and internal services. This lets agents perform work that crosses systems, including communication tools, document suites, issue trackers, vendor tools, and internal products.
The company has also built AI-specific foundations, including an MCP Gateway, AI Guard, and AIFX. The transcript suggests these systems handle the connection layer between agents and tools, along with safety, policy, and operational controls. The goal is broad automation without granting unchecked access to every system.
Uber's operating complexity shapes how it approaches automation. Products and support processes vary by city and country, so workflows need to account for local rules, expectations, and edge cases. A process that can be automated in one setting may need human review or different handling elsewhere.
Engineering productivity is framed as expanding what teams can ship, rather than reducing it to a single activity metric. The discussion acknowledges that Uber has examined signals such as diffs per engineer, while also emphasizing the need to measure a wider set of outcomes and keep improving the foundations engineers and agents depend on.
Practical Steps
- Build standardized remote development environments with cached dependencies, reproducible setup, and enough compute for builds and tests. Measure build and test turnaround times as service-level objectives.
- Give AI agents dedicated workspaces rather than direct, unrestricted access to production systems or employee laptops.
- Put a gateway in front of agent tool access. Centralize authentication, permissions, logging, policy checks, and protocol translation instead of wiring each agent directly into every service.
- Start automation with workflows that span existing tools, such as Slack, Google Workspace, Jira, Linear, and internal support systems. Define which actions an agent may take automatically and which require approval.
- Design workflows for regional variation early. Document where city, country, regulatory, or customer-support differences prevent a single global automation path.
- Track productivity through delivery outcomes and developer experience: build latency, test latency, setup reliability, feature throughput, and the time engineers spend on repetitive work.
Notable Quotes
- Uday Kiramendisethi: "Even the agents need the similar workspaces and cloud boxes."
- Uday Kiramendisethi: "People could automate anything, right, at that point, like from Slack to Google, Jira, Linear, like any tool, vendor tool, or any internal service."
- Uday Kiramendisethi: "The more we can unlock, the more features we can ship, the more productivity that we can unlock."
Full Transcript
What kind of internal tools do software engineers at Uber use to build software today? We get an exclusive, insider, and visuals-heavy look from one of Uber's longest-tenured engineers, Uday Kiramendisethi. Today, Uday leads much of the work on agentic AI at Uber. In this conversation, we get into Internal developer systems Uber has built and used pre-AI, like Uown, M3DB, Michelangelo, Cadence, Morpheus, and others. AI foundational systems the company built, like its MCP Gateway, AI Guard, and AIFX. Recent systems used by nearly all engineers, like Minion, The dev pod, and it has all the build system cached. I can have faster builds. It's working on cloud machines at a beefier than even the laptops. So then you could have, like, we could have really good SLAs on your build time, on your test time, and we don't have to worry about the setup issues because we can, we can install the right tools in place. And now the interesting part is as we got to the AI era, like even the agents need the similar workspaces and cloud boxes, and we are able to kind of latch on to that. Protocol transformations, any kind of, any kind of VPI gateways. So it was like we were able to pretty quickly build this. So I think this was probably like, especially once we got our Google Workspace and all of our Slack tools also into this, it kind of like created all kinds of like amazing agentic workflows. People could automate anything, right, at that point, like from Slack to Google, Jira, Linear, like any tool, vendor tool, or any internal service is— Partner cases are like even more, right? And we really think about, oh, what happens if this goes on? What happens if this goes on? How do we handle the support case for this? How do we handle— Yeah, I guess just needless to add, but I'll just add it because it might not be as obvious, but Uber operates in so many countries and cities, and even between two cities, the reality might be different, or might be different expectations, or people are used to different things, and so on. Yeah, absolutely. I think that's why it really becomes important to think about the right plan upfront, and this will also make it easy for both the— Like then, like you cannot automate this thing. And like, yeah, as you said, like these kind of stuff really helps. And I'll also like talk about like one more like pretty interesting thing, which is so Uber specific and it's very, very— Yeah, and this is like very, very hard to get right. And like we had like even many versions of build like this in the past, but I think this is probably our best version and we can like really scale it to all the teams. But essentially the idea is— More we can unlock, the more features we can ship, the more productivity that we can unlock. And, like, we are trying to measure a whole bunch of this and, like, constantly think about, like, what is the next set of foundations that we need to build to make it easy for engineers to work and to make it easy for agents to work. You mentioned productivity. How do you think about engineering productivity? Because when I was at Uber, this was, again, in, like, up to 2020, us managers did look at things. It wasn't the main thing, but we did look at things like diffs per engineer just to show, you know, if someone didn't contribute.