I used to have two tabs permanently open: my editor and Stack Overflow. When something broke, I’d copy the error message, search for it, scroll through answers from 2018, hope the top one still applied, and adapt the solution to my codebase.

It worked. But it was slow, and half the time the answers were for a different version of the library or a subtly different problem.

Now I debug with AI, and I’m genuinely not going back. Here’s the workflow I’ve settled on after months of refining it.

Step 1: Give the Full Picture

When something breaks, your instinct might be to paste just the error message. Resist that instinct. Give the AI three things:

  1. The error — full traceback, not just the last line
  2. The relevant code — the function or file where it’s happening
  3. What you expected — what should have happened vs. what actually happened

Here’s an example:

I’m getting this error when I try to create a new user:

sqlalchemy.exc.IntegrityError: (sqlite3.IntegrityError) UNIQUE constraint failed: users.email

Here’s my registration endpoint: [paste code]

I’m testing with a fresh database, so there shouldn’t be any duplicate emails. The error happens on the very first user creation.

That last sentence is the gold. It tells the AI that this isn’t a simple duplicate entry issue — something else is going on. Maybe the table isn’t being recreated properly, or there’s a migration issue, or the test is running against a stale database.

Stack Overflow would give you a generic answer about UNIQUE constraints. AI can analyze your specific code and context.

Step 2: Ask for Hypotheses, Not Just Fixes

This is the habit that leveled up my debugging the most. Instead of asking “How do I fix this?”, ask “What are the possible causes of this?”

Given this error and code, what are the most likely causes?
Rank them from most to least probable.

AI will typically give you 3-5 possibilities. More often than not, the actual cause is in the list. Now you can systematically check each one instead of guessing.

This is faster than jumping to the first fix you find online, because the hypotheses are tailored to your code. The AI can see that you’re using SQLAlchemy with SQLite, that your model has specific constraints, and that your endpoint has a particular flow. The hypotheses account for all of that.

Step 3: Use AI as a Rubber Duck (That Talks Back)

Sometimes the bug isn’t an error — it’s wrong behavior. The code runs fine but does the wrong thing. These are the hardest bugs to search for online because there’s no error message to Google.

This is where AI really shines. You can describe the expected behavior and the actual behavior, paste the code, and ask the AI to trace through the logic.

This function should return the top 5 users by score, but it’s returning them in the wrong order. Can you trace through the logic and find where the sorting goes wrong?

I’ve had AI catch off-by-one errors, incorrect comparison operators, and logic bugs that I’d stared at for twenty minutes without seeing. A fresh set of (artificial) eyes is surprisingly effective.

Step 4: Ask for the Test, Not Just the Fix

Once you’ve found and fixed the bug, don’t stop there. Ask AI to write a regression test.

Write a test that would have caught this bug.
It should verify that [expected behavior] works correctly
even when [the condition that triggered the bug].

This is the step that separates “I fixed it” from “I fixed it and it will never happen again.” And because AI is fast at writing tests, there’s no excuse to skip it.

Step 5: Learn from the Pattern

After the bug is fixed and tested, I sometimes ask one more question:

What general pattern or principle would have prevented this bug? Is this a common mistake with [technology/library]?

This turns every bug into a learning opportunity. AI is great at connecting specific mistakes to broader principles — like “always use parameterized queries” or “remember that JavaScript sort is lexicographic by default.”

A Real Example

Last week I had a Next.js API route that was intermittently returning stale data. No error, no crash — just occasionally wrong responses.

I gave AI the route code, described the symptom, and asked for hypotheses. The third hypothesis was the winner: I was reading from a module-level variable that persisted between serverless function invocations. The fix was a one-line change — moving the variable inside the handler function.

Time to find the bug on Stack Overflow: probably 30+ minutes of searching, reading, and adapting. Time with AI: about 4 minutes.

The Mindset Shift

The biggest change in debugging with AI isn’t the speed — it’s the approach. Instead of searching for someone who had the same problem, you’re working with a collaborator who can see your specific code and context.

You’re not limited to problems that other people have asked about publicly. You’re not adapting solutions from different frameworks or versions. You’re getting analysis tailored to your exact situation.

It doesn’t always work perfectly. Sometimes AI suggests fixes that don’t apply or misunderstands the problem. But even then, its hypotheses help you think about the problem differently. And that’s often all you need to find the answer yourself.

Give it a try next time something breaks. You might close that Stack Overflow tab for good.