In this article
Question: How do you debug an app you vibe coded but don't fully understand?
You debug it by stopping the blind AI fix loop and forcing the problem into smaller visible pieces: reproduce the bug, read the exact error, find the file or feature involved, make one small change, test again, and only then move to the next patch.
Why this gets confusing
That sounds slower than asking ChatGPT, Codex, Cursor, Bolt, Lovable, or Replit to "just fix it." In practice, it is usually faster. The messy part of a vibe coded app is not always that the code is impossible. The messy part is that you do not yet know which part of the app is actually failing.
This is where a lot of people lose the thread. The app mostly works. A button saves sometimes. Login works on one page and not another. A table used to load, then an AI patch changed something, and now the error has moved somewhere else. At that point, the worst prompt is usually the broadest one: "Fix this app."
Why vibe coded apps break in confusing ways
AI-generated apps often grow faster than your mental model of them. The first version feels impressive because screens appear quickly. The second version starts connecting forms, routes, environment variables, database tables, permissions, and deployment settings. The third version can become a pile of half-remembered decisions.
That does not mean vibe coding is useless. I still think it is useful. But debugging depends on visibility. A simple PHP page, a database table, a login check, and an admin screen can be easier to reason about than a clever stack where every failure disappears behind a build tool, a framework convention, or a generated abstraction.
This is why I like the idea in Make the Bug Smaller Before You Ask AI to Fix It. The first move is not a rewrite. The first move is making the problem small enough that the next change has a chance of being sensible.
The first rule: don't ask for a full rewrite
When you do not understand the app, a rewrite feels tempting. The AI sounds confident. It can produce a cleaner-looking file. It may even fix the visible bug. The trouble is that it might also remove a permission check, rename a route, change a schema assumption, or break a different page you have not tested yet.
Ask for diagnosis before code. A better prompt is:
Inspect the current code first. Do not change anything yet. Explain what happens when this action runs, which files are involved, and the most likely cause of the error.
That forces the AI to slow down. It also gives you a chance to catch a bad assumption before it becomes a patch.
Get the exact error message
"It does not work" is not a bug report. It is a mood. Before asking AI to fix anything, collect the exact failure.
Check the browser console. Check the server logs. Check the terminal output. Check the network tab if a request is failing. Copy the real error, including the file name, line number, status code, route, table name, or missing environment variable.
If the app says "column user_id does not exist", do not ask the AI to improve the dashboard. Ask why that query expects "user_id", where the schema is defined, and whether the table actually has that column.
Find the smallest failing action
A bug is easier to fix when you can reproduce it in one sentence:
- click Save on the edit form
- submit login with a valid password
- open "/admin/routes"
- upload a small CSV
- run the scheduled job manually
If you cannot describe the failing action, the AI will probably guess. Sometimes it guesses well. Sometimes it gives you a patch that feels productive and makes the app harder to understand.
Keep patches small
The safest debugging loop is plain:
- Reproduce the bug.
- Identify the smallest relevant files.
- Ask for the likely cause.
- Make one small change.
- Test the same action again.
- Commit or note the result.
This is also why a safer AI workflow matters. The approach in The Safer AI Coding Workflow I'm Using to Build Terralog.online is not just about being careful for the sake of it. It is about keeping the project understandable while the AI helps.
When to stop and rebuild the feature properly
Sometimes the honest answer is that the feature needs a rebuild. If every fix adds another condition, the error keeps moving, or you cannot explain the feature in plain English, the code may not have a clear shape anymore.
That is not failure. That is a useful debugging result. You learned that the feature needs a smaller contract: one form, one route, one table, one clear permission rule, and one test path.
The takeaway
Debugging a vibe coded app is not about proving you understand every line immediately. It is about making the system visible enough that each fix has a reason. Reproduce the bug, read the error, ask for an explanation, patch one thing, and test again. That habit will save more projects than another confident full rewrite.