What is AI code review?

AI code review is the use of a large language model to read a code change, usually the diff of a pull request, and report problems in it: bugs, security risks, missing tests and hard-to-maintain code. It is fast and runs on every change, and it notices a different mix of problems than people do. It reads text rather than a running system and can be confidently wrong, so it works best as a structured first pass whose findings feed a gate and a human reviewer, not as a replacement for either.

How AI code review works

An AI reviewer is a prompt, a model and some context. The context is the part that decides how useful it is.

• The diff. The lines added and removed are the core input. A reviewer that only sees the diff misses effects on code it cannot see.
• Surrounding code. Better reviewers pull in the files the change touches, their callers and related tests, within the model's context window.
• The intent. The ticket, task description or pull request text tells the model what the change is meant to do, so it can spot code that does something else.
• Conventions. Style guides, architecture notes and earlier decisions let it flag drift from how the codebase normally works.

The output comes in two broad shapes. Some tools post free-text comments on lines of the pull request, like a human reviewer. Others return structured findings: each problem with a title, a severity, a category, a file and line, and a recommended fix. Free text is pleasant to read. Structured findings can be counted, filtered, triaged and used to make a decision.

Review also varies by how much the reviewer can do. A single prompt over the diff is the simplest form. An agentic reviewer can open more files, search the repository or run tools before it answers. A multi-pass review runs several prompts, for example one for correctness, one for security and one for test coverage, and then merges their results.

What AI review is good at, and where it fails

AI review earns its place through consistency. It reads every line of every change with the same attention, including the 600th line of a large refactor and the change pushed at the end of a long day. It is good at:

• local logic errors: unchecked nulls, off-by-one loops, inverted conditions, unhandled errors and missing awaits;
• common security patterns: string-built SQL or shell commands, missing input validation, secrets in code, unsafe deserialisation and missing authorisation checks on a new endpoint;
• gaps between code and tests, such as a new branch with no test that exercises it;
• naming, duplication and readability problems that people stop mentioning because they feel petty.

It fails in predictable ways:

• No business context. It does not know that a field is legally required, that a customer depends on an odd behaviour, or that the team agreed to a trade-off last quarter.
• No runtime view. It reasons about text. Race conditions, performance under real load and configuration that only exists in production are mostly invisible to it.
• False positives. It flags problems that are not there, sometimes with a convincing explanation. Reviewers who see too many stop reading.
• Non-determinism. The same diff can produce different findings on two runs.
• Limited context. Effects across many files, or deep in dependencies, can fall outside what it was given.
• Untrusted input. The diff itself can contain text aimed at the model, such as a comment telling the reviewer the code is safe. That is prompt injection, and a reviewer should be built to survive it.

AI code review vs human code review

The two are complements. Each covers ground the other handles badly.

The last two rows matter most. Review is partly a check and partly how a team keeps shared ownership of its code. AI review can take over much of the first job, but not the second.

Reviewing code that an AI wrote

When the author is itself an AI agent, review becomes more important and slightly different.

The volume goes up. Agents produce working code quickly, and people cannot read every line of every change with the same care. Review output has to be prioritised by severity, so a person can spend their attention on the few issues that matter.

Independence matters. A model asked to check its own output tends to repeat its own assumptions. A separate review pass, with its own prompt and ideally run after the code exists rather than over the plan, is more likely to catch what the author missed.

The thing reviewed should be the real diff. In many agent workflows, planning and discussion happen before the code is written. Reviewing a plan is useful, but it is not a review of the change. The findings that decide whether code ships should come from reading the code that will ship.

Turning review output into a decision

A list of comments is advice. To make AI review part of how you ship, its output has to drive a decision, and that needs a few rules:

• Structured findings with a fixed set of severities, such as critical, high, medium, low and info, and categories such as security, quality or test coverage.
• A blocking threshold. For example, open findings of high or critical severity block the change.
• Triage states. A person can mark a finding fixed, won't fix, a false positive or a duplicate, and that decision is recorded with their name.
• Fail closed. If the review crashed, timed out or returned something unreadable, the change has not been reviewed. A missing review must never count as a clean one.
• A record. Which findings were raised, who dismissed them and why, kept with the change.

That is what turns review into one input of a quality gate.

How to roll out AI code review

1. Pick the scope. Start with the repositories or kinds of change where a second reader adds most, such as services that handle money, authentication or personal data.
2. Require structured output. Ask for findings with severity, category, file and recommendation, in a format your tooling can parse. Reject answers that do not parse.
3. Set the blocking severity. Start strict only on high and critical findings. Lower the threshold later if the false positive rate allows it.
4. Define triage. Decide who may dismiss a finding and which states end its blocking effect. Record every change of state.
5. Treat a failed review as a block. Timeouts, model errors and unreadable answers hold the change until the review is re-run.
6. Keep a human approval. The AI review informs the person who approves. It does not replace them, and the author of a change should not approve it alone.
7. Measure and tune. Track how many findings get fixed and how many are dismissed as false positives. Adjust prompts, context and thresholds from that, not from impressions.
8. Keep the record. Store findings and triage decisions with the change, so an auditor or a future maintainer can see why it shipped.

How AI CodeOps does it

AI CodeOps reviews every code change made by its own AI sessions in two layers. Review agents inside the workflow, such as the Reviewer and the Security Auditor, look at the plan and the proposed change from different angles. Then, after the code is written, a separate findings review reads the actual diff, with the earlier review notes as context. Only that second layer produces the findings that can block the change. The steps of a workflow run one after another; nothing is decided by a vote.

The findings review must answer with a JSON array, and each item becomes a finding:

[
  {
    "title": "Coupon code is passed to the pricing query without validation",
    "severity": "high",
    "category": "security",
    "description": "applyCoupon() forwards the raw request value to the discount lookup.",
    "recommendation": "Validate length and characters before the lookup and return 400 on a bad code.",
    "filePath": "src/api/checkout.ts"
  }
]

A review records at most 12 findings. An empty array means nothing was found. An answer that is not a readable array, a review that fails, or one that runs out of time or budget, marks the run as not reviewed, and the change is held until it is re-run.

Open findings of high or critical severity, in the states open, acknowledged or in progress, block the pull request and a merge from the console. Marking a finding fixed, won't fix, false positive or duplicate ends its block, and the triage is recorded. A person then approves the change, and the person who started the session cannot cast that vote while someone else in the workspace can approve. A CI job can ask the same gate about a pull request with /api/release/check and set blockingSeverity to medium to block on medium findings too.

The review only covers changes made through AI CodeOps sessions, not every pull request in your repository. See AI code review for the product overview, Multi-agent reviews for how the passes fit together, and Quality gates for triage and the full gate.

Go deeper

• How to handle false positives in AI code review: why AI reviewers flag problems that are not there, and how to triage findings and tune the reviewer without hiding real bugs.
• How to review code written by an AI agent: what to read before the code, the mistakes coding agents commonly make, and how to keep approvals meaningful.