What’s the First Thing to Check When a Vibe Coded App Breaks?

Question: What’s the first thing to check when a vibe coded app breaks?

The first thing to check is the exact error and the exact action that caused it. A vague bug report gives AI room to guess, but a specific action and error message make the next fix smaller and safer.

Why this should come first

This is the step people skip because it feels too simple. Something breaks, the app looks confusing, and the natural move is to paste a screenshot into an AI tool and ask it to fix everything. Sometimes that works. More often, it creates a patch based on an incomplete description.

If you want AI to help, give it a real bug report.

What did you click?

Start with the action. Not the whole app. Not the general feeling that it is broken. The action.

Examples:

• I clicked Save on the edit form.
• I opened the admin dashboard.
• I submitted the login form.
• I uploaded a CSV file.
• I ran the webhook test.
• I refreshed the page after changing a setting.

That one sentence narrows the problem. It tells you where to look and tells the AI what path to inspect.

What changed since it last worked?

Most bugs have a recent cause. Did AI rename a field? Did you add a new table? Did a package update? Did you move a file? Did you change “.env” on the server but not locally? Did a deployment skip a migration?

This does not mean the last change is always guilty. It means the last change is a sensible starting point.

If you are using AI coding tools, ask:

Review the last change and explain what parts of the app it could affect. Do not edit yet.

That is safer than asking for a fix immediately.

Is there a server error?

Server errors are useful because they often name the file, route, line, table, or function involved. Look for HTTP 500 errors, stack traces, failed requests, missing classes, permission errors, or database exceptions.

If the app is on a VPS or a simple LAMP stack, check the server logs. If it is running locally, check the terminal output. If it is a hosted AI app builder, look for whatever logs or deployment output the platform provides.

Copy the exact error. Do not summarize it too early.

Is there a browser console error?

Some bugs are frontend bugs. Open the browser console and look for red errors. A missing JavaScript file, failed API request, CORS problem, undefined variable, or 404 route can explain a lot.

The network tab is useful too. If clicking Save sends a request to “/api/tasks/undefined”, that is already a clue. If the request returns “401”, the problem may be authentication. If it returns “422”, the validation rules may not match the form data.

Is the database missing something?

A lot of generated app bugs are really schema mismatches. The code expects a column that does not exist. The form sends “userId” but the database has “user_id”. The AI added a migration locally but it never ran on the server.

Before asking for a rewrite, ask the AI to compare the query, model, migration, and form field names. That is a narrow debugging task.

This connects to the wider habit in Make the Bug Smaller Before You Ask AI to Fix It. The smaller the mismatch, the safer the patch.

Did AI rename something?

AI assistants love plausible names. Sometimes they change “project_id” to “projectId”, “is_admin” to “isAdmin”, or “/admin/jobs” to “/dashboard/jobs” because the new name looks cleaner.

Cleaner is not better if the rest of the app still expects the old name.

When something breaks after an AI patch, check renamed routes, fields, files, functions, and environment variables.

A useful first prompt

Use this before asking for code:

The app breaks when I do this: [exact action]

This is the exact error: [paste error]

Please inspect the relevant files and explain the likely cause. Do not change code yet. Tell me the smallest fix and how to test it.

That gives AI enough to be useful without letting it wander.

For broader prompt habits, How to Prompt LLMs Without Turning Your Project Into a Mess is worth pairing with this.

The takeaway

When a vibe coded app breaks, start with the exact action and the exact error. That turns a vague failure into a small debugging task. AI is much more useful when it is helping you inspect a real problem instead of guessing at a blurry one.