How to Use AI for Code Review

// In plain English

AI code review means having an AI model read a code change — a pull request, a diff, or a function you paste in — and give feedback on it: bugs, security gaps, style problems, unclear variable names, missing error handling. Think of it as a first-pass reviewer who never sleeps, has read every public code style guide, and finishes in under a minute.

There are two ways people use it. The first is automated PR review: a bot like GitHub Copilot Code Review or CodeRabbit installs on your repository and posts comments automatically every time a pull request is opened, using the full diff as context. The second is on-demand review: you paste code or a diff into Claude, ChatGPT, or a similar assistant and ask a focused question — "is there a race condition here?" or "what would break if this call fails?". The two approaches complement each other.

This is different from prompting a coding agent to write code (covered in How to Prompt a Coding Agent Effectively). Here you already have code and you are asking the AI to critique it. The output is comments and suggestions, not a finished file.

// Why it matters

Code review is one of the most expensive and slowest steps in shipping software. Reviewers context-switch, PRs sit open for hours or days waiting for feedback, and senior engineers spend significant time on routine catches that a machine could flag in seconds. According to the DORA 2025 Report, high-performing teams that adopted AI code review saw a 42–48% improvement in bug detection accuracy on their pre-merge checks.

The leverage is sharpest on three problems. First, catch-before-merge: a bug caught in review costs far less to fix than one caught in staging or production. Second, reviewer fatigue: when a human reviewer has to flag the same 15 style and safety patterns on every PR, they get bored and miss the subtle logic bugs. AI handles the repetitive patterns so the human can focus on intent, architecture, and edge cases that actually require thought. Third, team size asymmetry: a team of four cannot realistically review every PR with the same depth as a team of twenty. AI levels the floor.

There is also a security angle. Most security vulnerabilities in web applications — SQL injection, XSS, path traversal, insecure deserialization — are pattern-recognizable. A trained model can flag these consistently and immediately, even when the team has no dedicated security engineer.

// How it works

Automated PR review tools follow a consistent pipeline. When a pull request is opened, the integration pulls the diff, assembles a context payload (changed files, surrounding code, repository language and framework metadata, and any custom rules you have configured), sends that payload to an LLM, and posts the model's output as inline review comments under a bot identity. On each new push to the PR, the cycle repeats.

More advanced tools like Qodo (which introduced a multi-agent architecture in early 2026) run multiple specialized sub-agents in parallel: one for bug detection, one for security, one for code quality, and one for test coverage. Each agent focuses on its domain and posts findings independently, then a coordinating agent consolidates them.

On-demand review (paste-and-ask)

For on-demand use in a chat assistant, the model receives whatever you paste — a function, a diff, a whole file — plus your prompt. It has no access to the rest of your codebase unless you paste additional context. This is why on-demand review rewards targeted questions: "Is there an off-by-one error in this pagination logic?" returns sharper feedback than "review this file".

What context the model actually sees

Automated tools vary in how much context they gather. GitHub Copilot Code Review (GA since early 2025) runs on GitHub Actions and can access the full repository for context, not just the diff. Simpler integrations only see the diff itself. More context typically produces fewer false positives, because the model knows whether a function you changed already has a caller that validates input upstream.

// What AI catches vs. what it misses

Understanding the model's blind spots is the most important skill in AI-assisted review. Using AI well means routing work to it deliberately, not handing it everything and trusting the output.

The authorization gap deserves special emphasis. Research has documented cases where AI-generated apps had zero authentication on endpoints that exposed sensitive customer data, because the model had no way to know those endpoints required protection. The same applies in review: if an AI model only sees a diff that adds a new route, it can't flag a missing auth check unless the auth middleware is also in its context window.

// Prompting strategies for better reviews

Whether you're prompting a chat assistant or configuring a bot's system prompt, the structure of the request directly determines the quality of feedback. A vague "review this code" gets a generic response. A scoped, role-primed prompt surfaces real issues.

The four-part review prompt

1. Role: "You are a senior engineer reviewing a pull request for a production TypeScript API."
2. Focus areas: "Check for: (1) potential bugs or incorrect logic, (2) security issues including injection and auth, (3) missing error handling, (4) performance red flags."
3. Output format: "For each issue, state the line or block, what the problem is, why it matters, and a concrete suggested fix."
4. Approval condition: "If you find no critical issues, say so explicitly with a brief summary of what looks correct."

Asking the model to explain why an issue matters turns its output into a learning tool, not just a warning list. This is especially useful for less-experienced contributors who read the AI's comments as part of growing their skills.

Domain-specific security prompts

For security-sensitive paths, scope the prompt even further. Rather than a general security review, ask about the specific threat model: "This function receives a user-supplied filename and constructs a file path. Identify any path traversal or directory escape vulnerabilities and show how an attacker could exploit the current implementation."

You are a security engineer auditing a Node.js API.

Code under review:
<paste diff here>

Context: This endpoint is public (no auth required). It accepts a JSON body
from untrusted users and writes data to a PostgreSQL database.

Focus on:
1. SQL injection risks (even with an ORM — check for raw query interpolation)
2. Input validation gaps — what inputs could cause unexpected behavior?
3. Any data that reaches the database without sanitization

For each finding: quote the affected line, describe the attack vector,
and provide a corrected code snippet.

Configuring automated bots

Most automated tools (CodeRabbit, GitHub Copilot Code Review, Qodo) let you configure a custom system prompt or a .coderabbit.yaml / similar config file in your repository. Use this to inject your team's conventions: naming rules, banned patterns, required test coverage for new functions, and which paths are security-sensitive and need extra scrutiny. The GitHub awesome-reviewers project (open source) maintains a collection of ready-made system prompts organized by domain.

// Going deeper

Once you have basic AI review running, there are three directions to deepen the practice: improving context quality, layering in specialized security tools, and using AI review data to improve your codebase over time.

Improving context quality

The single biggest lever on review quality is how much of your codebase the model can see. For on-demand review, paste not just the changed function but also its callers, the type definitions it depends on, and the test file (if any). For automated bots, prefer integrations that index the full repository rather than operating only on the diff. GitHub Copilot Code Review's use of full-repo context (via Actions) is one reason it tends to produce fewer false positives than diff-only integrations.

Layering specialized security scanning

LLM-based review is not a replacement for dedicated static analysis security testing (SAST) tools like Semgrep, Snyk, or Checkmarx, which use rule-based engines tuned to specific CVE patterns and can run at the bytecode or AST level. The strongest pipelines layer both: SAST for known CVE patterns and rule-based checks, LLM review for contextual reasoning and novel combinations of issues that rules don't cover. Each catches what the other misses.

Using review data to improve the codebase

After a few months of AI-assisted PR review, you will have a log of every flagged pattern. Analyze it: which categories of issue appear most often? If null-pointer dereferences dominate, add a linter rule or a required utility function that enforces safe access. If the bot keeps flagging the same auth pattern on the same service, that service probably needs an architectural fix. AI review data is a diagnostic — treat it as one.

The human reviewer's evolving role

As AI handles the pattern-matching surface, the human reviewer's job shifts. The 2026 norm on high-output teams is that a PR description must answer: "What was the AI's role?" (e.g., "Generated first draft", "Refactored function X") and "What prompt was used?" Human reviewers then focus on what AI provably can't do: validating that the change solves the right problem, that it fits the system's architecture, that it handles the edge cases the product team cares about, and that it meets security requirements the model had no context for.