On this page
What Should You Actually Look For in a Code Review?
A code review checks correctness, security, readability, and tests — in that order. Learn the checklist that catches real problems, not just style.
Quick answer
- Review in order of impact: correctness first, then security, then readability and maintainability, then tests.
- Ask “does this do what it claims, and nothing unsafe?” before asking “is it pretty?”
- The review’s job is to catch problems and share knowledge — not to win an argument about style.
What a code review is for
A code review has two jobs: catch defects before they ship, and spread understanding of the code across the team. The second matters as much as the first — a review that shares why a decision was made leaves everyone better able to work in that code later. It’s also the last human checkpoint before a change becomes production behavior.
The checklist, in priority order
- Correctness — does the code do what it claims, including error and edge cases? Trace the paths, not just the happy case.
- Security — does it introduce injection, missing access control, or exposed secrets? This is the highest-stakes scan.
- Readability and maintainability — is it clear enough to debug in six months? Naming, structure, and code smells live here.
- Tests — do tests exist and actually cover the new behavior, including failure modes?
- Consistency — does it match the codebase’s conventions and avoid duplicating existing logic?
How to review well
Review the diff, not just the lines — understand what the change is for before judging it. Be specific: “this will return 500 if the ID is missing” beats “this could be better.” Prioritize the list above over nitpicks, and distinguish “must fix” from “nice to have” so the author knows what’s blocking.
Where this bites vibecoders
When the code came from an AI assistant, the review shifts emphasis: correctness and security dominate, because those are exactly the axes where generated code is weakest. The review is also the moment you become the owner of code you didn’t write — reading it is how you stop being surprised by it. For the AI-specific version of this checklist, see How to Review AI-Generated Code.
Where AI coding assistants get this wrong
- Reviewing (when asked) for style and ignoring correctness and security.
- Approving code that matches the request but fails the edge cases.
- Flagging trivial nits while missing a missing authorization check.
- Giving vague feedback that the author can’t act on.
Checklist
- Review correctness first, including error and edge paths.
- Scan for security issues: injection, access control, secrets.
- Check readability and maintainability for future you.
- Confirm tests cover the new behavior and its failures.
- Separate blocking issues from suggestions.
FAQ
How is this different from reviewing AI-generated code?
The axes are the same, but the weighting differs: generated code is more likely to be superficially correct while missing edge cases, authorization, and tests, so those get extra scrutiny. Human code has more typos and logic bugs. The checklist is shared; the emphasis shifts.
Should style be part of code review?
Consistency matters, but style should be automated with linters and formatters so reviews spend their human attention on correctness and security. Reserve manual review for what tools can’t judge: intent, design, and edge cases.
How long should a review take?
Review small changes quickly and thoroughly. Large changes should be split before review — a 2,000-line diff is a sign the change is too big to review well. Speed and thoroughness both come from small, focused diffs.