AN
Teach·Building with Lovable·Lesson 7

Debugging & Recovering

Read console errors, use history to roll back, and escape stuck loops with the agent.

15 min read·5 parts·beginner

The single biggest thing separating people who ship with Lovable from people who quit is not talent — it's how they react to red screens. This lesson is a small kit of habits for when things break: how to read what the app is telling you, how to describe it back to the agent, and how to escape the moments when the agent gets stuck.

Part 1 · Errors are information, not failure

A red screen is not the site saying "you broke it". It's the site saying "here is the exact line where I don't understand what to do". That's a gift. The alternative — the button silently doing nothing — is much worse, because now you have to guess where the problem is.

Avoid
Panic reflex
"It's broken." Close the tab, retry an hour later, hope it fixed itself. Same error, no new information.
Do
Reader reflex
Read the top line of the error. Copy it. Paste it to the agent with what you were doing when it happened. Ninety percent of bugs fix themselves at this step.
Rule of the red screen
The error text is not decoration. It names the file, the line, and usually the exact variable. If you send the agent a screenshot with the error text visible, you're already halfway to a fix.

Part 2 · Reading a red screen

Every error message has three parts. Once you can spot them, none of it is scary anymore — it's just a report.

Figure 2.1
TypeError: Cannot read properties of undefined (reading 'name')at ContactForm (src/components/ContactForm.tsx:42:19)at renderWithHooks (react-dom.js)WHAT — the failureWHERE — file & lineWHY — "undefined" means a value never arrived
Every error message says three things: what went wrong, where it happened, and (often) why.

Two places errors show up

  • Preview overlay — the big red box in the app itself. Usually a runtime error: something crashed while the page was running. Look here first.
  • Build errors — surface in the chat when the code can't even compile. Usually a typo, a missing import, or a mismatched tag. These block the preview entirely.
  • Browser console — for issues that don't crash but still misbehave (a fetch that 404s, a warning about a missing key). Open dev tools, look for red text.
Screenshots are debugging input
You don't have to transcribe errors. Take a screenshot of the red overlay — including the file path and line number — and drop it into the chat. The agent reads it perfectly.

Part 3 · Talking to the agent about a bug

"It's broken, fix it" gives the agent nothing. A good bug report has three lines: what you did, what you expected, what you got. That's it — three lines beat three paragraphs every time.

Avoid
"The contact form is broken"
The agent has to guess. Maybe validation? Maybe the save? Maybe styling? You'll get a shotgun fix that changes ten things and often introduces a new bug.
Do
Reproduce · Expect · See
"On /contact, I typed my name and email and clicked Send. I expected a success message. I got a red overlay: TypeError, undefined 'name', ContactForm.tsx line 42."
Figure 3.1
  1. 1Reproduce

    Do the exact clicks again. Confirm it happens every time, not just once.

  2. 2Describe

    What you did, what you expected, what you saw. Attach the screenshot.

  3. 3Constrain

    Tell the agent what NOT to change. "Fix only the submit handler."

  4. 4Verify

    Repeat the reproduction steps. If the same click now works, you're done.

A four-move loop for every bug. Skip a step and you'll fix the wrong thing.
"On /contact, submitting the form with a valid email throws TypeError: Cannot read properties of undefined (reading 'name') in ContactForm.tsx. Expected: the success card. Only fix the submit handler — don't touch styling or fields."

What NOT to say

  • "It doesn't work" — say what specifically doesn't work.
  • "Fix everything" — you'll get sweeping changes and lose the parts that were fine.
  • "Rewrite the page" — you almost never need this. Ninety percent of bugs are one line.

Part 4 · Rolling back with history

Every message in Lovable is a checkpoint. If a change broke the app and you can't see the fix, don't dig — revert. Go back to the last version that worked and re-approach the problem. This is the single most underused feature by beginners.

Figure 4.1
v1v2v3 ✓ known goodv4 brokev5 still brokenv6 reverted to v3revert
Your project is a timeline of versions. When a recent turn breaks things, revert to the last green dot and re-prompt from there.

When to revert vs. patch forward

  • Revert when the last 1–3 turns clearly broke something that used to work. Cheaper to start that turn over than to unwind it.
  • Patch forward when the broken thing is a small, isolated new feature you can describe precisely.
  • Always revert if the app won't even load. Debugging a blank screen with no preview is a bad trade.
Keep a mental "last known good"
After every meaningful milestone — first hero, first working form, first successful deploy — note the version. When something breaks two hours later, you know exactly where to fall back to.

Part 5 · Escaping stuck loops

Sometimes the agent tries a fix, it doesn't work, it tries again, and the same error keeps coming back. This is a loop, and continuing to say "still broken, try again" almost never breaks out of it. You need to change the shape of the problem.

Signs you're in a loop

  • The same error message appears after three fix attempts.
  • The agent starts editing files unrelated to the bug.
  • Each fix reintroduces a bug from two turns ago.
  • You've said "still not working" more than twice in a row.
Avoid
Keep patching
"Still broken." "Still broken." "Still broken." The agent piles fixes on fixes, the diff grows, and the real bug hides under three layers of well-meaning changes.
Do
Revert & restart the turn
Roll back to before the loop started. Re-describe the bug from scratch with the reproduce/expect/see structure — and add one hint about where you think it lives.

Four moves that break loops

  • Revert first — undo the last 1–3 turns, then re-prompt with a cleaner description.
  • Narrow the scope — "Fix only the submit handler in ContactForm.tsx. Don't change anything else."
  • Change the approach — "The current approach isn't working. Try a different one: validate on the server instead of in the component."
  • Split the task — break it into two small prompts instead of one big one. Small prompts fail less.
"The last three attempts didn't fix this. Please revert to the working version, then take a different approach: instead of adding checks inside the component, add a Zod schema and validate before the insert."
When in doubt, step away
Loops feed on urgency. Close the tab, take five minutes, and come back with a fresh reproduction. You'll be shocked how often the fix becomes obvious after a walk.

Debugging cheat sheet

Five habits that turn "everything is broken" into "one line is broken, and I know which line".

  • Read before you type — the error names the file and the line. Read it, screenshot it, send it.
  • Reproduce, expect, see — three-line bug reports beat three-paragraph ones every time.
  • Constrain the fix — tell the agent what NOT to change, not just what to change.
  • Revert is not defeat — it's the single fastest debugging tool you have.
  • Break loops early — after three failed fixes, change the shape of the request, don't repeat it.
Recap
You can now read errors, describe bugs in a way the agent can act on, roll back when a change goes bad, and break out of stuck loops. In Lesson 8 — the last of the beginner track — you'll take your finished site to the finish line: publishing, custom domains, SEO basics, and analytics, so the world can actually find what you built.
PreviousForms & Data CaptureNext Publishing & Custom Domains