13:18 - 14:18
Minion turns the prototype plan into a draft change
The previous chapter left the illustrative stadium-pickup idea as a prototype plan. That plan carried the product and design discussion far enough to begin implementation, but it was not a shipped feature. This chapter follows the handoff from Cortana, the assistant used for the earlier research and design work, to Minion, Uber's cloud coding agent solution.
By the end of this chapter, you should be able to describe that handoff and explain why, for a more complex end-to-end feature, the demonstration stops at a draft pull request (draft PR), a proposed change kept for inspection, before continuous integration (CI), the automated-check stage for a submitted change.
The handoff changes the kind of work
A prototype plan is an implementation-oriented description of what the team intends to build and how it should fit the existing application and backend context. It is not code that has already been accepted. The handoff changes the task from exploring the feature to producing a candidate change:
- Cortana helps turn the product and design discussion into an implementation context.
- That context is handed to Minion.
- Minion works in a prepared development environment instead of responding only in a chat window.
- The resulting code changes are collected for review rather than treated as integrated code.
The source does not explain the exact mechanism that transfers information from Cortana to Minion. What it supports is continuity: Minion starts with the feature context produced during research and design, not with an isolated request to generate a code snippet.
The following is a teaching summary of that flow:
prototype plan and existing feature context
↓
Minion in a prepared dev environment
↓
inspect frontend and backend code
↓
make coordinated changes across repositories
↓
draft PR(s)
Interactive and autonomous execution
Minion supports two execution modes. In interactive mode, a person works with the coding agent while it performs the task. In autonomous mode, Minion proceeds with less direct, step-by-step interaction.
These modes describe how much collaboration happens during execution. They do not say whether the resulting change is correct, approved, or ready to merge.
| Mode | What changes | What it does not imply |
|---|---|---|
| Interactive | A person stays involved while Minion works. | Every intermediate result is correct or ready to merge. |
| Autonomous | Minion proceeds with less direct interaction. | The change is trusted, integrated, or exempt from review. |
This separates an execution choice from a review state. A task can run autonomously and still stop at a draft PR.
Why the workspace matters
Minion is not presented as a chat interface that only writes a code snippet. The demonstration ties it to the prepared development environment described earlier in the lesson. That environment supplies a full build workspace in which the agent can inspect repositories, edit files, and work across repository boundaries.
For this feature, the scope includes both frontend and backend changes. As a teaching example, a frontend screen can look plausible while the backend integration is missing or inconsistent. Working across the relevant repositories lets Minion treat the feature as a connected change rather than a UI-only patch. The source does not describe Minion's internal architecture or permission model, so this does not mean that it can access every repository without restrictions.
The first visual shows the agent working across repositories:
Caption: A Minion cross-repository review view shows changes found in go-code and ios-code while android-code is still being read.
The UI visibly presents a cross-repository review state. Two repositories show identified file changes, a third repository is still marked as reading, and the review summarizes 246 changed lines. The count describes displayed change activity. It does not establish that the changes are correct or that the feature works. Source at 13:42
A draft PR is a control boundary
A pull request (PR) is a proposed code change sent through a team's review and integration process. A draft PR is a PR intentionally kept in a draft state so people can inspect it before it moves to the next gate. It is not a completed or landed feature.
CI, or continuous integration, is the automated-check stage that runs against a change submitted to that workflow. CI and code review have different jobs. CI runs the checks defined by the engineering workflow. Reviewers examine the proposed change and the evidence around it.
For the demonstration, Minion stops after creating a draft PR and before sending the change to CI. The sequence is:
- Minion works from the prototype plan in the prepared development environment.
- It reads and changes the relevant frontend and backend repositories.
- It groups the work into draft pull requests.
- The team can inspect the cross-repository proposal before sending it to CI.
This creates a boundary between a generated change and a validated change. The generated code exists as a proposal, but the workflow has not claimed that it passes CI, has received human approval, or has been integrated into the codebase. The draft boundary also leads into the inner and outer validation loops described in the next chapter.
The second visual makes the pre-CI state explicit:
Caption: A Minion workspace shows changes across three repositories and three draft pull requests, while the presenter appears in an inset.
The UI visibly presents a cross-repository workspace with draft pull requests and an explicit pre-CI status. It directly illustrates a draft PR before CI. The display does not show a correctness result, a CI result, or a landed feature. Source at 13:50
Why CI is delayed for this demonstration
The speakers say that Minion works well for toil, repetitive engineering work such as applying a similar migration across many places. They contrast that with a more advanced end-to-end feature, whose behavior must be coordinated across frontend code, backend integration, and product requirements.
The reason for stopping before CI is therefore about validation and capacity. The speakers want to validate a complex feature first and avoid adding unnecessary load to shared CI. Keeping the change in draft creates an earlier inspection step. The team can examine the generated changes and decide when the proposal is ready for CI.
The following comparison is teacher-created. It explains the distinction; it does not report a particular migration from the talk.
| Work type | Why the automation boundary may differ |
|---|---|
| Repetitive migration | The transformation is narrow and repeated, so its intended result can often be checked against a known pattern. |
| Complex end-to-end feature | The change crosses frontend and backend boundaries and must preserve product behavior. It needs more context and validation before autonomous work enters shared CI. |
This is a sequencing choice, not a replacement for CI. A draft PR has not shown that the feature builds, integrates, or behaves as intended. Nor does the distinction mean that Minion can never work autonomously on an advanced feature. It means the team can choose stronger validation before a cross-system change enters the outer workflow. Execution mode and validation strength are separate decisions.
What the demonstration does and does not establish
The presentation shows Minion reaching a cross-repository review state and creating draft PRs before CI. It does not provide the actual diff or a correctness result. The visible changes are evidence of the workflow state shown in the presentation, not evidence of a successful implementation.
The talk also leaves Minion's internal architecture, permission boundaries, and exact Cortana-to-Minion handoff unspecified. Those details would matter in a production design, but they are outside what this demonstration establishes.
Check your understanding
1. If Minion runs autonomously and creates three draft PRs before CI, has the feature been integrated?
No. Autonomous execution only changes how much direct interaction happens during the task. The draft PRs remain proposals, and the feature has not yet passed CI, human review, or integration.
2. Why might a repetitive migration be automated earlier than a complex frontend-and-backend feature?
A repetitive migration usually applies a narrower, more repeatable transformation. An end-to-end feature crosses more boundaries and carries more behavior to validate, so the team may require an inspection step and stronger validation before sending it into shared CI.
Synthesis
The handoff carries a prototype plan from Cortana into Minion's prepared cloud development environment. Minion can work interactively or autonomously and can coordinate frontend and backend changes across repositories. The demonstration stops at draft PRs before CI so the generated work remains inspectable while the team decides when it is ready for validation. That state is a proposed code change, not proof that the feature is correct or finished.