How are you guys handling code reviews when a lot of the code is written by AI?

GitHub, Google, Anthropic's Claude Code team and one team that published its checks write down these changes between them. Keep pull requests small: Google's engineering practices guide says "In general, the right size for a CL is one self-contained change", and GitHub's docs say "Small, focused pull requests are easier to review and safer to merge." Run checks before a person reads the diff: GitHub's tutorial on how to review AI-generated code begins its first step with "Always run automated tests and static analysis tools first." Make the author explain the change: the Claude Code team's pull request template asks how the change was tested and how to undo it. Let an AI pass go first, with the limits its vendors write themselves, and keep a person on what your rules reserve for people.

Every fact below comes from the pages listed at the end, as I read them on 25 October 2026, and none of their authors saw this text before publication.

What teams change when agents write the code

Each row comes from the page named in it, read on 25 October 2026.

Smaller pull requests

Smaller pull requests give the reviewer one change to judge at a time. Google's engineering practices guide, which is about Google's own changes (it calls them CLs), puts the right size at one self-contained change, says "The CL should include related test code", and gives a range with a condition: "100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large, but it's up to the judgment of your reviewer." It sets a lower bound too, "The CL is not so small that its implications are difficult to understand.", and adds "Reviewers rarely complain about getting CLs that are too small."

GitHub's docs say "When a change grows large, consider splitting it into smaller pull requests that each serve one purpose." For changes that depend on each other, GitHub documents stacked pull requests: "Break large code changes into a chain of smaller, dependent pull requests you can review and merge independently." Review rules hold on each one, "Branch protection rules, such as CODEOWNER approvals, are enforced on every pull request in the stack", and the page lists agents among the places to use stacks, "For agents, via the gh-stack skill". Graphite's docs open with "Learn how to create, review, and merge stacked pull requests with Graphite." The Claude Code team ties size to ownership: "Changes are small, so they're easy to review, debug and revert."

Checks that run before anyone reads the diff

Machines go first, so the reviewer starts from a diff that builds. GitHub's tutorial says "Make sure the code compiles and all tests pass. Check for any new warnings or errors." For AI output it names what to look for: "Look for hallucinated APIs, ignored constraints, or incorrect logic.", "Watch for tests that are deleted or skipped, instead of fixed.", and "Check if suggested dependencies exist and are actively maintained." It advises "Set up CI checks for style, linting, security, code quality and code coverage."

A branch protection rule turns those checks into a gate: "After enabling required status checks, all required status checks must pass before collaborators can merge changes into the protected branch." On the Claude Code team, Claude runs the tests, build and linter before a pull request exists, and "Then a subagent reviews the diff with fresh context." On the pull request, required CI and a separate security review run, and "A PR can't merge while any finding from the bug review or the security review is still open."

Make the author explain the change

The first person to read an agent's diff can be the one who asked for it. GitHub's docs say "Reviewing your own pull request before asking others to review it helps you catch mistakes early." and "A self-review can include reading the diff, checking for accidental changes, and making sure relevant builds or tests have run." A template makes the questions routine: "When you add a pull request template to your repository, project contributors will automatically see the template's contents in the pull request body." If a tool drafts the description, GitHub's advice is "A generated summary can help reviewers understand the main changes, but you should review it carefully and add context that only you know."

The Claude Code team describes its own template: "The PR template asks how the change was tested and how to undo it. Claude can fill that in, but the person who asked for the change signs off on it." Its advice to other teams is to require CI and to add Testing, Risk and How to revert to the pull request template. Claude Code's best practices ask the agent for evidence instead of a claim: "Have Claude show evidence rather than asserting success: the test output, the command it ran and what it returned, or a screenshot of the result." GitHub's tutorial suggests writing your expectations down: "Use a CONTRIBUTING.md file in your repository to document your expectations for AI-generated source code and content". LLVM's AI tool policy asks contributors to "label contributions that contain substantial amounts of tool-generated content" and says "Contributors should note tool usage in their pull request description, commit message, or wherever authorship is normally indicated for the work."

Ahmet Zeybek describes on dev.to the checks his team added after an agent began opening many of its pull requests. The description declares the intended scope as a list of files or directories, and a CI check fails any file outside it; another check requires a non-empty section of behavior changes when certain paths change; reviewers read the code before the tests, because "A green suite written by the code's author is weaker evidence than one written by someone else, and with agents it's always the same author." Size has a hard limit: "The limit we settled on is 400 changed lines, not counting generated files and lockfiles, and a check enforces it." And the template says "by opening this PR you confirm you've read every changed line and can explain it."

An AI pass first, and what the vendors say it is not

On the Claude Code team, "Most changes have been reviewed and fixed by Claude at least once before a human is asked to look." Every finding of that review needs a reply: "Every finding has to be answered. You either fix it or resolve the thread with a reason." GitHub's tutorial suggests a similar step for your own team: "build a self-reviewing agent that evaluates draft pull requests against your standards, checking for accuracy, appropriate tone, and business logic before requesting human review."

The vendors of these passes write their limits themselves. GitHub on Copilot code review: "Copilot is not guaranteed to spot all problems or issues in a pull request. Sometimes it will make mistakes." and "Supplement Copilot's feedback with a human review." Anthropic on Claude Code Review: "Code Review uses AI to review code and may miss bugs, security vulnerabilities, or other issues. A review with no findings doesn't mean your code is error-free or secure." OpenAI on Codex: "Code review rules guide Codex; they don't replace tests, branch protections, or required approvals." Cursor on PR Routing & Approval, which "routes pull requests to the right reviewers and can approve low-risk changes": "It does not replace a full code review."

Sigma (Mnemoverse, the author's company), in closed beta, reviews pull requests on GitHub; its homepage calls it "A useful second look" and says "Sigma checks potential issues and brings the evidence back to your code." Its docs say a fresh verifier "confirms, rejects or reclassifies each one", that "only confirmed candidates are verified findings" while suspicions no verifier confirmed stay labeled separately, and that "A verification label is agent-produced evidence, not proof that the code is correct." Its docs also say "Sigma never merges." Sigma runs on Claude Code and OpenAI models. Teams can request access on its homepage, which says "A request does not grant access automatically."

Where a person still has to look

GitHub asks for the same review on pull requests from its own agent: "Copilot pull requests deserve the same thorough review as any contribution." Its approval rule keeps a second person in the loop: "If your repository requires pull request approvals, your approval of a Copilot pull request won't count toward the required number. Another reviewer must approve the pull request before it can be merged." CI does not start on its own either: "By default, GitHub Actions workflows will not run automatically when Copilot pushes changes to a pull request." GitHub's tutorial adds "Ask teammates to review complex or sensitive changes."

The Claude Code team lists what stays with people, among them "Reviewing risky code such as billing, the auto-updater and CI workflows." and reading the evidence: "If you can't say what the checks would miss, ask for a real review rather than a quick approval." Its advice includes "Add automated security review, and require every review thread resolved before merge." On GitHub, the branch protection setting for this is Require conversation resolution before merging, which "Requires all comments on the pull request to be resolved before it can be merged to a protected branch."

Sources and method

Each quotation was checked word for word against its page on the reading day.

Related on this account: Why does Codex keep finding new issues every time it reviews its own code?, on review loops.

Sources, all read on 25 October 2026; this text describes them as of that date. Google: Small CLs. GitHub: Review AI-generated code, helping others review your changes, stacked pull requests, pull request templates, protected branches, Copilot pull requests, approving with required reviews, Copilot code review. Graphite: overview. Anthropic: How the Claude Code team does code review, Code Review, best practices. OpenAI: Codex in GitHub. Cursor: PR Routing & Approval. LLVM: AI Tool Use Policy. Ahmet Zeybek: How we review pull requests that an agent wrote. Sigma: homepage, reading a review.