How to Debug Code With ChatGPT Without Guessing

Start with the kind of failure you actually have

A traceback, an incorrect answer, and a test that fails only on one machine require different evidence. Pick the matching row before writing a prompt. The worked Python examples below cover the first two rows; the same evidence and verification rules apply when your project uses another language or test runner.

Make a small, safe reproduction

Run the failing command before consulting ChatGPT and save its output. Note the language version, the exact input, and the expected result. For an exception, keep the traceback through the final error line: its frames show where execution passed, while the final line names the exception and value. Python's error and traceback guide explains that structure. For a wrong answer, write the expected value before looking at a proposed patch; otherwise it is easy to accept a plausible result that merely matches the changed code.

Reduce the example by removing unrelated setup, but retain any condition needed to trigger the failure. Do not paste a whole repository when a function and one failing call will do. Replace credentials, customer records, internal addresses, and proprietary rules before sending material to a service your organization has not approved. If a harmless reproduction would hide the bug, debug in an approved internal environment and share only a description of the failure.

Case 1: a decimal input raises an exception

Our recorded ChatGPT session used a synthetic discount function. Its contract was specific: accept percentage strings from 0 through 100, including decimals; reject invalid or non-finite values; return integer cents using half-up rounding. At a price of 1,000 cents, a 12.5% discount should leave 875 cents. The original function instead converted the form value to an integer:

from decimal import Decimal, ROUND_HALF_UP

def apply_discount(price_cents: int, percent: str) -> int:
    discount = int(percent)
    remaining = Decimal(price_cents) * (Decimal(100) - Decimal(discount)) / Decimal(100)
    return int(remaining.quantize(Decimal("1"), rounding=ROUND_HALF_UP))

The failing test calls apply_discount(1000, "12.5") and expects 875. Download and extract the practice kit, open its folder, then run python3 -m unittest -v test_discount.py. Under Python 3.13.2, the decimal case produced this traceback, shown here with local directory paths shortened; the expanded practice suite also exposed two missing range checks:

Traceback (most recent call last):
  File "test_discount.py", line 8, in test_decimal_percentage_from_form
    self.assertEqual(apply_discount(1000, "12.5"), 875)
  File "discount.py", line 6, in apply_discount
    discount = int(percent)
ValueError: invalid literal for int() with base 10: '12.5'

The error happens before the later Decimal calculation. Changing the rounding formula would not address this exception. A useful debugging prompt asks for an explanation of the failing operation before asking for code:

Debug this isolated Python failure. Do not rewrite unrelated code.

Contract: percent is a string representing a decimal from 0 through 100,
inclusive. Reject invalid and non-finite values. Return integer cents
using half-up rounding.
Input: apply_discount(1000, "12.5")
Expected: 875
Observed: ValueError at discount = int(percent)

[Paste the complete function, failing test, and full local traceback.]

First explain which operation failed and why this input triggers it.
Then propose the smallest corrected function. List the cases that should
fail before the change and pass afterward. Mark any behavior the contract
does not define as an open question. Do not claim you ran the code.

In the August 19 recorded run, ChatGPT identified int("12.5") as the cause and proposed parsing with Decimal, rejecting non-finite and out-of-range inputs, and retaining half-up cent rounding. The screenshot shows the diagnosis; the retained conversation text records the full proposal. The corrected function is:

from decimal import Decimal, InvalidOperation, ROUND_HALF_UP

def apply_discount(price_cents: int, percent: str) -> int:
    try:
        discount = Decimal(percent)
    except (InvalidOperation, ValueError):
        raise ValueError("percent must be numeric")

    if not discount.is_finite() or discount < 0 or discount > 100:
        raise ValueError("percent must be between 0 and 100")

    remaining = Decimal(price_cents) * (Decimal(100) - discount) / Decimal(100)
    return int(remaining.quantize(Decimal("1"), rounding=ROUND_HALF_UP))

Decimal can represent NaN and Infinity, so numeric parsing alone does not enforce the contract. The finite and range checks do that work. The final quantize keeps the specified cent policy; Python's decimal documentation defines is_finite() and ROUND_HALF_UP. The code still assumes price_cents is a valid integer and leaves input syntax such as surrounding spaces or scientific notation to the product owner.

Verify the cause and the repair, not just a green result

Run python3 -m unittest -v test_discount_fixed.py from the practice kit. All four test methods passed locally on September 26 under Python 3.13.2. They cover "12.5", both allowed endpoints, 0.5-cent and 1.5-cent results, malformed strings, non-finite values, and values on both sides of the allowed range. Python's unittest runner reports each method and exits unsuccessfully when a test fails.

There is a trap in the original tests. An assertion that "-0.1" or "100.1" raises ValueError passes even without a range check, because int() rejects those decimal strings first. Testing "-1" and "101" reveals that the original function accepts out-of-range integers. When checking a fix, inspect where a failure came from and keep at least one case that distinguishes the intended validation from an unrelated exception.

Case 2: the exception disappears, but the answer is wrong

A passing original example is not enough. In a separate local exercise, we deliberately changed only the corrected function's final line to return round(remaining). That candidate returns 875 for the 1,000-cent example, so it appears to solve the reported exception. It returns 0 for apply_discount(1, "50"), where the contract requires 1. Python rounds a decimal half to the nearest even integer by default; the contract calls for half-up rounding.

The practice kit makes this silent error visible. python3 -m unittest -v test_rounding_bug.py reports AssertionError: 0 != 1 for the half-cent case, while the original 875-cent case passes. python3 -m unittest -v test_rounding_fixed.py passes all three checks with the half-up implementation. This is a deliberately planted candidate, not an output from the recorded ChatGPT conversation.

For a wrong result with no traceback, give ChatGPT the actual and expected values, the rule behind the expectation, and the function you ran. Ask it to trace the intermediate value before suggesting a change:

Input: apply_discount(1, "50")
Actual: 0
Expected: 1, because the written rule is half-up cent rounding.
The original 1,000-cent / 12.5% case must still return 875.

[Paste the candidate function and both tests.]

Trace the intermediate value and identify the first operation that
violates the rule. Propose the smallest change, then name the checks
I should run. Do not say the fix passes until I run it.

The expected value and written rule give ChatGPT something independent of its own proposed code to reason against. If no rule exists yet, settle that question with the product owner before asking for a patch.

When the first diagnosis does not fit

Use the next observed failure to narrow the investigation. Asking for a new rewrite without showing what failed can hide the original bug under more changes.

Know when a fix is ready for review

Keep the original reproduction, the proposed diff, and the test output together. The original version should fail for the reason you identified; the candidate should pass that case and the relevant unchanged behavior. Review any new dependency, data exposure, or exception handling in the diff. If a behavior such as negative prices, whitespace, scientific notation, or very large inputs was never specified, record it as a decision rather than silently assigning it to ChatGPT.

After the repair, add durable coverage with the unit-test workflow. If the change affects more than the isolated function, use the code-review workflow and run the repository's relevant integration checks before release.