So, behind Uber the app, which is used

by hundreds of millions of people

globally, there's an engineering

organization that has been building one

of the most mature internal AI platforms

in the industry by making deliberate and

compounding infrastructure bets over a

long period of time.

Today, Uber's background agent platform

called Minion is responsible for

generating over 11% of all merge PRs

across of Uber.

They also have a large-scale migration

management called Shepherd, which runs

migrations across a hundreds of millions

of lines of code. They have custom AI

tools for testing test generation, code

review, and more, all built internally

and compounding on top of each other.

So, my guest today is Nikhil, a software

engineer on Uber's developer platform

team. Nikhil has been at Uber since

2016. He came in as an intern, loved it,

and then just never left. So, he's been

there for a long time. And over that

time, he's been one of the leading

engineering voices behind Uber's agentic

shift. An early adopter of cloud code

inside of Uber, and he's been a key

force in building the primitives

underpin everything that you're about to

hear within Uber's development platform.

So, Nikhil, welcome and thank you so

much for being here.

Very flattering. Thanks for having me,

Lou. When it comes to building AI and

agent-first, you know, sort of AI-first

developer platform,

you already had an existing developer

platform, CI infrastructure, cloud

compute, development environments, you

know, sort of compounding investments

that you've made over those years. What

are those bets that you've placed that

have kind of taken you to where you are

today?

>> already getting to a point at Uber where

a engineer was not necessarily a

specialist. That is, they were not only

building Android code. They actually

happened to build Android, iOS, they

happened to build the backend, they

happened to build sometimes the

frontend. They actually happened to be a

fully product-focused engineer. So, if

you want to wear multiple hats, you need

to be able to switch between

environments, and environment isolation

wasn't a soft problem.

So, I actually built a

rudimentary container

for local development for Android

engineers.

And that rudimentary container, within

like a year, evolved into a prototype

called Devbox. Instead of

actually having this environment where

you had to set up and it wasn't

reproducible, now you'd have this box

and and you'd be able to just put

everything in the remote machine and

plan for a future where your engineers

are not really interfacing with the

local tooling

if they don't want to. In other words,

if if I don't want to have Android

tooling on my machine, I can use a

Devbox. If I want to build Go code, I

can use a Devbox. Yeah, exactly. So,

we're kind of, I guess, going from this

world before, right, onboarding humans.

And now this also translates over to to

agents and how do we onboard those? And

I think one question that's on a lot of

people's mind is what happens if, you

know, if we give agents their own

computers and allow them to do stuff.

And can we run them for a longer period

of time? Can we get them to do more

significant work? But that in itself is

a a new working model that we haven't

seen before, so it comes with it

challenges around security, challenges

around infrastructure, and also

wrangling large language models to kind

of do this longer horizon work. I know

that's something that Uber has also

started to experiment with. And you do

have an internal platform called Minion.

It'd be great if you could take us

through and sort of talk us, you know,

the inception of Minions, like where

that's at today and The key distinction,

I think, from Minion that that came

about was the idea of that

certain tasks are toil tasks. You are

working on a product feature or

something like that. Somewhere in the

middle you get a ticket. The ticket says

fix this

massive vulnerability. You quickly

reshuffle your work.

You say, "Okay, I need to make this fix,

but to make this fix, I have to make the

fix, I have to test the fix, I have to

make sure it's working in production.

And I'm the only person who can look at

it because I own the fix.

But, the actual fix is minor.

It's actually the validation loop that

takes

a long time, and that's what I'm

required for.

So, what do I do?

I have to reset my schedule and go and

make the fix myself. Now, actually at

Uber, as the stack grows the stack grew,

this kind of work became common work,

common engineering work. So, what is

Minions about?

We made a bunch of trade-offs. There are

toil tasks as a result of a lot of these

trade-offs that people have to deal

with. Can we give them a way

to

win back time

by

uh stack ranking their work

in a way where they can background some

of the toil,

right? So, that when they get to the

validation, 50% to to 70% of the work

required has been completed by a

background agent. So, first is the bet

on a a a specific tool that can do a

specific task.

Secondly, is that can do that task well.

So, a lot of the time people want to

say, "Write me a big feature from an

agent."

We cannot measure I cannot score on

that. I can score you on whether you can

do the basics. So, I tell you to change

a line of code, if you can figure out

whether you need to run tests also

as an agent, right? You need to

configure out, "Oh, I have a tree of

dependencies that may be affected by the

change I'm about to make." That I don't

have to explicitly tell you. This is the

bet. The bet is that toil work

that seems simple, but actually has

wide-ranging scale for a company like

Uber, can we automate the toil? And so,

I wrote like a little doc, and because

of that we founded like a platform where

we put this agent and a number of these

other specialist agents into our CI

infrastructure.

And we accept prompts in order to do

work. It goes through our CI checks, and

all our tests run,

and quality checks,

um you know, diff description, as much

metadata as we need. But the the end

goal is to actually remove the toil from

the engineer. And one key point I want

to make

the engineer is a is a sensitive

creature. That is

don't promise an engineer the world when

you give them a platform, give them a

valuable use case because you have to go

to where the pain lives. If I can prove

to an engineer that the the core value

proposition of taking certain painful

toil tasks away from you is beneficial,

they will naturally understand that AI

is not here necessarily to take away all

of the work, just the parts of the work

that are tedious, they require rigor and

tedium to to execute. When it comes to

those toil and those use cases, how are

you, you know, thinking about the sort

of use case identification and roll out

across Uber? Yeah, this is a big

challenge, I will admit.

Mainly because

you have the industry and the industry's

documentation of the various product use

cases for

each entity AI, right? And then you have

the internal conflict, which is not

everything will apply, but a lot of it

can in different ways. The common

feedback we get actually is that I don't

know what to choose. I don't even want

to choose.

And

I think for us that's very big signal,

right? If it comes down to us to make a

choice, then we go quite strictly with

like our developer satisfaction and

data. And the satisfaction data is like

onboarding and stuff.

Toil work is taking away a lot of my

time. I barely get any time to do deep

work, right? You have very clear signal

that you kind of need to invest Oh,

okay, code reviews are taking a lot of

time. We can't be like Apple. We can't

just put out a tool and say, "You use it

this way." Actually, they're going to

tell us, "No, No, we use it this way.

You need to listen to what I'm saying

and I I there's a little bit of a

negotiation there, too. We can now take

what bigger swings, I'd say.

Oh, reviews are a bottleneck. Let's try

to make high-quality agentic reviews.

Is is toil work like cleaning up feature

flags or cleaning up things or doing

small changes a bottleneck?

Let's give you that ability to

get you out of that zone and then

measure directly. I Is this actually

helping you? I think that's what most

organizations working in the space are

really looking for, right? They're

looking for people with

ingenuity to act on boring feedback.

You're going to get every quarter you're

going to find out documentation

is [snorts] is a is is a pain point,

that toil is a pain point. The feeling

of productivity is as important as

actual productivity. These two go hand

in hand when you actually want to have a

productive software engineers or a

productive workforce, right? Uber has or

has been investing in also in a platform

called Shepherd. What does it look like

if we can also apply agents at scale

across our organization uh for something

like migrations or you know, sort of

upgrades and things like that. You know,

anyone who's worked with, you know, Java

or some of these other tools know that

they need upgrading all the time. So,

then you're going to have to do this

across a number of different services,

some of which may not necessarily be

actively developed upon. And it seems

like Shepherd is

then exploring and experimenting with

that type of like large-scale change.

So, the idea behind Shepherd

is to take the real work that needs to

get done,

but put it in the context of an

evergreen engineering uh

yeah, it's evergreen engineering, right?

Like that's that's how I would put it,

right? You don't want to

be chasing your tail sort of when you're

doing this work. The work is a fact of

engineering.

You have to be on the cutting edge

regardless. But, what we found, I think

even with things like Shepherd, is if

you can give people the platform to be

able to disseminate changes

and give them the tools to be able to

have a mental model of a large change.

They can operate on that primitive.

And that that's a primitive. At the end

of the day, a large-scale change is a

primitive that we support now, which

happened. Minion is sort of one form of

primitive that can push toil off into

the background. Then you have Shepherd,

which is more for these large-scale,

you know, mass changes. And then then

Shepherd is effectively going to

manage the sort of merge conflicts and

keeping those PRs up to date and give

you a sort of centralized view then for

those mass changes across across the

organization.

Right, exactly. And and I think

the the the the angle with Shepherd

ultimately is

we need to keep evergreen code. We want

to keep our code healthy, and we want to

give people the primitive to be able to

do that. And less like Minion, which is

targeting some level of toil in one way,

Shepherd is targeting some of this work

in a different way. Organizations where

the engineers, I guess, identify a

little bit more with the idea of being a

builder or they're a little bit more

outcome-oriented,

uh seems to be where the organizations

are moving faster towards agentic or

AI-driven development.

Is the fabric of Uber,

you know, kind of that builder-oriented

culture? And would you say is is that a

factor in kind of what drives your speed

of adoption of AI? Is that Mandating the

use of AI didn't really get an option

where it needed to be.

People had to realize for themselves. It

had to reach a point of capability

before people adopted it.

What does that tell you about the

culture of engineers in general? They're

all builders. In fact,

the reason why we even have 90% of the

primitives we have before AI that I'm

talking about

is because the builders need to keep

building. They need to move fast.

For example, Dev Pods is just a a

function of being able to parallelize

manually, essentially, right? Uh like

the Dev Containers. Uh

these remote dev environments is just

parallelism without agents, right? We we

we already reached that point where

our builders were demanding more easy

ways to build. So, what does that mean

for platform? It means for our platform

side,

we have to also think about

whether we can wear some of those hats

for them

and

consider

what a builder would scrutinize as a

waste of time sometimes, right? It's How

do I make them stick? is is kind of And

the culture

of making it stick comes from being able

to give people the ability to fail in a

safe way.

If I If I give you the tool

and I tell you use this

or else, that's not going to work. If I

tell you I give you the tool and that

tool says I can do X, Y, and Z and then

you actually put it in production and it

can do a quarter of X, a tenth of Y, and

a fiftieth of Z, I will fail there as

well. What I need is

the engineer to be able to see that I

know the pain they see.

That's what gets a builder really

hungry.

When they know that they can take the

tool and they can mold it to their

outcome. In other words,

maybe for us agents at our company, for

us agents are

the way to go because our engineers are

builders who need to be able to finally

configure and control what they do. And

not that we um we are necessarily

forcing them to work with an expectation

that these things do things that maybe

they're not capable of. Any sort of

parting wisdom or final thoughts that

you have that you'd like to share? It's

not actually that late. And in fact,

most people still don't have it figured

out. And there's room here. There's

runway here to figure this out. Um

because the primitives have always been

the same.

Can I move my engineers faster?

Can I take away the pain that they see

on a daily basis uh so that they can

focus on building high quality features.

That mission as a platform is the same

10 years ago and it's the same today.

The only difference is the means with

which you go about solving your problem.

All investments

may or may not pay off. And of course

it's a sense of prioritization. That

doesn't mean the primitives of high

quality software delivery and

um

rapid iteration. The These things are

important to actually most I would say,

that's my personal opinion, most tech

companies are going to want rapid

iteration. So you want to have some of

these fundamental and make sure your

engineers have a space to fail.

Because if they fail and it's expensive

for you, that ends up looking kind of

tough for most people because the it it

erodes trust, right? So you want to

build a platform that lets people have

the space to fail and protect people

from toil and focus on the same things

that they're always trying to do, which

is build high quality products and

features for the business. Amazing.

Nikhil, thank you so much. Thank you.

Thank you, Lou.

>> [music]

[music]