Use AI for Debugging — AI-Assisted Coding, Part 7
Updated: Jul 30
AI-Assisted Coding · Part 7
AI is genuinely great at one debugging question — "what does this error mean?" — and genuinely dangerous at the next one: "so what's actually wrong?" It will hand you a confident diagnosis that sounds right and sends you fixing the wrong thing for an hour. This walks through using AI for debugging the way it actually helps: feeding it the stack trace and what you've already tried, treating its hypotheses as leads to test rather than answers to trust, and knowing when to close the chat and think.
AI is great at "what does this error mean?" Not always great at "why does this happen?"
Step 1: Paste the Stack Trace (5 min)
"Getting this error. What's likely the cause?
[paste full stack trace]"
Often AI:
Translates the error
Names common causes
Points to a likely fix
For unfamiliar errors: faster than Googling.
Step 2: Include the Code (10 min)
"This stack trace plus the function it points to:
[stack]
```python
def my_func():
...
What's the bug?"
Context. AI can spot the issue with both.
Without code: AI guesses from the error text alone.
## Step 3: State What You've Tried (10 min)
"I'm seeing X. I've tried:
Restarting the service
Checking env vars
Verifying the DB is reachable
The error persists. Any other ideas?"
Saves AI suggesting the obvious. Gets to less-common causes faster.
## Step 4: Ask for the Mental Model (10 min)
"I don't understand why this throws. Explain how Promise.all handles rejection."
AI is good at explaining concepts. Often: the explanation reveals your bug.
Better than "fix this" — you learn the why.
## Step 5: Have AI Generate Hypotheses (10 min)
"This bug is intermittent. About 1 in 100 requests fails with X. Give me 5 plausible causes."
AI brainstorms:
- Race condition
- Timeout
- Connection pool exhaustion
- Concurrency on shared state
- ...
Now you have a list to investigate.
## Step 6: Don't Trust the Diagnosis (15 min)
AI is confident. AI is sometimes wrong:
- Hallucinated cause
- Outdated docs
- Plausible-sounding but irrelevant
Verify each suggestion:
- Check the actual code path
- Read the actual docs
- Reproduce in isolation
If AI says "this could be a race condition," look at the actual concurrency. Don't just believe.
## Step 7: Use AI for Repro Steps (10 min)
"I see X in production. Help me write a minimal reproduction."
AI proposes a smaller version. Often: trying to reproduce surfaces the cause.
Reduction is a skill AI accelerates.
## Step 8: Test Your Hypothesis (10 min)
After AI suggests cause:
- Write a test that proves it
- Fix it
- Verify the test passes
Without verification: you might fix something else and think you fixed this.
## Step 9: Save the Solution (5 min)
After solving:
- Add a regression test
- Comment the fix if non-obvious
- If the bug class is common: document for the team
The next person hitting this bug: don't make them re-AI-debug.
## Step 10: When to Stop and Think (10 min)
If AI's suggestions aren't landing after 30 minutes:
- Step back
- Reproduce manually
- Use a debugger
- Read the code carefully
AI is a tool. When it's not helping, switch tools.
Don't spiral in AI-loop. Sometimes traditional debugging wins.
## What You Just Did
AI debugging: stack + code, what you've tried, mental models, hypotheses, verify, repro, test, save solution, step back when stuck. Faster bug hunts.
## Common Failure Modes
**Paste error; expect magic.** Without code/context: weak help.
**Believe AI's confident wrong answer.** Investigate the actual cause.
**No test for the fix.** Bug recurs.
**Loop with AI forever.** Stuck; should've used a debugger.
**Don't share findings.** Team re-debugs.
---
## Continue the AI-Assisted Coding path
- **Previous —** [Part 6: Use AI for Tests](/post/tutorial-6-use-ai-for-tests)
- **Next —** [Part 9: When Not to Use AI](/post/tutorial-9-when-not-to-use-ai)
_Part of the **AI-Assisted Coding** learning path._
