Claude Code's debugging loop isn't guessing from a pasted test — it's running the real suite, reading the real error, and confirming the real fix.
1A Real Failure Message Narrows the Diagnosis
'Expected: 5, Received: NaN' is more than a pass/fail signal — NaN specifically indicates arithmetic on a non-numeric value, pointing straight at a null or undefined being added rather than defaulted. Claude Code uses that real, specific signal to locate the actual cause instead of guessing at the function's behavior from the test alone.
2A Fix Isn't Done Until It's Re-Verified
Applying an edit that looks correct isn't the same as confirming it. The loop closes only when the same command that revealed the failure is re-run and shows both the specific fix working and no other previously-passing test broken as a side effect.
3Step-by-Step Breakdown
Back to the Failing Test, for Real This Time. Module 1 watched a chat model guess at sumTaskHours from a pasted test. Now you'll actually run the fix in Claude Code and watch the full debugging loop: run the suite, read the real failure, read the real implementation, fix it, and confirm with the suite again.
The Real Failure Message Is the Real Clue. NaN, not a wrong number, is the tell: somewhere a null hours value is being added directly instead of treated as zero. Claude Code reads src/tasks.js, finds the line doing the raw addition, and proposes the actual fix — not a guess based on the test alone, but a diagnosis based on the real failure and the real code.
Why is 'Received: NaN' more useful to Claude Code than just knowing 'the test fails'?
- →NaN specifically points to a null or undefined value being used in arithmetic, narrowing the diagnosis instead of leaving the actual cause to be guessed.
- →It's not actually more useful — any failure message is equally informative.
Verify the Fix, Don't Just Trust It. A proposed fix isn't done until it's actually re-run. Write the verification step you'd want Claude Code to take after applying the sumTaskHours fix, and explain what you'd check in the result.
One Bug Fixed, With Proof. The suite goes green, and you have proof — not just a plausible-looking diff. Next: the export feature, a multi-file change, and how to review a refactor-scale diff without approving something you didn't actually check.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
N/A — this workflow runs in the terminal.
N/A — this workflow runs in the terminal.
N/A — this workflow runs in the terminal.
N/A — this workflow runs in the terminal.
Accessibility (A11y)
1Read the Full Failure Output, Not Just Pass/Fail
Terminal test output carries the specific expected/received values and stack trace as plain text — reading it in full (rather than only the top-line pass/fail) surfaces the real diagnostic signal, and works the same with a screen reader as visually.
Expected: 5
Received: NaNSEO Implications
- 1
Target 'debugging with Claude Code' and 'AI agent fixing a failing test example' separately
Developers search for the general workflow and for a concrete worked example as different intents while evaluating the tool.
Best Practices
Always Re-Run the Exact Command That Revealed the Bug
The command that surfaced the original failure is the most direct proof a fix worked — re-running it (not just visually reviewing the diff) is the verification step that turns a plausible fix into a checked one.
Frequent Bugs
Accepting a proposed code change as 'the fix' without re-running the command that originally revealed the failure.
Always re-run the exact failing test or command after a fix is applied, and check both that the target case now passes and that nothing else regressed.
Real-World Examples
NaN as a Diagnostic Clue
A generic bug report of 'totals are wrong' would have left Claude Code guessing between several possible causes. The actual test failure output — Received: NaN — pointed specifically at unguarded arithmetic on a possibly-null field, letting it fix the real cause on the first attempt.
// Generic report: "totals are wrong somewhere"
// Real failure: "Expected: 5, Received: NaN" -- points at null-unsafe arithmetic