12 AI Debugging Prompts That Actually Find the Bug

The best AI debugging prompts do three things. They give the model the exact error, they say what you expected to happen, and they ask for the cause before the fix. Below are 12 you can paste into Cursor, Claude Code, or a plain chat window.

Swap the [brackets] for your own details. Most of these work in any tool.

Three rules before you paste anything

Paste the whole error. Don't retype it as "something about undefined." Claude Code's own best practices page recommends pasting the actual error, plus telling it to address the root cause rather than suppress the error.

Ask for hypotheses, not patches. One prompt guide puts it well: a good prompt makes the model prove the cause before it proposes a fix. Otherwise you get a try/catch wrapped around the real problem and a bug that has moved somewhere else.

Change one thing at a time. Apply a fix, run it, report back. If you accept five changes at once, you won't know which one worked.

Prompts for when you have an error message

1. The root-cause-first prompt

This is the one to keep. Use it by default.

Here is the error and the relevant code.
Error: [paste full error and stack trace]
Code: [paste the function or file]
Stack: [language, framework, versions]

Explain the root cause before proposing any code.
Then give the smallest fix, and tell me what test would catch this next time.

2. The "what does this even mean" prompt

Explain this error in plain English, as if I haven't seen it before.
List the three most likely causes in order of probability,
and for each one tell me how to check it in under a minute.
[paste error]

Good for cryptic build output and dependency errors. You get a checklist instead of a guess.

3. The expected vs. actual prompt

Expected: [what should happen, e.g. "API returns JSON"]
Actual: [what happens, e.g. "returns an HTML error page"]
Steps to reproduce: [exact steps or command]
What's different between expected and actual? Give me hypotheses, not a fix.

This one is for bugs with no error message. The app runs fine and the data is just wrong. Without a stated "expected," the model has to guess what correct looks like.

4. The "already tried" prompt

Error: [paste]
Already tried: [list each thing and what happened]
Don't repeat those. What else could cause this?

It saves you from the first three obvious suggestions you've already ruled out.

Prompts for bugs you can't pin down

5. The ranked hypotheses prompt

List every plausible cause of this behavior given the code below.
Rate each by likelihood and say what evidence would confirm or rule it out.
Don't write any code yet.

Use this for flaky or intermittent bugs. You pick which hypothesis to test first, and you stay in charge of the investigation.

6. The "add logging" prompt

I can't tell where this goes wrong. Add temporary log statements that would
confirm or reject your top three hypotheses. Tell me exactly what to do to
reproduce it, and which log lines to send back to you.

This is the manual version of what Cursor's Debug Mode automates. More on that below.

7. The trace-the-path prompt

Trace the execution path from [entry point, e.g. the button click handler]
to [where it breaks]. At each step, tell me what the value of [variable] should be.
Flag any step where it could differ.

8. The "it started after" prompt

This worked yesterday. Since then I changed: [list, or paste git diff].
Which change most likely caused this, and why?

Recent changes narrow the search a lot. A git diff is the best thing to paste here.

Prompts for AI-generated code that went sideways

This is the vibe coder's special case. The AI wrote it, it half works, and you didn't read all of it.

9. The "explain what you built" prompt

Walk me through how [feature] works in this codebase, file by file.
Mention anything that looks fragile or that you assumed without checking.

Run it before you start fixing. Half the time the bug shows up in the explanation.

10. The scope-limiting prompt

Fix only [the specific problem]. Don't refactor, rename, or touch
any file other than [file]. If you think another file needs to change,
tell me first and wait.

Agents love to "improve" things nearby. This keeps the diff small enough to review.

11. The verify-it prompt

Write a failing test that reproduces this bug. Run it and confirm it fails.
Then fix the code and run it again until it passes. Show me both runs.

Claude Code's docs say to give the agent something that produces pass or fail, so the loop can close on its own. A failing test is the cheapest way to do that.

12. The postmortem prompt

Now that it's fixed: why did this happen, and why didn't we catch it?
Suggest one test or check to add, and one line for my project rules file
so the agent avoids this next time.

The rules-file line is the part that pays off later. Put it in CLAUDE.md, Cursor rules, or whatever your tool reads on startup.

Use your editor's debug mode when it exists

Cursor has a dedicated Debug Mode. According to its docs, the agent forms hypotheses, adds log statements, asks you to reproduce the bug, reads the logs, makes a targeted fix, and then removes the instrumentation. You switch to it with the mode picker or Shift+Tab.

Cursor's own guidance says regular Agent mode is faster for straightforward errors with clear stack traces. Debug Mode is for bugs that are hard to reproduce or understand. If you're reaching for prompt 5 or 6 above, try the mode first.

In Claude Code, you can pipe an error straight in. The docs show cat error.log | claude as a way to send file contents directly. Prompts 1 and 11 work well there.

Mistakes that waste your afternoon

• Summarizing the error. Your paraphrase drops the line number or exception type, and that's usually the clue.
• Dumping the whole repo. Send the relevant files. Claude's docs note that performance degrades as the context window fills, so a long, messy session gets worse over time.
• Rephrasing instead of adding context. If the first answer misses, give more evidence (logs, a diff, a repro). Don't ask the same question differently.
• Looping on a bad thread. After a few failed attempts, start a fresh chat. Paste the error, the one relevant file, and a short list of what you've tried.
• Trusting the fix without running it. The model can't see your runtime unless you give it logs or let it run code. Always run it.

A quick routine

1. Reproduce the bug yourself and copy the exact error.
2. Paste prompt 1 (or 3 if there's no error).
3. Read the diagnosis. If it doesn't fit what you see, use prompt 5 or 6.
4. Apply one fix, using prompt 10 to keep the change small.
5. Confirm with a test (prompt 11), then run prompt 12.

FAQ

What is the best prompt for debugging code with AI?

Prompt 1 is the safest default. It includes the full error, the relevant code, your stack and versions, and it asks for the root cause before any code. If you only remember one habit, make it "explain the cause first."

Why does the AI keep giving me the same wrong fix?

Usually it's missing evidence, or the thread has gotten long and cluttered. Tell it what you already tried, add logs or a repro, or start a clean chat with a short summary. Switching to a hypothesis-first prompt (5 or 6) also breaks the loop.

Can I trust AI-written bug fixes?

Treat them as a draft from a fast colleague who can't see your running app. Read the diff, run the code, and check edge cases. A failing-then-passing test, as in prompt 11, is the quickest way to know the fix is real.

Cover photo: James Harrison on Unsplash