Debugging With AI

The app worked five minutes ago. You changed one thing. Now it's a blank white screen. Your instinct is to paste "it's broken, fix it" into the AI and hope. That instinct is why you'll be stuck for an hour.

Debugging with AI is a skill, and it's mostly about giving the AI what it needs — because the model can't see your screen, your console, or what you just did. It only knows what you tell it.

The mindset: you are the eyes, AI is the brain

You don't have to understand every line to debug. But you do have to become a good reporter. The AI is a brilliant diagnostician who is also completely blind. Your job is to describe the scene precisely.

A vague report gets a vague guess. A precise report gets a precise fix. The whole skill compresses to: collect good evidence, then hand it over.

Step 1: Read the actual error

Beginners' eyes glaze over at red text. Don't. The error message is the single most valuable clue you have, and it's usually more readable than it looks.

Two places to find it:

• The browser console (right-click → Inspect → Console). Frontend errors live here.
• The terminal or server logs where your app runs. Backend errors live here.

Copy the entire error, including the file name and line number. Not "there was an error" — the literal text.

Step 2: Describe what changed

Bugs don't appear from nowhere. Something changed: you added a feature, edited a file, installed something. Tell the AI the before and after:

"It was working. I asked you to add a delete button. Now the whole list page is blank and the console shows: [error]. Here is the file you changed: [code]."

"What changed" narrows the search from your entire project to the last thing you touched. That's usually where the bug is.

Step 3: Give it the three things it needs

Every good bug report to an AI has three parts:

1. What you expected to happen.
2. What actually happened (with the exact error).
3. The relevant code — the file involved, not the whole project.

Miss one and the AI guesses. Include all three and it usually nails the cause on the first try.

Step 4: Change one thing at a time

When the AI suggests a fix, apply it and test before asking for more. The biggest beginner mistake is stacking five suggested changes at once — now if it's still broken, you have no idea which change did what.

One change, one test. Slow is fast here. If a fix doesn't work, undo it before trying the next idea, so your code doesn't accumulate dead experiments.

Step 5: When you're truly stuck, make it smaller

If you've looped a few times and nothing works, stop adding. Shrink the problem instead:

"Let's isolate this. Make a minimal version of just this feature, on its own, with nothing else. Does it break there too?"

Reproducing the bug in isolation tells you whether it's the feature itself or how it connects to the rest. Either way, you've cut the search space in half.

Ask the AI to explain, not just fix

Here's the move that turns debugging into learning. After it fixes the bug, ask:

"What was actually wrong, and why did your fix work? Explain it like I'm new."

Do this every time and a strange thing happens: the same bug stops surprising you. You start recognizing the category of problem, and eventually you fix the easy ones before the AI even weighs in. That's the whole point — not to depend on AI forever, but to understand your own product a little more with every break.

The loop, in one breath

Read the error → say what changed → give expected/actual/code → fix one thing → test → ask why. Round and round until it's green. It's not glamorous, but it's the difference between debugging and praying.