Review Code the Model Wrote
Generate code, then review it properly. The habit this builds — never shipping generated code you have not read — is the single highest-value habit in AI-assisted development.
Why this one
Generated code usually works on the happy path. The failures live in the edges — empty input, concurrent access, error handling, resource cleanup — and those are exactly what a quick skim misses.
Steps
Generate something with real edges
Ask for a function with genuine edge cases: parse a date range from user input, retry a failing request with backoff, merge two sorted lists. Avoid anything trivial — a fizzbuzz has nothing to find.
Review it yourself first
Before asking the model anything, write down every problem you can find. Doing this first is the point of the exercise; asking immediately teaches you nothing about your own review skill.
Ask a different model to review it
A fresh context is much more critical than the one that wrote the code, which tends to defend its own output.
PromptReview this code as if it arrived in a pull request you must approve or reject. Find: unhandled edge cases, silent failures, resource leaks, incorrect assumptions about input, and anything that would break under concurrent use. For each, say what input or sequence triggers it. Do not rewrite the code, and do not tell me what is good about it.
Compare the two lists
What did it find that you missed? What did you find that it missed? Both directions matter — the second tells you where your judgement is still necessary, which is the reassuring half.
You should end up with
A reviewed function with a list of edge cases and who caught each.
Done when
- You reviewed it fully before asking for help
- At least one real defect was found
- You can name a category of problem you catch that the model does not
If you want to go further
- Write tests for every edge case found, then check they fail against the original