When to Stop Prompting and Start Reading the Code

There's a specific moment in every vibecoding session where re-prompting stops being productive: you've asked the AI to "fix it" three times, the bug has changed shape twice, and you're no longer sure what the code actually does. That's the moment to stop prompting and start reading.

The Pattern That Signals It's Time

Watch for these signs:

• The error message changed but the symptom didn't. You're patching downstream effects of a bug you haven't located yet.
• You can't describe the bug in one sentence. If you're not sure what's wrong, the AI isn't either — it's guessing from the same fuzzy description you gave it.
• The last fix introduced a new bug. This is the strongest signal. It usually means the AI is pattern-matching against your error text rather than understanding the actual data flow.
• You've stopped reading the diffs. If you're approving changes without reading them, you've lost the thread of what the code does — see the confidence trap for why that's dangerous on its own.

Any one of these alone is normal. Two or more together means re-prompting is now slower than reading.

What "Reading the Code" Actually Looks Like

You don't need to trace the whole file. Five minutes of targeted reading usually beats a fifth prompt attempt:

1. Find where the bad value first appears, not where it crashes. Add a console.log at the function boundary closest to the symptom and work backward.
2. Read the function signature before the body. What goes in, what comes out — half the time the bug is a mismatch between what a function returns and what the caller assumes.
3. Check the state, not just the render. Most vibecoded UI bugs are stale state or a missing dependency in a useEffect, not broken JSX.
4. Diff against the last working version, if you have one. git diff will often show you the exact line that changed behavior, which is faster than reasoning about the whole file.

Then Go Back to the AI — With More

Once you've located the actual cause, a targeted prompt ("the bug is in calculateTotal — it's not accounting for the discount before rounding") gets fixed in one shot, because you've done the diagnosis instead of asking the AI to do it blind. This is the same idea behind debugging with AI — the AI is a much better fixer than a diagnostician when you're the one holding the stack trace.

Reading the code isn't admitting defeat. It's the fastest path back to a working prompt.