Whoever wrote the code, you or an AI agent, is the worst-placed to review it. They know what it's supposed to do, so they read what they meant, not what's there. A second opinion with fresh eyes, a fixed checklist and evidence from the code catches what tests and the author miss.
Last reviewed by the Forge team
Each one: why it hurts, and how to spot it in your own project.
You read your intent, not your code. That's why typos survive proofreading and why the missing permission check looks fine to its author.
How to spot it: If the person or model that wrote a change is also its only reviewer, it hasn't really been reviewed.
Pull request reviews see one change at a time. Problems no single diff introduced (a cycle, a rule copied five times, a route that never had an auth check) are invisible to them.
How to spot it: When did someone last review the whole codebase, rather than the latest change?
Without a list, reviewers check whatever comes to mind. A fixed list per area (security, SEO, structure) makes coverage repeatable.
How to spot it: Can you say which topics your last review covered, and which it didn't?
'This might be insecure' wastes everyone's time. A useful finding names the file and line, quotes the code and says what goes wrong.
How to spot it: Check whether review comments point at real code, and whether anyone confirmed the code says what the comment claims.
A list of 80 issues with equal weight gets ignored. Reviews need to say what to fix now, what next, and what to just watch.
How to spot it: Does your last review's output tell you the first three things to do?
An audit from six months ago describes a different codebase. Without re-checks, you don't know what's fixed, what's new, and what got worse.
How to spot it: Can you tell which past findings are fixed today?
const next = await tokens.rotate(userId, current.refreshToken);rotates without checking for a refresh in flight