Debugging with AI
Turn a bug into a tight debugging prompt: the exact error, the code that threw, the input, and what you already tried.
TL;DR
- Give the full error and stack trace, the code that threw, and the input that triggered it.
- Ask for the root cause first, then the fix, so you understand the bug rather than just patching it.
- Say what you already tried so the model does not repeat dead ends.
Package The Bug
Full ErrorPaste the complete message and stack trace verbatim.
TypeError: Cannot read properties of
undefined (reading 'map') at Cart.tsx:28The CodeInclude the function that threw and the types it touches.
// paste Cart.tsx lines 20-35
// + the CartItem typeThe TriggerShow the input or state that caused it.
Happens when the cart is empty
(items is undefined).Ask The Right Way
Cause FirstRequest the explanation before the fix so you can vet the diagnosis.
"Explain why this throws, then
propose a fix."Multiple HypothesesAsk for a few likely causes ranked, not one confident guess.
"List the 2-3 most likely causes,
most likely first."State What You TriedRule out dead ends so the model does not suggest them again.
"I already checked the API response;
it returns items correctly."Validate The Fix
Cause, Not SymptomConfirm the fix addresses why it broke, not just that the error stopped.
"Does this fix the cause or just
silence the error?"Add A TestAsk for a test that fails on the old code and passes on the new.
"Write a test that reproduces the
empty-cart case."Check Side EffectsMake sure the fix did not change unrelated behavior.
"What else could this change affect?"When Stuck
Add LoggingHave the model insert targeted logs to narrow where state goes wrong.
"Add console.logs to show `items`
at each step."Shrink The ReproReduce to the smallest snippet that still fails to isolate the cause.
"Help me make a 10-line repro that
still throws."Rubber-Duck ItAsk the model to restate the flow; the mismatch often reveals the bug.
"Walk through what happens on an
empty cart, line by line."Tips
- Paste the complete stack trace, not a paraphrase; the frame and line often point straight to the cause.
- Ask 'what are the top 2-3 likely causes?' before accepting a single confident-sounding answer.
Warnings
- Models will confidently 'fix' code by changing behavior; confirm the fix addresses the cause, not the symptom.
- A fix that makes the error disappear is not always correct; it may just hide the problem.
In Practice
The error, the code, the trigger, and what you already ruled out, assembled into one prompt that asks for the cause before the fix. This is the difference between a real diagnosis and a lucky guess.
- The full stack trace points the model at the exact failing line.
- The code and type show what the line actually operates on.
- Naming the trigger (empty cart) hands the model the reproduction.
- Asking for cause-then-fix plus a test ties the solution to real behavior.
Error:
TypeError: Cannot read properties of undefined
(reading 'map')
at CartSummary (Cart.tsx:28:19)
Code (Cart.tsx 24-30):
function CartSummary({ cart }: { cart: Cart }) {
return <ul>{cart.items.map(i => <Row key={i.sku} {...i}/>)}</ul>;
}
type Cart = { items?: CartItem[] };
Trigger: a brand-new session where the cart has
not loaded yet, so `items` is undefined.
Already ruled out: the API response (returns items fine
once loaded).
Explain why this throws, then propose a fix that handles
the cause. Add a test that fails on the current code and
passes after the fix.FAQ
The full error message and stack trace, the function or lines that threw, the relevant types, and the input that triggered the failure. If you can, a minimal reproduction. That package lets the model reason about the real cause instead of guessing from a description.
Ask for the cause first. 'Explain why this throws, then propose a fix' gives you understanding and a chance to catch a wrong diagnosis before any code changes. A fix without a cause is a patch you cannot trust.
Tell it exactly what happened, the new error or behavior, and what you have already tried. Ask it to list two or three alternative hypotheses rather than doubling down. Keep the thread focused on the current known-good state.
Insist the fix address the root cause and ask what would prove it is fixed. For example, 'add a test that fails on the old code and passes on the new'. A test ties the fix to the actual behavior, not just the vanished error.