A practical workflow for reviewing AI-written code

AI coding tools write code quickly, and that is exactly the problem. A change that took thirty seconds to generate can take thirty minutes to understand, and code you haven't understood is code you can't safely ship.

This guide gives you a routine for reviewing AI-written changes. It combines three layers: your own eyes, a second AI doing a review pass, and automated checks. No single layer is enough, and none replaces the others.

The principle: you own the change

The AI proposes, you decide. If a change goes into your project, you are responsible for it, whoever typed it. That's easier to live with when you set things up so changes are small, visible and reversible.

Step 1: Make the change reviewable

Review is much easier when the change is small and isolated.

• Work on a branch. A branch is a separate line of work in Git, so a bad experiment never touches your main code. Our Git safety-net guide covers the basics.
• Ask for one thing at a time. "Add a password reset page" is reviewable. "Rework the whole login system" is not.
• Commit before and after. A commit before the AI starts gives you a clean point to return to, and a diff of exactly what it changed afterwards.

Step 2: Read the diff yourself first

Before you ask any AI for its opinion, look at what changed. In a terminal:

git status
git diff

git status lists which files changed, and git diff shows the exact lines. Your editor's source-control panel shows the same thing visually.

On the first pass, you aren't hunting for bugs. You're checking the shape of the change:

• Did it touch only the files you expected?
• Is the size of the change in proportion to what you asked for?
• Did anything appear that you didn't ask for, such as a new dependency, a deleted file or a changed config?

Surprises at this stage are the most valuable thing a review can find.

Step 3: Ask an AI to review it

A fresh AI pass catches things you'll miss, and it's cheap. The ideal is a separate session or tool from the one that wrote the code, so it isn't marking its own homework.

Claude Code

Claude Code has no special review ritual you must learn. You can ask for one in plain English, in a fresh session:

Review my uncommitted changes. Look for bugs, missing error handling, security problems and anything that doesn't match the conventions in this project. List the issues by severity and don't edit any files.

For security specifically, Anthropic documents a built-in /security-review command that you can run on demand in a Claude Code session, as well as a GitHub Actions version that reviews pull requests automatically. Anthropic's help centre recommends running it before committing significant changes, and describes automated reviews as a complement to, not a replacement for, your existing security practices and manual code review.

GitHub Copilot

If your code is on GitHub, Copilot can review a pull request. GitHub's docs describe requesting it from the Reviewers menu on the pull request, the same way you'd request a human reviewer. You can also set up automatic reviews for all pull requests. A few facts from GitHub's documentation worth knowing:

• Copilot always leaves a Comment review. It never approves or requests changes, so its review doesn't count toward required approvals and won't block a merge.
• It doesn't re-review on new pushes by default. To get another pass after you push fixes, use the re-review button next to Copilot's name in the Reviewers menu.
• It reads custom instructions from the pull request's base branch, so you can steer what it looks for.

OpenAI Codex

OpenAI's Codex CLI has a review mode. Type /review in the CLI and pick a preset, either Review against a base branch or Review uncommitted changes. For a non-interactive version, OpenAI's reference documents codex review with --base <branch> and --uncommitted options. It's a convenient choice when you want a second opinion from a different tool than the one that wrote the code.

Using a different vendor's tool for the review is a genuine advantage. Two different systems are less likely to share the same blind spot.

Step 4: Treat AI review as a list of leads

AI reviewers produce a mix of real findings, trivial nitpicks and the occasional false alarm. For each point, ask:

• Can I reproduce or verify it? Open the file and look.
• Is it relevant to this project, or generic advice?
• Does the suggested fix introduce a new problem?

Don't apply suggestions blindly. A review comment is a lead to investigate, not an instruction.

Step 5: Run the automated checks

Machines are better than people and AIs at the dull, certain stuff. Run whatever your project has:

npm test
npm run lint
npm run build

(Use your project's own commands. These are the common names in JavaScript projects.) If there are no tests, that's worth noticing: AI changes with no tests are the hardest to trust. Ask the AI to write tests for the new behaviour, then read the tests, because AI-written tests sometimes assert the wrong thing or pass without testing anything.

Step 6: Use the human checklist

Finally, go through this list on the diff. It's short on purpose.

Does it do what I asked?

• Run the feature yourself and try the normal case, then an empty input, a very long input and a wrong input.

Is anything missing?

• Error handling for when a network call or file read fails.
• Edge cases such as no results, duplicate entries and logged-out users.

Is it safe?

• No secrets, API keys or passwords written into code or committed files.
• User input is validated before being used in a database query, a file path or a command.
• Nothing that disables a security check "to make it work".
• Permissions are no broader than needed.

Is it honest?

• Look for code that fakes success: tests edited so they pass, errors silently swallowed, hard-coded values standing in for real logic.
• Check that any library the code imports actually exists and is the one you meant. AI tools occasionally invent package names, and a similarly named malicious package is a known attack.

Is it maintainable?

• Could a colleague understand it in a few minutes? Is there duplicated code that already exists elsewhere in the project?
• Did it add a new dependency when a few lines would do?

Step 7: Keep what you understand

When you're satisfied, commit with a clear message. If part of the change is something you don't understand, ask the AI to explain it, or remove it. "It works and I'm not sure why" is a debt that comes due later.

If a review pass found real problems, feed that back into your standing instructions so the AI stops repeating them. For example, add a line to your project's CLAUDE.md such as "Always validate user input before database queries."

A routine you can follow every time

1. Branch, commit, then ask for one small change.
2. Read git status and git diff yourself.
3. Get a second AI review from a separate session or a different tool.
4. Verify each finding before acting on it.
5. Run tests, lint and the build.
6. Walk through the human checklist.
7. Commit what you understand.

Where this routine has limits

AI review can miss things, and it can sound confident while being wrong. Neither Copilot's reviews, /security-review nor /review in Codex is a guarantee that code is safe. For anything handling payments, personal data or logins, get a human who knows the area to review it, whatever the tools say.