Generated code often works. “Often” is the problem: it looks equally confident when it is right and when it is quietly wrong.
Here is a checklist you can run in a couple of minutes.
1. Can you explain every line?#
Read it and narrate what each line does. Any line you cannot explain is a line you cannot debug at 11pm when it breaks.
If there is a line you do not understand, ask about that line specifically before using the code.
2. Does it actually do what you asked?#
Assistants sometimes answer a slightly different question — a nearby, easier one. Re-read your request and check it matches. This is especially common with “and also” requirements.
3. Do the functions and methods exist?#
Generated code sometimes invents plausible-sounding methods, or uses ones removed in a newer version. If something looks unfamiliar, check the official documentation rather than assuming.
A quick tell: a method whose name is exactly what you would have wished for is worth verifying.
4. What happens with awkward input?#
Generated code usually handles the happy path and ignores everything else. Test:
- Empty input — empty string, empty list, empty file
- Zero, and negative numbers
- Missing keys or fields
- Very large input
- The wrong type entirely
print(calculate_average([])) # ZeroDivisionError?
print(calculate_average([-5, 3])) # is negative sensible here?
print(calculate_average(None)) # crash, or handled?5. Is anything unsafe?#
Watch for these specifically:
- Hard-coded credentials — API keys or passwords in the code
- SQL built with string joining — should use parameters
eval()orexec()on input — runs whatever it is giveninnerHTMLwith user text — see DOM basics- A bare
except:that swallows every error including bugs
cursor.execute(f"SELECT * FROM users WHERE name = '{name}'") # unsafe
cursor.execute("SELECT * FROM users WHERE name = ?", (name,)) # safe6. Is it more complicated than the problem?#
Generated solutions often reach for a class hierarchy, a library or a design pattern where ten lines would do. Extra machinery is extra things to maintain and understand.
Ask: “rewrite this as simply as possible using only the standard library”.
7. Does it fit the rest of your code?#
Check naming style, error handling and structure against what you already have. A file where half the code is snake_case and half is camelCase is a small mess that compounds.
The fastest way to test#
Write two or three assertions before you trust it:
assert average([2, 4]) == 3
assert average([]) == 0 # decide what empty should mean
assert average([-2, 2]) == 0
print("All checks passed")Thirty seconds of this catches most problems, and you now have a small test suite for free.
When to discard it#
- You have gone three rounds and it still does not work — you probably misdiagnosed the problem
- It uses something you have never heard of for a simple task
- It is longer than you expected for the job
- You cannot explain it and it is going into something that matters
Writing your own version, even a worse one, is often faster than debugging code you did not write.
Questions people ask#
Why does generated code sometimes use functions that do not exist?
These models predict plausible text. A method name that should exist is highly plausible, so it sometimes appears even though it does not. Verify anything unfamiliar against the documentation.
Is it fine to use generated code at work?
Check your employer’s policy first. Some restrict what may be pasted into external tools, and some require disclosure. Either way, you are responsible for code you commit.
How do I get better at reviewing?
Read other people’s code. Open-source projects, pull requests, and even the generated code you decide against all build the instinct for what “off” looks like.