How to Debug AI-Generated Code

When an AI-built feature fails, asking the model to fix everything can produce a large rewrite that hides the original problem. A better debugging process reduces uncertainty one step at a time.

Describe the expected behavior, reproduce the actual behavior, locate the mismatch, and verify the smallest justified change.

Write a reproducible case

Imagine a fictional time-tracking app. Two entries represent 15 minutes and 5 minutes, but the displayed total is 0155 rather than 20.

Record the exact input, the action, the actual result, and the expected result. Keep the environment and relevant version information.

Do not begin with an invented cause such as the database is broken. State what you observed before deciding why it happened.

Follow the data to the first mismatch

In JavaScript, adding a number to a string can produce concatenation. If the values arrive as strings, a reduction beginning at zero can build text rather than a numeric total.

Inspect the input types at the point where the calculation runs. An AI explanation about a network problem is irrelevant if the first incorrect behavior is already visible in local data.

Use the smallest example that preserves the failure. Remove unrelated styling, remote services, and records when they are not needed to reproduce it.

Define valid input before changing the code

Decide what the function accepts. For this example, allow nonnegative finite numbers and nonblank numeric strings. Reject other values.

A possible implementation is:

function totalMinutes(entries) {
  return entries.reduce((sum, entry) => {
    const raw = entry.minutes;
    const value = typeof raw === "number"
      ? raw
      : typeof raw === "string" && raw.trim() !== ""
        ? Number(raw)
        : NaN;
    if (!Number.isFinite(value) || value < 0) {
      throw new Error("Invalid minutes");
    }
    return sum + value;
  }, 0);
}

The function makes conversion and rejection visible. Your actual product may need different rules, such as integer-only values. Change the contract and tests together when that requirement differs.

Ask for a narrow fix

Give the assistant the reproducible example, relevant function, expected result, and input contract. Ask it to explain the cause and propose a minimal correction without rewriting unrelated files.

Inspect the diff. A change to authentication or database structure should not appear in a small local numeric correction without a clear reason.

Keep a known starting revision so you can compare and undo changes during development.

Verify normal, boundary, and failure cases

Check two valid numeric entries, equivalent numeric strings, an empty entry list, and zero minutes. Then check a blank string, an invalid word, a negative value, and a nonfinite value.

The original reproduction should now return 20. Invalid cases should follow the agreed error behavior rather than disappearing into a total of zero.