AI Code Review for Pull Requests: What to Delegate and What Not

AI Code Review for Pull Requests: What to Delegate and What Not

AI code review for pull requests works best as a fast first read: it flags patterns that break team agreements, obvious bugs, missing error handling and missing tests before a person spends time on the change. Approving the change, understanding business context, judging architecture and weighing security risk stay with the human reviewer. To use it well, define what the AI comments on, what it never decides, and who is accountable for the merge.

Key takeaways

• AI is good at repetitive, detail-oriented reading: patterns, naming, common mistakes, forgotten edge cases and missing tests.
• AI does not know the business intent, the history of past decisions or the effect of a change on other systems. That is the human reviewer's job.
• An AI comment is a suggestion, never an approval. Formal approval of a PR should always come from a person.
• The diff is untrusted input: secrets, personal data and hidden instructions inside code or comments need clear limits.
• Start with one repository and one type of PR, measure whether the comments are useful, and only then expand.

What does AI review well in a pull request?

Human review gets tiring when a PR is large and full of mechanical detail. That is where AI helps, because its attention does not drop on the hundredth line. These categories usually pay off most.

• Patterns and conventions: inconsistent names, functions that are too long, duplicated code, unused imports, style that differs from the rest of the project.
• Obvious bugs: a wrong comparison, a variable used before it is defined, a condition that is never true, a resource opened and never closed, an error swallowed without a log entry.
• Edge cases: empty list, null value, accented text, dates in a different time zone, division by zero, unexpected input.
• Missing tests: a new code path with no test, an error branch with no coverage, a test that does not actually verify anything.
• Readability: a PR description that does not match the diff, an outdated comment, a function that does too many things.
• Basic security signals: a secret written into the code, a query built by string concatenation, a log line that prints sensitive data.

In these cases the gain is time and consistency. The human reviewer arrives at the PR with the noise already removed and can look at what matters.

There is one important limit: AI also makes mistakes. It can point to a problem that does not exist, suggest a change that breaks something else, or miss a real defect. Treat what it writes as a hypothesis to verify, not as fact.

What stays with the human reviewer?

Anything that depends on context outside the diff should not be delegated. The useful question is: does this judgment require knowing something that is not in the code? If yes, it is human work. For a broader view of that boundary, see what not to delegate to AI in business.

These stay with a person:

• Intent and business rules: does the change solve the right problem? Is the rule implemented the one the business agreed on?
• Architecture and technical direction: does the solution fit the system design, or does it create an unwanted dependency or debt nobody has taken ownership of?
• Impact on other systems: API contracts, queues, integrations, reports and routines that rely on the old behavior.
• Real security risk: authorization, data exposure, payment flows, database migrations, anything hard to undo.
• Compliance: handling of personal data under privacy law (LGPD in Brazil), retention, purpose and who can access what. AI can flag it, but the decision belongs to the company.
• The merge and deploy decision: whoever approves is accountable for what reaches production.

A simple rule helps: the harder a change is to reverse, and the closer it is to money, personal data or access, the more careful and independent the human review should be, whatever the AI comment says.

How to add AI to your review workflow, step by step

The design below is a proposed implementation, not a requirement of any particular tool. It works with assistants built into GitHub, GitLab or Bitbucket, and with custom agents. If you are still choosing a tool, the comparison of Claude Code, Cursor and GitHub Copilot for teams can help.

• Step one: pick one repository and one type of PR. For example, backend changes in a service with reasonable tests. Avoid starting with payment or authentication code.
• Step two: write the team's rules in a short document the AI can read: conventions, what is forbidden, what always requires a test. A repository instructions file does this job, as explained in how to write a good CLAUDE.md.
• Step three: define the AI's scope. It comments, summarizes and suggests. It does not approve, merge or change the branch without an explicit request.
• Step four: limit access. Read access to the diff and the files it needs, with no access to secrets, production or databases with real data. For tools that run on a developer machine, see Claude Code security: permissions, sandbox and secrets.
• Step five: ask for a fixed response format: a summary of what changed, risks found with file and line, suggested tests and questions for the author. A fixed format makes results easier to compare and measure.
• Step six: the human reviewer reads the AI comment after reading the PR, not before, so the AI does not steer the review.
• Step seven: record what happened. For each AI comment, mark whether it was useful, irrelevant or wrong. This log is the basis for adjusting the instructions.
• Step eight: review the rules after an agreed period and decide whether to expand, adjust or stop.

PR checklist for authors and reviewers

AI delivers more when the PR arrives well prepared. The author does the first part.

Author checklist before opening the PR:

• The PR has a single goal, and the description explains why, not just what.
• The size is reviewable. If it is large, it was split, or there is an explanation of why it could not be.
• There are tests for the new behavior and for at least one error case.
• No secret, key, token or real customer data appears in the code, the tests or the logs.
• Any behavior change visible to other systems is described.
• There is a rollback plan when the change is hard to undo.

Human reviewer checklist, after reading the AI output:

• The description matches what the code actually does.
• Each AI comment was read and either accepted, dismissed or answered.
• The business rule implemented is the agreed one, not just one that looks reasonable.
• Authorization and data access are correct for each user role.
• Personal data is used only for its intended purpose and does not end up in logs.
• Migrations, queues and integrations were assessed for ordering, retries and partial failure.
• The tests would actually fail if the code were wrong.
• If the AI said nothing, that was not taken as proof the code is fine.

Illustrative scenario: a discount rule in a PR

Illustrative scenario: an e-commerce team changes the function that calculates discounts for returning customers. The PR touches a few files and adds one new test.

The AI comments that the discount is applied after shipping in one place and before shipping in another, that the function does not handle an empty cart, and that the new test only covers the happy path. All three points can be verified in the code and save the first round of fixes.

The AI does not notice that the sales team agreed the discount must never stack with a campaign coupon. That rule lives in a conversation, not in the repository. The human reviewer, who took part in the decision, sees that the code allows stacking and asks for a fix. The reviewer also asks whether financial reports that read the final amount are still consistent.

The result combines both readings: the AI handled the mechanical detail, and the person handled intent and impact. Neither replaces the other.

What are the security and privacy risks of using AI on PRs?

The content of a PR is untrusted input. A code comment, a documentation file or the text of a dependency can contain instructions aimed at the model, such as telling it to ignore rules or approve the change. This is a case of prompt injection, described by OWASP, and the safe approach is to treat AI output as a suggestion that passes through human validation.

Practical points to watch:

• Secrets: set up secret scanning in the repository and keep the assistant from receiving environment files or credentials.
• Personal data: if the code or tests contain real data, sending it to an external service may have LGPD implications. Use fictional data in tests and confirm with legal or your data protection officer which repositories may be sent.
• Minimum permissions: the repository integration should be able to read and comment, and nothing more, with no permission to merge or change branch protection rules.
• Proprietary code: check the vendor's terms on how content is retained and whether it is used for training. That answer should come from official documentation and the contract, not from assumption.
• Traceability: keep a record of which model version and which instructions produced each comment, so you can explain a review later.

For the contractual question of who is processor and who is controller, the article on data controller vs processor in an AI vendor contract helps structure the conversation.

How to apply the method: map, limit, pilot, hand over

The same sequence used in other AI projects works for code review, without overdoing it.

Map: describe how review happens today. How long a PR waits, which comments repeat, where defects slip through. This is the baseline for knowing whether anything improved.

Limit: define what the AI reads, what it comments on and what it never does. No automatic approval, no access to secrets, no write access to the main branch.

Pilot: run it in one repository, logging useful and useless comments, with a metric agreed in advance, such as time to first review or the share of comments accepted. The article on how to measure an AI automation pilot covers decision criteria in detail.

Hand over: give the team the instructions, the log and the decision to expand, adjust or stop. From then on the team runs it, with periodic maintenance of the rules.

This describes a method, not a promise of results. The outcome depends on the quality of your tests, the size of your PRs and the discipline of the team.

Frequently asked questions

Can AI approve pull requests on its own? It is not recommended. Approving means taking responsibility for what goes to production, which requires business context and risk judgment. Use AI to comment and summarize, and keep approval with a person, especially for payment, access and personal data code.

Does AI review replace the human reviewer on small teams? It reduces mechanical work, which helps a lot when few people are available to review. But on a small team the risk of blind spots is higher, so a human reading of intent and impact is still needed, even if shorter.

How do I know whether AI review is worth it? Compare against the previous situation using a metric agreed at the start and the log of useful, irrelevant and wrong comments. If many comments are dismissed, adjust the instructions or narrow the scope. If defects keep slipping through at the same points, the problem may be in your tests, not in the review.

Can I send company code to an AI tool? It depends on the vendor's contract, the sensitivity of the code and whether the repositories contain personal data. Read the official documentation on data retention and use, remove secrets and real data, and align with legal before enabling the integration on sensitive repositories.

Sources

• OWASP: Top 10 for LLM Applications
• OWASP: prompt injection prevention
• Anthropic: Demystifying evals for AI agents