Scale Bottlenecks and the Build-Versus-Should-Build Decision

Chapter idea: When agents make software generation faster, writing code stops being the only limit. The scarce resources move toward infrastructure, CI, validation, experiments, monitoring, and human decisions.

The shift in the limiting factor

The speakers close by noting that monitoring and other parts of the software lifecycle still remain. They then identify several emerging constraints: infrastructure, CI, validation, experiments, and decisions. The closing slide places these constraints beside the agentic SDLC and the reusable platform building blocks (around 17:23–17:34 in the video).

A bottleneck is the constraint that limits the throughput of the whole system. If coding becomes twice as fast but CI can process no more changes, the system does not deliver twice as much validated software. The waiting line has simply moved to CI.

This is the main scale lesson:

Faster generation
        ↓
More candidate changes
        ↓
More demand for environments, CI, validation, and experiments
        ↓
More need to choose which work deserves those resources

The important measure is therefore not code volume alone. It is the amount of useful, validated, maintainable change that the organization can absorb.

What each emerging constraint means

The talk names the constraints but does not fully specify a monitoring design or quantify each limit. The following interpretation explains their role in the system without adding a claim about Uber's exact implementation.

Constraint	Why faster generation can expose it
Infrastructure	More agents need more execution environments, storage, model access, and other shared capacity.
CI	More proposed changes create more builds and tests for shared automation to process.
Validation	Generated code needs static, visual, integration, and other checks before it can be trusted.
Experiments	Product variants need test capacity and enough attention to interpret results.
Monitoring	After release, production behavior still needs observation. Passing development checks does not answer every production question.
Decisions	People must still decide which opportunities to pursue and which results justify continuing.

These constraints are connected. For example, an agent can generate many variants of a stadium pickup feature. Each variant may consume build capacity, validation capacity, experiment capacity, and later maintenance capacity. Generation makes the options cheaper to create, but it does not make every downstream activity free.

Monitoring is a separate loop

The closing slide includes monitoring as a lifecycle stage, but the source does not explain its tools, signals, or operating process. That boundary matters. We should not infer a particular dashboard, alert policy, or metric from the slide.

The general distinction is clear, however:

• Pre-release validation asks whether the change behaves acceptably in the checks available before release.
• Production monitoring asks what happens when the released change meets real traffic and operating conditions.

Teaching example: monitoring as the next loop

Suppose the stadium pickup feature has passed development checks and ships. Those checks may provide evidence that the code builds, the user interface matches its design closely enough, and the frontend can communicate with the staged backend. Monitoring begins with a different question: is the released feature behaving acceptably in operation?

This does not mean that monitoring replaces CI or earlier validation. It extends the feedback loop beyond release. A software factory that generates changes quickly must manage both the speed of creating changes and the ability to learn from their real-world behavior.

When CI and experiments become scarce

Imagine that a software factory increases the number of candidate changes from 10 per week to 100 per week. If shared CI and experiment infrastructure remain unchanged, several outcomes are possible:

1. CI queues become longer.
2. Reviewers see more changes at once.
3. More variants compete for a limited experiment budget.
4. Results take longer to interpret because more work is running or waiting.

The exact numbers are illustrative, not claims from the talk. The mechanism is the point: accelerating one stage increases pressure on later stages. Capacity planning must follow the entire path from generation to validation, experimentation, release, and monitoring.

A useful response is not automatically “generate less.” It may be to improve the constrained stage, schedule work more carefully, reject low-value candidates earlier, or make the evidence needed for a decision cheaper to obtain. The right response depends on which constraint is actually limiting throughput.

“Can we build it?” versus “Should we build it?”

The speakers describe a change in the central question. As building becomes easier, the organization must spend more effort deciding whether a proposed thing should be built at all.

These are different questions:

• Can we build it? Is the implementation technically feasible with the available agents, code, environments, and controls?
• Should we build it? Is the expected value high enough to justify the validation, experiment, operational, and maintenance capacity it will consume?

Technical feasibility is necessary, but it is not sufficient. A system can make five ideas easy to implement while still having enough capacity to test only two.

Teaching example: five variants, two experiments

Assume a team can implement five stadium pickup variants. Its experiment system can test only two at a time. The capability to build all five expands the option set, but it does not create five experiment slots.

The team now needs a selection rule. It might compare expected user value, confidence in the hypothesis, implementation risk, or learning value. Those criteria are teaching context; the source does not prescribe one. The source-grounded conclusion is that product judgment becomes more important when implementation is no longer the main difficulty.

Build capability:       5 variants are technically possible
Experiment capacity:    2 variants can be tested now
Decision required:      choose the two that deserve scarce evidence capacity

The same reasoning applies after the experiment. A result may justify shipping, revising, stopping, or maintaining a feature. Every choice consumes some combination of engineering, infrastructure, reviewer, experiment, and operational capacity.

The broader software-factory model

This chapter completes the lesson's progression. The earlier platform layers make agentic work possible at organizational scale. The lifecycle then connects research, design, coding, early checks, CI, review, maintenance, and monitoring. At the end, the platform's success is not measured by how many changes agents can produce in isolation.

It is measured by whether the organization can:

1. create useful candidates quickly;
2. validate them with appropriate evidence;
3. spend shared capacity on the strongest opportunities;
4. observe what happens after release; and
5. use those outcomes to improve future work.

The final decision is therefore an allocation decision. Agentic systems increase what a team could build. A managed software factory must also help the team decide what is worth building, validating, operating, and maintaining.

Source boundary: In the closing segment, the speakers name monitoring and the listed bottlenecks, then contrast the ability to build with the question of whether something should be built. The talk does not provide a detailed monitoring specification or a universal prioritization formula.

Source: Agentic SDLC at Uber — Uday Kiran Medisetty & Adam Huda, chapter 15 (17:16–18:22).