Short answer
Evaluating AI generated code means checking a script, formula or automation an AI wrote before you run it on real data: can you explain each line, what files does it read and change, do its imports really exist, does it handle awkward inputs, and has someone else reviewed it. A 20-minute routine catches most problems, including invented package names that attackers now register on purpose.
- Never run AI-written code on original files; write output to a new file.
- If you cannot explain a line, ask until you can or remove it.
- Check every import exists; invented package names are a known attack route.
- Write your own edge cases rather than trusting the AI’s tests alone.
- A second review, by a colleague or a fresh model, finds different problems.
Goal: Review an AI-written script with a repeatable seven-check routine, then decide whether to run it, fix it or throw it away. Who it is for: Operations and finance staff who now write small scripts, formulas and automations with AI, and developers adopting AI coding assistants. Time: 40 minutes, plus an AI assistant and a spreadsheet or Python environment for testing.
Code is the easiest AI output to trust by accident. Prose that is wrong usually reads a little wrong; code that is wrong usually runs, prints something plausible and quietly mangles row 4,000. It can also do things prose never can: overwrite the file you gave it, install a package you have never heard of, or send data somewhere. The routine below takes about 20 minutes once practised, and it is the same whether the code came from ChatGPT, Claude, Copilot, Gemini or a coding tool.
The seven-check review routine
Before running AI-written code, answer seven questions. Any red flag means fix it or stop.
| Check | Question to answer | Red flag |
|---|---|---|
| Explain | Can you say what each line does? | “It works, I think” |
| Files | What does it read, write or delete? | Writes over its input, deletes anything |
| Dependencies | Does every import really exist? | A package name you cannot find with a real history |
| Secrets | Are keys or passwords in the code or prompt? | Credentials pasted in plain text |
| Scope | Does it do anything you did not ask for? | Network calls, emails, extra files |
| Edge cases | What happens with blanks and odd formats? | Untested, or silently “fixed” |
| Second review | Has someone or something else checked it? | Only its author has looked |
Exercise: review a phone number clean-up script
- Make a practice file. Create a CSV with 15 made-up New Zealand phone numbers in mixed formats: mobiles (021, 022, 027), landlines (03, 04, 06, 07, 09), “+64 (0)21”, “0064”, 0800 numbers, blanks and one overseas number. Do not use real customer data.
- Ask for the code with constraints. Use the worked example prompt in ChatGPT, Claude, Copilot or Gemini. Require standard-library Python (or a spreadsheet formula), a new output file, a list of assumptions and tests.
- Explain it back. Ask for a line-by-line explanation. Anything you still cannot follow, ask for a simpler version.
- Check imports and files. Confirm each import is standard library or a package you have verified. Confirm it never writes to the input file.
- Test your own edge cases. Run it on a copy against your 15 numbers, not just its own tests. Note every surprising result.
- Get a second review. Paste the code into a fresh chat, or a different assistant, with the review prompt below. Or ask a colleague who writes code.
- Decide and record. Run, fix or discard. If you keep it, save it with a note of its purpose, date and who reviewed it.
Worked example: normalising NZ phone numbers
Write a Python function that converts New Zealand phone numbers to
+64 format (for example 021 123 4567 becomes +64211234567).
Constraints: standard library only. Never modify the input file; the
calling script must write results to a new file. If a number cannot be
converted with confidence, return None rather than guessing.
Then list every assumption you made, and write test cases including
landlines, mobiles, +64 (0) formats, 0064, 0800 numbers, blanks and an
overseas number.
Example output (illustrative, abridged; tested on 19 October 2026):
import re
def to_nz_e164(raw):
"""Return an NZ phone number as +64..., or None if unsure."""
if not raw:
return None
s = re.sub(r"[\s().-]", "", str(raw))
if s.startswith("+64"):
rest = s[3:]
elif s.startswith("0064"):
rest = s[4:]
elif s.startswith("0"):
rest = s[1:]
else:
return None
rest = rest.lstrip("0") # handles "+64 (0)21 ..."
if rest.startswith(("800", "508")):
return None # freephone: a business decision, not a guess
if not rest.isdigit() or not 8 <= len(rest) <= 10:
return None
return "+64" + rest
Then the second review:
Act as a sceptical senior developer. Review this function for bugs,
inputs it mishandles, data it could lose, and assumptions a business
owner should decide rather than the code. Be specific; quote lines.
Example review findings (illustrative, abridged):
1. "64 21 123 4567" with no plus sign returns None. Decide whether
to accept it, because it is a common way people write NZ numbers.
2. The length check (8 to 10 digits) is loose for landlines, so some
malformed landline numbers will pass. Acceptable for a clean-up,
not for validation.
3. Extensions ("03 477 1234 ext 2") return None, so they will need a
manual fix. Good: nothing is silently truncated.
The useful findings are decisions, not bugs: whether to accept “64” without a plus, and whether freephone numbers should ever be converted. Those belong to the business, which is why the code returns None instead of guessing.
Where AI-written code goes wrong
- Plausible but wrong logic. It runs and is wrong for 3% of rows. Your own edge cases are the control.
- Invented packages. The OWASP GenAI LLM Top 10 for 2026 notes that coding assistants “hallucinate plausible but nonexistent package names at scale”, and attackers register those names in advance so AI-suggested installs pull in malicious code.
- Insecure code shipped unreviewed. The same list now treats insecure AI-generated code as part of improper output handling, with the scenario of an application that deploys generated code “without human review or security testing”.
- Tests that test nothing. AI-written tests sometimes print results instead of checking them, or check only the happy path.
- Secrets in prompts. Never paste API keys or passwords into a chat. Use placeholders.
- Destructive file handling. “Clean the file” can mean overwrite it. Separate input and output, always.
Speed of generation is no longer the hard part. Levy Street’s World of ClaudeCraft, a free, open-source browser MMO, had its first playable version built in about 48 hours in June 2026 with the Claude Fable 5 coding model, and roughly 60 contributors have since pushed about 19,900 commits. At that pace, reading, testing and rejecting changes is the work; our write-up on what building games with AI taught us covers the engineering side. Developers using Claude Code or Cursor need the same routine at larger scale, and our custom AI development team applies it to production systems. If your script feeds analysis, pair it with analysing a spreadsheet with AI.
Self-check
- You can explain every line of the code, or it was simplified until you could.
- The code never writes to, or deletes, its input file.
- Every import is standard library or a package you verified exists.
- No credentials appear in the code or in your prompts.
- You tested it on your own edge cases using a copy of the data.
- A second reviewer, human or a fresh model, checked it.
- Business decisions the code exposed were made by a person and recorded.
Next lesson: Building your first internal AI tool.
Sources
- OWASP GenAI LLM Top 10 2026, OWASP GenAI Security Project, September 2026
Written by the Levy Street team in Wellington. Last updated 19 October 2026.