Conference talk by Uday Kiran Medisetty and Adam Huda (Uber) on the infrastructure behind Uber's agentic software development lifecycle. Covers a unified model gateway handling Spire identity, PII redaction, and safety models within a 100 ms budget; an MCP gateway that projects internal APIs into a CLI to reduce context-window token use; a managed skills marketplace; a 40-million-entry context graph for ownership and dependency facts; and an end-to-end demo of one feature built from a Slack thread to a draft PR that intentionally stops before CI for inner-loop validation. The talk closes with the argument that the bottleneck is now deciding what should be built at all. # Channel Identity Observations: Uber Software Factory Talk ## Video Identity - **Title:** *Building Blocks for Uber’s Software Factory — Uday Kiran Medisetty & Adam Huda, Uber* - **Speakers:** Two Uber engineers presenting jointly ("I'm Udai. I'm here with my colleague Adam"), with a structured handoff mid-talk. - **Format:** Conference-style technical presentation with a live end-to-end demo portion ("I'm going to show you what this looks like"). ## Explicit Self-Description - The talk is framed as: > "We'll talk about our journey towards [a] managed software factory." - Scope explicitly declared: > "I'll talk about the key building blocks that we are investing in... Adam's going to talk about how we take all of these blocks to build an end-to-end cohesive solution for our engineers." - Organization affiliation stated directly: speakers identify as Uber engineers describing internal systems ("for an engineer at Uber, you take the vanilla client, you set the project ID..."). ## Observable Presentation Patterns - **Depth over breadth:** Six "building blocks" each covered with concrete metrics (e.g., "800 plus projects... more than 100 million model requests per day"; "2,500 skills... 20,000 skill executions per day"). - **Engineering-led narrative:** Topics include model gateway, MCP gateway, agentic dev pods, skills marketplace, context graph, and an AI assistant ("Cortana") — all described as internal infrastructure. - **Candid maturity framing:** > "all of these are in various stages of maturity and rollout within Uber. But we want to give everyone a sneak peek." - **Forward-looking honesty about limits:** Explicit bottleneck discussion — CI capacity, experiment limits, and > "it's not about... can we build... it's more of a question of should we build it." ## Intended Audience - **Practitioner/technical conference audience:** Assumes familiarity with concepts like monorepos, Bazel, Kubernetes, MCP, CI/CD, Figma, and agentic AI coding tools without explanation. - Addresses peers managing engineering platforms at scale: > "few thousand engineers across 12 global tech sites." ## Claimed Scope of Content - Covers the **full software development lifecycle**: ideation, design, implementation, validation, code review, CI, maintenance, and monitoring — demonstrated via a World Cup pickup-location feature walkthrough. - Includes operational scale claims: > "more than 70% of our PRs now [are] either by local or cloud agents" and > "250 automated migrations [covering] 9 million lines of code." ## Distinguishing Claims vs. Demonstration - **Creator claims:** All quoted metrics and maturity statements are self-reported by speakers; no external verification is presented. - **Demonstrated:** The talk structure itself demonstrates a pattern of metric-heavy internal case-study presentation with a live product demo segment, typical of an engineering conference session rather than a tutorial or marketing video. # Delivery Observations: "Building Blocks for Uber's Software Factory" ## Overall Format - **Two-speaker talk** with a clear handoff: Uday covers the six "building blocks" overview, then Adam walks through an end-to-end feature demo. Uday explicitly frames this: *"in the first part of the talk I'll talk about the key building blocks... later Adam's going to talk about how we take all of these blocks to build an end to-end cohesive solution."* - **Metric-heavy delivery**: nearly every topic lands on a quantified claim. > *"70% of our PRs now either by local or cloud agents"* · *"250 automated migrations 9 million lines of code"* · *"800 plus projects... more than 100 million model requests per day"* · *"2,500 skills"* · *"40 million entries"* · *"20,000 sessions per day"* · *"40% fleetwide savings"* ## Uday's Delivery Patterns ### **Problem → solution → numbers structure** Each building block follows the same template: name a pain point, introduce the system, close with scale figures. - Pain: *"each one of them have different way to authenticate different way to set up which is a lot of hassle"* → MCP gateway → *"thousand plus MCP tools... saved more than 40%"* - Pain: *"there's a lot of duplication... superpar quality"* → skills marketplace → *"2,500 skills... 20,000 skill executions per day"* ### **Enumerated framing** He repeatedly structures content as numbered lists ("three things," "six building blocks," "one two three problems"), even when the enumeration is loose in delivery: > *"The three things that we wanted to en ensure was no PII ever leaves our parimeter..."* > *"So let's go to the building blocks the six building blocks one by one."* ### **Audience-facing framing device** He positions the talk as a preview: *"all of these are in various stages of maturity and rollout within Uber. But we want to give everyone a sneak peek of what we are up to."* ### **Verbal habits** - Frequent **filler restarts and repetitions**: *"we we had this,"* *"uh we we started noticing,"* *"it it knows all of the things."* - Occasional stumbles transcribed as-is: *"superpar quality"* (likely "subpar"), *"spend years"* (likely "spend tiers"), *"middleares"* (middlewares). ## Adam's Delivery Patterns ### **Conversational rhetorical markers** Adam uses *"right?"* as a constant cadence device, far more than Uday: > *"First up, right, we need to have an idea, right?"* · *"So, that's the idea, right?"* · *"All right, so now we got to go build this."* ### **Narrative walkthrough via a concrete scenario** He anchors the demo in a relatable example — a World Cup stadium pickup feature — and follows it through Slack → design → build → validation → CI → maintenance: > *"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?"* ### **Before/after contrast habit** He repeatedly contrasts past pain with present speed: > *"This process before could take a long time. It could take weeks to get everyone aligned. Now we can compress this into a very short amount of time."* ### **Design-rationale explanations** Adam frequently explains *why* a system behaves as it does: > *"it's going to stop at just creating a draft PR and it's not going to push it to CI yet. The reason being is... we want to prevent a lot of extra load coming on to CI."* ## Shared Communication Habits - **Insider naming with light explanation**: product names (DevPod, Minion, Cortana, Omni MCP) are introduced with brief glosses: *"We have a Minion agent. It's a Uber's cloud coding agent solution."* - **Closing with open problems**: Adam ends on bottlenecks rather than a triumphal summary: *"it's more of a question of should we build it."* - **Handoff etiquette**: both use explicit verbal transitions (*"I'll now pass on to Adam"* / *"All right. Thank you, Ud."*). ## Uncertainty Notes - Transcript quality is rough (fillers, mis-transcriptions like "parimeter," "coding hardnesses"), so some exact-wording claims above reflect the transcript, not necessarily the spoken audio. - Tone, pacing, and gesture are **not observable** from this transcript; only lexical and structural delivery features can be claimed here. # Position Record: "Building Blocks for Uber's Software Factory" — Uday Kiran Medisetty & Adam Huda, Uber ## Context and Stated Outcomes (Uday Kiran Medisetty) - Uber has a few thousand engineers across **12 global tech sites**. - Over the last year, agentic AI investments led to **70%+ of PRs authored by local or cloud agents** and **2x lines of code per engineer year-over-year**. - **250+ automated migrations covering 9 million lines of code**. - Prior six-year investments in **monorepos and Bazel** laid the foundation for this acceleration. - The six building blocks are "in various stages of maturity and rollout" — an explicit qualification that these are not all fully deployed. ## Building Block 1: Model Gateway (Medisetty) - Design goals: **no PII leaves the perimeter** by default; **strictly bounded latency** for guardrails; per-user, per-project, per-team attribution. - All internal and external use cases go through **one OpenAI/Anthropic-compatible endpoint** with middleware: - Identity/auth via **SPIRE** - **Data anonymizer** redacting 20+ PII types - **AI guard** with 5 specialized safety/policy models, all running **under 100 milliseconds** - Enables spend guardrails, audit logs, session traces feeding benchmarking and self-improvement loops. - Scale: **800+ projects, 100+ million model requests per day**, frontier and open-source models. ## Building Block 2: MCP Gateway (Medisetty) - Problem stated: thousands of internal APIs were not agent-accessible; SaaS tools had inconsistent auth; many MCPs create a **"massive token tax."** - An **automated crawler** converts internal APIs into MCPs with one config change; SaaS MCPs (Google, Slack, Jira) also route through the gateway with token exchange. - Evolution of patterns: **direct MCP → Omni MCP** (single discover/invoke MCP) → **CLI pattern** (responses don't consume context) → autoinstalled **code mode skill** generating Python scripts on the fly for top token consumers. - Result: **1,000+ MCP tools** and **40%+ fleetwide token savings**. ## Building Block 3: Agentified DevPods (Medisetty) - Built on existing cloud remote environments for large monorepos. - Requirements: agents need quick, isolated, installable, globally available long-running environments. - Solution: **pre-provisioned Kubernetes pods** with repos snapshotted and search index prebuilt — agents start **within seconds**. - **Mega devpod** combines all repositories since "roles of engineers are getting blurred"; used by autonomous coding agents and non-engineers alike. ## Building Block 4: Skills Marketplace (Medisetty) - Problems observed: **duplication**, **discovery/configuration hassle**, **uneven skill quality**. - Managed lifecycle: core and domain skills, lint checks, automated reviews; **one command** to discover/install; persona-based autoinstallation. - Actively collecting traces, comments, continuous evals for skill feedback — "an area of big investment for us right now." - Scale: **2,500 skills, 20,000+ skill executions per day**. ## Building Block 5: Context Graph (Medisetty) - Problem: agents burn tokens and latency finding basic context scattered across **20–30 internal systems**. - One graph of "how Uber runs": **150 unique node/edge types, 40 million entries**; spans mobile, backend, data lake, design docs, Jira, incidents. - Claimed results: "massive improvement in tokens, turns and latency" across evals (e.g., a cash-trips-in-India SQL query). ## Building Block 6: AI Assistant "Cortana" (Medisetty) - Surfaces skills, MCPs, and context graph on **Slack, CLI, and web**. - Employees can personalize with custom skills/prompts in team Slack channels. - Scale: **300 unique personas and 20,000+ sessions per day in the last month**. ## End-to-End Feature Walkthrough (Adam Huda) ### Ideation and Design - Example feature: a **better pickup location for riders leaving a busy World Cup stadium**. - Cortana, using the context graph, helps assess business opportunity (prior large-venue events, candidate stadiums); assists with product requirements (North America rollout), Figma mock-ups with **two A/B variants**, and planning what existing app screens/backend can be leveraged. - Claim: a process that "could take weeks" is compressed to a short time to prototype. ### Build — "Minion" Agent - Uber's cloud coding agent (**Minion**), interactive or autonomous, powered by devpods, works **across repos** (backend and frontend). - Stops at **draft PR, does not push to CI** — reasoning stated: prevent excess CI load and validate advanced features earlier. ### Validation — Inner/Outer Loop Shift - Shifting checks to the **inner loop**: static analysis fixes, visual validation (simulator screenshot vs. Figma spec), backend staging integration. - **Self-healing CI** for outer-loop failures. - Code review split: smaller/faster model in inner loop; powerful reasoning model with skill in outer loop. - Autonomous PRs carry a **table of checks and screenshots** to give human reviewers confidence. ### Maintenance - Services can be enrolled in **managed maintenance loops** (e.g., feature-flag cleanup of the losing B variant). - Qualifications: loops run through a **managed surface** (avoid unbounded sprawl), scheduled Sunday for CI capacity, with diff volume controlled to avoid overwhelming engineers Monday. - Landed/rejected diffs serve as **label data for skill improvement**; monthly cadence converts incident-review learnings into new maintenance skills. ### Stated Bottlenecks and Open Questions (Huda) - **CI capacity strain** from more code through the factory. - **Limited feasible experiments**. - **Decision-making**: "it's not about can we build… it's more of a question of should we build" — an explicitly unresolved tension. # Speaker Attribution & Provenance Record **Video:** Building Blocks for Uber's Software Factory — Uday Kiran Medisetty & Adam Huda, Uber **Video ID:** `01a15ca7-c930-786e-8aea-0ec837371823` ## Speakers & Roles | Speaker | Role | Segment | |---|---|---| | **Uday Kiran Medisetty ("Udai")** | **Presenter / Co-speaker** (Uber; identifies himself at start) | First part: six building blocks (model gateway, MCP gateway, devpod, skills marketplace, context graph, AI assistant "Cortana") | | **Adam Huda** | **Presenter / Co-speaker** (introduced as Uday's colleague) | Second part: end-to-end feature demo, validation loops, maintenance skills, bottlenecks | - No narrator, guest, or audience speakers; no promotional segments identified. - Mentioned (non-speaking, future talk): **Aha** (spelled "aha" in transcript), presenting on agentic code review in the same room. ## Referenced Sources & Third-Party Claims - **Third-party systems/companies named:** OpenAI, Anthropic (compatible endpoint), Google, Slack, Jira, Figma, Kubernetes, Spire, Bazel, Python. - **Internal Uber systems described by speakers:** model gateway, MCP gateway, Omni MCP, DevPod, Mega DevPod, skills marketplace, context graph, Cortana AI assistant, Minion coding agent. - **Quantitative claims** (all attributed to speakers, unverified): 70% of PRs by agents; 2x lines of code per engineer YoY; 250 automated migrations / 9M lines of code; 800+ projects; 100M+ model requests/day; 1,000+ MCP tools; 40% fleetwide token savings; 2,500 skills; 20,000 skill executions/day; 40M context graph entries; 300 personas; 12 global tech sites; ~few thousand engineers. ## Uncertainty Notes - Transcript is auto-generated; some names/terms may be misspelled (e.g., "Udai" vs. Uday, "aha", "Cortana"). - No curated metadata supplied; **comment availability unknown**. - No external citations, sources, or references beyond those listed above. Hey uh let's get started. Uh good morning everyone. I'm Udai. I'm here with my colleague Adam. We'll talk about our journey towards manage software factory. And in the beginning in the first part of the talk I'll talk about the key building blocks that we are investing in. 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. To set some context, we have few thousand engineers across 12 global tech sites. 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. And all of this led to twice the number of lines of code per engineer year-over-year. And this extends way beyond coding and we see it in every aspect of the engineering life cycle today. And we are also accelerating toil at a toil reduction at a massive pace. We handled more than 250 automated migrations 9 million lines of code automatically for our engineers. 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. 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 uh with all of these and all of these are in various stages of maturity and rollout within Uber. But we want to give everyone a sneak peek of what we are up to. So let's go to the building blocks the six building blocks one by one. The first one is model gateway. This is one of our earlier investments. 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 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. So \[snorts\] we have a model gateway. 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. It goes through a series of middleares. The first one is identity and authentication using Spire. Uh we have a data anonymizer that redacts 20 plus PII types. We have a AI guard that has five specialized models that handles various parts of safety and policy that we want to ensure. And all of that runs under 100 milliseconds. We also are investing in all kinds of caching and token optimization strategies at this layer. And every request that goes through this, we are able to attribute to a specific project in our catalog. And we can attribute per caller, per user, per team both in real time but also in our data lake. This enables us to create all kinds of spend years and guardrails in a holistic way across our portfolio. 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. 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. Today we have 800 plus projects internally going through this cumulatively handling more than 100 million model requests per day. This includes both the frontier models and also open source models whether that is hosted in our infrastructure or some of our vendors. The next is how do we provide tools to all of these models. 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 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 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 and projects all of these into MCPS with one single config change. 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. We h we host them, we do the token exchange. So for all the engineers, they go through one single entry point, one common way to install any MCPS. This simplified a lot for all of our engineers and employees. And then the whole bunch of token optimization strategies. We initially had direct MCP pattern. 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. 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. 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 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. So once we have the models and the tools, we need a place to run all of this. For many years we had devpod which is our cloud remote environments. 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. And now we took what we had with devots and we agentified that. Now we need some environment for agents to run for longer period of time. They need to be quick. They need to be isolated. We can install any number of them and they need to be globally available across all of our sites. So we have a pre-provisioned Kubernetes balloon pods. When an agent requires a new environment to run, it can take one of that which is already pre-provisioned. It has all of the repositories already snapshotted. The search index is already built. So the agents can start working within a matter of seconds. The next thing we noticed is the the the roles of engineers are getting blurred. We used to offer a dev port per language flavor for Go, Java, Android and so on. Now we need agents to work across repositories and engineers also to work across repositories. 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. 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. Then now we get to knowledge part of it and we jumped on this bandwagon earlier this year. Uh we started noticing engineers building tons of skills across many repositories. 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. So what we built an entire life cycle around skills. So we have core core skills and domain specific skills. All of that go into a managed skills marketplace. We have 2,500 skills there right now. 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. And we also simplified the installation and discovery. So there is one single command to discover and install any plug-in in our ecosystem. And based on the engineer personas, we even autoinstall some of the default skills. So the agents automatically can pick up the right skill. You don't even have to even install them. 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. And this is an area of big investment for us right now. and we have 2,500 skills and cumulatively more than 20,000 skill executions per day across our fleet. The next piece of knowledge is context graphs. 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. 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. And all of this context is gathered across scattered systems across Uber. There's 20 to 30 different systems. Each needs its own skill skills, its own MCP to gather the context. And this burns tokens. This adds a lot of latency and it creates more unpredictable outcomes. So we have one context graph. We took all of the information of how Uber runs into one context graph. This has 150 unique node and edge types. We have 40 million entries there right now. It captures all the way from how our mobile apps are built to our back end to our data lake. All the design docs, Jira, incident bugs, everything is connected and this enables agents to quickly find the right context within our ecosystem. 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 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 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 and the last thing is how do we package all of this for everyone in the company to use. So we have uh our AI assistant called Cortana. 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. So anyone in the company, they can ask a simple question. 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. And now we started allowing employees to even personalize that. 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 that teammate. And this this is a simple example of how you can invoke the same question before in Slack. Um and all of the employ more like one or more people can even collaborate on the same Slack channel. And we have the just in the last one month 300 unique personas created and more than 20,000 sessions per day. 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. \>\> All right. Thank you, Ud. All right. And as Ud said, we've got those building blocks. We're going to use those to power our software factory. So, we're going to take a feature here and show it going end to end through this. All right. First up, right, we need to have an idea, right? A good idea probably for this moment would be something around the World Cup, right? 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? So, that's the idea, right? We have our idea. We're jamming on it in Slack here. Let's tag in Cortana, right? That's our AI assistant to help us with that idea. Cortana with that context graph can help us determine whether this is a good business opportunity to go after. So, we can go here from Slack and now open Cortana into a web interface. And you'll see an example here of what that business research could look like, right? What other largecale venue events have happened before? What are some stadiums that would make sense here? From there, we start to think about the product requirements, right? This should be probably just a North America rollout since that's where the stadiums are. We can even then bring in Cortana to help us think about uh the Figma designs. We can create some initial mock-ups, right? Do two variants here. We want to run an experiment A and B. So the the button strings here are different between the two. So we'll test those two variants and see which one performs better. 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? What can we leverage that's in the app already? what screens and what can we leverage on the back end. Right? So this process before could take a long time. It could take weeks to get everyone aligned. Now we can compress this into a very short amount of time now. Right? And get to a prototype here very quickly. All right. So now we got to go build this. So we we hand off from that Cortana agent to what we have at Uber. We have a Minion agent. It's a Uber's cloud coding agent solution. All right. So you can use Minion in an interactive mode or you can run it in an autonomous mode as well. So I'm going to show you what this looks like. Um UD mentioned the dev pod building block. So this is powered by that dev pod. So it's got a full build environment and it can work across repos. So we're doing backend changes and the front end changes here too as well. 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. 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. So if we can validate sooner before we push to CI um that would be a big benefit. So that's what we're going to see here next on validation. Right? In the SDLC, we have an inner loop. We have the outer loop. Of course, we can have these be aensified where we're shifting more checks now to happen in this inner loop. Right? So, some of the checks that initially happen that we've had there previously is like this the static analysis sort of checks. When those are detected, now we fix those. But we can shift things to happen in inter loop. Things like visual validation. So, we can launch an simulator with a skill, grab a screenshot from the simulator, compare it to the Figma specs. We can also bring up the service and our backend staging environment and compare the front end and the backend integration together. 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 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 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. And in the interloop, we can have a smaller model that runs uh faster with a with a with a medium model. 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 already, right? That not just touching that initial generation that happened, but all these other steps have happened. And so on the PR, you will have a table attached that says all these different checks that it went through, including the screenshots. All right, so we've got a lot more code coming through the software factory now, right? Let's talk about maintenance. Right, maintenance is even more important. 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. So these are uh some examples of those skills that we have. Uh feature flag cleanup, right? We had two variants of that world cup uh modal. Now that the the B variant is no longer needed, we can have that scheduled on a loop. So the key thing here is that this is actually a managed loop that you go to, right? We don't want thousands of loops being set up across the company without any bounds. You have a managed surface that you go to to set up the loop. So it runs on Sunday when we know we have better uh CI capacity available. U we also don't want to overwhelm engineers that Monday morning with a bunch of extra diffs. We want to control how many diffs they're seeing on Monday as well. 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. That's all good label data that we can use to improve the skill itself. 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. All right, so you've seen uh these parts of the SDLC that we've identified. There's other parts too like monitoring. Have you seen the uh building blocks that you can use to power those and the architecture underneath them? One of the other things that we're really thinking about now is bottlenecks, right? We're now we're putting more strain on our infrastructure. So we're trying to anticipate where our CI capacity needs to be and make the right foundational investments there. There's only so many experiments that we can feasibly run as well. So that's another bottleneck. And then lastly too, right, decision- making, right? 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 is going to be actually from Uber as well and if you want to learn more about our agentic code review aha and will be presenting that next uh in this room thank Thank you.