AI-written code often runs on the first try and still has problems you only meet in production. It tends to look tidy, so it is easy to wave through. This is a short routine to run before you launch anything an assistant wrote for you.
None of it replaces tests, a second person's eyes or a proper security review for anything handling payments or personal data. It catches the common, cheap-to-fix things first.
Step 1: run it as a stranger would
Before reading a line of code, run the app from a clean checkout. Clone it into a new folder, install from the lockfile, and follow your own README. If that fails, the code only worked on the machine that wrote it. Fix this first.
Step 2: check the dependencies
Assistants sometimes name packages that do not exist or are not what they sound like. For each new dependency, confirm it exists on the official registry, check who maintains it and when it last changed, and make sure you actually need it. Remove anything you cannot justify.
Step 3: look for secrets and open doors
Search the repo for keys, tokens and passwords, including in config examples and test files. Then check every route or function that takes input: is the user allowed to do this, is the input validated, and what happens with an empty or huge value? Look at anything that builds a query, a shell command or a file path from user input.
Step 4: ask the assistant to review, in a fresh chat
Open a new conversation so it is not defending its own work. Paste the code and this prompt.
Review the code below as a careful senior engineer who did not write it. The code will go to production.
Report only problems you can point to in the code. For each one give: the file and line or function, what goes wrong, a realistic way it would happen, and the smallest fix.
Check these in order:
1. Input handling: anything from users, URLs, files or APIs used without validation.
2. Secrets: keys, tokens or passwords in the code or config.
3. Access control: places where any logged-in user, or anyone, could reach someone else's data.
4. Errors: calls that can fail (network, disk, parsing) with no handling, and errors that leak internal details.
5. Dependencies: packages you do not recognise, or used in a way that looks wrong.
6. Anything that works in a demo but not under real load, such as loops over unbounded data.
Do not praise the code. Do not suggest style changes. If you are unsure about something, say "unsure" and say what you would need to see. If you find nothing in a category, write "nothing found".
CODE:
[paste here]Step 5: verify each finding yourself
Treat the answer as a list of leads. Some will be wrong and some real issues will be missing. For each item, reproduce it or read the code it points to. Write a test for the ones that are real, then fix them.
Step 6: test the boring paths
Try an empty form, a very long string, a repeated click, a logged-out visit to a logged-in page, and the app with the network off. These are where generated code most often falls over.
Limits
- A review prompt reads only what you paste. It cannot see your servers, your cloud settings or code in files you left out.
- It can miss real bugs and report ones that are not there. Passing a review does not mean the code is safe.
- It does not replace automated tests, a dependency audit tool or a human review for payments, health or personal data.
- If you cannot read the code at all, get someone who can to look before real users do.
Follow for new free skills
New free skills and guides appear in all of these as we publish them. Pick whichever you already use.
- RSS feed for any feed reader
- Watch the free skills repo on GitHub
- Follow on Gumroad