How to debug a vibe-coded app when nothing works

The app worked yesterday. Today it doesn’t. You didn’t change anything. Welcome to the most frustrating 30 minutes in vibe coding.

This is the playbook I use when something breaks in an app I built with AI. It’s not theoretical — these are the actual checks I run, in order, and they catch the bug 90% of the time within 15 minutes. The other 10% is the kind of deep dive that needs a real developer, and I’ll tell you when you’re at that point too.

If you’ve never debugged a vibe-coded app before, the most important mindset shift is this: the AI is your debugger, not your magic wand. The technique that works is “look at the actual error yourself first, then paste it into the AI with full context.” The technique that doesn’t work is “tell the AI it’s broken and hope it figures out the problem.” The first works because the AI is great at fixing specific errors. The second doesn’t because the AI is bad at guessing which of a thousand possible things might be wrong.

1. Read the actual error

The single biggest debugging mistake vibe coders make: not reading the error message. When something breaks, you’ll usually see a red box, a popup, a sad face emoji, or “Something went wrong.” The instinct is to show this to the AI and say “fix it.” The problem is that what you see is a summary of the error. The actual error is in the browser console or the server logs, and it has a line number and a specific message that the AI needs to fix it.

How to see the actual error:

1. Open the browser’s DevTools: right-click anywhere on the page, choose “Inspect” (Chrome/Edge) or “Inspect Element” (Firefox). Or press F12.
2. Click the “Console” tab. Refresh the page. Watch for red text.
3. Click the “Network” tab. Reproduce the action that broke (click the button that errored, submit the form, etc.). Look for a request that returned a red status (4xx, 5xx). Click it, click “Response” to see the actual error from the server.

For server-side errors, you’ll also need to look at the tool’s server logs. In Blink, Lovable, and Bolt, you can find the logs in the project settings or in the chat panel where the AI is running. Look for the most recent error message — usually it has a stack trace.

What to look for in the error:

• A specific file and line number (at handleSubmit in /api/submit.js:42)
• A specific error type (TypeError: Cannot read property 'email' of undefined)
• A specific HTTP status code (500, 404, 401, 422)

Once you have these three things, you can give the AI an actionable prompt.

2. Use this exact prompt pattern

The prompt that gets the best fix from the AI is structured like this:

The [feature] is broken. Here's what happens:
1. I [user action]
2. I expect [expected behavior]
3. Instead I see [actual behavior]

Here's the error from the browser console / server logs:
[PASTE THE FULL ERROR MESSAGE, INCLUDING STACK TRACE]

Here's the file and line the error points to:
[file path]:[line number]

Please fix this specific error. Don't change anything else.

The reason this works: it gives the AI (a) the symptoms, (b) the exact error text (not your interpretation), (c) the location, and (d) a guardrail to not refactor unrelated stuff. Vague prompts like “the app is broken” produce vague guesses. Specific prompts like the above produce specific fixes.

The “don’t change anything else” guardrail is critical. Without it, the AI will often “fix” the bug by rewriting 200 lines of code that you don’t want rewritten. With it, the AI will make a targeted change to the specific function that’s broken.

3. Check the five things that always break

When you don’t have a clear error message (the page just hangs, the UI looks wrong, a button does nothing), run through this checklist. These are the failure modes that show up over and over.

3.1 Environment variables

The number one cause of “works in dev, breaks in production” bugs. Every API key, database URL, and third-party service token is an environment variable. If you forgot to set one in production, the app will fail at runtime when it tries to use that service.

The fix:

• In your tool’s project settings, find the environment variables section
• Compare your dev variables to your production variables. Anything in dev should also be in production (with the production value, not the dev value)
• Most common miss: a new feature you added used a new API key, and you set it in dev but forgot to set it in production

3.2 Database schema drift

The second most common cause. You added a new column to the database in dev, the app works fine in dev (because the new column is there), but the production database doesn’t have the new column yet.

The fix:

• If your tool has a “sync schema” or “push migrations” button, click it
• If not, paste your current dev schema into the AI and ask: “compare this to the production schema and tell me what’s missing”
• The actual fix: in your AI prompt, say “the production database is missing the [column name] column. Add a migration that creates it. Don’t change any other schema.”

3.3 Stale build / cache

Sometimes the app loaded an old version of the code. The dev server has a hot-reload, but production deployments often have aggressive caching.

The fix:

• Hard refresh: Ctrl+Shift+R (Windows) or Cmd+Shift+R (Mac)
• Open in an incognito/private window (bypasses all caches)
• If neither works: in your tool’s settings, find the “clear cache” or “rebuild” button, click it, redeploy

3.4 Auth/session state

Authentication state is per-browser-session, and it can get out of sync. A logged-in user suddenly appears logged out. A user can’t access a page they should be able to access.

The fix:

• Sign out and sign back in
• Clear cookies for the site
• Check that the auth provider (Clerk, Auth0, Supabase Auth, etc.) is using the same API keys in dev and production — same env var pattern as 3.1

3.5 The data is wrong

Sometimes the app works fine, but the data it shows is wrong. A user expects to see their own orders but sees someone else’s. A dashboard shows zero when it should show ten.

The fix:

• Open the database directly (most tools have a built-in database viewer, or use the dashboard of your database provider — Supabase, Neon, PlanetScale, etc.)
• Look at the actual data. Is the user ID stored correctly? Is the filter being applied?
• Paste a sample row into the AI and say “the dashboard is showing wrong numbers. Here’s what the data looks like: [paste]. Here’s what it should show: [expected]. Find the bug in the query.”

4. The “show me what the AI is doing” trick

When nothing else works, the most powerful debugging move is to ask the AI to explain what it’s doing, not to fix anything. Specifically:

Don't change any code. Instead, walk me through what happens in
this app when a user clicks the "Submit" button. Trace the flow
from the button click to the database write. List every function
that runs and what it does.

The AI will produce a flow diagram in text. Read it. The bug is usually visible in the flow. Either a function is missing that should be there, or a function is there but does the wrong thing, or the order is wrong.

Once you have the flow, you can point at the specific step that looks wrong and say “I think step 3 is the problem. Here’s why: [reason]. Check that step and fix it if I’m right.”

This trick works because it turns debugging from “guess what’s wrong” into “verify the plan.” The AI is much better at the second than the first.

5. When to call a real developer

There are bugs that vibe coding tools and AI can’t reliably fix, and it’s better to recognize them early than to spend hours in a loop. The signals:

• The bug involves security (auth, permissions, payments, data leakage). The AI will suggest something that works but might be insecure. Pay a developer to review.
• The bug is in infrastructure you don’t control (a third-party API is misbehaving, a database provider is having an outage). The fix is in their status page, not in your code.
• The bug is in a custom business logic that no AI can guess (a complex tax calculation, a multi-party workflow with edge cases). You need a developer who understands the business rules.
• The bug is in a state machine with many transitions (a checkout flow with 7 steps and edge cases at each). The AI can write the code, but debugging the interactions between steps is hard for any tool.

For all of these, the move is the same: stop trying to fix it yourself, write up a clear description of the bug (including the error, the steps to reproduce, and what you’ve already tried), and hand it to a developer. The clearer your writeup, the less they bill you.

The debugging flow cheat sheet

When something breaks, in order:

1. Read the actual error in the browser console + server logs
2. Note the file, line number, and error type
3. Use the prompt pattern from section 2 above
4. If the AI’s fix doesn’t work, check the 5 things in section 3
5. If those don’t fix it, ask the AI to walk through the flow (section 4)
6. If none of that works in 2 hours, stop and call a developer (section 5)

The biggest time-saver is doing steps 1-2 before you prompt the AI. The AI’s first guess with a clear error is right 80%+ of the time. The AI’s first guess with no error is right 20% of the time.

FAQ

I have no coding background. Is this article still useful for me?

Yes. The first three sections (what to check, browser DevTools basics, console log reading) don’t require any code knowledge. The “prompt the AI to fix it” section is the move for non-coders. The deeper sections on environment variables, network requests, and database state are useful for understanding what your developer (or your AI) is looking at when things go wrong, but you can skip them and still ship working apps.

How long should I debug before I give up and start over?

Rule of thumb: if you’ve been stuck on the same bug for 2 hours and you don’t have a clear next step, stop and rebuild that section. The vibe coding model is built for fast iteration, not for hours of debugging. The exception is when the bug is structural (auth doesn’t persist, data isn’t saving) — those are worth the time because re-architecting them later is worse. For UI/visual bugs and edge cases, just rebuild.

Should I let the AI debug my code without reading the bug?

No. Always look at the error message yourself first, even if you don’t understand the code. The AI will often misread or hallucinate fixes if you don’t tell it the exact error. Copy-paste the actual error text (not your interpretation of it) into the prompt. “I have a 500 error when I click submit” is much less useful to the AI than “POST /api/submit returned 500 with body {“error”:“unique constraint violated”}”.

What if the bug only happens in production, not in the dev environment?

This is the most common debugging failure for vibe-coded apps. The most likely cause is environment variables. Your dev environment has a different set of secrets than production (different API keys, different database URL, different Stripe keys). Add a debug step that logs the env var name (not the value) at the start of the failing function. Compare what your dev env has to what your production env has. 80% of “works in dev, breaks in prod” bugs are missing or wrong env vars.

What’s the single most useful debugging habit for a vibe coder?

Read the actual error message out loud, all the way to the bottom, including the stack trace. The actual error is almost always in the last 2-3 lines of the trace. Most vibe coders stop reading at the first error word (“Error:”, “TypeError:”, etc.) and miss the line that says WHICH file and WHICH function the error is in. Once you know the file and function, paste the entire error into the AI and say “fix this specific error in this specific file.” You get a much better answer.

How do I know if the bug is in my code or in the tool?

The 80/20 test: if the same code worked yesterday and doesn’t work today, it’s almost certainly the tool (tool update, infra change, regional outage). If the same code never worked, it’s almost certainly your code. Check the tool’s status page and changelog first when something breaks suddenly. The vibe coding tools all have public status pages and Discord/Slack communities where people report new bugs in real time. reviewed: true