Debugging a vibe-coded app is mostly learning to slow the agent down. Do not ask it to fix a bug it has not reproduced. Ask it to prove the bug, isolate the cause, make the smallest fix, and verify the result. To make that concrete, this post walks one real bug from broken to fixed, then leaves you the method to reuse.
The bug: a form that says it saved, but nothing appears
Here is the situation, the kind every beginner hits. You built a lead-intake form. You submit it, the page shows a success message, and the leads list stays empty. It "works" and does nothing, which is the most confusing kind of bug because there is no red error on screen.
Reproduce before you repair
Write the exact steps that trigger it: route, browser, account, the button clicked, the values entered, the expected result, and the actual result.
Route: /leads/new
Steps: fill name "Test", email "test@example.com", submit
Expected: lead appears at top of /leads
Actual: success toast shows, /leads stays empty
A bug report is a prompt with evidence. If you cannot reproduce it on demand, that is the first thing to fix, because you cannot confirm a repair you cannot trigger.
Read the first real error
Beginners paste the whole terminal dump. Instead, find the first meaningful line. Open the terminal running the dev server, submit again, and read what prints. Say it shows:
POST /leads/new 200
error: null value in column "user_id" violates not-null constraint
That single line changes everything. The request returned 200, so the form and route are fine. The database rejected the insert because user_id was empty. The success toast fired anyway, which is a second, smaller bug: the code celebrated before checking whether the write succeeded.
Isolate the layer
Most app bugs live in one layer: UI, data fetching, API route, database, auth, deployment, or a third-party service. The error above points squarely at the database write, triggered by a missing value that should have come from auth. Ask the agent to confirm the layer before it edits anything:
This insert fails with a not-null violation on user_id, but the route
returns 200 and shows success. Which layer is at fault, and what evidence
supports that? Do not change code yet.
Making the agent name the layer with evidence stops it from spraying edits across files that were never broken.
Make the smallest fix
Now, and only now, ask for a change, and constrain its size:
Fix this with a minimal change and do not refactor unrelated code:
1. Set user_id from the current session before the insert.
2. If the insert throws, return an error and do not show success.
Show me the diff.
When the diff comes back, read it. A good fix here touches one file and a few lines: it reads the session, adds user_id to the insert, and wraps the write so a failure returns an error instead of a toast. If the diff is large, or it starts renaming things or bumping dependencies, stop and ask why. A small bug that produces a big diff is a warning, not progress.
Verify and record
Run the same reproduction steps again, plus one nearby case that could have broken. Ask for proof, not a claim:
Submit a valid lead and confirm it appears on /leads. Then submit with a
logged-out session and confirm it now shows an error instead of false
success. Paste the terminal output for both.
Two green checks and you are done. Then write the lesson down in one line: "success toasts must wait for the write to succeed; always set owner fields from the session, not the form." That note becomes context for you and the agent next time, and debugging compounds when you save the lesson instead of relearning it.
The method, in five moves
Strip the story away and the reusable method is short: reproduce with exact steps, read the first real error, make the agent name the layer with evidence, demand a minimal diff, and verify with a command that produces output. Run that loop and you will fix most beginner bugs without the agent quietly turning a typo into a rewrite.
Keep the lesson
Save each bug's reproduction steps and one-line lesson in Command Center, so your hardest bugs become a debugging playbook instead of a feeling you have seen this before.
Sources and further reading
FAQ
What should I paste into an AI agent when debugging? Reproduction steps, expected and actual behavior, the first meaningful error line, and the relevant route or screenshot. Not the entire terminal dump.
Why does the AI keep making the bug worse? The task is probably too vague or too large. Make it investigate first, name the layer with evidence, and propose a minimal fix before editing anything.
Should beginners learn debugging before building bigger apps? Yes. Debugging is the skill that keeps vibe coding from becoming blind acceptance of code you cannot check.