Densifying Validation into the Inner Loop

The previous chapter stopped Minion at draft pull requests, before shared CI. This chapter explains what happens before that outer gate: several useful checks move closer to the code-generation environment.

The speakers describe three kinds of early validation:

1. Static analysis checks code structure and rules.
2. Visual validation compares a rendered interface in a simulator with its Figma specification.
3. Frontend/backend staging checks exercise a mobile flow against a staged backend service.

These checks do not remove CI. They make the first feedback arrive earlier, while the later outer loop still provides another validation boundary.

Inner and outer loops

An inner loop is the fast cycle that runs close to development. A developer or coding agent makes a change, runs checks, sees a failure, repairs the change, and tries again. An outer loop is a later, more shared process such as CI and review.

The word inner describes position and speed in the workflow. It does not mean “less serious” or “optional.” A check can be rigorous and still belong in the inner loop when it can run earlier and return feedback quickly.

The talk's diagram places code, visual, and integration checks inside the inner loop. It keeps CI and agentic review in the outer loop, before human review. The design therefore has two layers of evidence rather than one large check at the end:

                 generated change
                       │
                       ▼
        ┌─────────────────────────────┐
        │          Inner loop          │
        │  code · visual · integration │
        └──────────────┬──────────────┘
                       │
                       ▼
        ┌─────────────────────────────┐
        │          Outer loop          │
        │          shared CI           │
        │       agentic review         │
        └──────────────┬──────────────┘
                       │
                       ▼
                  human review

The practical goal is to reduce the distance between a bad change and the place where it can be repaired. If a generated change fails a check in the devpod, the agent can address it before the change consumes shared CI capacity or reaches a reviewer.

Teaching context: This is similar to finding a spelling error while writing a document instead of after sending it for publication. The later review still matters, but the cheap and immediate correction should happen first.

1. Static analysis: catch code problems before CI

Static analysis inspects code without running the complete program. It can detect violations of known rules, such as a required structure or a forbidden pattern.

In the chapter's teaching example, a generated change violates a code rule that can be detected in the devpod. Running that check in the inner loop changes the repair path:

generate change → run static analysis → find violation → repair → rerun

The value is not that the check becomes more correct merely because it runs earlier. The value is that the feedback is local to the work that caused the problem. The agent can receive a precise failure while its repository context and execution environment are still available.

Moving a check inward also avoids a misleading success signal. A draft PR may exist, but its code is not ready for the outer pipeline if a fast local check already identifies a violation. Early failure is useful because it prevents a known problem from being handed to a slower, shared stage.

The outer check remains important. The inner run may use the development environment and the outer run may apply the organization's shared CI rules and conditions. The same broad category of check can provide useful evidence at both boundaries.

2. Visual validation: turn a design into a check

Code can satisfy structural rules and still render the wrong interface. The walkthrough addresses this gap by comparing the generated pickup UI with its Figma design.

The mechanism joins three things:

1. a design specification in Figma;
2. an implementation produced by the coding agent; and
3. a rendered view in a simulator.

The comparison makes the design artifact part of the validation path. Instead of asking only whether the code compiles, the team can ask whether the running interface resembles the interaction that was agreed during design.

At about 14:18, the talk's diagram shows code, visual, and integration checks inside the inner loop while CI and agentic review remain outside it.

Teaching context: A Figma file is normally a design artifact. It becomes an executable check only when the workflow can render the implementation and compare the result with that artifact. This does not by itself prove usability, accessibility, or product success. It answers a narrower question: does the implementation match the intended visual design closely enough for this gate?

This distinction prevents two opposite mistakes. Treating a mockup as proof of a working feature is too strong. Treating visual comparison as decoration is too weak. The comparison supplies evidence about an important part of the feature while leaving other questions for later checks and review.

3. Frontend/backend staging: test the boundary between components

The pickup experience crosses a service boundary. A mobile client is the frontend: it presents the user flow. A backend service supplies behavior or data that the client needs. Checking each part alone can miss a mismatch between them.

The demonstration uses a staged backend service and validates the mobile clients against it. This brings an integration check into the inner loop before the change reaches the later shared pipeline.

The question is different from the static-analysis question:

Check	Main question
Static analysis	Does the code obey detectable structural rules?
Visual comparison	Does the rendered UI match the Figma specification?
Frontend/backend staging	Do the connected client and service work together in the demonstrated flow?

In this example, a mobile component can look correct in isolation and still fail when it requests data or behavior from the backend. Conversely, a backend endpoint can be healthy by itself while the client sends the wrong request or interprets the response incorrectly. A staged cross-layer check exposes that boundary mismatch earlier.

At about 14:48, the demonstration shows mobile clients being validated against a staged backend service through a completed integration checklist.

The staging environment is useful because it gives the client something close enough to the service boundary to exercise the feature without requiring production traffic. It is still a test environment, so passing this check is evidence for the demonstrated integration, not proof that every production condition has been covered.

Why these checks belong before shared CI

The three checks find different classes of problems:

code rule violation       → static analysis
wrong rendered appearance → simulator-to-Figma comparison
cross-service mismatch    → frontend/backend staging check

If all feedback waits for CI, every small repair can incur the cost and delay of the shared pipeline. The inner loop reduces that delay by putting relevant checks next to generation. It also lets the coding agent repair straightforward failures while the change is still in its working environment.

This is especially important for agent-produced changes. An agent can create code quickly, but quick generation can also create errors quickly. A useful system therefore increases the density of evidence around generation. “Densifying validation” means adding more relevant checks to the path where changes are made, not simply asking the model to be more careful.

Inner validation complements outer validation

The outer loop still has a distinct role. Shared CI offers a later, organization-wide gate. Agentic review can inspect the resulting change at another stage. Human review remains outside those automated checks.

The separation gives the workflow a useful division of labor:

• Inner loop: fast feedback for code, appearance, and connected behavior.
• Outer loop: later shared CI and agentic review.
• Human review: a final decision point with the evidence from earlier stages available.

An inner pass should therefore not be reported as a merge decision. It says that the change passed the checks run so far. It does not say that the change is approved, deployed, or correct under every condition.

Takeaway

The chapter's central idea is to validate generated software where feedback is cheapest and fastest. Static analysis catches detectable code-rule violations in the development environment. Simulator-to-Figma comparison checks the rendered pickup UI against its design. A staged frontend/backend check tests the mobile flow across a service boundary.

Together, these checks make the inner loop more informative without eliminating the outer CI and review loop. The software factory becomes safer not because generation is assumed to be reliable, but because each generated change meets evidence-producing gates before it consumes later shared capacity.

Source: Agentic SDLC at Uber — Uday Kiran Medisetty & Adam Huda, approximately 14:16–15:00.