AI code review: how to review AI-written code, and what AI reviewers do

What does AI code review mean?

People use the phrase for two different jobs, and a good workflow covers both.

If you build with a coding agent, the first job is the one that matters most, because the agent produces code faster than you can write it and nobody else will read it before it runs. The second job is a useful extra pair of eyes. It does not remove the need for the first.

How do you review code an AI wrote?

Review the diff, not the app. An app can look right and hide a bug in a branch you did not click. Follow the same order each time so you do not skip steps when the diff is dull.

1. Check the size first. Run git diff --stat. If the change touches many more files than the task needed, ask why before reading a line.
2. Check scope. Compare the changed files with what you asked for. Look for renamed functions, reformatted code, new dependencies and new features you did not request.
3. Run the tests yourself. Do not rely on "all tests pass" in the agent's summary. Run them, and run the app once on the main path.
4. Read the tests. Tests the AI wrote may assert whatever its code does. Ask what each new test would catch. Delete the fix and confirm the test fails.
5. Read every changed line. Look for the failure patterns in the table below.
6. Probe the edges. Empty input, a huge input, a duplicate, a missing value, a user without permission, a slow network.
7. Check secrets and data. No key in client code, no personal data in logs, no new public endpoint that returns more than it should.
8. Check dependencies. Does every new package exist, with the name spelled right, and is it maintained? Does the code call functions that exist in the version you have installed?
9. Commit or revert. Accept the step as a commit, or throw it away. Do not leave half-reviewed changes lying in the working tree.

What do AI-written changes get wrong?

These are patterns, not statistics: places to look first because a fluent model produces them in a convincing way.

What prompts help the AI review its own work?

Ask for criticism explicitly. A model that wrote the code leans toward defending it, so start a fresh session or a sub-agent for the review where you can, and ask for faults, not reassurance. These prompts are tool-agnostic. For more of this kind, see coding prompts to copy.

Act as a strict senior reviewer. Review the diff between main and the current branch (`git diff main...HEAD`).

Report only real problems, ordered by severity:
1. Bugs and logic errors, with the line and a failing example.
2. Missing edge cases: empty, null, large, duplicate, concurrent.
3. Security: secrets, injection, missing authorization, unsafe file or URL handling.
4. Anything that goes beyond the task described below.
5. Tests that would still pass if the code were wrong.

Task that was requested: <paste the task>.
Do not praise. Do not suggest style changes. If you find nothing in a category, say what you checked.

Compare this diff to the task below. List every change that was not required by the task: new files, renamed symbols, new dependencies, behavior changes, deleted code. For each one say whether I should keep it or revert it, and why.

Task: <paste the task>

For each test added in this diff, name one realistic bug in the code under test that this test would catch, and one that it would miss. If a test would pass even when the code is wrong, say so and rewrite it.

List every route, server function or API endpoint added or changed in this diff. For each, answer: who can call it, where is that checked in the code, and what happens if an anonymous user calls it directly? Quote the lines.

List every new dependency in this diff or lockfile change. For each: what it is for, whether the standard library or an existing dependency could do the same, and whether the package name and the functions used are real for the installed version. Say which claims you were unable to verify.

Which AI code review tools exist?

Two are documented by their makers in enough detail to compare. Both are described below as of October 2026; plans and settings change, so check the linked pages before relying on them.

GitHub's Copilot code review documentation states plainly that the tool is not guaranteed to spot all problems, sometimes makes mistakes, and that its feedback should be validated and supplemented with a human review. Anthropic's Code Review documentation describes four stages: find, verify, rank and post. It also lists a command you can run yourself from a Claude Code session on any plan, /code-review, and a way to run Claude inside your own CI with GitHub Actions or GitLab CI/CD.

Other AI review products exist. Judge any of them on the same questions: does it read the whole repository or only the diff, how many of its comments are noise, can you tell it what your project cares about, and who sees your code.

How do you combine human and AI review?

Give each reviewer the work it does best. A tool never gets tired of checking the fiftieth null case. A person knows what the product is supposed to do.

A simple pipeline for a solo builder: the agent writes a change on a branch; you read the diff with the checklist; a review tool runs on the pull request; you read its findings, fix what is real and ignore what is not; you merge. For a larger team, the same pipeline adds one human reviewer who did not write the prompt.

[ ] I read every changed line, including deleted lines.
[ ] The diff only touches what the task required.
[ ] I ran the tests myself and they pass.
[ ] I broke the code on purpose and a test failed.
[ ] Each new endpoint has an explicit authorization check.
[ ] No secret, key or personal data in code, logs or client bundles.
[ ] Every new dependency is real, needed and maintained.
[ ] Empty, large, duplicate and missing inputs behave sensibly.
[ ] An AI review ran, and I looked at every finding (fixed or dismissed with a reason).
[ ] I can explain this change to someone else.

Review habits are easier to build on small projects. Pick a small idea from the board, have an agent build it, and run this checklist on the result. A tool such as Which env var changed between the deploy that worked and the one that didn't is a good size for it. If you are doing the building as a pair, the routine in AI pair programming covers the earlier steps.