A useful debugging conversation starts with evidence: the code you ran, the input, the actual result and what should have happened. Asking an assistant to rewrite everything can hide the original problem and introduce new ones. Work through one failure at a time, using the small Python example below or an equally small example from your own project.
Reproduce the failure in a small example, include the exact error and state the expected behavior. Ask for a likely cause and the smallest justified change. Run the same failing case after the edit, then test an ordinary case and an edge case. Keep only changes whose behavior you can verify.
Go straight to the stepsBefore you begin
Remove API keys, passwords, tokens, private customer data and unnecessary logs from anything you paste. Use a local copy or development environment. Read proposed commands before executing them, especially commands that delete files, install packages or change a database. A chat response is not evidence that code has been run.
What you’ll need
- A copy or branch of your code
- The exact input and error or wrong output
- Your language and relevant library versions
- A clear expected result
- A way to run a small local test
Let’s do this
Step by step
- 01
Write down the expected behavior
For the practice function, the average of [2, 4, 6] should be 4. Decide what an empty list should mean before asking for a fix. In this guide, an empty list is invalid and must raise ValueError with the message ‘at least one value is required’. Returning zero would hide the distinction between no values and values whose average is zero.
- 02
Capture one reproducible failure
The starting function is def average(values): return sum(values) / len(values). It works on the three-number example, but average([]) raises ZeroDivisionError. Include that exact error, the function and the input in your prompt. For a larger program, preserve the relevant traceback and enough surrounding code to reproduce the same failure.
- 03
Ask for a diagnosis before a rewrite
Request the smallest explanation consistent with the evidence and a way to test it. Here, the empty list has length zero, so the function divides by zero. No library upgrade or project restructuring is needed to explain this example. If several causes remain possible in your own code, run one distinguishing check before changing it.
- 04
Review the proposed change
For this stated contract, add a check before division: if not values: raise ValueError('at least one value is required'). Keep the original return statement after the check. This is a guard for an empty list. It does not validate every possible input type, and the guide's example assumes a list of numbers.
- 05
Run the failing case and the ordinary cases
Confirm that [] now raises the intended ValueError and message. Then check [2, 4, 6] returns 4, [0] returns 0, and [-2, 2] returns 0. Record what actually happened. If a check fails, send the observed output back to the assistant rather than assuming its proposed test result is a real execution result.
- 06
Review the final difference and keep the lesson
Look at every changed line and remove unrelated edits. In a real project, run the relevant existing tests as well as your new regression case. Write a brief note explaining the cause and the chosen behavior. If you cannot explain the fix yet, ask for a walkthrough using your specific input before applying it to important work.
Put it into practice
Prompts you can copy and try
Replace bracketed placeholders with your own details. The examples are starting points; check the replies against your actual task.
Diagnose a small reproducible bug
This complete Python example needs no third-party packages.
Help me debug this Python 3 function. Explain the cause and propose the smallest change. Do not rewrite unrelated code.
def average(values):
return sum(values) / len(values)
Input: average([])
Actual error: ZeroDivisionError
Expected behavior: an empty list should raise ValueError with the message 'at least one value is required'. A non-empty list of numbers should still return its arithmetic mean.
Show the corrected function and tests for [], [2, 4, 6], [0] and [-2, 2]. Clearly distinguish expected test results from tests you actually ran.Then try this follow-up
Explain why returning zero for [] would violate the behavior I requested, even though it would stop the division error.
Prepare a useful debugging question for your own code
Replace each field and include only the material needed to reproduce the failure.
Investigate this bug one change at a time. Language/runtime: [version] Relevant library versions: [versions] Smallest relevant code: [paste] Input or steps to reproduce: [details] Actual error or output: [exact text] Expected behavior: [specific result] Recent relevant change: [change or unknown] First summarize the mismatch. Give the best-supported hypothesis and one check that could confirm or reject it. Ask for missing information instead of guessing APIs. Do not suggest deleting data or upgrading dependencies without explaining why that is necessary.
Then try this follow-up
I ran your proposed check and got [actual result]. Update the diagnosis using that evidence and propose one next step.
Ask for a focused patch review
Paste the old and new code after saving your own working copy.
Review this proposed fix against the requested behavior. Identify changes that are necessary for the bug, unrelated changes, and any behavior that still needs a test. Do not assume that a test passed unless I provide its result. REQUESTED BEHAVIOR: [paste] BEFORE: [paste] AFTER: [paste] Explain your review in plain language and point to the relevant lines.
Then try this follow-up
Remove the unrelated changes from your recommendation. Keep the smallest patch that addresses the stated failure.
Design tests from the requirement
Describe the intended behavior before asking for tests, so the tests do not just repeat the proposed code.
Suggest a small set of tests for this requirement: [describe]. Include an ordinary input, the original failing input and one meaningful boundary case. For each, state the expected result and why the requirement implies it. If an expected result is ambiguous, ask me to decide it. Then show how to run the checks using the existing tools in [project or language]. Do not add a testing framework unless it is needed.
Then try this follow-up
Here are the actual test results: [paste]. Explain what they establish and what important behavior they still do not cover.
The complete corrected practice function
Use the copyable function below in a scratch file. The guard makes the empty-input decision explicit before the calculation runs. It is intentionally small: this exercise assumes a list of numbers and does not attempt to handle arbitrary objects, numeric strings or every numerical precision requirement.
Python's documentation distinguishes syntax errors from exceptions that occur during execution. The traceback and final exception line help you locate and describe a failure. Keep that distinction when asking for help: code that cannot be parsed is a different problem from code that runs and returns the wrong number.
def average(values):
if not values:
raise ValueError('at least one value is required')
return sum(values) / len(values)
assert average([2, 4, 6]) == 4
assert average([0]) == 0
assert average([-2, 2]) == 0
try:
average([])
except ValueError as error:
assert str(error) == 'at least one value is required'
else:
raise AssertionError('Expected ValueError for an empty list')
print('All four checks passed.')When each suggested fix creates another problem
Return to the last understood version and reduce the example further. Save the original input and error, then compare one proposed change at a time. If the assistant keeps inventing function names, provide the relevant official documentation for your installed version and require the recommendation to use it. Do not keep stacking patches you cannot explain.
For a bug that touches stored data, authentication or payments, use the project's established review and test process. The small local example here establishes a debugging habit, not a deployment procedure. The useful question is what the observed test results prove about your requirement, not how confident the assistant sounds.
Expected results for the corrected function
| Input | Expected outcome | What it checks |
|---|---|---|
| [] | ValueError: at least one value is required | The explicit empty-input contract |
| [2, 4, 6] | 4 | An ordinary list |
| [0] | 0 | A valid zero is preserved |
| [-2, 2] | 0 | Positive and negative values |
A quick final check
- The failure can be reproduced with the supplied input.
- Expected behavior is explicit, including the edge case.
- The patch changes only what is justified.
- Actual test results are recorded separately from predictions.
- No secrets or unrelated private data were shared.
Common questions & sticking points
What should I include when asking ChatGPT to debug code?
Include the language and relevant versions, a small runnable example, the exact input, the error or actual output, and the result you expected. Mention a recent relevant change if you know one. Remove secrets and private records. Ask for one diagnostic check before accepting a broad rewrite.
Can I trust code that an AI assistant says it tested?
Look for actual execution output and confirm what environment and cases were used. A predicted result or a written test is not a completed test run. Run the original failing case and relevant regression checks in your own environment before relying on the fix, even if the assistant reports success elsewhere.
Should I paste my whole project into an AI chat?
Start with the smallest example that reproduces the failure and the relevant versions or configuration. Too much unrelated material can make the problem harder to isolate, and it may expose information unnecessarily. Expand the context only when a specific missing function, setting or dependency matters to the diagnosis.
Why does fixing a coding error with AI sometimes create a new error?
The proposed change may rely on a wrong assumption, a different library version or an incomplete description of expected behavior. Keep a working copy, compare the changes and run tests after each meaningful edit. If the problem moves around, return to a minimal example and gather evidence before trying another rewrite.
Sources & further reading Optional
References used to check this guide. Follow your product’s own safety instructions where its design differs.
- Python documentation: Errors, exceptions and tracebacks
- OpenAI: Code generation and coding assistance