2.1 The vibe loop (idea → prompt → output → test → refine)

What the vibe loop is

The vibe loop is a tight iteration cycle you repeat until the software is real:

idea → prompt → output → test → refine → (repeat)

The loop is the product. The model is just one component inside it.

In vibe coding, you’re optimizing for time-to-verified: how quickly you can go from a desired change to a verified, working result.

Why the loop beats “one big prompt”

One big prompt tries to compress planning, implementation, and verification into a single response. That usually fails because:

• Large outputs hide mistakes: the more text/code you get, the harder it is to review.
• Ambiguity compounds: small assumptions become big architectural decisions.
• Context drifts: older instructions conflict with newer ones and the model “blends” them.
• Verification is delayed: you discover issues late, after investing time in an unverified direction.

The vibe loop fixes this by forcing you to validate reality after each step.

The artifacts each loop should produce

To keep the loop productive, each iteration should produce at least one concrete artifact you can evaluate:

• A plan: 3–7 steps that describe the approach and risks.
• A small diff: specific file changes (or a new small file) with limited scope.
• A verification step: what to run or check to prove it works.
• A note: one sentence about what you learned or what to do next.

The loop, step by step

Here’s the vibe loop in a form you can execute repeatedly.

Step 1: Idea (define the next smallest outcome)

Translate your goal into a single, testable next step. Examples:

• “Add pagination to the API response.”
• “Fix the crash when input is empty.”
• “Extract a module so this function is testable.”

Good loop goals are small enough that you can verify them in minutes, not hours.

Step 2: Prompt (constrain the model’s behavior)

A good prompt is a tiny spec. Include:

• Constraints: language/runtime, libraries, file boundaries, “diff-only,” “ask questions first.”
• Acceptance criteria: what “done” means (and what failure looks like).
• Evidence: errors, logs, tests, and reproduction steps.
• Working set: the minimum files/snippets needed for this change.

Step 3: Output (plan + diff, not an essay)

Prefer outputs that are easy to integrate and review:

• “Plan in 5 steps.”
• “Provide a minimal diff only.”
• “List the commands to verify.”

When you receive output, treat it as a draft. Your job is to review it like you would a junior engineer’s PR.

Step 4: Test (reality check)

Run the fastest truth source you have:

• Unit tests for logic changes.
• Smoke run for basic app flow.
• Schema validation for structured outputs.
• Minimal reproduction for bugs.

If you don’t have a test yet, create a tiny one. A single regression test often saves hours later.

Step 5: Refine (tighten the next prompt with evidence)

Refinement is not “ask again.” Refinement is:

• Pasting the exact failing output.
• Narrowing the scope to the smallest fix.
• Updating constraints or acceptance criteria based on what you learned.

Over time, your prompts become sharper because they’re grounded in evidence, not speculation.

How to scope a loop (the 10-minute skill)

Scoping is the highest-leverage human skill in vibe coding. Here are practical scoping rules:

Rule 1: One change per loop

One feature, one fix, one refactor. If you need three changes, do three loops.

Rule 2: Bound the blast radius

Explicitly list:

• Files allowed to change.
• Files not allowed to change.
• Interfaces that must remain stable.

Rule 3: Define “done” in observable terms

Good acceptance criteria are things you can verify:

• “Given input X, output is Y.”
• “This test passes.”
• “No longer throws error Z.”
• “Latency under N ms for this endpoint” (with measurement).

Rule 4: Timebox exploration

If you’re unsure about architecture, do a short exploration loop:

• Ask for 2–3 approaches with tradeoffs.
• Pick one.
• Switch to low-randomness implementation loops.

Example vibe loops

These examples show what “tight loop” looks like in practice.

Example: bug fix loop

1. Idea: “Fix crash when input is empty.”
2. Prompt: include the stack trace + the function + constraints: “minimal diff.”
3. Output: patch that adds a guard clause + a regression test.
4. Test: run the failing test and confirm it passes.
5. Refine: if edge cases remain, add another test and patch.

Example: small feature loop

1. Idea: “Add a --json flag to CLI output.”
2. Prompt: acceptance criteria with sample outputs.
3. Output: minimal diff: parse flag, new output path, tests updated.
4. Test: run CLI examples and unit tests.
5. Refine: handle invalid flag combos, update help text.

Example: refactor loop

1. Idea: “Extract parsing logic into a pure function.”
2. Prompt: specify file boundaries and “no behavior changes.”
3. Output: new module + updated imports + tests proving same behavior.
4. Test: run existing tests; add one for the extracted function if needed.
5. Refine: rename for clarity, delete dead code.

Common anti-patterns (and fixes)

Anti-pattern: prompt → accept → move on (no test)

• Why it fails: hallucinations slip through; regressions accumulate.
• Fix: require “what to run to verify” in every loop.

Anti-pattern: giant rewrites as default

• Why it fails: large diffs hide mistakes and kill iteration speed.
• Fix: “diff-only changes,” file allowlists, and small scoped goals.

Anti-pattern: chatty exploration forever

• Why it fails: you’re not accumulating working artifacts.
• Fix: ship a walking skeleton; then iterate in slices with verification.

Anti-pattern: vague prompts

• Why it fails: the model guesses; you debug guesses.
• Fix: acceptance criteria + examples; force questions when unclear.

Checklists you can reuse

Before you prompt

• What is the smallest next outcome?
• What files are allowed to change?
• What must not change?
• What would prove success?
• What evidence (errors/logs/tests) do you have?
• What’s your fastest verification step?
• What risk category is this (low/medium/high)?
• Do you need a new session or summary reset?

After you get output

• Does it follow constraints (files, style, scope)?
• Is the diff small and reviewable?
• Are there any invented APIs/claims?
• Is the verification step clear and runnable?
• What is the next smallest refinement if it fails?

Copy-paste prompt templates

Template: one vibe loop

Goal (one sentence):
...

Constraints:
- Diff-only changes
- Files allowed to change: [...]
- Must not change: [...]

Context (minimal):
- Relevant snippets / failing output:
...

Acceptance criteria:
- ...

Deliver:
1) Plan (3–7 steps)
2) Minimal diff
3) Exactly what to run to verify

Template: “fix with evidence” loop

Here is the failing test / error output:
...

Task:
Propose the smallest diff to make it pass.
If you need more context, ask for specific files/functions.
Then tell me what to run to verify.

Template: exploration loop (options + tradeoffs)

Goal:
...

Constraints:
...

Generate 3 meaningfully different approaches.
For each: pros/cons, risks, and how I would verify it.
Then recommend one and explain why.

Where to go next

• 2.2 When vibe coding is great vs when it’s dangerous
• 2.5 The “spec first” habit that prevents spaghetti