Skill guide
How do you review AI-generated code?
Published
Quick answer
Review AI-generated code the same way you should review any proposed change: start with the required behavior, inspect the diff for hidden assumptions, test normal and boundary cases, and make sure you can explain every important line. Generated code can be useful scaffolding, but polished syntax is not evidence that it handles your data, security model, performance constraints, or local conventions. The reviewer still owns the decision to merge it.
Start with the contract, not the explanation
Generated explanations can be convincing because they arrive with the code. Put them aside for a minute. Read the task, test, API contract, or bug report and state the expected behavior in your own words.
Then compare the implementation with that statement. If the code does something extra, ask why. If it leaves a case unhandled, do not assume the omission is safe because the rest of the diff looks polished.
Look for the places generic code guesses
Generic examples often make assumptions about null values, pagination, retries, authentication, transaction boundaries, error messages, and dependency versions. Those assumptions may be fine in a sample and wrong in your system.
Focus review time where the code crosses a boundary: input validation, permission checks, persistence, network calls, retries, and conversions between domain models. That is where a plausible default can become a real defect.
Make verification proportional to the risk
A formatting helper needs a different review from a migration or an authorization change. Start with focused tests that prove the intended behavior, then add integration or manual checks when the change crosses important boundaries.
If you cannot explain why a change works after reviewing the relevant docs and tests, it is not ready to merge. Ask for a smaller diff, reduce the problem, or investigate the uncertain part before adding more generated code on top.
A small practice loop
- 01Before reading a generated diff, write the expected behavior and two cases that must fail safely.
- 02Mark every external boundary in the diff: input, authorization, storage, network, retries, and output.
- 03Run or add the smallest tests that prove the main behavior and the highest-risk edge case before merging.
Common questions
Should AI-generated code receive a stricter review than hand-written code?
The required evidence should match the risk of the change, not the source alone. Generated code often arrives faster and in larger chunks, so it can deserve more deliberate decomposition and verification before review is complete.
What is the fastest way to find a flaw in generated code?
Start with the contract and the boundaries. Write or run a focused case for the most important input, then test an edge case involving missing data, limits, permissions, retries, or failure handling that the task requires.
Check your own starting point
Unrust uses short, timed, unassisted drills to give developers a per-skill snapshot. One session cannot explain the cause of a result, but it can show you what is worth practicing next.
Take the free diagnostic