How to Review AI Generated Code Before It Ships (2026)

AI code review for agent pull requests comes down to five checks in a fixed order: run it, prove the behavior, read the architecture, question the agent, then let scanners sweep for security. Most people do only the third one, badly, by scrolling a 2,000 line diff and typing "LGTM." That habit is now expensive. Veracode's 2026 GenAI Code Security Report found the average model still fails 44% of its security tasks, and the top model in its summer 2026 test group (GPT-5.5) still fails 32%. Code that compiles is not code you can ship.

Last verified: October 22, 2026. We added the Claude Code team's review process, published by Anthropic on October 15, 2026, and checked it against Anthropic's post, the Code Review docs and the Claude Help Center on October 22, 2026. Tool details for Whiteboard, Canary and Critic come from each vendor's own launch post, published the week of Sept 21, 2026, and were last checked on Sept 28, 2026. We have not run Code Review, Canary or Critic against a production repo, and we did not check pricing for Canary or Critic. Treat their claims as the vendor's until you test them on your own code.

Why reviewing agent code became its own skill

Agents write faster than people read. The founders of Whiteboard put a name on the result in their Hacker News launch: as more agent PRs merged without their understanding, "cognitive debt" built up until they struggled to contribute to their own system.

The numbers explain why reading harder isn't enough. In Veracode's Spring 2026 update, code that runs without syntax errors climbed from about 50% to 95% since 2023. Security pass rates stayed flat, between 45% and 55%, across every model generation. Cross site scripting defenses passed only 15% of the time. So agent code looks cleaner every year while hiding the same class of bugs.

GitHub's own guide to reviewing AI generated code lists the traps worth memorizing: hallucinated APIs, packages that don't exist, ignored constraints, and tests that were deleted or skipped instead of fixed. None of those show up as a red squiggle.

The five ways to check agent code, compared

Each check below catches a different kind of mistake. None of them replaces the others, and the order matters because the cheap ones filter out work for the expensive ones.

1. Run it and read the diff yourself

This is classic line by line review: pull the branch, run the tests, read every changed line. It catches wrong logic in code you already understand, naming that will confuse the next person, and the deleted test GitHub warns about.

Best if: the change is small and sits in code you know well. Avoid it if: the PR spans dozens of files. Attention fades long before the last file, and you start approving on trust, which is exactly the failure this whole process exists to stop.

2. Prove the behavior with tests of what must never happen

Behavioral verification starts from what the software should do and, more importantly, what it must never allow. Canary, a YC company, launched this idea as a product on Hacker News the week of Sept 21. In their launch post, the coding agent sends Canary the changeset, the intended behavior and team knowledge. Canary then runs agent swarms that try to trigger suspected failures in remote sandboxes and send the evidence back to the agent.

You can do the unglamorous version by hand. Write down three invariants before you read the code, such as "private files stay private," "credentials never reach a log," and "a retry never charges twice." Then write or demand a test for each one.

Best if: the change touches money, permissions, personal data or retries. Avoid it if: nobody has written down the intended behavior yet. A verifier with no spec just confirms the code does what the code does.

3. Read the architecture, not the lines

Architecture review asks whether the change fits the system: where data flows, which service now owns what, what the agent decided on its own. Whiteboard (YC W26, MIT licensed) is the clearest example so far. It plugs into Claude Code and Codex, lets the agent draw sequence and entity diagrams linked to the real code, and ships a Rust diff viewer that understands syntax. That viewer summarizes large new functions as pseudocode and collapses test and documentation changes by default. A decision log shows which choices the agent made without asking.

At launch it could not edit files, and the founders renamed it from "IDE" to "canvas" after pushback in the thread. Windows support followed two days later.

Best if: the agent built a new feature across many files or made a design call you didn't specify. Avoid it if: it's a one line fix. Drawing a diagram for a typo is ceremony, not review.

4. Question the agent that wrote it

Here you interrogate the author. Critic, from Feyn, launched Sept 24 as a plugin for Codex and Claude Code. It makes the agent write a narrative of the change, flag its assumptions and annotate complex code, and it won't let the agent end its turn until that narrative passes word count and format checks. When a reviewer asks a question, Critic forks the original agent session and forwards it there.

GitHub's guide suggests similar prompts you can use with any agent, for example: "When examining this code, what assumptions about business logic, design preferences, or user behaviors have been made?"

Best if: you're reviewing someone else's agent PR and need the why fast. Avoid it if: you plan to accept the agent's explanation as proof. An explanation is a claim. Checks 1 and 2 are the evidence.

5. Let scanners and an AI reviewer sweep every PR

Automated review covers what humans skip on a Friday: CodeQL for static analysis, Dependabot for vulnerable dependencies, license checks, and an AI pull request reviewer as a first pass. The Whiteboard team described their own split: an automated reviewer on small changes, with escalation to a human session when judgment is needed.

A worked example from the Claude Code team. On October 15, 2026 Anthropic published how the Claude Code team reviews code, and it's the most concrete public playbook we've seen. Here's the life of one of their pull requests:

1. Claude reviews every PR before a person does. It reads the diff against the whole repo and the PR's stated intent. When they launched the research preview, the share of internal PRs getting substantive review comments went from 16% to 54%.
2. Agents vote on findings. Several agents look for bugs at once, then a separate group votes on each finding, and it's only posted if enough of them agree it's real. Style and cleanup findings get dropped.
3. Security review can block the merge. A PR can't merge while any bug or security finding is still open. You fix it or close the thread with a reason.
4. Human approvals scale by risk. Low risk changes (docs, copy, additive changes behind a flag) need no human approval once automated checks are green. Ordinary product changes need one person. The highest risk paths need two. A classifier picks the tier from the change, not from the author.
5. Review rounds are capped at three. An agent author and an agent reviewer can keep each other busy indefinitely, so after three rounds the reviewer asks the author to rethink the approach.

Two files make it work. CLAUDE.md tells the reviewer what the project is. REVIEW.md, written by the code owners, says what failure looks like in that repo ("it lies" for docs, "it misroutes" for config), caps the nits, lists paths to skip, and asks for a file and line as evidence. Anthropic says the public version, Code Review for Claude Code, is now generally available on Team and Enterprise plans. Per the Claude Help Center (checked October 22, 2026), reviews are billed separately through usage credits, average about $15 to $25 each, and aren't available to organizations with zero data retention. Admins set each repo to Quick, Standard or Deep review. You can run /code-review locally, and /security-review covers the security pass. One detail from the Code Review docs: the local /code-review command reads CLAUDE.md but not REVIEW.md, so put rules you need in both places in CLAUDE.md.

The line that matters most for you: an agent's approval never counts as a person's. Automated review can clear a low risk change, but it can't fill a slot that calls for a human, and whoever directed the agent is on the hook for the code.

Best if: you want a floor under every single PR, including the boring ones. Avoid it if: it's your only gate. A model reviewing a model shares its blind spots, and Veracode's data shows security misses that have not improved in four years of releases.

A review order that works on a real agent PR

1. Run the tests and scanners first. If CI is red or a test disappeared, stop there and send it back.
2. Check every new dependency exists and is maintained. GitHub calls out hallucinated packages and "slopsquatting" by name.
3. Write your three invariants, then test them. Do this before reading code so the diff can't anchor you.
4. Look at the shape. Which files, which services, which decisions the agent made alone.
5. Ask the agent about anything surprising. Treat the answer as a lead to verify, not a verdict.
6. Read the risky lines yourself. Auth, payments, data deletion and anything that runs on a schedule.
7. Cap the back and forth. If you and the agent have gone three rounds on the same PR, stop patching and ask whether the approach is wrong. That's the limit the Claude Code team uses.
8. Match the human sign off to the risk. A docs change can ride on green checks. Auth, payments and anything a code owner marked sensitive needs a person, and a bot approval doesn't count as one.

This takes longer than "LGTM." It takes far less time than rolling back a release.

What this means if you're choosing how to learn

If you come from QA, IT support or data analysis, notice that four of these five checks are testing and systems thinking, not typing speed. That background counts. If you're changing careers from outside tech, our read is that reviewing agent output is becoming part of the job you're aiming for, so any path you pick has to make you ship code and get it critiqued, not just watch videos.

Three realistic ways to build the skill:

• Teach yourself with the docs. GitHub's review guide and the vendor launch threads cost nothing. Best if you already code and have a real repo to practice on. Avoid it if you've quit online courses before at the point where it got hard and no one answered.
• AI Flex. Self paced, with an AI tutor, a diagnostic test and a monthly plan you can cancel anytime. Best if you're a developer or an explorer who wants structure without a fixed schedule. Avoid it if you need a cohort and human deadlines to keep going.
• AI Engineering. A cohort AI engineering bootcamp where you build agents, RAG systems and production AI apps, with lifetime mentorship and career support. Best if you want the full path into an AI engineer role and support when you get stuck. Avoid it if you only want prompt tips or a weekend course.

Whichever you compare, ask one question of every program, ours included: will someone review the code I ship and make me fix it?

Which one should I pick?

Agents will keep writing more of the code. The skill worth building is saying, with evidence, whether it's safe to ship.