7. The Core Vibe Coding Patterns

What these patterns are (and why they work)

Vibe coding feels “fast” when you reuse a small set of repeatable workflows. This section is that set.

Each pattern is a compression of the same core idea:

• keep the change small,
• keep the model constrained,
• keep verification close to the change,
• keep your architecture stable,
• keep your loop time short.

How to use patterns in real projects

A common failure mode is reading patterns as advice and then going back to ad-hoc prompting. Instead, treat patterns like defaults you intentionally apply.

Use patterns as loops

• Pick one pattern for the current task.
• Write a minimal spec (goal + constraints + done).
• Run the pattern as a sequence of prompts (plan → diff → verify).
• Stop at ship points and lock in progress (tests + git commit).

Make the pattern explicit in the prompt

Don’t assume the model will infer your workflow. Tell it the pattern you’re running:

We are using the “diff-only changes” pattern.
First propose a plan. Then output a minimal diff for step 1 only.

How to choose the right pattern

Different tasks fail in different ways. Choose the pattern that prevents the most likely failure.

A practical chooser

• Starting a new project: use 7.1 scaffold → implement → refine.
• Task feels too big for one prompt: use 7.2 small modules, stitched later.
• Correctness really matters (or you’re fixing a bug): use 7.3 write tests first.
• You’re touching messy or unfamiliar code: use 7.4 explain then rewrite.
• You’re changing an existing codebase (almost always): use 7.5 diff-only changes.

How patterns combine (stacking)

Patterns are composable. In real projects you’ll stack them:

• Scaffold → implement → refine is often combined with diff-only as soon as the repo exists.
• Small modules, stitched later often uses tests first inside each module.
• Explain then rewrite usually starts with plan first and ends with diff-only.

Think of patterns as “how you run a single iteration,” not as mutually exclusive philosophies.

Anti-patterns that cause spaghetti

These are common ways vibe coding goes off the rails:

• One giant prompt: too much scope, too little verification.
• Rewrite-by-default: losing history, introducing regressions, impossible review.
• No ship points: no stable checkpoint, so every change is risky.
• No acceptance criteria: “done” becomes a vibe, not a fact.
• Debugging by conversation: arguing with the model instead of running tests and collecting evidence.

Section 7 map (7.1–7.5)

• 7.1 The “scaffold → implement → refine” pattern
• 7.2 The “small modules, stitched later” pattern
• 7.3 The “write tests first” vibe pattern
• 7.4 The “explain then rewrite” pattern
• 7.5 The “diff-only changes” pattern

Where to go next

• Start with 7.1 scaffold → implement → refine
• Then continue to Section 8 (debugging)