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:

  1. First attempt: Fix Build or a short follow-up prompt
  2. Second attempt: a precise prompt with context from the error
  3. 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.ts has no function called formatDate. 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."

On this page