Why Uber frames agentic development as a software factory

Chapter 1 · approximately 00:14.39–01:50.079

By the end of this chapter, you should be able to explain why the speakers treat shared platform foundations as necessary for agentic software development at Uber's stated scale, and describe what the six-block roadmap is meant to provide.

The opening problem is scale, not only model choice

Uday describes a journey toward a managed software factory for a few thousand engineers across 12 global technology sites. In this lesson, a software factory means the managed system that moves engineering work from an idea toward shipped and maintained software.

The factory is not one model that produces code on demand. It is a connected set of capabilities around engineering work: model access, tool access, a place for agents to run, reusable skills, relevant context, and a user-facing entry point. The wider flow also needs validation, review, maintenance, and feedback.

The speakers use agentic AI for AI agents applied across engineering work, including coding and other parts of the software lifecycle. That scope matters. Agentic development is not only a request such as “write this function.” It can support the work around coding that helps an idea become software and keeps that software usable later.

Teaching interpretation: A single team can sometimes assemble its own model client, tools, workspace, and workflow. At the stated organizational scale, many teams would otherwise repeat those setup and control decisions. Shared foundations address common needs once and make them available through a repeatable path. That is the scale argument; it is not a claim that every Uber team uses an identical setup.

The basic terms describe different points in the flow

A repository stores source code and related project files. A monorepo is one repository containing a very large shared codebase. The speakers refer to monorepos with millions of lines of code.

A PR, or pull request, is a proposed code change that can be reviewed and sent through the team's integration process. A migration is a coordinated change to existing code, often repeated across many files or services. Toil is repetitive engineering work; the speakers say their automation is reducing this kind of work.

These terms should not be treated as interchangeable. A migration is work to perform. A PR is a proposed change. Toil describes the repetitive effort that a team wants to reduce. The distinction helps when interpreting the measures Uday mentions later.

What the existing code foundation contributes

Uday points to prior investment in monorepos and a build foundation. A large shared repository gives engineers and agents a common codebase to inspect. A build foundation gives the organization an established way to work with that codebase. The speakers present those investments as preparation for a faster agent rollout than a starting point with disconnected repositories and build setups would have provided.

Preparation is not the same as proof of causation. The monorepo and build foundation give newer agent layers somewhere consistent to operate. They do not, by themselves, provide model policy, tool access, runtime capacity, reusable skills, organizational context, or review.

The build-system name in the supplied transcript is transcribed as “basil.” It may refer to Bazel, but the source does not spell this out. This chapter uses build foundation rather than treating that interpretation as established fact.

Treat reported activity as an indicator, not an outcome

The speakers report agent adoption and toil-reduction figures. They also refer to PR activity, migrations, code volume, and lines of code. Such measures can indicate that work is moving through the system or that the amount of generated code has changed. They do not, on their own, establish better software quality, greater customer value, or a productivity improvement caused by the platform.

Teacher-created example: Suppose an agent opens more PRs and adds more lines than a team previously produced. Those counts show output activity. A reviewer still has to determine whether the changes are correct, useful, safe, and worth maintaining. More PRs can coexist with rejected changes, rework, or defects.

The source gives no definitions, denominators, baselines, or measurement methods for the reported figures. Read them as speaker-reported indicators and rollout or toil-reduction claims, not as a complete productivity or quality evaluation.

The six-block roadmap

Uday then previews six building blocks. Each answers a different platform need. They are complementary layers, not six names for one agent.

Building block	What it contributes to the factory
Model gateway	A common path for model access, so each engineering use case does not have to manage model connectivity separately.
MCP gateway	A common path to tools and internal capabilities. The talk uses MCP for this tool-integration layer.
Agent environments	A prepared place where an agent can inspect, edit, and build software.
Skills	Reusable agent capabilities or workflows that teams can discover, use, and improve instead of recreating.
Context graph	Connected software, organizational, and business context that helps an agent find information relevant to its task.
Assistant	A user-facing way to reach the models, tools, skills, context, and execution capabilities.

The table is a teaching summary of the roles the roadmap previews. It is not an implementation sequence. A useful way to see the relationship is:

model access ───────┐
tool access ────────┼──> agent work in a prepared environment
reusable skills ────┤                 │
connected context ──┘                 ↓
                         coding and wider lifecycle work
                                      ↓
                             validation, review, maintenance
                                      ↑
                                feedback loops

The assistant gives people an entry point. The other five blocks supply different forms of access or support beneath that entry point. The model is not the tool gateway. The runtime is not the context graph. The assistant does not replace validation. Keeping these responsibilities distinct is part of making the system manageable.

Click to enlarge

The slide directly supports the overview request by enumerating six prerequisite platform blocks on the left and showing a four-stage build/use progression on the right. No explicit maturity labels or rollout sequence beyond these visible groupings is shown. Source visual: open the video at 01:38.

The speakers say that the six blocks have different maturity and rollout stages. They do not specify those stages in this opening. The roadmap therefore explains purpose, not equal maturity or general availability.

Why the layers must connect

Here is a teacher-created trace of the dependency the roadmap is meant to clarify. Imagine that a team starts with a feature idea:

1. The assistant gives the team a place to describe the idea and ask for help.
2. The context graph helps locate relevant code, organizational information, and business context.
3. Skills and the MCP gateway provide reusable workflows and access to tools that can investigate or change the software.
4. The model gateway supplies managed model access for reasoning and generation.
5. An agent environment gives the agent a workspace in which it can inspect, edit, and build the code.
6. The resulting work can move through validation, review, and maintenance rather than ending when text or a diff is generated.

This trace explains why the speakers present a factory instead of a standalone code generator. If the layers are isolated, engineers may need to configure access repeatedly, move context between systems, and build one-off workflows. A connected platform can make the path repeatable while leaving each responsibility visible.

More automated changes also create downstream work. Reviewers may receive more proposed changes. Build and validation systems may process more work. Teams may need to maintain generated code and remove changes that are no longer needed. A guardrail is a control around agent or model use that enforces a rule; a feedback loop uses what happened in one run to improve a later run. These controls and capacity decisions belong beside generation in a managed factory.

Contrasts to keep in view

A model is not a factory. A model generates an answer from the information it receives. A factory includes the access, tools, runtime, context, workflows, user interface, and later checks that make engineering work repeatable.

More output is not automatically more value. PR counts, migration counts, code volume, and line counts describe activity or output. They need quality and outcome evidence before supporting a stronger conclusion.

Agentic development is wider than code generation. The speakers place it across the lifecycle, including the work that precedes implementation and follows it. The roadmap is therefore about connecting engineering work, not only asking a model to write code.

Check your understanding

1. Why does Uber's stated scale make shared foundations more important than simply giving engineers access to a model?

   Answer: A few thousand engineers across 12 sites would otherwise repeat model, tool, environment, context, and workflow setup. Shared layers make common access and controls repeatable across teams.

2. If PRs and lines of code increase, what can those measures show, and what can they not show by themselves?

   Answer: They can show increased activity or output. They cannot by themselves show better quality, business value, or a causal productivity improvement without definitions, baselines, and outcome evidence.

Synthesis

The opening frames agentic development as a managed software factory because the work must operate across a large organization and a broad lifecycle. Prior monorepo and build investments provide a useful starting foundation, while the six-block roadmap adds shared model access, tool access, agent environments, reusable skills, connected context, and an assistant. The purpose is not simply to generate more code. It is to connect engineering work end to end while preserving the controls, feedback, and capacity needed to manage what agents produce.

Source boundaries and uncertainties

This chapter covers approximately 00:14.39–01:50.079. The build-system name remains transcribed as “basil”; it may refer to Bazel, but that is not established by the supplied source. The adoption, toil-reduction, PR, migration, code-volume, and line-count figures are speaker-reported without stated definitions, baselines, or measurement methods. The speakers say the six blocks are at different maturity and rollout stages, but do not specify those stages here.