Debugging code you didn't write

The strange bargain of vibe coding: the AI writes the code, but when it breaks at 11pm, you're the one holding it. Debugging code you didn't write is the defining intermediate skill — and it's very learnable, because most of it is method, not knowledge.

Rule zero: commit first

Before any debugging session, make a save point. Debugging means changing things, half your changes will be wrong, and you want a way back. Git guide here if that sentence wasn't obvious yet.

Read the error message. Actually read it.

Error messages look like hostile noise and are usually a polite, specific note. Three parts matter:

• The message itself — often plain English: Cannot read properties of undefined, fetch failed, Invalid API key.
• The location — a file name and line number, frequently of the exact broken spot.
• The first line vs. the wall of text — when twenty errors cascade, the first one is the cause; the rest are dominoes. Fix top-down.

Where errors hide: the terminal or build output for server/build problems, and the browser console for anything that breaks silently on the page (right-click → Inspect → Console — learn this one, it's where "button does nothing" bugs live).

Ask the AI like a witness, not an oracle

The quality of AI debugging help tracks the quality of your report. Weak: "it's broken, fix it." Strong:

"Clicking Save on the settings page does nothing. Console shows: [pasted error]. It worked before we added avatar uploads. Fix this specific issue without changing anything else."

That's the whole formula: symptom + exact error + what changed recently + scope limit. The scope limit matters more than people expect — AI models have a documented urge to "improve" surrounding code while fixing bugs, which is how a one-line fix becomes three new bugs.

Two more prompts that punch above their weight:

• "Add logging that will reveal where this goes wrong, and tell me what to do to trigger it." — turns a mystery into evidence.
• "Explain what this error means and what the likely causes are, before changing anything." — forces diagnosis before surgery.

Spotting when the AI is confidently wrong

AI coding tools fail in patterns. After a while you can smell them:

• The apology loop. "You're absolutely right, the issue is X" → fix fails → "You're absolutely right, the issue is actually Y" → fails. Two loops means it's guessing. Stop asking for fixes; ask for evidence ("add logging") or roll back and re-approach.
• The phantom fix. It declares the bug fixed; nothing changed. Always re-test yourself — "should work now" is a hypothesis, not a result.
• Fixing the symptom. The error disappears because the code that threw it was deleted or wrapped in a silent catch-all. If a fix seems too easy, ask "did this address the cause or hide the error?"
• Inventing APIs. It calls functions or settings that don't exist, especially on newer or niche libraries. If a fix fails with not a function or similar, say "verify that against the actual documentation."

The pattern behind the pattern: the AI optimizes for a plausible-sounding answer now, while you have access to the ground truth — the actual running app. Trust the app.

The escalation ladder

When a bug won't die, climb one rung at a time instead of thrashing:

1. Re-describe from scratch in a fresh chat — long debugging threads poison the context with failed theories.
2. Roll back to the last good commit and re-attempt the feature in smaller steps.
3. Isolate it: "build a minimal page that only does the broken thing." Tiny reproductions get fixed in one shot remarkably often.
4. Search the exact error text in quotes — for platform-specific issues, a forum thread sometimes beats the model.
5. Walk away. Unreasonably effective. The bug will still be there tomorrow; your patience won't be missed tonight.

You're learning more than you think

Every debugging session quietly teaches you how the project actually fits together — which file does what, how data flows, what the AI tends to get wrong. That knowledge compounds. It's exactly what makes graduating to pro tools feel natural instead of terrifying, and it's what the "How it was made" tab on gallery projects is really documenting: not just prompts, but battles won.