Log in
You know the drill. Something’s broken. You’re not sure where. You add a console.log. Then another. Then twelve more. You run it again. The bug doesn’t appear. You add more logs. Now it appears but the logs don’t help. You start guessing.
This is debugging by wandering. It works eventually, but it’s slow and frustrating.
Here’s what I’ve learned: AI is annoyingly good at debugging. Not because it’s smarter, but because it’s systematic. You describe the symptoms, AI lists the likely causes in order of probability, and you work through them methodically.
While you’re guessing, AI is pattern matching against every bug it’s ever seen.
Why AI Is Good at Debugging
Debugging is pattern matching. You have a symptom. You need to find the cause. The space of possible causes is large.
AI has seen millions of bugs. It recognizes patterns: “silently fails sometimes” often means race condition, async issue, or swallowed error. “Works locally but not in production” often means environment variables, database differences, or timing issues.
When you describe a bug, AI immediately narrows to the most likely categories. Then it helps you test each one systematically.
The Debugging Prompt
Here’s the prompt that starts most debugging sessions:
I have a bug. Help me find it.
Symptom: [describe what's happening]
Expected: [describe what should happen]
Frequency: [always / sometimes / rarely]
Environment: [local / staging / production]
Relevant code:
[paste the code you think is involved]
Recent changes:
[paste recent commits if relevant]
What I've tried:
[what have you already ruled out?]
Help me:
1. List the top 5 most likely causes
2. For each cause, how would I confirm or rule it out?
3. What logging would help narrow it down?
A Real Debugging Session
Here’s how the card transfer bug went:
Me:
I have a bug. Help me find it.
Symptom: Card transfers sometimes fail silently. The API returns
success, but the card stays with the original owner.
Expected: Card ownership should transfer to the new owner.
Frequency: Sometimes. Maybe 1 in 100 transfers.
Environment: Production only. Can't reproduce locally.
Relevant code:
[pasted the transferCard function]
What I've tried:
- Added logging to the function
- Checked for database errors
- Verified the API is being called correctly
AI:
Top 5 most likely causes for intermittent silent failures:
1. Race condition in concurrent transfers
The ownership check and update aren't atomic. Two concurrent
transfers could both pass the ownership check before either writes.
Confirm: Add logging with timestamps before check and after write.
Look for overlapping timestamps in production logs.
2. Database transaction isolation
Default isolation level might allow dirty reads where the ownership
check sees stale data.
Confirm: Check your database isolation level. Test with two
simultaneous transfers of the same card.
3. Stale cache
If you're caching card data, the check might use cached ownership
while the write goes to the database.
Confirm: Check for any caching layer. Try disabling cache and
testing.
4. Optimistic locking failure without proper handling
If using optimistic locking, version conflicts might be silently
swallowed.
Confirm: Search for where version conflicts are caught. Check if
they're being logged.
5. Unhandled promise rejection
An async operation might be failing without the error bubbling up.
Confirm: Add try/catch around all async operations. Add
.catch() to any promises.
The race condition hypothesis led me to add timestamp logging. Sure enough, I found cases where two transfers were within 50ms of each other. Both passed the check. Both tried to write. Only one succeeded. The other silently did nothing because the ownership had already changed.
The Hypothesis-Test Loop
Good debugging is scientific. Hypothesis, test, refine.
Based on our debugging so far:
Hypothesis: [what you now think the cause is]
Evidence: [what supports this hypothesis]
Against: [what doesn't fit this hypothesis]
Next test: [what would confirm or refute this]
Generate the specific code or query I should run to test this hypothesis.
This keeps the debugging focused. No more random changes hoping something works.
Log Analysis
When you have logs but can’t see the pattern:
Analyze these logs for the bug we're tracking.
Bug: [describe the symptom]
Logs from successful operation:
[paste logs]
Logs from failed operation:
[paste logs]
Compare them:
1. What's different between success and failure?
2. What's missing in the failure case?
3. What sequence of events leads to failure?
4. What timestamp patterns do you notice?
AI is good at spotting differences humans miss. Different order of operations. Missing log entries. Timing anomalies.
Stack Trace Analysis
When you have a stack trace but don’t understand it:
Explain this stack trace and help me find the root cause.
Error: [paste the error message]
Stack trace:
[paste the full stack trace]
For each frame:
1. What file and function?
2. What was it trying to do?
3. Is this library code or our code?
Then:
1. Where did the error actually originate?
2. What caused the error?
3. What's the fix?
The Rubber Duck With Context
Sometimes you just need to explain the problem:
I'm stuck on a bug. Let me explain it to you, and ask questions
that help me think through it.
The bug: [describe it]
The code: [paste it]
Ask me questions about:
1. What I've already tried
2. What I expect vs what happens
3. Any recent changes
4. Edge cases I might have missed
AI asking you questions often reveals assumptions you didn’t realize you were making.
Narrowing Down
When the bug could be anywhere:
Help me narrow down where this bug lives.
System overview: [describe the components involved]
The bug: [describe the symptom]
Help me create a binary search:
1. What's the midpoint? What can I test to determine if the bug
is in the first half or second half of the flow?
2. Based on that test, what's the next midpoint?
Goal: narrow to a single component in as few tests as possible.
Common Bug Patterns
AI recognizes these patterns instantly:
“Works sometimes” → Race condition, caching, timing issue
“Works locally, fails in production” → Environment config, data volume, network latency
“Worked yesterday, broken today” → Recent commit, dependency update, data change
“First request works, subsequent fail” → State mutation, connection pool, memory leak
“Works for me, fails for users” → Permissions, data differences, browser/client differences
Tell AI which pattern matches your bug, and it knows where to look.
Adding Strategic Logging
When you need more visibility:
I need to add logging to debug this issue.
The bug: [describe it]
The code: [paste it]
Generate logging that will help me:
1. Trace the exact path execution takes
2. See the state at each decision point
3. Capture timing information
4. Include enough context to identify the specific request
Use our logging format: [describe your logging pattern]
Make the logging easy to add and remove.
The Fix Verification Prompt
Once you think you’ve found it:
I think I found the bug and have a fix.
The bug: [describe it]
The cause: [describe what was wrong]
The fix: [paste your fix]
Review this fix:
1. Does it actually address the root cause?
2. Could it introduce new bugs?
3. What tests should I add to prevent regression?
4. Are there other places with the same bug pattern?
Debugging AI-Generated Bugs
AI code has predictable bug patterns:
This is AI-generated code that has a bug.
The bug: [describe it]
The code: [paste it]
Common AI code bugs:
- Off-by-one errors in loops
- Missing null checks
- Incorrect async/await handling
- Wrong array methods (map vs forEach vs filter)
- Missing error handling
- Incorrect type coercion
Check for these patterns first.
Tomorrow
Debugging is reactive. You find bugs after they exist. But what about bugs in production where you can’t just add console.log?
Tomorrow I’ll cover production debugging: when it’s on fire and you need to find problems with only the observability you already have.
Try This Today
- Think of a bug you recently spent too long finding
- Write up the initial prompt as if you were starting fresh
- See what AI suggests
Notice how quickly AI narrows to likely categories. That systematic approach is what makes AI debugging faster than random guessing.
Next time you hit a bug, start with AI instead of ending with it.
