0:14 - 1:48
The Software-Factory Thesis and Operating Baseline
The opening idea is simple: useful agentic software delivery is not mainly a story about choosing a powerful coding model. It is a story about building a managed system around agents.
The speakers describe Uber's direction as a software factory. In this lesson, that means an engineering system that combines models with shared infrastructure, controls, context, execution environments, reusable procedures, and user-facing orchestration. The goal is not only to generate code. The goal is to move work through a repeatable path from an engineering request to a change that people can check, review, and maintain.
Source claim: Udai and Adam present Uber's journey toward a managed software factory. They describe six platform building blocks and report agent use across ordinary pull requests and large migration work, along with increased code output.
The explanations and examples that follow are teaching context built from that source claim. They clarify what the factory idea implies, but they are not additional statements attributed to the speakers.
A coding bot is one station; a factory is the whole system
A coding model can produce a patch from a prompt. That is one useful capability, but it leaves many practical questions unanswered:
- Can the agent reach the right internal systems without uncontrolled access?
- Does it have the repository context needed to make a compatible change?
- Can it start in an environment that is ready for the task?
- Is there a known procedure for this kind of work?
- Which checks produce evidence before a person reviews the change?
- Does the organization learn from the result and improve the procedure?
A coding bot focuses on the generation station. A software factory connects that station to the rest of the production line. This distinction matters because software changes are rarely isolated. They touch repositories, build systems, services, reviewers, and operational constraints.
Teaching example: updating one library across 200 services
Imagine that a company asks an agent to update an authentication library across 200 services.
Generation is only one step. A factory also needs a repeatable way to find the affected services, prepare their environments, apply the change, run appropriate checks, expose the proposed changes for review, and handle the results. It may need to repeat the same controlled process many times.
The model may write much of the code. The factory is what makes that work scalable and governable. Without the surrounding system, the company has a clever worker. With the surrounding system, it has a process that can be reused across many similar jobs.
Uber's six building blocks
The talk presents six platform blocks as the foundation of this managed system:
| Building block | Plain-language role in the factory |
|---|---|
| Model Gateway | A managed entry point for model use. |
| MCP Gateway | A managed entry point for tool capabilities. |
| DevPods | Prepared execution environments where agents can work. |
| Agent Skills | Reusable procedures and guidance for recurring work. |
| Context Graph | Connected information that helps locate relevant context. |
| AI Assistant | A user-facing way to compose and access the platform. |
This table is a map, not a claim that every task must use every block. The blocks are composable. A workflow can draw on the capabilities it needs while retaining the relevant controls.
Teaching example: changing a checkout API and its mobile client
Suppose an agent must change a checkout API and update its mobile client. It may need repository context, a prepared development environment, a procedure for the change, model access, and tools that can inspect or modify internal systems. Another task may need only a subset of those capabilities.
The value of the platform is therefore not that every request follows one enormous fixed path. The value is that teams can assemble different workflows from shared foundations instead of rebuilding access, context, execution, and controls for every individual agent.
The operating baseline comes before autonomous scale
The speakers also describe earlier repository and build investments as part of the baseline. This is an important point. Agents do not remove the need for a workable software environment. They make weaknesses in that environment more consequential because more changes can arrive more quickly.
For an agentic workflow, repositories and builds are not background details. They are the places where the agent finds code, makes changes, and produces evidence. If repository structure is difficult to understand or builds are unreliable, faster generation can create more rework rather than more useful delivery.
This gives the factory a practical dependency order:
- The organization prepares repositories and build infrastructure.
- Shared platform blocks provide controlled access, context, execution, procedures, and orchestration.
- Agents use those foundations to perform repeatable engineering work.
- Checks and later outcomes determine whether the work is useful and how the system should improve.
The first two steps do not guarantee a good result. They make a controlled result possible.
What the adoption signals do—and do not—show
Uber reports broad agent adoption across ordinary pull requests and large automated migrations. It also reports increased code output. These observations explain why a platform approach is needed: when agent use expands beyond isolated experiments, shared foundations become more valuable than one-off integrations.
However, output is not the same as quality. More generated code does not, by itself, show that the code is correct, safe, maintainable, or valuable to the business. Adoption and migration volume are signals about use and scale. They are not independent proof of engineering quality or business impact.
That distinction is central to the rest of the lesson. Later chapters follow the controls and feedback loops that can turn generated output into evidence-bearing engineering work. The factory thesis is not “produce more code and assume success.” It is “build a system in which production, checking, review, and learning fit together.”
The mental model to carry forward
Think of the six blocks as shared stations around an agent, not as six competing products. The model supplies generation, but the platform supplies the conditions under which generation can become dependable work:
┌─────────────────┐
│ AI Assistant │
│ user-facing │
│ orchestration │
└────────┬────────┘
│
┌─────────────────────────┼─────────────────────────┐
│ │ │
┌───────▼────────┐ ┌─────────▼────────┐ ┌────────▼────────┐
│ Model Gateway │ │ MCP Gateway │ │ Context │
│ managed models │ │ managed tools │ │ Graph │
└───────┬────────┘ └─────────┬────────┘ └────────┬────────┘
│ │ │
└─────────────────────────┼─────────────────────────┘
│
┌─────────────▼─────────────┐
│ DevPods + Agent Skills │
│ prepared work + procedure │
└─────────────┬─────────────┘
│
┌─────────────▼─────────────┐
│ repository and builds │
│ the operating baseline │
└───────────────────────────┘
The diagram is a teaching model of the relationships introduced here. It does not mean that all six blocks are invoked in exactly this order.
The key shift is from asking which model can write this code to asking what managed system lets an agent do this work repeatedly, with the right context, controls, evidence, and feedback. The next chapters examine those building blocks one at a time.
Source window: 00:14–01:48 in Agentic SDLC at Uber — Uday Kiran Medisetty & Adam Huda, Uber. The six-block map is shown immediately afterward at about 01:50.