Self-Healing CI and Evidence-Bearing Code Review

The previous chapter moved several checks into the developer's inner loop. This chapter continues outward to shared CI and human review. The goal is not to remove those stages. The goal is to make them more useful:

• CI can repair a limited class of predictable failures and try again.
• Some review checks can happen earlier, before a human opens the pull request.
• Deeper review can use a more capable model when the change justifies the cost.
• An autonomous pull request can arrive with visible evidence of the checks it already passed.

The result is a shorter repair loop without treating automation as proof that a change is safe.

The basic distinction: inner loop and outer loop

The inner loop is the fast feedback cycle inside the agent's prepared development environment. It can catch problems while the change is still being produced. The outer loop is shared validation around the pull request, including CI and later review.

Moving a check inward usually makes a failure cheaper to fix. The same check can still matter in the outer loop because the shared system provides an independent boundary and validates the proposed change in its repository context. “Earlier” does not mean “optional.”

This gives the workflow two useful properties:

1. Fast local correction: an agent can discover and repair many problems before it asks shared infrastructure to do work.
2. Independent release evidence: CI and review still examine the change before merge.

The chapter's design is therefore a layered set of checks, not a single gate that an agent is expected to pass perfectly.

Self-healing CI is a bounded loop

Self-healing CI means that the CI system can respond to some failures instead of stopping immediately. The important word is some. It does not mean that CI can diagnose and repair every failing build.

A safe mental model is:

run CI
  ↓
classify the failure
  ↓
is this failure class supported?
  ├─ no  → report the failure for normal handling
  └─ yes → apply the allowed repair
                    ↓
                 rerun CI
                    ↓
          pass, or report the remaining failure

The classification step limits the system's authority. A repair is allowed only when the failure matches a known, supported class. The rerun then supplies new evidence. If the rerun passes, the system has shown that this particular repair resolved the checked failure. If it does not pass, the loop should stop and expose the unresolved result rather than continue changing the code without a clear boundary.

Example: a stale-base conflict

Suppose an agent creates a draft PR. Before CI starts, the target branch changes. The PR is now based on stale code, so the proposed change no longer applies cleanly. This is a stale-base conflict.

One bounded self-healing path is:

1. CI identifies the stale-base condition.
2. The system rebases the change onto the current target branch.
3. CI runs again on the repaired state.
4. The result is recorded as a pass or as a remaining failure.

The visible flow in the talk shows these classify, repair, rerun, and pass states at about 15:07. This is a useful example because rebasing is a recognizable repair with a clear trigger. It does not justify the broader claim that arbitrary test failures or design problems can heal themselves.

Put model depth where it earns its cost

Not every check needs the same model. A quick check may run often, so speed and cost matter. A cross-repository change may require more reasoning, so a slower and more capable model can be appropriate at that gate.

This is model tiering: assigning different model sizes or capabilities to different jobs. The trade-off can be described as follows:

Gate	Typical need	Useful model property
Inner-loop check	Run frequently and return quickly	Small, fast model
Ordinary review check	Inspect a routine change	Balanced speed and reasoning
Deep outer review	Reason across repositories or a complex change	More capable model

This arrangement avoids two opposite mistakes. Using the strongest model for every edit can make feedback too expensive or slow. Using a small model for every decision can miss relationships that require broader reasoning. The right question is not “Which model is best?” in isolation. It is “How much reasoning does this gate need, and how often will it run?”

An autonomous PR must carry its provenance

Autonomy changes how a change is produced. It does not remove the need for human authority over whether the change should land. That is why an autonomous PR should make its prior work inspectable.

In the talk, Minion's autonomous cross-repository PR includes a table of checks performed earlier and screenshots or reports attached as validation evidence. The reviewer can inspect the diff together with the checks that produced it. The evidence does not replace review. It gives review a concrete starting point.

Think of the PR as carrying a small evidence packet:

change proposal
├── cross-repository diff
├── checks already run
├── results of those checks
└── screenshots or attached validation reports

This is provenance: information about how an artifact was produced and checked. It answers questions such as:

• What did the agent change?
• Which validations ran before review?
• What did those validations report?
• Can a reviewer inspect the supporting output?

The value is not that a checklist creates trust automatically. The value is that the reviewer can see the basis for the agent's proposal instead of relying on the fact that the proposal was generated autonomously.

Example: reviewing an autonomous cross-repository change

Imagine that Minion proposes one feature across several repositories. A reviewer opens the cross-repository diff. Alongside it, the PR shows the checks that ran earlier and attaches their screenshots or reports.

The reviewer can use that information to focus attention:

1. Confirm that the proposed files match the intended scope.
2. Check which inner-loop and CI validations actually ran.
3. Inspect the attached output for failures, omissions, or surprising results.
4. Use human judgment to decide whether the change should land.

This division of labor is important. Automation gathers and presents evidence. Human review retains the merge decision. A successful check can show that a tested condition held; it cannot establish that the feature is valuable, that every relevant condition was tested, or that the change should be deployed.

The combined pattern

Self-healing CI, tiered models, and evidence-bearing PRs solve different parts of the same scaling problem:

Problem	Mechanism	Boundary that remains
A known infrastructure or integration failure blocks validation	Classify, repair, and rerun	Only supported failure classes are repaired
Every check cannot afford deep reasoning	Match model depth to the gate	Important changes still need deeper review
Autonomous work is hard for a human to assess	Attach checks, results, and screenshots or reports	Human review and merge authority remain

Together, these mechanisms make the outer loop more efficient without pretending that it is unnecessary. The system spends shared capacity on changes that have already received earlier feedback, repairs only failures it understands, and gives reviewers evidence they can inspect.

What this means for an agentic SDLC

The chapter's broader lesson is that autonomy must be paired with controlled recovery and visible evidence. A coding agent that produces more diffs is not yet a dependable software factory. Dependability comes from the surrounding system:

• checks are placed where feedback is fast enough to act on;
• repairs have explicit supported boundaries;
• model capability is allocated according to the reasoning task;
• every autonomous change remains reviewable;
• prior validation is retained as part of the change's record.

At about 15:48, the talk shows validation proof attached before human review. That visual grounds the chapter's final point: autonomous origin should increase the need for inspectable provenance, not reduce the need for review.