Course A · Module A4 Build · Lesson 16 of 17

Debugging With AI deep dive

Fix what's broken without burning credits going in circles.

~18 min · Have your A14 app open with something not quite right · Prereq: A15 Reading Code Without Fear

You shipped something. Then you changed something. Now it's broken and you've sent three messages to the AI asking it to fix the thing, and each time it "fixes" it something else breaks, and you're watching your credit meter tick down. That cycle has a name — the debugging doom loop — and it is the number-one credit sink for non-technical builders. Your single win today: a four-step debugging process that breaks the loop. Once you have it, a broken app stops being frightening and starts being a solvable puzzle.

Why the loop happens

Imagine phoning a mechanic and saying "my car is making a noise." They guess: spark plugs. You pay, pick it up, still making the noise. You call back: "it's still making the noise." They guess: timing belt. Still making the noise. You're paying for guesses, not diagnosis.

Now imagine saying: "There's a high-pitched whine from the front-right wheel only when braking above 30 mph, and it started the day after I hit a pothole." That's a diagnosis. The mechanic goes straight to the wheel bearing. Debugging is the same skill: describe the problem precisely enough that the fix is obvious.

The four-step debugging loop

Run this loop once per problem — not once per message

Read the error message first. Don't immediately paste the error into the AI. Read it yourself. The message usually names a file, a line number, or a function. Find the word that looks like a location and write it down. Even if you don't understand the rest, that location is gold.
Isolate the one thing that changed. Ask yourself: "What was the last change I made before this broke?" That change is almost always the cause. If you made several changes at once (you were warned), revert to the last working version and make one change at a time from there.
Paste the error WITH context to the AI. Don't just paste the error. Include: (a) the exact error message, (b) the file or section it came from, (c) the one change you made before it broke, and (d) what you expected to happen. Four facts, one message.
Apply one fix, then test immediately. The AI will suggest a change. Make exactly that change — nothing else. Refresh and test. Did it fix the error? If yes, you're done. If a new error appears, run the loop again from step 1 with the new error. Never apply two suggested fixes at once.

How to describe a bug precisely

The quality of the fix depends almost entirely on the quality of the bug description. Use this structure every time:

Bug description template

What I expected: [e.g., "Clicking 'Draft Reply' should show generated text below the button"]
What actually happened: [e.g., "Nothing appears — the button just turns grey for a moment then nothing"]
Error message (exact copy-paste): [e.g., "TypeError: Cannot read properties of undefined (reading 'choices') at line 42"]
The last change I made: [e.g., "I added a second prompt variable called systemPrompt in the JavaScript file"]
What I have NOT changed: [e.g., "The HTML and CSS are untouched — only the JS changed"]

Notice item 5: telling the AI what didn't change is as useful as telling it what did. It rules out half the codebase instantly.

When to revert vs. push on

Push on when

The error message points to a specific line
You know exactly what changed
The fix is one small thing
The rest of the app still works
You're on the first or second fix attempt

Revert when

You've made three fix attempts and it's still broken
The AI keeps re-introducing the same error
Multiple things broke from one change
You can't name what changed before it broke
The credit meter is running and you're just guessing

Reverting is not failure. It is the fastest path back to a working tool. In Lovable, use the version history sidebar. In Bolt, the undo history covers recent generations. The moment you find yourself saying "I'll just try one more thing" for the fourth time, revert instead and start the loop from a clean state.

The golden rule: one change at a time, always. This applies before the bug happens (it prevents most bugs) and during the fix (it means you always know what worked). Founders who burn the most credits are the ones who send five-part requests and then can't trace which change caused the problem. Keep the loop tight and the fixes are almost always fast.

Check yourself

Answer before opening — recalling it is what makes it stick.

You paste an error message with no other context and the AI gives you a fix that breaks something else. What did you leave out?

Context: what you expected, what actually happened, and what changed last. The AI is guessing at the cause without that information — which is why its fix is itself a guess. The four-part bug description (expected / actual / error / last change) is what turns a guess into a diagnosis.

After three failed fix attempts on the same bug, what should you do?

Revert to the last working version. Three failed attempts means either the bug is more systemic than a one-line fix, or the AI is going in circles. Reverting costs nothing; a fourth speculative fix costs credits and may leave the codebase in a worse state than when you started.

Why is "what I have NOT changed" a useful thing to tell the AI?

It rules out large sections of the codebase immediately. If you tell the AI the HTML and CSS are untouched, it knows to look only in the JavaScript. That narrows the search space and produces a more targeted fix with fewer follow-on breakages.