If code generation is cheap, code correctness is only the inner game.

The larger challenge is whether we are building the right feature, with the right behavior, for the right users, under the right operational constraints. That is where an extended loop matters: a loop that starts before coding (requirements and planning) and goes beyond coding (runtime validation, documentation, and contract-level clarity).

This is not a replacement for the “close the coding loop” idea. It is the next layer around it.

The Core Shift

The classic loop in AI-assisted engineering is:

generate -> test -> fix

The extended loop is:

frame -> specify -> implement -> validate -> integrate -> observe -> refine

That outer loop is where feature relevance, user outcomes, and non-functional qualities are decided and continuously corrected.

Why an Outer Loop Is Necessary

SVPG’s (Silicon Valley Product Group) discovery-and-delivery model is a useful anchor: teams need to learn fast and also release with confidence [1]. If we optimize only for implementation throughput, we risk shipping well-tested irrelevance.

A narrow loop can prove that code works. It cannot prove that the feature should exist, that users can succeed with it, or that it will remain reliable and supportable in production.

A Nested-Loop Model

The practical model is two loops, not one:

  • Inner loop: fast implementation correctness
  • Outer loop: feature fitness across lifecycle artifacts and outcomes
flowchart TD
  A[Problem framing / opportunity] --> B[Feature hypothesis]
  B --> C[Functional + non-functional specification]
  C --> D[Inner loop: generate -> test -> repair]
  D --> E[Contract + docs + release readiness]
  E --> F[Progressive rollout]
  F --> G[Runtime signals: quality, usage, reliability]
  G --> H{Hypothesis confirmed?}
  H -- No --> B
  H -- Yes --> I[Scale and standardize]
  I --> J[Next opportunity]
  J --> A

The inner loop minimizes local defects; the outer loop minimizes systemic waste.

Perspectives by Discipline

1. Product perspective: discovery and delivery must stay coupled

Discovery and delivery are not opposing phases; they are coupled risk controls [1]. Product work in the outer loop should answer:

  • Is there evidence of user/problem demand?
  • What is the smallest testable outcome?
  • What invalidation signal would make us stop?

This keeps agentic throughput pointed at validated opportunities instead of broad backlog expansion.

2. UX perspective: behavior beats opinion

UX research methods distinguish clearly between attitudinal and behavioral evidence, and between qualitative and quantitative methods [2]. In outer-loop terms:

  • Use qualitative methods early to find why users fail.
  • Use quantitative methods later to measure how much it improves.
  • Treat usability testing as an iterative control, not a one-time gate [3].

This prevents “technically correct, experientially wrong” releases.

3. Engineering perspective: keep the trunk healthy and reversible

High-feedback engineering practices matter because outer-loop learning collapses if integration is slow. Trunk-based development emphasizes short-lived branches, frequent integration, and CI discipline as enablers of continuous delivery [4].

DORA’s metrics then give a practical signal set for throughput and instability (lead time, deployment frequency, change fail rate, failed deployment recovery time, rework) [5].

Together, these create a measurable engineering substrate for fast outer-loop iteration.

4. Architecture/governance perspective: decisions and contracts are first-class artifacts

When features cross service boundaries, “working code” is not enough. Contract and decision artifacts are part of product quality:

  • API/interaction contracts: OpenAPI provides machine-readable interface definitions for consumers and tooling [6].
  • Consumer constraints: consumer-driven contract thinking helps providers evolve without breaking hidden consumer assumptions [7].
  • Decision traceability: ADRs preserve rationale and trade-offs over time [8].

In enterprise environments, these artifacts reduce rework and coordination latency.

Outer-Loop Controls for Corporate Teams

A minimal outer-loop control set can stay lightweight and still be effective:

  1. Specification gate
    • Require explicit functional + non-functional acceptance criteria before implementation starts.
  2. Integration gate
    • Merge only through short-lived branch workflows with required CI checks [4].
  3. Contract/documentation gate
    • Update API and externally relevant behavior descriptions in the same change set [6].
  4. Runtime evidence gate
    • Promote rollout stages only when delivery and stability indicators remain within agreed thresholds [5].
  5. Security/provenance gate
    • Align build and release processes to SSDF outcomes and provenance requirements [9] [10].
  6. Supply-chain transparency gate
    • Maintain SBOM availability and policy for dependency risk handling [11] [12] [13].

These are “small levers,” but together they shift the system from code-centric to outcome-centric execution.

Workflow and Tooling Implications

Extending the loop means the workflow stack must evolve, not just prompts.

  • CI/CD: from build pipeline to policy + evidence pipeline.
  • Version control: from code history to artifact history (specs, contracts, ADRs, docs).
  • Dependency management: from package updates to trust posture (SBOM, provenance, repository hygiene signals).
  • Release management: from single launch event to progressive exposure and feedback-informed rollout.

In other words: the loop is no longer just in the IDE; it spans planning systems, repos, pipelines, runtime telemetry, and governance controls.

Being “Feature Complete”

This extended-loop model aligns with the “last mile” concern: a feature is only complete when it is integrated into system reality, not when implementation is merged.

Agentic tooling accelerates implementation. The outer loop ensures that acceleration compounds into product value rather than operational entropy.

Closing Thought

The most useful question for agentic teams is no longer:

“How fast can we generate code?”

It is:

“How quickly can we learn whether a shipped feature is valuable, usable, reliable, and maintainable—and feed that learning back into the next cycle?”

That is what it means to extend the loop.

Bibliography

<
Previous Post
Closing the Loop: How to Get Better Features, Not Just More AI Code
>
Blog Archive
Archive of all previous blog posts