6. When Things Break
MODULE 6

When Things Break


6.1: The Counterintuitive Truth

The most important debugging principle in vibecoding: fixing forward is slower than fixing backward.

When AI generates broken code, your instinct is to say "fix this error." Don't. That leads to a chain of patches on top of a flawed foundation.

THE SLOW WAY (fixing forward)

Prompt -> Broken code -> "Fix this" -> More bugs ->
  "Fix that too" -> Different error -> "Try this instead" ->
  Context polluted -> Start over anyway

Time: 45 minutes. Result: frustrated, same problem.


THE FAST WAY (fixing backward)

Prompt -> Broken code -> STOP
  -> Original prompt + error log + "avoid this" -> Working code

Time: 5 minutes. Result: clean solution, fresh context.

6.2: Why This Works

AI models don't learn from mistakes within a conversation. When you say "fix this," the AI:

  1. Carries forward confusion from the original error
  2. Patches symptoms instead of addressing root causes
  3. Pollutes the context window with failed attempts
  4. Compounds errors with each iteration

Going back to the original prompt with new information gives AI a clean slate with complete context.

6.3: The Oneshot Formula

[Original Prompt] + [Error Log] + [What to Avoid] = Working Solution

First attempt failed:

"Create a function to fetch user data from /api/users"

Result: returns undefined, crashes on empty response.

Bad follow-up (don't do this):

"The function returns undefined, can you fix it?"
"It's still not working, now I get a type error"
"Actually the whole thing is broken"

Oneshot restart (do this):

"Create a function to fetch user data from /api/users.

Previous attempt failed with: Cannot read property 'data' of undefined.
The endpoint returns { users: [...] } not { data: [...] }.

Requirements:
- Handle the actual response shape { users: [...] }
- Return empty array if no users
- Handle network errors gracefully"
Error logs are gold

The error message tells AI exactly what went wrong. "Fix this" tells it nothing. Always paste the full error log.

6.4: The 3-Strike Rule

If you've tried to fix something 3 times and it's still broken, stop. Go back to the beginning with a fresh prompt containing everything you've learned.

Strike 1: "Fix this error"      -> Still broken
Strike 2: "Try this instead"    -> Different error
Strike 3: "What about..."       -> Even more broken

STOP. Oneshot restart with full context. -> Works.

6.5: When to Fix Forward vs. Restart

SituationApproach
Fundamental misunderstandingRestart -- AI needs complete context
Typo or missing importFix forward is fine
Wrong API shapeRestart -- describe the actual shape
Logic errorRestart -- explain expected behavior
Security vulnerabilityRestart -- explain the threat model
Performance issueRestart -- provide benchmarks and targets

The rule of thumb: if the fix requires AI to understand something new, restart. If it's a trivial correction, fix forward.

6.6: When to Start a Fresh Chat

Sometimes the entire conversation is polluted. Start a new chat when:

  • AI keeps making the same mistake after restarting
  • Responses are confused or repetitive
  • You've switched to a completely different task
  • The context window feels full (long conversation)

When starting fresh, bring your context efficiently:

"Read user rules. Read src/services/AuthService.ts.

In our last session, we decided:
1. Use JWT for auth (not sessions)
2. Store refresh tokens in httpOnly cookies
3. Access tokens expire in 15 min

Now implement the token refresh logic."
🧠
Module Checkpoint
Test your understanding -- try to answer from memory before looking
What is the oneshot formula?

Why is fixing forward usually slower than fixing backward?

What should you do after 3 failed fix attempts?

When is it OK to fix forward instead of restarting?