The worst debugging prompt is four words long: “fix this error” plus a stack trace yanked out of context like a fish out of a river.
Models will still answer. Confidently. They will invent a cause that sounds plausible for a generic React app that is not your React app. You will apply it. You will make a new error. You will blame the model. Cute cycle. Expensive cycle.
I debug with AI every day. The upgrade was not a smarter model. It was attaching more context and pasting less noise.
What “attach more” means
Give the agent the same things you would give a sharp teammate on Slack.
- the exact error text
- the file where you think it starts (not the whole monorepo unzipped into the void)
- the command you ran
- what you expected
- what you observed
- the last change you made before it broke
- relevant env differences (local vs staging) without dumping secrets
Screenshots help for UI bugs. Network response payloads help for API bugs. A minimal reproduction helps more than your feelings about the framework.
If the truth lives in a 40-line function, attach the function. Do not attach your life story.
Paste less of the wrong stuff
Huge logs feel thorough. They often hide the line that matters under a blanket of repeated warnings.
I trim. you keep the first failure, a little surrounding context, and anything that shows input shape. I remove tokens, cookies, and customer data before it ever hits the chat.
Also remove your theory if it is weak. You can share a hypothesis. Label it as a hypothesis. Otherwise the model will politely agree with your wrong idea and dig a deeper hole.
A template that works
When you are in a hurry Still force this structure:
- Goal: what should happen
- Actual: what happens
- Repro steps: shortest path
- Suspect files: paths
- Error: trimmed
- Constraints: don’t refactor the world, small diff, keep public API stable
- Ask: propose cause, then a minimal patch
That last line matters. If you only ask for a fix, you get a fix-shaped guess. If you ask for cause then patch, you get something you can argue with.
Let it read the repo when it can
IDE agents and coding agents that can open files beat copy-paste chat for debugging. They see imports, types, and callers.
My habit: point at the failing test or the route handler, ask for a diagnosis, require a small diff, run the test. If it wants to rewrite the auth system because a null check was missing, you say no like a parent at bedtime.
Use the model for experiments, not superstition
Good asks:
- “What are three plausible causes ranked by likelihood given this stack?”
- “Write a failing test that locks this bug.”
- “Add logging around this boundary so we can see the payload shape.”
Bad asks:
- “Why is JavaScript bad?”
- “Rewrite everything in a new framework so we never have bugs.”
One of those ships. The other is therapy.
Close the loop
When the fix works, tell the agent what worked. When it fails, paste the new error and say what you tried. Debugging is iterative for humans. It is iterative for agents too.
Also keep a short note in the PR: root cause in one sentence. Future-you will not remember the chat thread. Future-you will remember the note.
If the same class of bug shows up twice, turn the fix into a regression test before you move on. Agents are great at writing that test once you point at the repro. That is how you stop paying the same tuition every sprint.
Bottom line
AI debugging fails when you treat the model like a search box for stack traces. It works when you treat it like a pair who needs the repro, the files, and the definition of done.
Paste less junk. Attach more truth. Demand small diffs. Run the test.
That is not glamorous. It is how you stop gambling and start fixing.
