Building with Minion Before CI

The previous stage turns an idea into a working plan: requirements, design choices, and a map of the repositories that must change. This chapter shows the handoff from that planning work to code production.

The key design choice is the stopping point. Minion, Uber's cloud coding agent, creates draft pull requests (PRs), but the demonstration does not send those changes into shared continuous integration (CI) yet. This creates a cheap checkpoint where people and local checks can find problems before the work consumes shared CI capacity.

The handoff: from intent to implementation

Cortana has been used as the planning and orchestration surface. In the walkthrough, it has assembled:

• requirements for the stadium pickup feature,
• design artifacts, including the proposed user experience, and
• a code map covering three repositories.

Cortana then hands this prepared plan to Minion. Minion is specialized for changing code in a cloud development environment. The handoff matters because Minion receives more than a short request such as “build this feature.” It receives the decisions and boundaries produced during research and design.

At about 13:24, the checked requirements and design artifacts are shown being handed to Minion. The frame supports the existence of a prepared handoff; it does not by itself show every implementation step.

Why use separate agents?

Planning and coding are related, but they answer different questions:

Responsibility	Main question
Planning and orchestration	What problem should be solved, with what scope and design?
Coding	Which files and services must change, and how can the planned change be implemented?

Keeping these responsibilities distinct makes the boundary visible. A coding agent can work from a stable plan instead of repeatedly rediscovering the product and engineering context. Conversely, the planning agent does not need to be the component that edits every repository.

This separation is a teaching model for the workflow, not a claim that the agents have no overlapping capabilities. The source claim is narrower: Cortana hands the plan to Minion, Uber's cloud coding agent.

Two ways to run Minion

Minion can run in either of two interaction modes:

1. Interactive mode keeps an engineer involved while the work proceeds. The engineer can inspect progress, answer questions, or redirect the agent during execution.
2. Autonomous mode lets Minion proceed toward its goal with less ongoing intervention.

The important distinction is the amount and timing of interaction. It is not a distinction between “safe” and “unsafe,” and it does not remove the need for evidence. An autonomous run still needs a reviewable result. An interactive run still needs checks before its changes are trusted.

Mode	Human interaction	What still remains necessary
Interactive	Frequent steering and clarification	Validation, review, and an approval boundary
Autonomous	Less frequent intervention	Validation, provenance, review, and an approval boundary

In other words, autonomy changes how often a person steers the work. It does not automatically grant permission to merge or deploy it.

Why stop at draft PRs?

A draft PR is a visible proposal that is not yet ready to merge. In this demonstration, Minion produces three draft PRs for the stadium feature. CI has not been triggered at that point.

That boundary creates an early validation stage:

Prepared plan
    |
    v
Minion implements across repositories
    |
    v
Three draft PRs  <-- inspect and validate here
    |
    v
Shared CI, later review, and merge decisions

The reason is operational as well as procedural. Shared CI has finite capacity. Sending every incomplete or obviously unsuitable attempt into CI would spend that capacity before the change is ready. A draft state lets the team inspect the generated work and perform early checks first. Only then does the change continue toward the outer validation loop.

This does not mean that draft PRs prove the feature is correct. They are a checkpoint, not a completion certificate. They show that Minion produced reviewable artifacts. The later workflow still needs CI and human decisions.

At about 13:49, the demonstration shows three draft PRs while CI has not yet been triggered. This visible status grounds the pre-CI boundary.

A concrete mental model

Imagine a feature that requires coordinated changes in a mobile client, a routing service, and another supporting repository. A bare coding prompt asks an agent to discover all of this while it edits. The Minion workflow instead starts after the planning stage has identified the intended behavior and the affected repositories.

Minion can then work in a full cross-repository devpod, which is Uber's prepared cloud development environment for this work. It can execute interactively or with more autonomy. Its first externally visible result is not an automatic merge. It is a set of draft PRs that people and later validation systems can inspect.

The example illustrates a broader principle: generate early, authorize later. Code production can be automated without making merge or deployment automatic. The draft boundary preserves human authority while allowing the coding agent to do substantial work.

What this stage contributes to the software factory

This chapter connects three platform ideas:

1. Prepared context: the plan carries requirements, design, and repository relationships into implementation.
2. Prepared execution: Minion works in a cloud devpod suited to cross-repository coding.
3. Staged evidence: draft PRs make the result inspectable before shared CI begins.

Together, these ideas make the workflow more than a model generating code. The platform controls the handoff, supplies an execution environment, and places an explicit gate before expensive shared validation.

Source boundary

The video presents Minion as Uber's cloud coding agent, shows interactive and autonomous operation, and demonstrates three draft PRs before CI is triggered (approximately 13:18–14:16, with the highlighted frames at 13:24 and 13:49). The explanations about finite CI capacity, separate planning and coding responsibilities, and the meaning of a draft boundary are teaching interpretations of that workflow. They do not claim that the demonstration merged or deployed the feature.