Skip to main content

What is AI Code Review?

Introduction​

AI code review uses a language model to inspect code changes for likely bugs, security problems, missing tests, and violations of project conventions. It can run before a human opens the diff or alongside the human review.

Definition

AI Code Review

The use of an AI model to examine code changes and report possible defects, security risks, missing tests, and departures from agreed coding practices.

Code review depends on limited human attention. Reviewers can spend so much time finding missing null checks or forgotten error handling that they have less time to consider the design and product behaviour. AI can perform a quick first pass over every change, but it cannot replace a reviewer who understands why the change exists.

This article explains what AI review can find, what it tends to miss, and how to introduce it without filling pull requests with unhelpful comments.

Understanding the Concept​

An AI reviewer receives a diff, instructions, and sometimes related files from the codebase. It compares the change with patterns learned from code and previous review examples. This works well for familiar mistakes, but less well when the answer depends on business rules, undocumented decisions, or context outside the files it can see.

AI review is good at finding:

  • unchecked null or error values
  • common boundary and control-flow mistakes
  • familiar security flaws such as injection and unsafe input handling
  • changed behaviour without matching tests
  • duplicated code and departures from visible project patterns

It is less reliable at deciding whether the feature solves the right problem, whether the design will still make sense in a year, or whether a trade-off is acceptable for the product. Those decisions still belong to people with knowledge of the system.

Definition

False Positive

A review finding that reports a problem where no meaningful problem exists.

The useful model is a sequence of filters. Tests check known behaviour, AI review looks for recognisable mistakes, and human review checks intent, design, and risks that require wider context. Passing one filter does not make the others unnecessary.

Applying It in Practice​

Start with a narrow review goal. Asking an AI reviewer to find every possible improvement usually produces vague or low-value comments. Asking it to inspect changed input-handling code for security problems and missing error paths gives it a clearer job.

Useful findings point to a specific line, explain the failure, and describe when it occurs. “user.id is read before user is checked for null” can be verified and fixed. “Consider better error handling” leaves the author to rediscover the issue.

A common pull request flow is:

  1. The author or coding agent opens a pull request.
  2. Tests and static checks run.
  3. AI review comments on a small set of configured concerns.
  4. The author fixes or explicitly dismisses each finding.
  5. A human reviews the complete change and decides whether to approve it.

When AI reviews AI-generated code, use different instructions for generation and review. A reviewer asked to look for security and correctness problems approaches the change differently from an agent asked to implement a feature. The two models can still share the same mistaken assumptions, so human review remains necessary.

For a first rollout, choose one valuable category such as unsafe input handling or missing error handling. Run it on real pull requests for a few weeks, then remove rules that produce noise before adding more.

Engineering Considerations​

The benefit is earlier feedback on routine problems. Authors can fix simple issues before a human spends time on the change, while human reviewers can focus on behaviour and design.

The main cost is noise. If the reviewer posts too many irrelevant comments, authors learn to dismiss all of them. A small number of findings that are usually correct is more useful than a long list intended to be comprehensive.

Definition

Review Fatigue

The loss of attention that occurs when reviewers receive so many low-value findings that they begin dismissing comments without evaluating them carefully.

No findings does not mean the code is correct. It only means the reviewer did not recognise a problem within the categories and context it was given. The interface and team process should avoid presenting AI review as a pass or certification.

Manual use may be enough for a small team. A developer can ask for a second pass on a risky diff without installing a pull request bot or maintaining a CI integration. Automate it only when repeated use justifies the setup and tuning.

Scaling and Operations​

Track which findings are fixed, dismissed, or ignored. A high dismissal rate usually means the instructions are too broad, the reviewer lacks project context, or a rule is not useful for that codebase.

Decide how AI comments affect merging. Requiring authors to resolve or explicitly dismiss each finding keeps the process clear. Sending findings to a separate dashboard usually makes them easier to ignore.

Review the data policy of any external service before sending it private code. Diffs may contain proprietary logic, internal architecture, personal data, or credentials committed by mistake. Check how the provider stores prompts, retains code, and uses submitted data.

Keep human ownership explicit. The person approving the change remains responsible for understanding it, regardless of how many automated checks ran first.

Next Steps​