Approve an AI written pull request when it clearly improves the overall health of the codebase, even if it is not perfect, and reject it when it makes the code worse. That is the same standard Google publishes for human changes, and it needs no special case for bots.
The standard
Google's engineering practices say reviewers should approve a change once it definitely improves overall code health, and that there is no such thing as perfect code. Reviewers should not hold changes for perfection, and should reject those that worsen code health, with emergencies as the stated exception. Disagreements should be settled by seeking consensus and escalating if needed, not by letting the change sit.
Applying it to generated code
The author's tool does not change the test. A change is judged by what it does to the codebase. Ask:
- Does it solve the stated problem?
- Is the design sensible and does it belong here?
- Is it understandable by the next person?
- Are there tests that would fail if it broke?
- Is documentation updated where behavior changed?
Those questions mirror the list Google gives reviewers for design, functionality, complexity, tests, naming, comments and documentation.
Where AI authored changes need extra care
Volume and polish. Generated code often looks tidy, which lowers a reviewer's guard. Google asks reviewers to read every line of human written code assigned to them and understand it. If you cannot understand a block, ask the author to explain it. Whoever submits the change owns it, whichever tool produced it.
Over-building. Google warns against over-engineering and tells developers to solve the problem they know needs solving now. Models sometimes add abstractions nobody asked for. Ask for the smaller version.
What not to block on
Do not block on taste. Google says style points are governed by the style guide, minor points should be labeled as nits, and facts outweigh personal preference. If your objection is that you would have written it differently, approve it.
What to always block on
- A security flaw, even if the code is otherwise fine.
- Missing or meaningless tests for risky logic.
- Code the author cannot explain.
- New dependencies nobody has checked.
Make it routine
Put the standard in your contributing guide and apply it equally to everyone. Reviewers who know the bar can approve faster and with less friction, and authors know what to fix.
A short approval comment
When you approve, say what you checked. A line such as "ran it locally, tests fail when I break the parser, design fits the module" tells the author and later readers what the approval means. It also nudges reviewers to actually do those things.
Quick check
Should perfect code be the approval bar?
No. Google's standard is that a change should clearly improve code health, and perfection is not expected.
Does the author's tool change the review standard?
No. The change is judged on its effect on the codebase, and the submitter owns it.
Sources
- Google Engineering Practices, The standard of code review
- Google Engineering Practices, What to look for in a code review
Last reviewed: 19 October 2026.
