Debugging Generated Code

Unit ID: M06-U07 Estimated active time: 20-30 minutes

Generated code is untrusted input

An AI tool may produce useful code, outdated code, invented APIs, unsafe operations, or logic that appears plausible but fails at boundaries.

Do not run it merely because it is formatted confidently.

Review before execution

1. State what the code is supposed to do.
2. Identify imports and package-install commands.
3. Identify file, network, account, system, and deletion operations.
4. Trace inputs, outputs, and state changes.
5. Check that referenced functions and APIs exist in authoritative documentation.
6. Reduce the code to a safe, small example.
7. Use fictional or supplied data.
8. Run in an isolated course environment.
9. Add tests before accepting the result.

Watch for broad exception handling

Generated code often uses:

try:
    risky_work()
except Exception:
    return None

This can hide programming defects and destroy useful evidence. Replace it with the narrow expected exceptions and a documented result.

Watch for silent coercion

hours = int(float(raw_hours))

This accepts "8.9" and changes it to 8. That may violate the whole-number contract. Short code is not automatically correct code.

Ask the tool for evidence, then verify independently

An AI tool can suggest tests or explain a traceback, but its explanation may be wrong. Run the test, inspect official documentation, and keep human responsibility for the decision.

Practice

Review a supplied generated parser containing broad except, silent float-to-int conversion, and source mutation. List every risk before changing or running it.

Takeaway

Treat generated code as a proposal. Inspect capabilities and side effects, isolate execution, verify APIs, and require tests. You are ready to repair the deliberately broken checkpoint program.