Debug with ChatGPT: bring the failure, then test the explanation

Paste the exact error, the smallest code that still fails, and what you expected to happen. Ask ChatGPT for a diagnosis you can test before accepting a rewrite. A useful explanation predicts which input fails and why; you can then check that prediction in the environment where the problem occurs.

Include the language and version, how you run the program, and relevant package versions. A browser console, a Python terminal and a server log can describe different parts of one application. State where the failure appears so the investigation starts in the right place.

Reduce the failure without removing its cause

The following original Python practice example reads a setting represented as text:

config = {"retries": "3"}
attempts = config["retries"] + 1
print(attempts)

Adding a string to an integer raises a TypeError. The important clue is the runtime type of config["retries"], not the name “retries.” A real report should include its actual traceback, rather than substituting an error remembered from a similar program. Python's errors and exceptions tutorial explains how the traceback identifies the execution context and exception.

For this exercise, the intended rule is: retries is a required nonnegative integer written as text, and total attempts is retries plus the initial attempt. Therefore "3" should produce 4, and "0" should produce 1. Missing, negative and malformed values should produce a clear configuration error, rather than silently changing the setting.

Those rules distinguish a repair from a patch that only hides the exception. Converting everything to a string would make "3" + "1" produce "31". That avoids this type mismatch while violating the required result.

Separate a hypothesis from evidence

Ask ChatGPT what to inspect next. For the small example, type(config["retries"]).__name__ would reveal str. For your application, inspect only the relevant permitted value and type; do not dump credentials or an entire private configuration into the chat.

If the real value is already an integer, the example's explanation does not fit. Return the actual failing expression and traceback. A diagnosis should change when the evidence changes.

OpenAI's prompting documentation supports giving context, constraints and focused follow-ups. A debugging follow-up is most useful when it reports an observation: “the value is the string 0 and the result should be one attempt,” rather than “try harder.”

Help diagnose this failure before rewriting the program.
Language/runtime and version: [ENTER]
How I run it and where the failure appears: [ENTER]
Exact error and relevant traceback/log: [PASTE]
Smallest permitted code and input that reproduce it: [PASTE]
Expected behavior, actual behavior and relevant rules: [ENTER]
Recent changes and checks already tried: [ENTER]

Identify the most plausible cause and the evidence supporting it.
Separate confirmed observations from hypotheses. Propose the smallest
next check that could disprove your explanation. Ask for missing
context. Do not invent a successful execution or change unrelated code.
After the diagnosis is supported, suggest a focused fix and explain
what it changes. Include checks for the original trigger and nearby
valid and invalid cases. Do not suppress the error by inventing defaults.

Repair the input boundary deliberately

For the stated practice contract, parse the setting once and reject invalid input before using it:

raw = config.get("retries")
if not isinstance(raw, str):
    raise ValueError("retries must be supplied as integer text")
try:
    retries = int(raw)
except ValueError:
    raise ValueError("retries must be integer text") from None
if retries < 0:
    raise ValueError("retries cannot be negative")
attempts = retries + 1

Here int() defines the accepted integer-text syntax, including surrounding whitespace and a sign. If your configuration format requires digits only, add that explicit validation instead of assuming this parser enforces it. A setting already stored as a number would need a different input contract.

The authored expected checks are "3" → 4, "0" → 1, "-1" → configuration error, "many" → configuration error, and missing setting → configuration error. These expectations follow from the exercise's rules; they are not a claim that ChatGPT ran your application.

Close the investigation with the original trigger

Run the reproduction and the affected application path after making the fix. Record the actual input, output, runtime and tested revision. A fix that passes a new toy case but still fails the original trigger has not resolved the report.

The ChatGPT code-review guide helps inspect a proposed change, while the unit-test guide explains how to preserve the contract in assertions. Keep the smallest useful reproduction with the accepted fix so the next developer can see both what failed and what now prevents it.

Keep reading