A developer describes a feature to an AI assistant in the morning. By lunch there is a 900-line pull request with passing tests and clean-looking code. When it is time for review, is there anyone on the team who can read those 900 lines and say "yes, this is right"?

Generating code now takes minutes. Reading it takes as long as it always did, so review is where the work slows down. AI tools can review a pull request too, but a person who understands the code should approve the merge. Small pull requests and tests written from the definition of the work are what make that practical.

Code that looks right can be wrong

Code from an AI assistant usually compiles, reads well and looks right at first glance. Wrong code and right code look the same on the surface. Even when the assistant misreads the request, it can produce code that looks consistent and careful.

Google's 2024 DORA report has a finding on this. According to the report, a 25% increase in AI adoption is associated with a 7.5% increase in documentation quality, a 3.4% increase in code quality and a 3.1% increase in code review speed. In the same data, as AI adoption increased, delivery throughput fell by an estimated 1.5% and delivery stability by an estimated 7.2%. The report concludes that speeding up development does not improve software delivery on its own unless teams keep to basics such as small batch sizes and robust testing.

In the same report, 39% of respondents said they had little or no trust in AI-generated code. Teams already treat this code with caution. A written review process turns that caution into something every reviewer applies the same way.

Small pull requests and tests that match the work

Because generating code is fast, it becomes easy to pack a lot into one pull request. A whole feature, a few refactors and some fixes made "while we were in there" all end up in the same change. Reviewing it either takes hours or ends with a skim and an approval.

Google's engineering practices documentation describes the right size as one self-contained change that addresses one thing. According to the guide, 100 lines is usually reasonable and 1,000 lines is usually too large, though the reviewer makes the final call. The number of files matters too: a 200-line change in one file might be fine, but spread across 50 files it would usually be too large. The guide says small changes are reviewed more quickly and more thoroughly, are less likely to introduce bugs and are simpler to roll back. It adds that reviewers can reject a change for the sole reason that it is too large.

For a team working with AI, this means splitting the work instead of asking the assistant for the whole feature at once: data model first, then the service layer, then the interface. When refactoring and behavior changes sit in separate pull requests, the reviewer can follow what changed and why. The person who made the change writes the description. If they start from the assistant's summary, they read and correct it first. Lock files, migration output and other generated files should be called out in the description so the reviewer knows where to focus.

The tests pass, but is the work right?

Google's guide says a small change should include its related test code. AI assistants make writing tests faster too, with one catch.

When the same tool writes the code and the tests from the same request, both can rest on the same assumption. If the assistant misunderstood the request, it writes the code with that misunderstanding and builds the tests to confirm the same behavior. The tests pass and the code still does not do what was asked, because a passing test only shows that the code agrees with itself.

To lower that risk:

  • Acceptance criteria first: The developer decides which input should produce which result before the code is written. The assistant writes tests against those scenarios.
  • Edge cases: Empty lists, zero, very long strings and unauthorized users appear in the tests explicitly. When a reviewer asks "which bug would this test catch?" there should be an answer.
  • The tests themselves: Tests get the same careful review as the code. A test that calls a function and only checks that it does not throw raises the coverage number but says nothing about behavior.

What should the reviewer look at?

Indentation, naming and formatting rarely cause trouble, since linters and formatters already catch them. Review time is better spent elsewhere.

First, intent: does the code solve the problem described in the issue or ticket? The assistant may have skipped part of the request or extended it with its own interpretation. Only someone who knows the work will notice.

Second, failure cases. Code that works on the expected path can break on a network error, a timeout, a missing field or the same request arriving twice. Check whether errors are silently swallowed and whether the logs would help during an incident.

Third, security. Check that user input is validated, database queries are parameterized, authorization sits in the right layer and no key or password has been written into the code. Tidy-looking code is no reason to skip these checks.

New packages

Dependencies are one of the easiest things to miss. An assistant can import a package that does not exist. In a study presented at USENIX Security 2025, researchers generated 576,000 code samples in Python and JavaScript with 16 different models. On average, at least 5.2% of the packages suggested by commercial models and 21.7% of those suggested by open-source models did not exist. In total the researchers found 205,474 unique hallucinated package names.

If someone registers one of those made-up names in a package registry and adds malicious code, a team that installs without checking pulls it into its project. When a pull request adds a new dependency, check that the package exists, who publishes it, whether it is still maintained and whether the project needs it.

Who approves?

AI does not only write code. It reviews code too. Tools such as GitHub Copilot can leave automated review comments on a pull request. Those comments can point the reviewer to places worth a closer look.

GitHub's own documentation says Copilot is not guaranteed to spot every problem, sometimes makes mistakes and should be supplemented with a human review. By default, Copilot's reviews do not count toward the required approvals for a pull request. That changes only when Copilot approvals are enabled in the repository, organization and enterprise settings.

Who approves can also be set in configuration. On GitHub, protected branches can require a set number of approving reviews before a merge. A CODEOWNERS file names the people or teams responsible for parts of the codebase. Their approval can be made mandatory for pull requests that touch those parts. On sensitive code paths such as payments, authorization or data deletion, this rule, together with branch protection, keeps an AI-written change from reaching the main branch without approval from the listed code owners.

A checklist for the pull request template

When the rules are written down, every reviewer looks at the same things. A list you can add to a pull request template:

  1. Does this pull request do one thing? Does the description say what changed and why?
  2. Which parts of the code were written with an AI assistant? This tells the reviewer where to look more closely.
  3. Are the acceptance criteria and edge cases covered by tests?
  4. Were user input, authorization checks and secrets reviewed? If a new dependency was added, were the package's existence and source checked?
  5. Has the person who opened the pull request read the code line by line? Can they explain it?

Item 5 may matter most. The person who opens the pull request owns the code, even if they did not type it. "The assistant wrote it that way" does not answer a reviewer's question. Whoever wrote the code, someone who understands it should approve it before it reaches the main branch.