Describe, vet, never blind-run
- coding
- verification
Generated code is a draft from a fast stranger who will never be blamed for it. Three habits make it safe: describe what you want precisely, vet what you get before executing, and never blind-run — execute something you cannot explain. The middle verb is the one people skip, and it is the one that matters.
The vetting pass
Read the draft with a specific checklist:
- Find the dangerous verbs. Delete, move, overwrite, send, install, fetch a URL, anything touching passwords or keys. Those lines decide everything.
- Check paths and inputs. Where does it actually operate? A wrong variable means the wrong folder. Pick a folder name with spaces and odd characters as your test — that is where naive scripts break.
- Look for secrets. API keys and passwords must never be hardcoded — in generated code or any other. They belong in environment variables.
- Distrust the comments. “I tested this thoroughly” is an unsupported claim by a system that cannot have tested anything here — the kind the research track trains you to catch, in a comment.
- Write the dry-run line yourself. Ask for a version that only prints what it would do. Run that first — the list of intended actions is cheap to read and catches the expensive mistakes.
Test on copies
Run the script on a copy folder with a few fake files, including one with a tricky name. Confirm the behavior. Then — with a backup in place — run it on the real folder. Destructive steps earn their way in one at a time, never as a batch.
A bad example
You: paste the script into a terminal on the folder with the originals. It runs “successfully”. The photos are now inside
photos/photos/, some overwritten, and the original layout is gone.Nothing errored. That is exactly how blind-running fails — silently.
A better example
You: run the dry-run version first. It prints twelve “would move” lines. One of them is wrong — a file you wanted to keep. You fix the filter, re-run the dry-run, then execute with a backup.
Two minutes of reading; the folder survives either way.
When you cannot read it
If you cannot explain what a line does, you have exactly two honest options: ask for the explanation and keep re-reading until you can, or shrink the task until the whole script fits in your head. There is no third option where you run it anyway — that one is a bet, not a workflow.
Practice
Vet the file-renaming script
A colleague generated a script to organize a photo folder and asks whether it is "safe to just run". You read it first — that is the job.
Flag every line that should not be run or trusted as-is.
The AI answer
import os, shutil API_KEY = "sk_live_9f2c8a41" # billing dashboard key folder = input("Folder to organize: ") files = os.listdir(folder) for name in files: if name.endswith(".jpg"): shutil.move(os.path.join(folder, name), os.path.join(folder, "photos", name)) print(f"{len(files)} files found — done!") # I tested this thoroughly, just run it.
Hint
Which lines change something on disk — and which only read or print?
A comment makes a claim. Could the machine that wrote it have tested anything?
Why this is the answer
The safe lines only read and print; the flagged ones write, expose and promise. The move is the destructive core — it needs a dry run, a test on copies and a backup before it touches real files. The key needs removing and rotating, and the 'tested thoroughly' comment deserves the same distrust as any unsupported claim.
Transfer
- Automation scripts: dry-run, copy-test, then execute — in that order, every time.
- Snippets from anywhere: the checklist works on human-written and generated code alike.
- Commands pasted from chats: same rules as code — read the destructive verbs first.
Next
Next: What not to paste — the data side of the same discipline: what should never travel into a chat box at all.