Guides / Prompting and shipping

How to Review AI-Generated Code

A practical way to review code an AI wrote: check what changed, test the behaviour, then look for missing permission checks, leaked secrets and invented APIs.

Mythex Team · 2026-09-29 · 5 min read

To review AI-generated code, start with what changed — which files and why — then test the behaviour yourself before reading any line of code. After that, check the areas where AI code most often goes wrong: missing server-side permission checks, secrets exposed to the browser, unvalidated input, packages or functions that don't exist, and edits to things you never asked it to touch.

AI writes code that usually runs and often looks tidy. That makes it easy to approve without really checking. This guide is a review routine that works whether you read code fluently or not at all.

Scale the review to the risk

Not every change needs the same attention.

Step 1: See what changed

Before judging the code, get the list of changes:

• If the project is in Git, look at the diff: the files and lines that changed since the last commit. See how to use Git with an AI-built app.
• Or ask the AI directly:

List every file you changed in the last change, and for each one explain in one sentence what changed and why.

Red flags at this stage: files unrelated to the request, deleted files, changes to configuration or dependencies you didn't ask for.

Step 2: Test the behaviour first

Reading code tells you what it's meant to do; testing tells you what it does. Before reading:

• Try the change as a normal user, on desktop and a phone-size screen.
• Try it with wrong input: empty fields, very long text, negative numbers, a date in the past.
• Try it logged out, and as a different user.
• Re-run the flows that matter most: sign up, log in, the main action, payment.

If testing fails, you've saved yourself reading time — report it clearly and let the AI fix it. See how to write a good bug report.

Step 3: Check permissions on the server

The single most important thing to check. AI tools often hide a button in the page but leave the server willing to do the action for anyone who asks.

For every route or function that reads or changes data, ask:

• Does it check the user is logged in?
• Does it check this user is allowed to access this record?
• Is that check on the server, not just in the page?

For each API route you added or changed, tell me what permission check it does on the server, quoting the line. Flag any route without one.

Then test it: log in as user A, note a record's ID, log in as user B and request it. The security checklist for AI-built apps has the full test.

Step 4: Look for exposed secrets

• Search the changed files for anything that looks like a key or password.
• Check that secret keys are read from environment variables and only used in server code.
• Watch for public prefixes such as VITE_ or NEXT_PUBLIC_ on secret variables — those are built into browser code.

See how to keep API keys safe.

Step 5: Check input and errors

• Validation on the server. Browser checks can be skipped. Required fields, lengths, formats and allowed values should be checked by the server too.
• Database queries use parameters, not text built by joining user input into a query.
• Errors aren't swallowed. A try/catch that does nothing hides failures. Errors should be logged, and users should see a plain message.
• No internal details shown to users — stack traces and database errors belong in logs.

Step 6: Check it's real

AI models sometimes produce code that looks right but refers to things that don't exist.

• Packages: every new dependency should be a real, maintained package with that exact name. Be wary of names that look like typos of popular ones.
• Functions and API options: if the code calls a library function or an external API option you've never seen, check the official documentation.
• Placeholder code: search for TODO, mock, fake, hard-coded sample data, or functions that return a fixed value.

Did you add any new packages? For each, give the exact name, what it's for, and whether we could do without it.

Step 7: Check it fits

Code can work and still make the app harder to change later:

• Duplication. The same logic copied into several places will drift apart.
• Consistency. It should follow the patterns the rest of the app uses.
• Size. A 20-line request that produced 600 lines deserves a question.
• Dead code. Old versions left behind next to new ones.

Is there any code in the project that's now unused because of this change, or logic that's duplicated elsewhere? Don't change anything; just list it.

Common mistakes

• Approving because it looks clean. Neat code can still skip a permission check.
• Reading instead of testing. Test first; read second.
• Only testing the happy path. Try bad input, the wrong user, and logged out.
• Ignoring unrelated file changes. Ask why every file changed.
• Trusting a self-review completely. Use the AI's review as a first pass and confirm by testing.
• Reviewing a week of changes at once. Review small changes as they happen.

Checklist

• I know which files changed and why, and nothing unrelated changed.
• The change works on desktop and phone, with bad input, logged out and as another user.
• Every data route checks login and ownership on the server.
• No secrets in code or browser bundles.
• Input is validated on the server; queries use parameters.
• Errors are logged, not swallowed, and not shown in detail to users.
• New packages are real and needed; no invented functions or placeholders remain.
• High-risk changes had a careful read and, where needed, a second reviewer.

Reviewing code on Mythex

• Ask mode answers questions about the code without editing it — ideal for "explain every change" and "which routes lack a permission check" prompts. See Chat.
• Code view shows the file tree, editor and terminal on every plan (read-only on Free, editable on Pro), so you can read what changed yourself. See Code editor.
• /test has the agent click through the preview as a user and report broken flows.
• Checkpoints let you revert a change that fails review.

If a developer is reviewing for you, how to work with a developer on an AI-built app covers the handoff; if the review turns up a bug, see how to debug an AI-built app.