That is the whole prompt most of the time. You paste an error message with maybe a stray line of code above it. I’ve done it. You’ve probably done it too around the 3rd hour of chasing a bug that should have taken 10 minutes and sometimes it works. The model spits out a patch. The red squiggly line goes away, tests pass, and you move on with your life.But a lot of the time it just looks like it worked. You get a fix that papers over the symptom. You ship it because it is late and the tests are green. Then 3 weeks later the same bug shows up wearing a different costume.
Nobody learned anything. The AI didn’t actually understand your system. It pattern-matched against similar bugs it had seen 1,000 times and gave you its best guess with total confidence.
A wrong answer and a right answer look identical when they arrive in the same calm tone. So here is what I found actually works better. I am talking about a different way of thinking about the AI while you are stuck.
Why the one line prompt keeps failing you
I need to make a quick detour before the list because it matters.
You ask the model to guess what is wrong with a house it has never seen when you paste a bare error with no context. It only has a photo of 1 broken window. It doesn’t know your data shape, framework version, or what else touches that variable.
So it fills in the gaps with the most statistically likely explanation. That explanation is often right. But you have no way to tell the difference from the outside.
You have to give the model enough information to actually reason with.
1. Dump in way more context than feels necessary
This moves the needle the most. It is almost embarrassingly simple.
You might normally type something like this.
“This throws a TypeError, fix it.”
Try something closer to this.
This function processes a list of orders and throws TypeError: Cannot read property ‘total’ of undefined on line 14. Here’s the function, the shape of the input data, and the full stack trace. I’ve already confirmed the array isn’t empty. What’s causing this, given [framework + version]?
Notice what is actually in there. You have the real error text, the surrounding code, and your environment.
That last one matters a lot. The same error can have completely different causes depending on your library version. Models sometimes blur versions together in their answer.
A teammate would need to ask you a clarifying question before they could help. The AI needs that same info up front. Skipping it just delays the back-and-forth until after you get a bad answer.
2. Make it explain the bug before it touches the fix
Ask for the explanation first. Do not let it jump straight to the patch.
“Before you suggest anything, walk me through what’s actually happening here and why it produces this specific error.”
Generating a plausible fix and correctly diagnosing the root cause are 2 different tasks. A model can do the first one without really nailing the second. This happens often when a bug has multiple possible explanations.
Forcing the explanation step out into the open gives you a chance to catch a wrong diagnosis. You can stop it before any code gets changed.
And you actually learn what broke. You get more than just new code where the old code used to be.
Say something directly if the explanation doesn’t line up with what you know about the system. That mismatch is usually the most useful piece of information in the whole conversation.
3. Ask for a list of suspects, not a verdict
The nastiest intermittent bugs almost never have one obvious cause. Start asking for a suspect list.
Give me 3 or 4 possible causes here, ranked by how likely each one is. Tell me the fastest way to confirm or rule out each.
This turns the AI into a research partner. You stay in charge. You can check each hypothesis quickly with a log line or a quick value check.
This beats applying one suggested fix and crossing your fingers.
It is especially worth doing for anything involving timing, shared state, or ordering. A confident single answer usually addresses whatever symptom happened to be most visible in the code you pasted. The actual cause is usually sitting quietly somewhere else.
4. Shrink the problem before you throw it at the AI
Strip the bug down to the smallest possible version that still breaks. This is old school. It works just as well with AI in the loop as without it.
Help me build the smallest reproduction of this bug so I can isolate what’s actually causing it.
Two things happen when you do this. A smaller snippet is genuinely easier for the model to reason about correctly. It has less surface area to get distracted by something irrelevant 3 functions away.
The act of minimizing also often reveals the cause before you even get a response. You start cutting things out, the bug disappears, and you put something back to find it.
Experienced developers have been doing this for decades without any AI involved. Using a model to help you do it faster is just a quicker version of that exact same skill.
5. Talk it through instead of just handing it off
The most useful mode is a real back and forth where you explain your own theory and let the model poke holes in it.
Here’s what I think is going on: [your theory, in your own words]. Does that actually hold up, or am I missing something?
This is basically rubber duck debugging with a duck that talks back. The old trick works because explaining a bug out loud tends to surface the gap in your own reasoning before anyone else even weighs in. An AI that can respond and push back is just a more useful version of that same trick.
You have to explain your understanding first. Avoid dumping code and waiting silently.
Finding out you can’t actually put your theory into words tells you something too. You probably don’t understand the bug quite as well as you thought.
Old vs better approach
| Old approach | Better approach |
| Paste error, say “fix this” | Paste error + code + what you’ve already tried + environment |
| Take the first suggested fix | Ask for the reasoning before the fix |
| Apply one fix, hope for the best | Ask for ranked possible causes, test them one by one |
| Debug the whole file at once | Shrink it to a minimal reproduction first |
| One-shot prompt, done | Ongoing back-and-forth where you explain your thinking |
Where I’d still be careful
I have a few spots where I double-check the AI, no matter how confident it sounds.Watch out for anything security-related. This includes auth, payments, permissions, and user data. Cross check against your framework’s actual docs.
Pay attention to version specific behavior. Models mix up defaults and syntax across library versions frequently. Check against the version you are actually running. Sometimes a fix kills the symptom but you can’t explain the original cause to someone else. Dig one more level before you ship it.
Timing, concurrency, and external systems are genuinely hard to diagnose from a snippet alone. The real cause is often sitting in the environment.
Treat it the way you treat a sharp colleague who gets occasionally overconfident. The model is useful and right most of the time. It is always worth double checking before it goes anywhere near production.
AI speeds up the version of debugging you are already decent at. It does almost nothing when you are just hoping something sticks.
Every one of these 5 habits points the exact same direction. Treat the model like a capable collaborator who only knows what you explicitly explain.
Resist the one-liner next time you get stuck. That extra 30 seconds spent giving real context pays off. It saves you the 10 minutes you would otherwise spend debugging a bad fix.
