This is my personal summary, written as notes taken while watching the talk. It is not a journalist article. I just watched the video, read the write-up, and wrote down what I found most useful. If you work as a senior architect or product owner, I strongly recommend watching the original video and reading the full article by Gergely Orosz on The Pragmatic Engineer. Links are at the bottom:
- Full deep-dive by Gergely Orosz: The Pragmatic Engineer more detail, more numbers, highly recommended
I watched the Pragmatic Summit talk by Anshu Chada (Engineering Director at Uber’s Dev Platform) and Ty Smith (Principal Engineer). I took notes because I think what Uber is doing is one of the most honest real-world examples I have seen recently on the topic of AI in engineering. What struck me immediately: they are not selling a dream. They talked about what works, but also about costs going up, slower-than-expected adoption, and metrics that are still unsolved. That made it credible from the start.
From pair programming to peer programming
Uber has used AI for years in its core products, driver-rider matching, demand forecasting, and so on. But integrating AI into the daily work of engineers is something different and much more recent. The shift they describe is from “a copilot that helps you while you type” to “an agent that works on its own while you do something else.” They call this peer programming. The model is simple: you give a task to an agent, you wait, and meanwhile you start another one. You only come back to review or redirect.
What developers actually use agents for
When Uber opened up agentic workflows to their engineers, 70% of submitted tasks were what they call “toil”: library upgrades, dead code cleanup, writing documentation, fixing simple bugs. This makes sense. These tasks have a clear start and end state, so the agent knows when it is done and success is easier to measure. Higher success rate meant more usage, which meant more toil offloaded, which meant engineers had more time for real product work. A good cycle.
As of March 2026, the numbers shared after the event are quite striking:
- 84% of Uber developers are active agentic coding users
- 65–72% of code inside IDEs is AI-generated
- Claude Code usage nearly doubled in just three months
The platform they built
This is the part I found most interesting as an architect. Uber did not just give developers access to external tools and call it done. They built a whole internal stack.
Here is what they built, layer by layer:
- MCP Gateway : a central proxy that connects AI agents to internal systems like source code, documentation, Jira, and Slack. It handles authorization, logging, and telemetry. Developers do not connect directly to anything; everything goes through this gateway.
- Minion : their internal background agent platform. A developer submits a task through a web UI, Slack, or CLI. The agent runs inside Uber’s own infrastructure (not a vendor’s cloud), has access to the monorepo, and a few minutes later sends a Slack notification with a link to a ready GitHub PR. The demo they showed was very concrete: a developer pastes a user-reported error, and seven minutes later there is a PR with a fix and a test plan.
- AIFX : a CLI tool that configures agent clients, installs MCP servers from a registry, and applies standard defaults so that even new developers start with a good setup.
- Code Inbox : a unified inbox for code reviews. With more agents generating more PRs, review became a bottleneck. This tool filters noise, assigns reviewers smartly based on ownership and availability, and batches Slack notifications so developers are not constantly interrupted.
- U-Review : an internal AI code review bot. They tried external products but found they produced too many low-value comments. U-Review runs multiple plugins, filters duplicates, and only surfaces high-confidence issues that developers actually fix.
- AutoCover : a test generation agent that produces around 5,000 merged tests per month across the company. It includes a critic engine to avoid low-quality or useless tests.
- AutoMigrate + Shepherd : a campaign management system for large-scale changes. The example they gave: upgrading all Java services to Java 21. Shepherd generates all the PRs, assigns reviewers, tracks progress, sends notifications, and refreshes PRs if they go stale. This is the kind of work that used to take months of manual coordination.
What this means if you are an architect or product owner
A few things I wrote down that I think are worth keeping:
- Abstraction layers are not optional. Uber can swap models or vendors without rewriting their platform. This is important because the best model today may not be the best one in six months. If your AI tools are tightly coupled to one provider, you will pay for that later.
- Start with toil, not features. The highest success rate and the clearest ROI came from well-defined tasks with a clear finish line. Migrations, upgrades, and bug fixes are much easier to automate than new features. If you want to prove the value of agents internally, start there.
- Adoption is a people problem, not a technical one. Even at a forward-thinking company like Uber, adoption was slower than expected. Top-down mandates had limited effect. What worked much better was engineers sharing their own wins with other engineers. Peers trust peers more than they trust directors.
- Cost is a real concern. Uber’s AI infrastructure costs grew 6x since 2024. They now help developers choose the right model for each task: a more powerful model for planning, a cheaper one for execution. If you are rolling out agents at scale, someone needs to own cost management from day one.
- Business impact is still hard to measure. Activity metrics are easy: number of PRs, test coverage, diff velocity. But connecting AI usage to revenue or product outcomes is a problem Uber is still working on. Their plan is to measure the full pipeline from design to production experiment and see if AI is compressing that timeline.
