Debugging mindset
How to think when a build goes sideways. Read the signal, pick the right tool, and stop wasting credits on the wrong fix.
Building with an AI is different from building by hand. The code shifts under you, the failures come in unfamiliar shapes, and the temptation is to keep talking at the problem until it goes away. This concept page is about the mindset that gets you unstuck faster.
Why it matters
Most wasted time in AI-driven building comes from one habit: re-prompting when you should be reading. You see a red screen, you type "fix it," the AI tries something, it fails again, you type again. Three credits in, you are no closer. The way out is to slow down for one minute, read the signal, and pick the right tool.
The mental model — four levers
You have four ways to respond when something goes wrong. Any given problem has one right lever.
1. Fix forward
Ask the AI to keep going. Works when the error is small and local — a missing import, a typo, a single bad prop.
Use when: the error names one file, the change was narrow, and the AI has not already tried this fix.
2. Describe more precisely
The AI tried something and it was not right. Write a clearer prompt — name the file, quote the error, say what the fix should not do.
Use when: the first fix went the wrong direction, but the problem is still understood.
3. Roll back
Return to a known-good version and start the change over, smaller. The version you leave behind is still in history.
Use when: two or more attempts have failed, or the current state is further from working than where you started.
4. Clone and branch
Make a copy of the project. Keep the clean one. Experiment on the copy.
Use when: you want to try something risky without risking the current project, or when two directions look equally promising.
Read the signal before you pull a lever
The signal is the difference between a five-minute fix and a fifty-minute detour.
The error message is the primary signal
Do not skip it. Click Copy on the error card and skim the first 20 lines. Look for:
- The first error — the rest are often cascades
- A file path — tells you where the AI needs to look
- A specific symbol — an undefined name, a missing import, a type mismatch
Most errors name their own fix.
The chat log is the secondary signal
Scroll up in chat. What did the last successful build do differently? What did the AI just change that the previous build did not have? The delta is often the bug.
The preview is the tertiary signal
If the build succeeded but the app is wrong, click around the preview. The visual state often tells you exactly which component or route to point at.
Three anti-patterns
The re-prompt spiral
Symptom: you keep typing "please fix it" or "try again." The AI keeps trying variants of the same fix.
Escape: roll back. You are asking a question the AI has already answered wrong three times.
The scope creep fix
Symptom: the error is about one file. The AI rewrites ten.
Escape: in the next prompt, constrain scope explicitly. "Only change components/nav.tsx. Do not touch any other file."
The silent state drift
Symptom: the build succeeds, but something in the database or a config file is now wrong, and you only notice later.
Escape: watch the build log in chat while it runs. Migrations and config edits surface there before they become invisible.
A rule of thumb
Give yourself a two-attempt budget for any single problem. If two rounds of chat have not fixed it, stop and change tools:
- First attempt: Fix Build or a short follow-up prompt
- Second attempt: a precise prompt with context from the error
- If still broken: roll back and approach the change differently
Credits are cheap individually and expensive in aggregate. The three-round rule keeps the aggregate in check.
Rollback costs zero credits. It is the single most underused tool in AI building.
When the AI is clearly wrong
Sometimes the AI is confidently wrong. It will insist a file exists, or that a library behaves a certain way, and you know it does not. Two moves:
- Correct it directly. Quote the actual file contents or the actual library docs in the prompt. "The file
lib/utils.tshas no function calledformatDate. Stop importing it." - Constrain the solution space. Instead of asking "fix this," say "fix this by removing the import, not by adding the missing function."