14:18 - 15:54
Move validation inward, then make the outer loop self-healing and reviewable
Minion has produced a change and placed it in a draft pull request (PR). A draft PR is a proposed change that is still open for inspection. It is not a landed feature. This chapter follows the validation work between that draft and human review.
By the end, you should be able to distinguish the inner loop from the outer loop, trace where static, visual, integration, CI, and code-review checks occur, and explain how an evidence table helps a person review an autonomous diff.
An autonomous diff is a set of code changes that Minion produced autonomously. Continuous integration (CI) is the shared automated workflow that runs checks on a proposed change. The Figma specifications are the intended screen designs used as the visual comparison point in this chapter.
The speakers' design has two connected goals:
- Find and fix more problems before a change reaches shared CI.
- Keep the checks that remain visible enough for a person to review an autonomous change efficiently.
The design changes where feedback arrives and how it is recorded. It does not remove validation.
The two-loop model
The inner loop is the fast, earlier feedback cycle around a change. The outer loop is the later CI and code-review cycle that the change still enters after the inner checks. These names describe when and where feedback happens. They do not describe two different kinds of code.
An earlier check can find a code, UI, or integration problem while the change is still close to the agent that produced it. Fixing that problem then avoids sending an easily detectable failure to shared CI for the first time. The outer loop still supplies CI and deeper review for the remaining change.
The flow can be summarized like this:
autonomous diff
|
v
inner loop: code + visual UI + backend integration
|
v
outer loop: self-healing CI + agentic code review
|
v
human review, with evidence attached to the diff
This is a teaching summary of the sequence described by the speakers. The talk gives examples of checks, rather than a complete inventory for either loop.
Source visual — The slide visually distinguishes an inner validation loop that checks code and generated UI from an outer loop involving self-healing CI and agentic code review. Its displayed results show issues being auto-fixed, some items flagged for review, and the pull request moving toward human attention. Source at 14:19
What moves into the inner loop
The inner loop brings different kinds of evidence together. Each check answers a different question about the same change.
Static analysis checks code without running the full feature
Static analysis is automated inspection of code without running the full feature. The speakers want some static checks to happen earlier. This can expose code-level problems before the change enters the slower, shared part of the workflow.
Putting a check in the inner loop does not mean that CI will never run a related check. It means useful first feedback should arrive before the outer CI stage.
Visual validation checks the running UI
Visual validation launches the application in a simulator, captures a screenshot of the generated UI, and compares it with the Figma specifications. This checks the interface as it appears while running.
Static analysis cannot answer that question. Code can pass code-level checks while a button, layout, or screen looks different from the intended design.
Source visual — The visual provides direct evidence of a validation dashboard progressing through code validation, visual validation, and backend staging, with checks, an auto-fix count, and flagged items visible. Source at 14:41
Backend staging checks integration
The speakers also describe bringing up the backend service in a staging environment. Here, staging is a service environment used to check a change before the outer loop. The check asks whether the frontend and backend work together in the prepared environment.
These checks should not be treated as interchangeable:
| Check | Question it answers |
|---|---|
| Static analysis | Does the code show problems that can be found without running the full feature? |
| Visual validation | Does the running UI resemble the intended Figma design? |
| Backend staging | Do the frontend and backend work together in the prepared environment? |
This table is a teaching aid, not a claim that these are the only checks in the speakers' inner loop. The design choice is to obtain these different kinds of evidence before shared CI and deeper review.
What remains in the outer loop
The outer loop still matters. It adds shared CI and a deeper code review after the earlier checks.
Self-healing CI
Self-healing CI is the speakers' term for CI that fixes many issues it encounters instead of only reporting failures. The word many matters. It is not a promise that every failure is corrected without human involvement.
The validation interface shows one recovery pattern. A CI run encounters a merge conflict. The system classifies the failure, performs an automatic rebase, and runs CI again. The supplied visual shows passing checks after that rerun. This demonstrates a known recovery step, not a complete description of every failure the system can handle.
Source visual — Across the supplied nearby frames, the UI progresses from a merge-conflict failure to classification and then an automatic rebase with passing checks, making the recovery state visible. Source at 14:51
Deeper agentic code review
The speakers pair the outer loop with agentic code review. They describe choosing models according to the job performed by each loop:
- The inner loop uses a smaller, faster model for quick feedback.
- The outer review uses a more powerful model and a reasoning skill for deeper review.
These choices are complementary. A fast model fits frequent feedback with a short wait. A more capable model fits a later review that needs deeper reasoning about the remaining change. The plan does not specify the exact model names or sizes, so no stronger comparison can be made.
Evidence makes an autonomous diff reviewable
The speakers propose attaching the validation record to the autonomous diff. The record includes the checks that ran and visual evidence such as screenshots. It can also show issues that were automatically fixed and items that remain flagged.
That record gives a human reviewer a path through the change:
| Evidence | What the reviewer can inspect |
|---|---|
| Code-validation result | Which code checks ran and what they found |
| Screenshot and visual result | How the running UI compared with the intended design |
| Backend-staging result | Whether the frontend and backend were checked together |
| CI recovery or failure | Whether CI needed a rebase, rerun, or further attention |
| Review findings and flags | Which issues the system identified and which questions remain |
This is an explanatory representation of the evidence described by the speakers, not a claimed schema for the PR. The evidence table does not approve the change. It makes the path to approval inspectable. Human review remains the final activity named in this flow.
Source visual — The visual directly presents self-healing CI as part of nested validation and review loops, with an example status panel showing an automatic rebase, CI rerun, completed validation, and handoff to human review. Source at 15:50
Teacher-created tracing example
The following scenario is teacher-created. It illustrates the sequence; it is not a result reported in the talk.
Suppose an autonomous agent changes a mobile screen and the backend endpoint that supplies it. The validation record could be traced as follows:
- The inner loop runs static analysis.
- It launches the simulator, compares a screenshot with Figma, and records the visual result.
- It brings up the backend in staging and checks the integration.
- The system fixes issues it can handle and flags the rest.
- The outer loop runs CI. If a merge conflict occurs, self-healing CI can attempt the described rebase-and-rerun recovery.
- A deeper agentic review examines the remaining change.
- A human reviewer uses the checks, screenshots, and flags to decide what still needs attention.
Each stage leaves information for the next stage. That is why evidence belongs with the diff rather than being treated as a separate presentation artifact.
Keep the distinctions clear
Moving validation inward does not eliminate CI or code review. It changes the point at which some problems are found, so the outer loop receives a better-prepared change.
Self-healing CI does not mean that no human is needed. The speakers describe fixing many issues, while the scope of that capability remains unspecified. Unresolved or flagged items still belong in review.
Visual validation is not cosmetic. The screenshot comparison tests the running interface, and backend staging tests frontend/backend integration. Static analysis answers a different question and cannot replace either one.
The faster inner-loop model and the deeper outer-loop model are also not competing answers to one universal model-selection question. The first is chosen for feedback speed. The second is chosen for more demanding review reasoning.
Check your understanding
1. Where should the first static-analysis feedback occur in the described design, and does that remove CI?
Answer: It occurs in the inner loop, before the outer CI stage. CI remains part of the workflow. The goal is to find some problems earlier and reduce avoidable shared work.
2. Why attach screenshots and check results to an autonomous diff?
Answer: They show a human reviewer what was checked, what was fixed, and what remains flagged. They support review by making the process inspectable, but they do not replace human review.
Synthesis
The speakers move static, visual, and frontend/backend integration feedback into a fast inner loop. They keep self-healing CI and deeper agentic code review in the outer loop. A smaller, faster model serves early feedback, while a more capable model and reasoning skill serve later review. The checks, screenshots, recovery steps, and flags travel with the autonomous diff so a human can evaluate the change with visible evidence.
The transcript does not define a complete inventory for either loop, the exact scope of self-healing CI, or the model names and sizes. Its word for making the loops more check-heavy is garbled and is rendered in the plan as “aensified.” This chapter therefore describes the intended operation as shifting more checks into the inner loop, without turning that interpretation into a claim that every failure is fixed automatically or that every autonomous diff is safe to merge.