How to review AI-generated code before you ship it
A practical checklist for reviewing code from Cursor, Claude Code, Copilot or an app builder: scope, security, data changes, dependencies, tests and tools.
Leer en español →
To review AI-generated code before shipping, read the diff rather than the agent's summary, confirm it changed only what you asked, run it yourself, and then check for the mistakes AI tools make most: secrets in browser code, missing permission checks on the server, risky database changes, packages that shouldn't be there, swallowed errors, and tests that were weakened to pass. Automated reviewers help as a second pair of eyes, not as the only one.
This guide gives a checklist you can follow even if you don't write code, shows where to look for each item, and covers the review tools in GitHub, Cursor and Claude Code.
Why can't I trust the agent's summary?
The summary describes what the agent meant to do. The diff shows what it did. They differ more often than you'd expect: an agent may report that tests pass without having run them, mention one file when it changed six, or describe a fix that only covers the case you showed it. Treat the summary as a table of contents and the diff as the text.
How do I read a diff if I'm not a developer?
Start with the list of changed files, not the lines. On GitHub, open the pull request and click Files changed; in Cursor, review the agent's changes file by file before accepting them.
Some file names should make you slow down every time:
.envor anything withsecret,keyorconfigin the name- Database migrations (
supabase/migrations/…,prisma/migrations/…) package.jsonand lock files (new dependencies)- Anything with
auth,middleware,policy,admin,paymentorwebhookin the path - Deleted test files
If a request like "change the button color" touched any of these, ask the agent to explain why before you read further.
What should I check, step by step?
1. Scope
Does the change do what you asked, and only that? Unrequested refactors, renamed files and "while I was here" cleanups are where regressions hide. Ask for them as separate tasks.
2. Does it run?
Pull the branch, start the app, and do the thing the change was for. Then do one or two things it wasn't for, like log in and open the main screen. Run the build and the tests yourself.
3. Security
- No secret keys in frontend code. Anything in the browser bundle is public. In Vite apps, only variables starting with
VITE_reach the browser, so aVITE_STRIPE_SECRET_KEYis a red flag. - Permission checks happen on the server or in the database, not only by hiding a button.
- New database tables have access rules. In Supabase, that means Row Level Security enabled with policies; see Supabase Row Level Security for Lovable and Bolt apps.
- User input that reaches a query, a file path or an AI prompt is validated.
4. Data changes
Read every migration. Look for DROP, DELETE, TRUNCATE, renamed columns and new required columns without a default. Any of these can break or erase existing data. They should run on a test database first.
5. Dependencies
AI tools sometimes suggest packages that are outdated, unnecessary, or don't exist at all, and attackers have registered names that models tend to invent. For each new package, open its npm page: does it exist, is it maintained, is it widely used, and do you actually need it? Run npm audit for known vulnerabilities.
6. Error handling
Search the diff for empty catch blocks and errors that are only logged to the console. When something fails, the user should see a message and you should be able to find out why.
7. Tests
Were tests added for the new behavior? Were any deleted, skipped (.skip, .only) or loosened to pass? A test changed in the same diff as the code it tests deserves a careful look.
8. Duplication
Did it write a new helper that already exists elsewhere? Duplicates are how two parts of the app start disagreeing about the same rule.
Which review tools can help?
| Tool | What it does | Where |
|---|---|---|
| Copilot code review | Reviews pull requests and leaves comments | GitHub, on Copilot plans that include it |
| Cursor Bugbot | Reviews pull requests for bugs and security issues; reads project context from .cursor/BUGBOT.md | GitHub and GitLab, triggered automatically or with a cursor review comment |
Claude Code /code-review | Reviews your local changes or a branch, and can apply fixes | In a Claude Code session |
| GitHub secret scanning | Flags or blocks pushes that contain known secret formats | Repository security settings |
npm audit | Lists dependencies with known vulnerabilities | Your terminal or CI |
One more trick: open a fresh session, paste the original request and the diff, and ask for a critical review. A new context isn't attached to the decisions the first session made.
When do I need a human reviewer?
When the change touches money, login, permissions or personal data, or when you can't explain in a sentence what the diff does. Those are the areas where a quiet mistake costs the most. The OWASP Top 10 is the standard list of web security risks a reviewer will check against, and our security checklist for AI-built apps translates it into concrete checks.
Quick answers
How long should a review take? If it takes more than fifteen to twenty minutes, the change is probably too big. Ask for smaller tasks.
Can one AI review another AI's code? Yes, and it catches real issues, but both can share the same blind spots. Use it in addition to running the code yourself.
What's the single most important check? Run it. A surprising number of AI changes fail at the first click.
Should I review changes from Lovable or Bolt too? Yes, if the code syncs to GitHub. Every commit there is a diff you can read the same way.
Want a professional review?
If the app is about to handle real users or payments, an outside review is cheap insurance. Our Cursor project help and Devin Desktop and Windsurf project help pages explain how we review AI-agent code, starting with a written report. Pair it with tests for AI-generated code, run the free health check for the outside view, or contact us.
