How to review AI-written code when you can’t code (2026)
A practical review method for non-engineers: what to look at in a diff, how to use a second AI as a reviewer, the behaviour tests that replace reading code, and the red flags worth stopping for.
Key Takeaways
- Review the shape of a change, not every line. Which files changed, how many lines, and whether anything touched sign-in, payments, permissions or the database tells you where to look harder.
- Use a reviewer that didn’t write the code. A fresh AI session, or a built-in command like Claude Code’s /code-review, isn’t swayed by the reasoning that produced the change.
- Behaviour tests replace much of line-by-line reading. Two accounts, a signed-out browser, bad inputs and a mobile screen catch the bugs that matter most to users.
- Some changes always deserve a stop. New secret keys in frontend files, deleted checks, disabled security settings, destructive migrations and new packages you didn’t ask for.
- Ask the agent to explain in plain English. If it can’t explain a change in terms of your app’s behaviour, the change probably isn’t what you wanted.
Quick-Start Prioritization Framework
| Check | How long | What it catches |
|---|---|---|
| Read the list of changed files | 1 minute | Changes in places you didn’t expect |
| Plain-English explanation from the agent | 2 minutes | Misunderstood requests |
| Fresh-session AI review of the diff | 5 minutes | Logic bugs, missing checks, security issues |
| Red-flag scan (secrets, auth, migrations, packages) | 3 minutes | The highest-impact mistakes |
| Two-account behaviour test | 5–10 minutes | Data leaks between users |
| Signed-out and bad-input test | 5 minutes | Unprotected pages, crashes on odd input |
If you build with AI and can’t read code fluently, “review the code” sounds like advice for someone else. It isn’t. You can’t check whether a loop is efficient, but you can check what changed, where it changed, whether it touches anything dangerous, and whether the app behaves the way you asked. That covers most of the bugs that hurt. This guide gives a review routine that works without programming knowledge: reading a diff at the level of files and names, using a separate AI review that didn’t write the code, testing behaviour directly, and a short list of red flags that should always make you stop.
What “review” means if you don’t write code
Professional code review has two parts: does the code do what was intended, and is it written well. You can’t judge the second part without experience. You can absolutely judge the first, and it’s the part that decides whether users get hurt.
Think of yourself as the product owner signing off on a contractor’s work. You don’t inspect every weld. You check the structure is where it should be, ask what was done and why, look at the risky bits, and test that it works.
Step 1: look at the shape of the diff
A diff is the list of changes between two versions. Every coding agent shows one, and in Git you can see it with git diff or git diff --stat for a summary.
Read the file list first
git diff --stat prints each changed file with a count of lines added and removed. You asked for a new button on the settings page. If the list includes the login code, the database schema and a payments file, stop and ask why. Unexpected files are the most reliable early warning you have.
Check the size
A small request that produced 900 changed lines usually means the agent rewrote something it didn’t need to. Large diffs are where old behaviour quietly disappears. Ask the agent to redo it with the smallest possible change.
Scan the names
You don’t need to understand the syntax to read names. Function and variable names like deleteAllUsers, isAdmin, skipAuth, disableVerification or TODO are worth a question. So are comments like “temporary” or “for testing.”
Step 2: ask for a plain-English explanation
Ask the agent: “Explain this change as if to a product manager. For each file, say what behaviour changed for users, and list anything that affects sign-in, permissions, payments or stored data.”
What a good answer looks like
It maps each change to something you asked for, names any side effects, and is honest about what it didn’t do. A good answer often includes a sentence like “I also changed X because Y.” That’s exactly the sentence you want to scrutinise.
Warning signs in the answer
Vague phrasing (“refactored for clarity”), changes it can’t connect to your request, or claims of testing with no command or output. Follow up with “show me the test you ran and its output.”
Step 3: get a second opinion from a fresh reviewer
The agent that wrote the code is the worst reviewer of it, for the same reason you’re a poor proofreader of your own essay. A reviewer that never saw the conversation judges the code on what it does.
Built-in review commands
Claude Code ships a /code-review command. Its docs say it reviews the changes on your branch for correctness bugs and, in a terminal session, runs as a background subagent with its own context window. It takes a target: /code-review with no argument reviews your current branch and uncommitted changes, and /code-review src/auth reviews a path. Adding --fix asks Claude to apply the findings.
A review prompt for any agent
In a new session in Codex, Cursor or another tool: “Review the uncommitted changes in this repository as a senior engineer. Focus on: users seeing other users’ data, secrets exposed to the browser, missing input validation, data that could be deleted or corrupted, and behaviour that used to work and might now break. List findings by severity with file and line. Don’t edit anything.”
Review against what you asked for
If you wrote a short spec, point the reviewer at it: “Check this diff against SPEC.md. Is every requirement implemented? Is anything implemented that wasn’t asked for?” Anthropic’s best-practices guide suggests exactly this kind of spec-based review prompt.
Step 4: scan for red flags
These are the changes that deserve a stop and a question every time, whoever wrote them.
| Red flag | Why it matters | What to ask |
|---|---|---|
| A key or token in a frontend file | Anything sent to the browser is public | “Move this to a server-side secret” |
| Removed or commented-out checks | Often how permission bugs are born | “Why was this check removed?” |
| Security setting turned off | Row Level Security disabled, CORS set to allow everything, webhook verification skipped | “Turn it back on and fix the real cause” |
| Migration that drops or renames columns or tables | Data loss can’t be undone with Git | “Back up first; can this be additive instead?” |
| New package you didn’t ask for | Supply-chain risk and bloat | “Why this package? Is it maintained?” |
| Error handling that swallows errors | Failures become silent | “Log this and show the user a message” |
Step 5: test the behaviour yourself
Behaviour tests are where non-engineers can be better reviewers than engineers, because you test like a user.
The two-account test
Create two ordinary accounts. As user A, create data. As user B, visit every page that shows data, and try A’s URLs directly (copy the address of A’s record and paste it in B’s browser). B should see nothing of A’s. OWASP lists Broken Access Control as the top web application risk in its 2025 edition, and this test is the quickest way to find it.
The signed-out test
Open a private window. Visit the admin page, the dashboard and the settings page directly by URL. Each should send you to sign-in, not show a half-loaded page with data.
The bad-input test
Leave required fields empty. Paste a very long text. Use a negative number for a quantity, a date in the past for a booking, an emoji in a name. The app should refuse politely, not crash or save nonsense.
The regression check
Keep a short written list of the five things your app must always do: sign up, sign in, the core action, payment if any, sign out. Run through it after every significant change. Better yet, ask the agent to turn the list into automated tests.
Building review into your routine
Review works best as a habit tied to commits, not an event before launch.
Small changes, reviewed often
Ask for one feature at a time and review before the next. Ten small diffs are far easier to check than one big one, and each review is a natural point to commit.
Put review rules in your instruction file
Add lines like “never put secret keys in frontend code” and “every query that returns user data must filter by the signed-in user” to CLAUDE.md or AGENTS.md. Codex’s docs describe a Code Review Rules section in AGENTS.md for exactly this purpose.
Know when to bring in a human
Before you take payments, store health or financial data, or open sign-ups to the public, a few hours of an experienced engineer’s time on the auth and data code is cheap insurance. Bring them your spec and your list of red-flag answers.
Common mistakes
The review habits that feel thorough but miss the real problems.
- Asking the same session that wrote the code whether it’s correct. It will usually say yes.
- Reviewing only the preview while signed in as yourself, the one account that’s guaranteed to see its own data.
- Approving large diffs because they’re too big to read. Size is the reason to push back.
- Accepting “I tested it” without seeing what was run.
- Ignoring changes to files you didn’t mention because the feature works.
- Treating a passing review as permission to skip the behaviour tests.
If you’d rather not do this yourself
If you’d rather not review database and login code yourself, platforms such as Floot provide sign-up, login with roles and a per-app Postgres database as part of the platform, so the agent builds on those pieces instead of writing them from scratch. You should still run the two-account test before launch.
Frequently Asked Questions
Can I trust AI-generated code without reviewing it?
For a personal tool or a throwaway prototype, often yes. For anything with other people’s data, payments or public sign-ups, no. At minimum, run a fresh AI review and the two-account test.
How do I review code if I can’t read it?
Check which files changed and how much, ask for a plain-English explanation, run a separate AI review, scan for the red flags in this guide, and test behaviour with two accounts, signed out and with bad inputs.
Is a second AI review actually useful?
Yes, when it runs in a fresh context. A reviewer that didn’t see the original conversation isn’t anchored on the reasoning that produced the code, so it catches different things.
What does Claude Code’s /code-review do?
Its docs say it reviews the changes on your branch for correctness bugs and reports findings in your conversation. You can point it at a pull request, branch or path, and add --fix to have Claude apply the findings.
What’s the most important thing to check?
Whether one user can see or change another user’s data. Test it with two real accounts and by pasting one user’s URLs into the other’s browser.
When should I pay a developer to review?
Before taking payments, storing sensitive data or launching publicly. Focus their time on sign-in, permissions, payment handling and database migrations.
Sources
- Anthropic, Review locally with /code-review, 2026 https://code.claude.com/docs/en/code-review-local
- Anthropic, Best practices for Claude Code, 2026 https://code.claude.com/docs/en/best-practices
- OpenAI, AGENTS.md (ChatGPT Learn), 2026 https://learn.chatgpt.com/docs/agent-configuration/agents-md
- OWASP, OWASP Top 10:2025, 2025 https://top10.owasp.org/2025
- Supabase, Row Level Security, 2026 https://supabase.com/docs/guides/database/postgres/row-level-security