Most of my worst vibe coding days looked the same. Error. "Fix it." New error. "Fix it." Original error again. Credits gone, nothing working, and me staring at a chat that had forgotten what the app was even meant to do.
What changed it for me was a boring habit: split understanding the bug from fixing it. I stop asking the AI to "just fix it" until it has explained what is going on. That one change cut most of my loops short.
Why "just fix it" fails
AI builders like Cursor, Lovable, Bolt and Replit are good at making a change. They are less good at knowing when they are guessing. Keep saying "still broken, try again" in the same chat and they often repeat a fix, edit files that were fine, or sound confident while nothing changes.
The chat gets muddled, and a fourth attempt in that mess almost never works for me. So I treat diagnosis as a separate job from editing.
Three prompts I use all the time
I paste these almost word for word. Swap in your error, the parts that work, and the bug you care about.
1. Explain first
Here's the exact error: [error]. Before you change anything, explain what it means, which file, most likely cause. Don't edit till I say go.
Paste the real error: browser console (F12), terminal output or build log. Vague lines like "login is broken" send it on a tour of the whole app. If your tool has an ask or plan mode that cannot edit, use that for this step.
2. Fence off what works
These parts work and must not change: [list]. Only edit files related to [the bug]. List the files you plan to change and wait.
This stops the classic "fixed the form, broke the nav" spiral. Name the bits that are fine and make it list its planned edits before it runs them. If the list includes something you did not ask for, say no.
3. Prove it
You said this was fixed, but it isn't. Stop editing. What's the cause, what's your evidence, what have you already tried? Then suggest something different.
When it claims victory and nothing changed, do not hit try again. Force a pause. If its "already tried" list has repeats, it is stuck. That is your cue to stop the loop, not to burn another credit.
The 3-strikes rule
After three failed fixes for the same bug in the same chat, I stop. I do not go for a fourth.
Instead I:
- Ask for a short handover note: the problem, the exact errors, what was tried, which files matter. Under 200 words, no keys or secrets.
- Roll back to the last version that worked.
- Start a fresh chat (or clear context where the tool allows it).
- Paste the note and say: do not repeat anything already tried. Explain the cause before changing anything.
A messy chat rewards guessing. A clean chat with a clear brief rewards a plan.
How I roll back in each tool
Save a working checkpoint before you try anything risky. When you hit three strikes, go back to that rather than digging through broken changes.
Cursor. Hover an earlier message and use Restore Checkpoint. It restores files only; the chat stays. Checkpoints are local and separate from Git, so commit before anything risky. Ask mode helps for diagnosis because it cannot edit while it explains. Start a new chat after the handover note.
Lovable. Open History and Revert to the last version that worked. Bookmark versions you trust. Revert restores code only. It does not undo database changes, and you do not get the credits back, so stopping at three saves money as well as time.
Bolt. If it broke right after a change, open Version history (the clock icon), preview the last good version, and Restore this version. That does not change your Bolt or Supabase databases. Get the handover note first, then type /clear and choose Clear context. Code stays; muddled chat goes. Put permanent rules in project knowledge so they survive /clear.
Replit. In the Agent chat, open the history icon, find the checkpoint, and choose Rollback to here. By default that does not change your database. You can tick Database under additional options for the development database. Production data is separate. Rolling back also rewinds the Agent's conversation context, which is usually what you want after a loop.
One rule across all of them: most rollbacks restore code, not live data. If the AI touched the database during the loop, check that separately.
Before every fix
- Copy the exact error, not a paraphrase
- Run Explain first before any edit
- Fence off what must not change
- Save or bookmark a working version
- Re-test after each attempt
- Stop at three strikes
None of this is clever. It is just refusing to let the tool thrash in a long chat. Make it explain before it edits, and after three fails roll back and start fresh.
I run Debuff Labs. There's a free one-page flowchart here: https://payhip.com/b/QaRgh, and the full kit of 25 rescue prompts is here: https://payhip.com/b/qRu0s.
Top comments (0)