When an assistant produces a large diff, ask for it to be split into smaller pull requests, review design before details, run the code, and check that tests fail when behavior breaks. Do not approve what you did not read. If you cannot read it, send it back.
Why large diffs are a trap
Models make big changes cheaply, but reviewer attention does not scale. Google's guidance tells reviewers to read every line of human written code assigned to them and to ask for clarification when they cannot understand it. A diff too large to follow breaks that rule in practice, and approval turns into a formality.
Step 1: ask for a split
Request separate pull requests for refactors, new features and test changes. Mechanical moves and renames can go in their own change so reviewers can skim them, and behavior changes get close attention. Smaller changes also get faster, better feedback.
Step 2: review design first
Google calls design the most important thing to cover. Before any line comments, ask whether the change belongs here, whether the interactions between components make sense and whether the timing is right. A design problem makes line comments wasted effort.
Step 3: look at the shape
Scan the file list. Unexpected files deserve a question, especially workflow definitions, dependency manifests and configuration. Check the dependency diff by hand, because some review bots do not read those files at all.
Step 4: run it
Check out the branch. Run the tests, then run the feature. Try one input you would expect to fail. A few minutes of running code finds problems that reading hides.
Step 5: check the tests
Google's question for tests is whether they will actually fail when the code is broken. Break the code under test in one or two places and see. Tests that only assert a function returns something are not protection.
Step 6: check complexity
Look for abstractions nobody asked for, helper layers with one caller and configuration for cases that do not exist. Google asks developers to solve the problem they know needs solving now. Ask the author to remove what is speculative.
Step 7: record what you did not review
If you skimmed generated fixtures or snapshots, say so in the review. An honest note lets the next person know where scrutiny was thin.
When to decline
If the author cannot explain the change, if tests do not protect it or if it will not split, decline politely. The standard is that a change should clearly improve code health, not that it arrived finished.
Quick check
What should you do with a thousand line AI generated diff?
Ask for it to be split by purpose, review design first, run the code and verify that the tests would fail on broken behavior.
Is it acceptable to approve code you only skimmed?
Not without saying so. Google's guidance expects reviewers to understand what they approve, so note any part you did not fully read.
Sources
- Google Engineering Practices, What to look for in a code review
- Google Engineering Practices, The standard of code review
- GitHub Docs, Copilot code review
Last reviewed: 19 October 2026.
