Debug your code with AI

Give it three things: the code, the exact error text, and what you expected to happen. Without all three it's guessing, and its guess will be confident and wrong.

The more it knows about your intent, the sharper the answer. 'It's broken' gets you a lecture. 'It returns 0 when I expected 5' gets you the fix.

1. Paste the full code block, not a snippet
2. Paste the complete error and stack trace
3. Say what you expected vs what happened
4. Ask for the exact line and reason, not general advice
5. Ask it to confirm the fix with one test

Silent wrong answers are the worst kind — no crash to point at. The trick is showing the AI a concrete input and the wrong output next to the right one.

Give it one small example where you know the correct answer by hand. That turns a vague hunt into a math check the AI can actually reason through.

1. Pick one input where you know the correct output
2. Paste the code, the input, and both outputs
3. Ask it to trace the code line by line with that input
4. Have it point to where the value goes wrong
5. Ask for the fix and re-trace to confirm

Big stack traces are fine — the AI reads the whole thing. What confuses it is missing the top line, which is usually where your code is, buried under library noise.

Include everything but tell it what's yours. It'll ignore the framework internals and zero in on your file.

1. Copy the entire trace, top to bottom
2. Tell it which file names are your own code
3. Paste the code from those files too
4. Ask which frame is the real cause
5. Ask what to log to confirm before you touch code

Inherited code is a maze. Use the AI as a fast reader — have it explain the flow before you touch anything, so you're not fixing blind.

Ask what the code is trying to do first. Once you understand intent, the bug usually shows itself.

1. Paste the file and ask for a plain-English summary of what it does
2. Point to the bug's symptom and error
3. Ask which function is responsible
4. Ask what assumptions the code makes that might be wrong
5. Get the fix and ask what else it might affect

This is almost always environment, not logic — different versions, missing env vars, timing, or file paths. Feed the AI both logs and it'll spot the mismatch fast.

Give it the CI config too. The difference is usually hiding in there.

1. Paste the test code and the CI failure log
2. Paste your local pass log and CI config
3. Ask what differs between the two environments
4. List suspects: versions, env vars, ordering, timezone
5. Ask for one change to test the top suspect

The AI doesn't run your code — it predicts what a fix looks like. When it lacks context it fills gaps with plausible-sounding code that compiles but breaks something else.

Give it more real context and it stops inventing. The invented fixes come from thin information, not from the model being dumb.

• It never actually executes your code — it reasons about it
• Missing context forces it to assume, and assumptions get wrong
• It may 'fix' by changing behavior you actually wanted
• It can hallucinate library functions that don't exist
• Always run the fix before trusting it
• Ask it to explain why the fix works — bad ones can't

Debugging finds why your code broke so you learn and the fix is minimal. Rewriting throws it out and hopes the new version works — you lose the lesson and often the surrounding logic.

Rewrite when the code is a mess anyway. Debug when it mostly works and one thing is off. Reaching for a full rewrite every time is how you stay a beginner forever.

Understand it. Paste-and-pray works until the same bug shows up in a new shape and you're stuck again, still helpless. The whole point of debugging is that next time you're faster.

Spend two minutes asking 'why did this break' after every fix. That's the difference between someone who can code and someone who can only copy.

Intermittent bugs are timing, memory, or race conditions nine times out of ten. Describe exactly when it does and doesn't happen — the pattern is the clue, even when it feels random.

Give the AI the code plus every crash log you've got. It'll spot conditions you didn't notice were shared across the crashes.

Null errors are a value that was never set, or got cleared somewhere upstream. Give the AI the trace and the functions in the chain, and ask it to find where the value should have been assigned.

It'll walk backward through the calls faster than you can. Then verify by logging that one spot before you fix it.

Slow code is usually one loop, one query, or one thing done repeatedly that should be done once. Paste the function and ask the AI to rank operations by likely cost.

Don't guess and optimize blind — that's how you make it uglier and no faster. Get the AI's suspect list, then measure the top one before changing anything.

They fit different moments. Copilot lives in your editor for quick fixes as you type. Claude Opus handles deep reasoning on nasty bugs. Claude Code can actually read your whole repo and run things.

Most people end up using two: an in-editor helper plus a chat model for the hard stuff.

Editor tools are fast for small stuff — you don't break flow. Chat models win when you need to explain the whole situation and get real reasoning back.

Rule of thumb: one-liner bug, use the editor. Bug you can't even describe, open a chat and dump everything.

Because you still have to know when the AI is wrong — and it will be, especially on your specific edge cases and your weird setup. You can't judge a fix you don't understand.

Trust the AI to speed you up, not to think for you. The people who thrive use it to learn faster, not to skip the learning. The ones who paste blind stall out the moment the bug is unusual.

Trust the reasoning, verify the behavior. The AI can explain the bug perfectly and still hand you a fix that breaks an edge case it never saw. It doesn't run your code — you do.

Before you ship: read the fix, understand why it works, and run your tests. Two minutes of checking beats a 2am rollback. Never ship a fix you can't explain out loud.