17.5 Iterating features with controlled scope

Goal: add features without regressions

Iteration is where vibe coding either becomes a disciplined engineering loop or becomes chaos. Your goal is to keep changes:

• small,
• verifiable,
• reviewable,
• reversible.

The unit of work: one feature per loop

Define a “feature” as a single behavior change you can test. Then:

• write a mini spec,
• add or update tests,
• implement a small diff,
• verify,
• commit.

Then repeat.

The mini-spec (micro requirements)

Each iteration should start with a mini spec:

• Goal: one sentence
• Non-goal: one sentence (“not doing X”)
• Acceptance criteria: 3–8 bullets
• Files in scope: limit to a small list

This prevents the model from turning a small change into a rewrite.

Diff-only + small steps (default posture)

Once you have a repo, use diff-only changes by default:

• plan first for anything non-trivial,
• implement step 1 only,
• run verification,
• proceed to step 2.

This is the single best way to keep vibe speed without creating spaghetti.

Tests and checks (truth source)

Use tests as the truth source:

• add a test before implementing tricky behavior,
• keep tests deterministic (no real model calls in unit tests),
• run tests after every step.

Even if your project starts with only 3 tests, those tests are your guardrails.

Context management for iteration

To keep model output coherent over many iterations:

• maintain an authoritative spec block,
• maintain a short file map,
• paste only relevant files and failing outputs,
• reset summaries when the conversation drifts.

Do not rely on long chat history as your spec.

Copy-paste iteration prompts

Prompt A: plan for the mini spec

Here is the mini spec:
(paste)

Task:
1) Confirm assumptions and ask questions if needed.
2) Propose a 3–6 step plan.
3) For each step: files touched and how to verify.
Stop after the plan. No code yet.

Prompt B: implement one step (diff-only)

Implement step 1 only.

Constraints:
- Diff-only changes
- Only touch the files listed for step 1
- Keep changes minimal
- After the diff, list verification commands

Prompt C: fix a failing test minimally

Here is the failing output:
(paste)

Fix it with the smallest possible change.

Constraints:
- Diff-only changes
- Do not refactor unrelated code
- Do not change tests unless the test is wrong (explain if so)

Ship points and commits

Each iteration should end at a ship point:

• tests pass,
• feature works as defined in acceptance criteria,
• commit created.

This is how you avoid “I’m not sure what state the repo is in.”

Iteration anti-patterns

• Giant prompts: too much scope, too little verification.
• Rewrite loops: accepting big rewrites “just to move on.”
• No tests: debugging becomes guesswork and regressions multiply.
• No ship points: progress is fragile and hard to recover.

Where to go next

• 18. Vibe coding for existing codebases
• Reference: diff-only changes