How to review AI-generated code

Stop trying to read everything

The instinct after generating a few thousand lines is either to read all of it or none of it. Both fail. Reading all of it does not scale, and the boring majority rarely contains the incident. Reading none of it is how a live key ends up in a browser bundle.

Instead, review by risk. A small fraction of the code decides almost all of the outcomes.

Review the risky 20%

If you review nothing else, review those six. They are where a demo becomes an incident.

• Authentication and authorization: who can sign in, and what each role is allowed to do.
• Money: payment flows, prices, webhooks and anything that changes an amount.
• Data access: every query that reads or writes a user's data, and the rule that protects it.
• Input handling: anything a user can type that reaches a query, a shell or a page.
• Secrets and configuration: what is exposed to the client and what stays on the server.
• Infrastructure: deployment settings, storage buckets and the rules that decide who can read them.

Ask the model to review the model

An AI assistant is genuinely useful as a second reader, especially for a file you have not opened. It is unreliable as a judge of its own output, so use it to find candidates and verify them yourself.

• “List every endpoint in this project and, for each one, tell me what checks the caller's identity and permission.”
• “Show me every place a user-supplied value reaches a database query, a template or an outbound request.”
• “Which environment variables are read in client components, and what would be exposed if each one leaked?”
• “Write a test that proves a normal user cannot read another user's records.”

Make the machine check the machine

• Run the type checker and the linter, and fix what they say. Most of it is real.
• Build the app the way it will be built for production, not just on the dev server.
• Write a handful of tests around auth, money and data access, and keep them.
• Scan the built output for secrets, and scan the repository history too.

Check the running app, not just the source

Some defects do not exist in the source at all. They appear when the app is deployed: a header the platform did not send, a bucket that defaulted to public, an endpoint that answers without a session. Reading the code will never show you these, because the code is not wrong. The configuration is.

• Open the site as a stranger and as a signed-in user, and compare what each can reach.
• Look at the response headers on your most important pages.
• Try to fetch a file you thought was private.
• Read the page copy the way a customer would, looking for placeholders that shipped.

Write down what you verified

A review that leaves no record cannot be repeated, handed over or trusted a month later. Keep the finding, the evidence and the decision, even if the decision was to accept the risk.

This is also what makes a re-review cheap: you compare against what you knew, not against a vague memory.

A review loop you can repeat

1. 01

   Generate

   Build the feature with the AI tool as usual.

2. 02

   Sweep

   Run the linter, the type checker, the tests and a secret scanner.

3. 03

   Read the risky parts

   Auth, money, data access, input and configuration get an actual look.

4. 04

   Probe from outside

   Call the API without a session, try to read another user's data, check the headers.

5. 05

   Record

   Note what you found, what you fixed and what you accepted.

6. 06

   Re-check after the next change

   A fix that is not verified is a hope, not a result.