9.2 The Vibe Coding Loop

1. The Five Phases

Picture a developer who has just pasted twenty test cases and a plain-English description into an AI coding assistant: within seconds a candidate implementation appears, six tests pass, fourteen fail, and the real work begins. That "real work" is a five-phase cycle that repeats until every test goes green or the developer decides to scrap the session and start fresh. Each phase has a distinct purpose and a distinct set of artifacts. Figure 9.2 shows the loop structure, including the reset path that returns to the specify phase when convergence stalls.

Without a structured loop, developers fall into one of two traps: they accept the first generated code and ship bugs they never noticed, or they rewrite prompts endlessly without converging on a working solution. The difference between frustration and fluency is knowing the shape of the cycle.

In the vibe coding loop, a human developer and an AI code generator collaborate through repeated rounds of specification, generation, testing, and correction. This structured cycle transforms AI code generation from a gamble on a single prompt into an engineering process with measurable, progressively improving quality. Each iteration feeds the test results and failure diagnostics from the previous round back into the model's context. The model therefore gains strictly more information about the target behavior with every pass. Use this loop (rather than manual coding or one-shot prompting) when the task is too complex for a single prompt to produce correct code, yet well-defined enough that you can write executable tests to judge correctness.

Phase 1: Specify. The developer writes a prompt that describes the desired behavior. Following the template from Section 9.1, this prompt includes task description, input/output schemas, behavioral requirements, edge cases, and examples. The developer also writes (or has previously written) executable contracts: test cases, type annotations, and schema validators. The specification phase produces two artifacts: the prompt text and the test suite.

Phase 2: Generate. The AI model receives the prompt (plus any relevant context: existing code, documentation, prior conversation) and produces code. In tools like Claude Code, this generation happens within an agentic loop (where the model autonomously invokes tools, reads files, and runs commands across multiple internal steps before returning a result) where the model can read existing files, run commands, and iterate internally before presenting its output. The generate phase produces one artifact: the candidate implementation.

Phase 3: Observe. The developer (or an automated pipeline) runs the executable contracts against the candidate implementation. This includes running the test suite, the type checker, the linter, and any end-to-end tests. The observe phase produces a verification report: which contracts pass, which fail, and what the failure messages say.

Phase 4: Steer. Based on the verification report, the developer provides feedback to the model. This feedback can take several forms: sharing error messages and stack traces, clarifying ambiguous requirements, adding new test cases that encode previously implicit assumptions, or providing examples of correct behavior. The steer phase refines the specification and provides the model with information about why its previous attempt was insufficient.

Phase 5: Commit or Repair. If all contracts pass, the developer commits the code. If contracts still fail after steering, the developer decides whether to continue the repair loop (return to Phase 2 with the steering feedback) or reset (start a new session with a revised specification). The commit/repair decision is the critical judgment call in vibe coding. In short: specify what you want, let the model try, check the evidence, tell it what it missed, and repeat until every contract passes or the session has earned a fresh start. Figure 9.2.1 illustrates the five-phase vibe coding loop with decision branches.

from dataclasses import dataclass, field
from enum import Enum
from typing import Callable

class LoopOutcome(Enum):
    COMMIT = "commit"
    REPAIR = "repair"
    RESET = "reset"

@dataclass
class VibeCodeIteration:
    """One iteration of the vibe coding loop."""
    iteration: int
    prompt: str
    generated_code: str
    tests_passed: int
    tests_failed: int
    error_messages: list[str] = field(default_factory=list)

    @property
    def pass_rate(self) -> float:
        total = self.tests_passed + self.tests_failed
        return self.tests_passed / total if total > 0 else 0.0

@dataclass
class VibeCodingSession:
    """Tracks the full history of a vibe coding session."""
    iterations: list[VibeCodeIteration] = field(default_factory=list)
    max_iterations: int = 10

    def should_reset(self) -> bool:
        """Heuristic: reset if pass rate has not improved in 3 iterations."""
        if len(self.iterations) < 3:
            return False
        recent = self.iterations[-3:]
        rates = [it.pass_rate for it in recent]
        # No improvement across last 3 iterations
        return rates[-1] <= rates[0]

    def should_commit(self) -> bool:
        """Commit when all tests pass."""
        if not self.iterations:
            return False
        return self.iterations[-1].tests_failed == 0

    def decide(self) -> LoopOutcome:
        """Decide the next action based on session history."""
        if self.should_commit():
            return LoopOutcome.COMMIT
        if self.should_reset():
            return LoopOutcome.RESET
        if len(self.iterations) >= self.max_iterations:
            return LoopOutcome.RESET
        return LoopOutcome.REPAIR

    def convergence_rate(self) -> float:
        """Estimate convergence: slope of pass rate over iterations."""
        if len(self.iterations) < 2:
            return 0.0
        rates = [it.pass_rate for it in self.iterations]
        n = len(rates)
        # Simple linear regression slope
        x_mean = (n - 1) / 2.0
        y_mean = sum(rates) / n
        numerator = sum((i - x_mean) * (r - y_mean) for i, r in enumerate(rates))
        denominator = sum((i - x_mean) ** 2 for i in range(n))
        return numerator / denominator if denominator > 0 else 0.0

2. Convergence Dynamics

Knowing the five phases tells you what to do at each step; the next question is how many trips around the loop you should expect before the code is ready.

Not all vibe coding sessions converge at the same rate. The convergence speed depends on three factors: the completeness of the initial specification, the complexity of the target code, and the quality of the steering feedback.

We can model convergence formally. Let \(p_t\) denote the test pass rate at iteration \(t\). In the ideal case, each iteration fixes at least one failing test without breaking any passing tests. This gives us a monotonically increasing sequence (each term is at least as large as the previous one):

where \(N\) is the total number of tests. Under this ideal model, convergence takes at most \(N\) iterations. In practice, iterations are not monotonic: fixing one test can break others, especially when tests are coupled through shared state. A more realistic model treats each iteration as a noisy step:

where \(\alpha_t \in [0, 1]\) is the repair efficiency (fraction of remaining failures that this iteration fixes) and \(\epsilon_t\) is noise from regressions. When \(\alpha_t\) is consistently positive and \(|\epsilon_t|\) is small relative to \(\alpha_t\), the loop converges. When \(\epsilon_t\) dominates, the loop oscillates: each repair introduces new failures at a rate comparable to the fixes.

import numpy as np

def simulate_vibe_loop(
    n_tests: int = 20,
    repair_efficiency: float = 0.3,
    regression_rate: float = 0.05,
    max_iterations: int = 30,
    seed: int = 42,
) -> list[float]:
    """
    Simulate vibe coding loop convergence.

    Parameters:
        n_tests: total number of tests in the suite
        repair_efficiency: fraction of failing tests fixed per iteration
        regression_rate: probability that a passing test regresses per iteration
        max_iterations: cap on iterations
        seed: random seed for reproducibility

    Returns:
        List of pass rates across iterations.
    """
    rng = np.random.default_rng(seed)
    # Start with all tests failing
    passing = np.zeros(n_tests, dtype=bool)
    history = [0.0]

    for _ in range(max_iterations):
        # Repair: fix some failing tests
        failing_indices = np.where(~passing)[0]
        if len(failing_indices) == 0:
            break
        n_fix = max(1, int(len(failing_indices) * repair_efficiency))
        to_fix = rng.choice(failing_indices, size=n_fix, replace=False)
        passing[to_fix] = True

        # Regression: some passing tests break
        passing_indices = np.where(passing)[0]
        regress_mask = rng.random(len(passing_indices)) < regression_rate
        passing[passing_indices[regress_mask]] = False

        history.append(passing.mean())
        if passing.all():
            break

    return history


# Compare three scenarios
fast = simulate_vibe_loop(repair_efficiency=0.5, regression_rate=0.02)
normal = simulate_vibe_loop(repair_efficiency=0.3, regression_rate=0.05)
stalled = simulate_vibe_loop(repair_efficiency=0.15, regression_rate=0.10)

print(f"Fast convergence:    {len(fast)-1} iterations, final pass rate {fast[-1]:.0%}")
print(f"Normal convergence:  {len(normal)-1} iterations, final pass rate {normal[-1]:.0%}")
print(f"Stalled convergence: {len(stalled)-1} iterations, final pass rate {stalled[-1]:.0%}")
# Fast convergence:    7 iterations, final pass rate 100%
# Normal convergence:  14 iterations, final pass rate 100%
# Stalled convergence: 30 iterations, final pass rate 75%

The simulation suggests an approximate threshold: when the regression rate exceeds roughly one-third of the repair efficiency, the loop typically stalls. In practice, every prompt that fixes one bug introduces a new one. Two root causes dominate. First, the specification may be internally inconsistent, with two requirements that contradict each other. Second, the model's context window (the maximum amount of text the model can consider at once, typically measured in tokens) may have accumulated enough conflicting instructions that it cannot satisfy all of them at once. To fix the first, review the test suite for contradictions. To fix the second, reset the session with a cleaner, consolidated prompt.

3. Session Management Strategies

A vibe coding session accumulates context: the initial prompt, each steering message, error logs, generated code, and the model's internal reasoning. This context grows with each iteration, and context quality degrades in predictable ways.

Context dilution occurs when the session's context window fills with debugging artifacts (stack traces, intermediate attempts, abandoned approaches) that distract the model from the core specification. The signal-to-noise ratio (the proportion of useful specification content relative to accumulated debugging artifacts) of the context tends to decrease with session length.

Context contradiction occurs when early steering messages conflict with later ones. "Use pandas for the CSV parsing" followed ten messages later by "actually, use the csv module to avoid the pandas dependency" leaves both instructions in the context, and the model may follow either one.

Context anchoring occurs when the model becomes anchored to an early (incorrect) implementation choice and makes incremental patches rather than reconsidering the overall approach. This is the AI equivalent of the sunk cost fallacy.

from dataclasses import dataclass
from enum import Enum

class SessionHealth(Enum):
    HEALTHY = "healthy"           # pass rate improving, no contradictions
    DILUTED = "diluted"           # context noisy, but still improving
    CONTRADICTED = "contradicted" # conflicting instructions detected
    ANCHORED = "anchored"         # stuck on wrong approach

@dataclass
class SessionDiagnostic:
    """Diagnose the health of a vibe coding session."""
    iterations: list[VibeCodeIteration]

    def diagnose(self) -> SessionHealth:
        if len(self.iterations) < 2:
            return SessionHealth.HEALTHY

        rates = [it.pass_rate for it in self.iterations]

        # Check for contradiction: oscillating pass rate
        if len(rates) >= 4:
            oscillations = sum(
                1 for i in range(2, len(rates))
                if (rates[i] - rates[i-1]) * (rates[i-1] - rates[i-2]) < 0
            )
            if oscillations >= len(rates) // 2:
                return SessionHealth.CONTRADICTED

        # Check for anchoring: same errors repeating
        if len(self.iterations) >= 3:
            recent_errors = [
                set(it.error_messages) for it in self.iterations[-3:]
            ]
            # If the same errors appear in all 3 recent iterations
            common = recent_errors[0] & recent_errors[1] & recent_errors[2]
            if len(common) > 0:
                return SessionHealth.ANCHORED

        # Check for dilution: improving but slowly
        if len(rates) >= 5:
            recent_improvement = rates[-1] - rates[-5]
            if 0 < recent_improvement < 0.1:
                return SessionHealth.DILUTED

        return SessionHealth.HEALTHY

    def recommend_action(self) -> str:
        health = self.diagnose()
        actions = {
            SessionHealth.HEALTHY: "Continue: the session is converging normally.",
            SessionHealth.DILUTED: (
                "Consolidate: summarize the current state and requirements "
                "in a fresh message to reset the effective context."
            ),
            SessionHealth.CONTRADICTED: (
                "Review tests: check for contradictory requirements "
                "in the test suite. Resolve the contradiction, then reset."
            ),
            SessionHealth.ANCHORED: (
                "Reset: start a new session with a revised specification "
                "that explicitly excludes the anchored approach."
            ),
        }
        return actions[health]

4. Steering Strategies

Diagnosing a sick session is only half the battle; the other half is choosing the right intervention to get convergence back on track.

The quality of steering feedback directly determines convergence speed. Four strategies have proven effective in practice, roughly ordered from least to most informative.

Error forwarding is the simplest strategy: copy the error message or failing test output and paste it into the conversation. This gives the model a concrete signal about what went wrong but no guidance about what to do instead. Error forwarding is sufficient for straightforward bugs (typos, import errors, off-by-one mistakes) but often fails for design-level problems.

Constraint injection adds a new constraint to the specification. "The function must also handle the case where the input list is empty" or "Use only the standard library, no pandas." This narrows the search space \(S_{\text{prompt}}\) from Section 9.1, reducing the specification gap. Constraint injection is effective when the root cause of a failure is underspecification.

Example provision gives the model a concrete input-output pair that demonstrates the desired behavior. "For input [3, 1, 2], the output should be [1, 2, 3], not [1, 2]." Examples are more informative than constraints because they simultaneously constrain the behavior and demonstrate the expected format.

Approach redirection tells the model to abandon its current implementation strategy and try a different one. "Instead of using recursion, use an iterative approach with a stack" or "This needs a different data structure; use a heap instead of a sorted list." Approach redirection is the most invasive steering strategy but is necessary when the model is anchored to an unsuitable approach.

from enum import Enum

class SteeringStrategy(Enum):
    ERROR_FORWARD = "error_forward"
    CONSTRAINT_INJECT = "constraint_inject"
    EXAMPLE_PROVIDE = "example_provide"
    APPROACH_REDIRECT = "approach_redirect"

def select_steering_strategy(
    iteration: VibeCodeIteration,
    session: VibeCodingSession,
) -> SteeringStrategy:
    """
    Select the appropriate steering strategy based on session state.

    Rules of thumb:
    1. First failure: forward the error.
    2. Same error twice: add a constraint or example.
    3. Three iterations with no improvement: redirect approach.
    4. Oscillating pass rate: review for contradictions first.
    """
    if len(session.iterations) <= 1:
        return SteeringStrategy.ERROR_FORWARD

    prev = session.iterations[-2]

    # Same errors repeating: escalate from error forwarding
    if set(iteration.error_messages) & set(prev.error_messages):
        # Tried error forwarding already, provide an example
        if len(session.iterations) >= 3:
            prev_prev = session.iterations[-3]
            if set(iteration.error_messages) & set(prev_prev.error_messages):
                # Three iterations, same errors: redirect approach
                return SteeringStrategy.APPROACH_REDIRECT
        return SteeringStrategy.EXAMPLE_PROVIDE

    # Pass rate not improving but errors are different: add constraints
    if iteration.pass_rate <= prev.pass_rate:
        return SteeringStrategy.CONSTRAINT_INJECT

    # Default: forward the new errors
    return SteeringStrategy.ERROR_FORWARD

5. The Reset Decision

Even the best steering strategy has limits; sometimes the most productive move is to walk away from the accumulated context and begin again.

The hardest judgment call in vibe coding is when to reset. Discarding accumulated context feels wasteful, but a stalled session costs more than a fresh start: each additional iteration adds noise without making progress.

Three signals reliably indicate that a reset is warranted:

Plateau detection: the pass rate has not improved by more than 5% in three consecutive iterations. This suggests the model is making lateral moves in the solution space rather than converging.

Error cycling: the same error message appears, disappears, and reappears across iterations. This indicates that fixes for one test are regressing another, and the model is cycling between two incompatible solutions.

Context overflow: the conversation has exceeded roughly 50 messages or 20,000 tokens of steering feedback. At this point, early context is being pushed out of the model's effective attention window, and the model may lose track of core requirements (even with context windows of 128K tokens or more, available since 2024, attention quality degrades over long conversations; the bottleneck is not raw capacity but the model's ability to prioritize relevant instructions amid accumulated noise).

When resetting, the developer should carry forward three artifacts from the failed session: the test suite (which has been refined through the session), the consolidated specification (incorporating all clarifications), and a brief note about which approaches failed. The note serves as negative context: "Do not use recursion for this problem; an iterative approach with a heap is needed."

Exercises

1. (Conceptual) A vibe coding session has produced the following pass-rate trajectory over 8 iterations: [0.0, 0.4, 0.6, 0.5, 0.7, 0.65, 0.7, 0.7]. Diagnose the session health using the three signals (plateau, error cycling, context overflow). What would you recommend: continue, consolidate, or reset? Justify your answer.
2. (Coding) Extend the simulate_vibe_loop function to accept a steering_boost parameter that increases repair efficiency by 50% every 5 iterations (simulating effective human steering). Compare the convergence curves with and without the boost. How many iterations does the boost save in the "stalled" scenario?
3. (Analysis) Run a real vibe coding session with Claude Code (or another AI coding assistant). Ask it to implement a function to merge two sorted lists. Track the pass rate across at least 5 iterations. Plot the convergence curve and compute the empirical repair efficiency \(\alpha_t\) for each iteration. Does the diminishing-returns pattern from the research literature hold?