ChatGPT for Debugging: Reproduce, Isolate, and Verify

Use ChatGPT for debugging by giving it an exact failure, a small example that reproduces it, and a way to check competing explanations. Apply a focused fix only after the evidence supports it, then rerun the failing case. fenbs keeps the bug context, verified result, and lesson available when another assistant picks up the work.

What should you do before asking for a fix?

1. Write the expected behavior and the actual behavior. Include the exact error text, not a paraphrase such as the request failed.
2. Reproduce the failure in a safe development environment. Record the input, steps, language, relevant library versions, and configuration that matter.
3. Reduce the example while keeping the failure. Remove unrelated code, credentials, customer records, and other sensitive information.
4. Ask ChatGPT for competing explanations and a check that distinguishes them. Test one explanation before changing several parts of the program.
5. After a focused patch, rerun the original example and appropriate nearby checks. Record what passed and what remains untested.

This preparation is part of debugging, even when it reveals the problem before you send the prompt. You are turning an impression into a repeatable observation. For the wider development workflow, see ChatGPT for code work.

What makes a reproduction small enough to help?

A minimal reproduction is the smallest practical example that still fails in the same way. It might be one function and a sample input, or a short sequence involving a browser and a test server. Small means enough to preserve the cause, not so little that ChatGPT must invent the missing system.

Say a settings screen displays Saved, but a refresh restores the old value. Supply the save handler, the request and response shape, and the read path used after refresh. A screenshot of the success message alone cannot show whether the write failed, the read is stale, or the wrong record was updated.

OpenAI’s coding prompt examples↗ (opens in a new tab) likewise emphasize reproduction steps, relevant files, constraints, and checking the result. Save the recipe with the bug in fenbs project context, so the next session can repeat it instead of guessing what you observed.

How do you ask for explanations you can test?

Ask for a short list of plausible causes, the evidence for each, and the smallest observation that could rule it out. Separate observed facts from guesses. Request missing information before a patch when the available evidence cannot distinguish the causes.

Expected: saving the changed setting survives a refresh.
Actual: the success message appears, but the old value returns.
Environment and reproduction steps: [supply details].
Relevant code and sanitized response: [supply details].

List up to three possible causes. For each, show:
- Evidence in the supplied material.
- What is still unknown.
- One small check that distinguishes it from the other causes.
Do not rewrite the feature. Start with the check most likely to clarify the failure.

If ChatGPT says the cache is responsible, ask which value would differ before and after bypassing it. If it suggests a race between two requests, ask which event order would demonstrate that race. A useful explanation predicts something you can observe.

How do you check a confident diagnosis?

Check language and library behavior in the official documentation for the version you use. An explanation can sound familiar while relying on a function that does not exist or an error condition that does not apply. Ask ChatGPT to point to the exact statement it relies on, then open that source yourself.

For example, if the failing line uses JavaScript’s JSON parser, inspect the input before blaming the network or changing the parser. MDN documents JSON.parse↗ (opens in a new tab), including its error behavior for invalid JSON. A parser error does not, by itself, explain why the program received invalid data.

Keep the original failure visible while testing. Do not replace an exception with an empty result merely because the screen stops crashing. That may conceal the same defect and give later code misleading information. A fix needs to address the cause or implement an explicitly agreed recovery behavior.

What should count as a verified fix?

First, show that the original reproduction now behaves as expected. Then check a nearby valid case, a relevant failure case, and the boundary most likely to be affected. For the settings example, test a successful save, a refused save, and a refresh after each.

Inspect the change as well as the test output. Did the patch alter the API, bypass validation, or remove an error check? A passing result proves only what that check actually exercised. Write down any environment you could not test and any manual review that remains.

When practical, keep a regression check: a test that fails for the original defect and passes after the correction. Confirm that it tests the reported behavior rather than merely repeating the new implementation. If the defect depends on a particular environment, preserve the manual reproduction too, with the conditions needed to run it. Another passing unit test may not exercise that environment.

The code review workflow covers reviewing a change in more depth; generating code with ChatGPT covers new behavior. Keep this debugging session focused on explaining and correcting the reproduced defect.

What should you save when the bug is still unresolved?

Save the reproduction, the last known state, the checks you ran, and what each result ruled out. Include the next discriminating check and any temporary changes still present. A precise unfinished record is more useful than a list of possible fixes with no outcomes.

A second assistant may help challenge an assumption; Claude for debugging describes that workflow. For tool choices, see Claude versus ChatGPT for coding and ChatGPT Codex. Whichever tool continues, give it the evidence rather than only the previous assistant’s conclusion.

How to do this with fenbs

1. Create a free account and add the software project. One person can start free, with no credit card.
2. Create a bug task containing the observed failure, expected behavior, sanitized reproduction, and relevant file references.
3. Connect a supported assistant and ask it to read the project context before investigating. Record each useful check and its actual result.
4. Save the testing status and notes on the task. Add a lesson only when the investigation supports a concrete cause or a useful prevention step.
5. Save Where we left off before stopping, including the next check, unresolved assumptions, and any work waiting on a person.

fenbs keeps the investigation record; it does not replace a debugger, test runner, or code repository. For a short question about an isolated expression, a chat and a local test may be enough. Explore other practical workflows in the AI at work hub.