WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=17-YSUHo6Lk

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/17-YSUHo6Lk.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.719 --> 00:00:13.920
Hey uh let's get started.

s3
00:00:13.920 --> 00:00:15.200
Uh good morning everyone.

s4
00:00:15.200 --> 00:00:16.000
I'm Udai.

s5
00:00:16.000 --> 00:00:17.760
I'm here with my colleague Adam.

s6
00:00:17.760 --> 00:00:21.600
We'll talk about our journey towards manage software factory.

s7
00:00:21.600 --> 00:00:26.240
And in the beginning in the first part of the talk I'll talk about the key building blocks that we are investing in.

s8
00:00:26.240 --> 00:00:33.680
And later Adam's going to talk about how we take all of these blocks to build an end to-end cohesive solution for our engineers.

s9
00:00:33.680 --> 00:00:38.480
To set some context, we have few thousand engineers across 12 global tech sites.

s10
00:00:38.480 --> 00:00:49.039
Over the last year, all of the investments we made in agentic AI have led to more than 70% of our PRs now either by local or cloud agents.

s11
00:00:49.039 --> 00:00:54.640
And all of this led to twice the number of lines of code per engineer year-over-year.

s12
00:00:54.640 --> 00:01:00.160
And this extends way beyond coding and we see it in every aspect of the engineering life cycle today.

s13
00:01:00.160 --> 00:01:04.640
And we are also accelerating toil at a toil reduction at a massive pace.

s14
00:01:04.640 --> 00:01:12.400
We handled more than 250 automated migrations 9 million lines of code automatically for our engineers.

s15
00:01:12.400 --> 00:01:25.759
And before even the building blocks um you know one all the investments we made over the last six years on moving to monor repos moving to basil all of that also laid a really solid foundation for us to accelerate this.

s16
00:01:26.960 --> 00:01:37.040
So the first I'll cover all of these six building blocks and Adam's going to talk about a specific example and show how that feature can be built end to end

s17
00:01:37.040 --> 00:01:42.079
uh with all of these and all of these are in various stages of maturity and rollout within Uber.

s18
00:01:42.079 --> 00:01:46.399
But we want to give everyone a sneak peek of what we are up to.

s19
00:01:46.399 --> 00:01:49.840
So let's go to the building blocks the six building blocks one by one.

s20
00:01:49.840 --> 00:01:52.000
The first one is model gateway.

s21
00:01:52.000 --> 00:01:54.159
This is one of our earlier investments.

s22
00:01:54.159 --> 00:02:07.360
The three things that we wanted to en ensure was no PII ever leaves our parimeter to any of the vendor by default and any guardrail that we add here the latency of that is strictly bounded

s23
00:02:07.360 --> 00:02:15.440
and every request that goes through this whether it's uh and we need to be able to attribute per user per project and per team.

s24
00:02:15.440 --> 00:02:15.586
So

s25
00:02:15.586 --> 00:02:15.680
[snorts]

s26
00:02:15.680 --> 00:02:16.720
we have a model gateway.

s27
00:02:16.720 --> 00:02:25.680
We made sure all of our internal use cases, our coding hardnesses, our external use cases, they all go through one single OpenAI anthropic compatible endpoint.

s28
00:02:25.680 --> 00:02:27.760
It goes through a series of middleares.

s29
00:02:27.760 --> 00:02:31.520
The first one is identity and authentication using Spire.

s30
00:02:31.520 --> 00:02:36.160
Uh we have a data anonymizer that redacts 20 plus PII types.

s31
00:02:36.160 --> 00:02:43.840
We have a AI guard that has five specialized models that handles various parts of safety and policy that we want to ensure.

s32
00:02:43.840 --> 00:02:46.800
And all of that runs under 100 milliseconds.

s33
00:02:46.800 --> 00:02:52.640
We also are investing in all kinds of caching and token optimization strategies at this layer.

s34
00:02:52.640 --> 00:02:58.319
And every request that goes through this, we are able to attribute to a specific project in our catalog.

s35
00:02:58.319 --> 00:03:05.519
And we can attribute per caller, per user, per team both in real time but also in our data lake.

s36
00:03:05.519 --> 00:03:12.640
This enables us to create all kinds of spend years and guardrails in a holistic way across our portfolio.

s37
00:03:12.640 --> 00:03:23.200
We also use this layer for capturing audit log session traces which are then plugged into our benchmarking and all kinds of self-improvement loop efforts.

s38
00:03:23.280 --> 00:03:30.560
And for an engineer at Uber, you take the vanilla client, you set the project ID and we and we take care of everything else.

s39
00:03:30.560 --> 00:03:38.000
Today we have 800 plus projects internally going through this cumulatively handling more than 100 million model requests per day.

s40
00:03:38.000 --> 00:03:46.239
This includes both the frontier models and also open source models whether that is hosted in our infrastructure or some of our vendors.

s41
00:03:46.799 --> 00:03:50.480
The next is how do we provide tools to all of these models.

s42
00:03:50.480 --> 00:04:03.120
Last year when we started on this journey we had thousands of internal APIs but none of them are agent accessible out of the box and we had so many other SAS tools and each one of them have different way to authenticate

s43
00:04:03.120 --> 00:04:14.000
different way to set up which is a lot of hassle for for everyone and once you end up with enough MCPs they'll all add up to and and have a massive token tax

s44
00:04:14.000 --> 00:04:23.919
similar to model gateway we have an MCP gateway that handles whole bunch of middleares for for engineers And we have an automated crawler that looks at our internal APIs

s45
00:04:23.919 --> 00:04:29.759
and projects all of these into MCPS with one single config change.

s46
00:04:29.759 --> 00:04:36.880
And we do the same thing even for our SAS MCPS whether it's Google, Slack, Jira, all of this, they go through the MCP gateway.

s47
00:04:36.880 --> 00:04:39.680
We h we host them, we do the token exchange.

s48
00:04:39.680 --> 00:04:44.560
So for all the engineers, they go through one single entry point, one common way to install any MCPS.

s49
00:04:44.560 --> 00:04:49.120
This simplified a lot for all of our engineers and employees.

s50
00:04:49.199 --> 00:04:52.800
And then the whole bunch of token optimization strategies.

s51
00:04:52.800 --> 00:04:55.360
We initially had direct MCP pattern.

s52
00:04:55.360 --> 00:05:05.120
Earlier this year we created Omni MCP which is one single MCP that you install which can discover and invoke any MCPS within the gateway.

s53
00:05:05.120 --> 00:05:12.720
And couple of months ago we projected all of these MCPS into CLI pattern so that even the response doesn't eat up in your context.

s54
00:05:12.720 --> 00:05:26.240
And of late we also have a code mode skill which is autoinstalled which on the fly creates Python scripts to hyper optimize some of the top MCP token consumer consuming use cases

s55
00:05:27.680 --> 00:05:39.759
and all of this led to like now we have thousand plus MCP tools and uh just with these optimization efforts we've saved more than 40% fleetwide savings.

s56
00:05:41.120 --> 00:05:46.000
So once we have the models and the tools, we need a place to run all of this.

s57
00:05:46.000 --> 00:05:50.960
For many years we had devpod which is our cloud remote environments.

s58
00:05:50.960 --> 00:05:57.680
We we we had this because we had like large mono repos with millions of lines of code and this is how engineers work at Uber.

s59
00:05:57.680 --> 00:06:02.560
And now we took what we had with devots and we agentified that.

s60
00:06:02.560 --> 00:06:06.800
Now we need some environment for agents to run for longer period of time.

s61
00:06:06.800 --> 00:06:07.759
They need to be quick.

s62
00:06:07.759 --> 00:06:09.039
They need to be isolated.

s63
00:06:09.039 --> 00:06:14.960
We can install any number of them and they need to be globally available across all of our sites.

s64
00:06:15.280 --> 00:06:18.800
So we have a pre-provisioned Kubernetes balloon pods.

s65
00:06:18.800 --> 00:06:24.400
When an agent requires a new environment to run, it can take one of that which is already pre-provisioned.

s66
00:06:24.400 --> 00:06:26.880
It has all of the repositories already snapshotted.

s67
00:06:26.880 --> 00:06:28.479
The search index is already built.

s68
00:06:28.479 --> 00:06:32.400
So the agents can start working within a matter of seconds.

s69
00:06:32.400 --> 00:06:37.919
The next thing we noticed is the the the roles of engineers are getting blurred.

s70
00:06:37.919 --> 00:06:44.319
We used to offer a dev port per language flavor for Go, Java, Android and so on.

s71
00:06:44.319 --> 00:06:49.520
Now we need agents to work across repositories and engineers also to work across repositories.

s72
00:06:49.520 --> 00:06:57.840
So we have a mega dev port that has all of the repositories in one one common place and this is what we use for our autonomous coding agents now.

s73
00:06:57.840 --> 00:07:08.639
And even for our non-engineer employees, we are providing a simple way for them to get started with any of the agent harnesses in matter of seconds.

s74
00:07:09.919 --> 00:07:14.880
Then now we get to knowledge part of it and we jumped on this bandwagon earlier this year.

s75
00:07:14.880 --> 00:07:19.440
Uh we started noticing engineers building tons of skills across many repositories.

s76
00:07:19.440 --> 00:07:33.199
Um one three problems we noticed was there's a lot of duplication same skill being built by different engineers in different discovery and configuration was a huge hassle and a lot of skills were of superpar quality.

s77
00:07:33.199 --> 00:07:35.599
So what we built an entire life cycle around skills.

s78
00:07:35.599 --> 00:07:39.120
So we have core core skills and domain specific skills.

s79
00:07:39.120 --> 00:07:42.080
All of that go into a managed skills marketplace.

s80
00:07:42.080 --> 00:07:45.120
We have 2,500 skills there right now.

s81
00:07:45.120 --> 00:07:54.160
Um and it goes through a whole bunch of lint checks, automated reviews which ensures a baseline skill quality for any skills that we have.

s82
00:07:54.160 --> 00:07:57.280
And we also simplified the installation and discovery.

s83
00:07:57.280 --> 00:08:02.479
So there is one single command to discover and install any plug-in in our ecosystem.

s84
00:08:02.479 --> 00:08:07.520
And based on the engineer personas, we even autoinstall some of the default skills.

s85
00:08:07.520 --> 00:08:09.840
So the agents automatically can pick up the right skill.

s86
00:08:09.840 --> 00:08:13.039
You don't even have to even install them.

s87
00:08:13.199 --> 00:08:24.080
And of late, we started working on collecting traces and comments and capturing continuous evals so that we can go give feedback back to the skill authors for skill improvements.

s88
00:08:24.080 --> 00:08:27.360
And this is an area of big investment for us right now.

s89
00:08:27.360 --> 00:08:35.440
and we have 2,500 skills and cumulatively more than 20,000 skill executions per day across our fleet.

s90
00:08:37.680 --> 00:08:40.640
The next piece of knowledge is context graphs.

s91
00:08:40.640 --> 00:08:48.880
Uh we we started noticing in our execution traces agents spending lot of time even trying to find basic context especially in our large monor repos.

s92
00:08:48.880 --> 00:08:56.080
You need to identify where the service is located, what are the dependencies, um who owns it, what kind of patterns I need to follow.

s93
00:08:56.080 --> 00:09:00.959
And all of this context is gathered across scattered systems across Uber.

s94
00:09:00.959 --> 00:09:02.560
There's 20 to 30 different systems.

s95
00:09:02.560 --> 00:09:07.279
Each needs its own skill skills, its own MCP to gather the context.

s96
00:09:07.279 --> 00:09:09.440
And this burns tokens.

s97
00:09:09.440 --> 00:09:15.120
This adds a lot of latency and it creates more unpredictable outcomes.

s98
00:09:15.360 --> 00:09:17.519
So we have one context graph.

s99
00:09:17.519 --> 00:09:21.760
We took all of the information of how Uber runs into one context graph.

s100
00:09:21.760 --> 00:09:24.480
This has 150 unique node and edge types.

s101
00:09:24.480 --> 00:09:26.720
We have 40 million entries there right now.

s102
00:09:26.720 --> 00:09:32.160
It captures all the way from how our mobile apps are built to our back end to our data lake.

s103
00:09:32.160 --> 00:09:41.279
All the design docs, Jira, incident bugs, everything is connected and this enables agents to quickly find the right context within our ecosystem.

s104
00:09:41.279 --> 00:09:50.480
We are now plugging all of our skills and use cases into the graph whether it's our on call RCAs whe it's a planning or data analysis or security scans

s105
00:09:50.480 --> 00:10:07.440
and we see across all of this they we are improving uh the skills by a lot and I'm just showing a very simple example of asking a simple question of how many mobility trips in India are are cash this needs to understand the concepts of each of these which tables what kind of cities you need to create

s106
00:10:07.440 --> 00:10:18.480
for this SQL with and without graph we see massive improvement in tokens, turns and latency and we see that across any earlier val that we did within our infrastructure

s107
00:10:19.440 --> 00:10:23.839
and the last thing is how do we package all of this for everyone in the company to use.

s108
00:10:23.839 --> 00:10:26.880
So we have uh our AI assistant called Cortana.

s109
00:10:26.880 --> 00:10:37.440
All of the things that I mentioned so far, whether it's skills, MCPS and context graph, they're all plugged into that in every surface possible whether it's on Slack, CLI, web.

s110
00:10:37.440 --> 00:10:40.000
So anyone in the company, they can ask a simple question.

s111
00:10:40.000 --> 00:10:49.440
It can look up the context graph, invoke any skill, check any code, check any code in any codebase and give an answer across any of these surfaces.

s112
00:10:49.600 --> 00:10:53.760
And now we started allowing employees to even personalize that.

s113
00:10:53.760 --> 00:11:04.399
You can hook up your custom skills, custom prompt and hook it up into your team Slack channel so that it it knows all of the things about that team and works like a the

s114
00:11:04.399 --> 00:11:06.640
that teammate.

s115
00:11:07.440 --> 00:11:11.920
And this this is a simple example of how you can invoke the same question before in Slack.

s116
00:11:11.920 --> 00:11:19.200
Um and all of the employ more like one or more people can even collaborate on the same Slack channel.

s117
00:11:19.200 --> 00:11:25.760
And we have the just in the last one month 300 unique personas created and more than 20,000 sessions per day.

s118
00:11:25.760 --> 00:11:33.760
I'll now pass on to Adam who'll talk about how we take all of this and build uh take and ship a feature end to end.

s119
00:11:34.000 --> 00:11:34.399
All right.

s120
00:11:34.399 --> 00:11:35.600
Thank you, Ud.

s121
00:11:35.600 --> 00:11:35.839
All right.

s122
00:11:35.839 --> 00:11:38.079
And as Ud said, we've got those building blocks.

s123
00:11:38.079 --> 00:11:40.640
We're going to use those to power our software factory.

s124
00:11:40.640 --> 00:11:46.079
So, we're going to take a feature here and show it going end to end through this.

s125
00:11:46.079 --> 00:11:46.399
All right.

s126
00:11:46.399 --> 00:11:48.800
First up, right, we need to have an idea, right?

s127
00:11:48.800 --> 00:11:52.640
A good idea probably for this moment would be something around the World Cup, right?

s128
00:11:52.640 --> 00:11:59.279
Would it be awesome if you were a writer and you were leaving a busy stadium if there was a better pickup location to get you away from the crowd?

s129
00:11:59.279 --> 00:12:01.200
So, that's the idea, right?

s130
00:12:01.200 --> 00:12:02.320
We have our idea.

s131
00:12:02.320 --> 00:12:04.640
We're jamming on it in Slack here.

s132
00:12:04.640 --> 00:12:06.160
Let's tag in Cortana, right?

s133
00:12:06.160 --> 00:12:08.800
That's our AI assistant to help us with that idea.

s134
00:12:08.800 --> 00:12:14.800
Cortana with that context graph can help us determine whether this is a good business opportunity to go after.

s135
00:12:14.800 --> 00:12:20.800
So, we can go here from Slack and now open Cortana into a web interface.

s136
00:12:20.800 --> 00:12:25.440
And you'll see an example here of what that business research could look like, right?

s137
00:12:25.440 --> 00:12:28.560
What other largecale venue events have happened before?

s138
00:12:28.560 --> 00:12:31.120
What are some stadiums that would make sense here?

s139
00:12:31.120 --> 00:12:33.600
From there, we start to think about the product requirements, right?

s140
00:12:33.600 --> 00:12:37.920
This should be probably just a North America rollout since that's where the stadiums are.

s141
00:12:37.920 --> 00:12:42.240
We can even then bring in Cortana to help us think about uh the Figma designs.

s142
00:12:42.240 --> 00:12:44.480
We can create some initial mock-ups, right?

s143
00:12:44.480 --> 00:12:45.440
Do two variants here.

s144
00:12:45.440 --> 00:12:50.320
We want to run an experiment A and B. So the the button strings here are different between the two.

s145
00:12:50.320 --> 00:12:54.480
So we'll test those two variants and see which one performs better.

s146
00:12:54.480 --> 00:13:00.399
Now we'll start to think a little bit about the design and Cortana 2 can help us think about what code changes we need to happen, right?

s147
00:13:00.399 --> 00:13:02.240
What can we leverage that's in the app already?

s148
00:13:02.240 --> 00:13:05.600
what screens and what can we leverage on the back end.

s149
00:13:05.600 --> 00:13:05.920
Right?

s150
00:13:05.920 --> 00:13:08.880
So this process before could take a long time.

s151
00:13:08.880 --> 00:13:10.720
It could take weeks to get everyone aligned.

s152
00:13:10.720 --> 00:13:13.760
Now we can compress this into a very short amount of time now.

s153
00:13:13.760 --> 00:13:14.000
Right?

s154
00:13:14.000 --> 00:13:17.440
And get to a prototype here very quickly.

s155
00:13:17.600 --> 00:13:17.839
All right.

s156
00:13:17.839 --> 00:13:19.040
So now we got to go build this.

s157
00:13:19.040 --> 00:13:22.720
So we we hand off from that Cortana agent to what we have at Uber.

s158
00:13:22.720 --> 00:13:24.399
We have a Minion agent.

s159
00:13:24.399 --> 00:13:28.160
It's a Uber's cloud coding agent solution.

s160
00:13:28.160 --> 00:13:28.399
All right.

s161
00:13:28.399 --> 00:13:32.639
So you can use Minion in an interactive mode or you can run it in an autonomous mode as well.

s162
00:13:32.639 --> 00:13:34.880
So I'm going to show you what this looks like.

s163
00:13:34.880 --> 00:13:37.360
Um UD mentioned the dev pod building block.

s164
00:13:37.360 --> 00:13:39.040
So this is powered by that dev pod.

s165
00:13:39.040 --> 00:13:42.320
So it's got a full build environment and it can work across repos.

s166
00:13:42.320 --> 00:13:46.720
So we're doing backend changes and the front end changes here too as well.

s167
00:13:46.720 --> 00:13:53.440
We're going to see Minion kind of progress here and it's going to stop at just creating a draft PR and it's not going to push it to CI yet.

s168
00:13:53.440 --> 00:14:08.639
The reason being is that we were seeing um uh that this was great for doing like toil sort of workloads but to build more advanced like endtoend features we really need to be able to validate uh the feature first and we want to prevent a lot of extra load coming on to CI.

s169
00:14:08.639 --> 00:14:14.720
So if we can validate sooner before we push to CI um that would be a big benefit.

s170
00:14:14.720 --> 00:14:17.279
So that's what we're going to see here next on validation.

s171
00:14:17.279 --> 00:14:17.519
Right?

s172
00:14:17.519 --> 00:14:19.279
In the SDLC, we have an inner loop.

s173
00:14:19.279 --> 00:14:20.320
We have the outer loop.

s174
00:14:20.320 --> 00:14:27.680
Of course, we can have these be aensified where we're shifting more checks now to happen in this inner loop.

s175
00:14:27.680 --> 00:14:27.920
Right?

s176
00:14:27.920 --> 00:14:33.120
So, some of the checks that initially happen that we've had there previously is like this the static analysis sort of checks.

s177
00:14:33.120 --> 00:14:35.440
When those are detected, now we fix those.

s178
00:14:35.440 --> 00:14:37.440
But we can shift things to happen in inter loop.

s179
00:14:37.440 --> 00:14:39.440
Things like visual validation.

s180
00:14:39.440 --> 00:14:45.279
So, we can launch an simulator with a skill, grab a screenshot from the simulator, compare it to the Figma specs.

s181
00:14:45.279 --> 00:14:53.040
We can also bring up the service and our backend staging environment and compare the front end and the backend integration together.

s182
00:14:53.360 --> 00:15:04.399
So now that we've moved a um now that we've done uh that part uh we move to the outer loop where CI uh typically happens errors can still happen on CI

s183
00:15:04.399 --> 00:15:16.000
right uh so self-healing CI is something that we've implemented here where we can fix a lot of the issues that you hit on CI code review is another thing that happens in the outer loop but this is another thing that we've shifted

s184
00:15:16.000 --> 00:15:23.440
we've moved parts of code review to happen in the inner loop right the outer loop code review can have a powerful model use reasoning a skill to do a deeper review.

s185
00:15:23.440 --> 00:15:30.000
And in the interloop, we can have a smaller model that runs uh faster with a with a with a medium model.

s186
00:15:30.000 --> 00:15:39.600
Now, another key thing here, right, is this if this is an autonomous diff coming from minion, we want to give a human reviewer some confidence that this diff has gone through a lot of self-improvement

s187
00:15:39.600 --> 00:15:40.480
already, right?

s188
00:15:40.480 --> 00:15:44.880
That not just touching that initial generation that happened, but all these other steps have happened.

s189
00:15:44.880 --> 00:15:52.480
And so on the PR, you will have a table attached that says all these different checks that it went through, including the screenshots.

s190
00:15:53.519 --> 00:15:56.560
All right, so we've got a lot more code coming through the software factory now, right?

s191
00:15:56.560 --> 00:15:57.680
Let's talk about maintenance.

s192
00:15:57.680 --> 00:16:00.079
Right, maintenance is even more important.

s193
00:16:00.079 --> 00:16:10.000
Um, what we have set up now is we can actually enroll our feature or skill into u our feature or ser uh service into maintenance uh skills.

s194
00:16:10.000 --> 00:16:13.759
So these are uh some examples of those skills that we have.

s195
00:16:13.759 --> 00:16:15.120
Uh feature flag cleanup, right?

s196
00:16:15.120 --> 00:16:19.600
We had two variants of that world cup uh modal.

s197
00:16:19.680 --> 00:16:24.880
Now that the the B variant is no longer needed, we can have that scheduled on a loop.

s198
00:16:24.880 --> 00:16:28.320
So the key thing here is that this is actually a managed loop that you go to, right?

s199
00:16:28.320 --> 00:16:33.759
We don't want thousands of loops being set up across the company without any bounds.

s200
00:16:33.759 --> 00:16:36.320
You have a managed surface that you go to to set up the loop.

s201
00:16:36.320 --> 00:16:40.880
So it runs on Sunday when we know we have better uh CI capacity available.

s202
00:16:40.880 --> 00:16:45.519
U we also don't want to overwhelm engineers that Monday morning with a bunch of extra diffs.

s203
00:16:45.519 --> 00:16:49.120
We want to control how many diffs they're seeing on Monday as well.

s204
00:16:49.120 --> 00:16:56.639
Another cool key thing here is that when that ski uh skill runs and makes those diffs, those diffs will get comments and either get landed or not landed.

s205
00:16:56.639 --> 00:17:00.800
That's all good label data that we can use to improve the skill itself.

s206
00:17:00.800 --> 00:17:13.120
And then at a kind of monthly cadence, we're looking to see what skills can we now learn um from in our incident reviews and turn those into new maintenance skills that we can apply to all of our services.

s207
00:17:14.720 --> 00:17:18.559
All right, so you've seen uh these parts of the SDLC that we've identified.

s208
00:17:18.559 --> 00:17:21.280
There's other parts too like monitoring.

s209
00:17:21.280 --> 00:17:27.280
Have you seen the uh building blocks that you can use to power those and the architecture underneath them?

s210
00:17:27.280 --> 00:17:31.600
One of the other things that we're really thinking about now is bottlenecks, right?

s211
00:17:31.600 --> 00:17:33.679
We're now we're putting more strain on our infrastructure.

s212
00:17:33.679 --> 00:17:39.200
So we're trying to anticipate where our CI capacity needs to be and make the right foundational investments there.

s213
00:17:39.200 --> 00:17:42.320
There's only so many experiments that we can feasibly run as well.

s214
00:17:42.320 --> 00:17:43.679
So that's another bottleneck.

s215
00:17:43.679 --> 00:17:45.840
And then lastly too, right, decision- making, right?

s216
00:17:45.840 --> 00:17:56.080
It's not about you know can we build we know we can probably build it now it's more of a question of should we build it all right so that's what we have for you today and the next talk

s217
00:17:56.080 --> 00:18:04.480
is going to be actually from Uber as well and if you want to learn more about our agentic code review aa and will be presenting that next uh in this room

s218
00:18:04.480 --> 00:18:06.720
thank Thank you.

s219
00:18:22.377 --> 00:18:24.377
[music]