Claude for Debugging: Reproduce, Investigate, and Test

Use Claude for debugging by giving it a repeatable failure, asking it to investigate before editing, and requiring a test that demonstrates the fix. Treat each explanation as a possibility until the evidence supports it. fenbs can keep the bug’s investigation, remaining checks, and lessons outside the conversation, so the next session starts with what you actually know.

How do you make the bug repeatable?

Start with one behavior someone can observe. “Checkout is broken” gives Claude room to guess; “submitting an empty ZIP code shows a success message” gives it a specific mismatch between expected and actual behavior. State where that expectation comes from, such as an approved requirement or an existing test.

1. Write the shortest sequence that triggers the failure. Include the starting screen or command and the input that matters.
2. Record the expected result and the actual result separately. Keep the exact error text, with passwords, personal data, and access credentials removed.
3. Record the relevant environment: software versions, operating system, project revision, and whether the failure happens locally or elsewhere.
4. Repeat the sequence before asking for changes. If it fails only sometimes, record when it fails and when it succeeds.

When the full app is hard to run, prepare a minimal reproduction: the smallest example that still fails. Preserve the conditions that matter. Removing a database or changing the time zone may remove the bug along with the complexity.

What should you give Claude before it investigates?

Provide the reproduction, relevant code, nearby tests, and the rules for changing the repository. Anthropic’s Claude Code best practices↗ (opens in a new tab) recommend specific context and a check Claude can run. If you are new to the tool, our Claude Code introduction explains its role in a project.

If your Claude session can only discuss supplied code, run the commands yourself and return the output. If you are using Claude Code with repository access, agree on the allowed files and commands. Anthropic’s permissions documentation↗ (opens in a new tab) explains the controls; a written request alone does not enforce a technical boundary.

Investigate the empty-ZIP-code checkout failure.
Expected: reject submission with a field error.
Actual: success message appears.
Read the checkout handler and its tests first.
List possible causes and the evidence for each.
Reproduce the failure before changing source code.
Propose the smallest fix and a regression test.
Do not change dependencies, publish, or use live customer data.
Report commands run, results, and checks you could not run.

How do you separate a cause from a guess?

Ask Claude to trace the failing input through the relevant code and name the next observation that would distinguish two explanations. A hypothesis is simply a possible explanation you can test. Test one meaningful difference at a time rather than accepting several edits followed by a hopeful retry.

A matching error message is a clue, not proof of the cause. Keep observations separate from interpretations, including explanations you ruled out. Saving that distinction in fenbs AI context notes helps another assistant continue without repeating the same guess.

What should change in the proposed fix?

Ask for the smallest change that addresses the demonstrated cause and preserves the intended behavior. For the checkout example, hiding the success message would be insufficient if the server still accepted invalid input. The explanation should connect the changed condition to the failing path.

Read the proposed code changes before accepting them. Check whether Claude changed unrelated files, removed useful error handling, weakened a permission check, or made a test easier to pass. If the existing test described the right behavior, rewriting its expectation to match the bug is not a fix.

Separate necessary repair from optional cleanup. A bug investigation should leave you able to explain which change corrected the behavior. Larger design changes can become separate tasks with their own review.

How do you verify that the fix actually works?

Use a regression test: a check that catches this bug if it returns. Its expected result should come from the requirement, rather than from the implementation Claude just produced. For a suitable automated test, establish that it fails on the old code and passes on the proposed fix.

1. Repeat the original reproduction with the fix in place. Confirm the expected behavior, not just the disappearance of the error.
2. Run the focused regression test and nearby tests for valid input, invalid input, and relevant permission boundaries.
3. Run the repository’s required checks. Record their actual commands and results, including checks blocked by missing dependencies or access.
4. Check the affected user flow when a unit test cannot establish the full result. Identify any environment that still needs a person to verify it.

Do not confuse “Claude says it passed” with observed output. Read the results and confirm the test exercised the failing path. If a command stopped before running tests, record that limitation; it is not a passing check.

What belongs in the debugging checkpoint?

A debugging checkpoint is a short written account of the investigation, not a backup of the code. Save it when you pause, switch assistants, or reach a verified fix. Another developer should be able to find the evidence without rereading the conversation.

• The failure and the reproduction, with the relevant project revision.
• The supported cause, discarded explanations, and evidence locations.
• The files changed and the checks that ran, failed, or remain outstanding.
• The next action and anything waiting on a person.
• A reusable lesson: what happened, what you learned, and what to do differently.

Keep the lesson specific: “Test invalid submissions directly against the server” is more useful than “validate better.” fenbs Lessons learned keeps that instruction with the project so a connected assistant can read it before similar work.

How to do this with fenbs

1. Create a free account. fenbs is free for one person, no credit card.
2. Add the project and a Bug task. Put the observed problem in its note and the investigation steps in its plan.
3. Connect Claude Code using the integration guides. The connection uses MCP, a standard way for an AI app to use an outside tool.
4. Ask the assistant to read the project context before investigating, then record test status and test notes on the task.
5. Before stopping, save progress and the next action. When the cause is verified, add the useful lesson and move the finished task to Completed.

fenbs is not the right fit if you only need a debugger or a place to run tests. Keep those tools in your development environment; fenbs holds the work record they inform.

What do you do when Claude gets stuck?

Pause after repeated speculative edits. Return to the smallest failing example and ask which observation is still missing. If the failure depends on a service you cannot access, record that gap instead of asking Claude to invent its behavior.

Use our Claude Code documentation map for tool configuration questions; Claude Code’s operating workflow and debugging with ChatGPT cover those separate topics. For more practical workflows, browse AI at work.