Automated Code Review

Overview

Linters catch formatting errors. Type checkers catch type mismatches. But what catches the logic bug where a developer checks for user.isAdmin when the field is actually user.role === 'admin'? What flags the SQL query that works in testing but returns wrong results when the production database has null values? Automated code review powered by AI agents operates at a level traditional static analysis cannot reach -- it understands intent, context, and the subtle ways code can be correct syntactically but wrong semantically. This lesson covers how to build review workflows that catch real bugs, not just lint.

Beyond Linting: What Agents Can Review

Traditional tools and agent-powered review occupy different layers of the quality stack:

The agent reviewer is not a replacement for linters -- it covers the gap between what machines have traditionally caught and what only humans could evaluate. The value is in understanding what the code is trying to do and spotting where it fails to do it correctly.

The Review Workflow

An effective automated review follows a clear sequence from trigger to posted comments:

Review workflow sequence: a pull request triggers the CI runner, which checks out the code and computes the diff. The runner sends the diff to the review agent for correctness analysis, then for security analysis, then for synthesis and prioritization. The agent returns consolidated findings, and the CI runner posts a review comment on the PR via the GitHub API.

The critical design choice here is dimensional separation -- running distinct review passes for correctness, security, and performance rather than asking one agent to cover everything in a single pass.

Why Dimensional Separation Works

When you ask an agent to "review this code," it produces a grab-bag of findings: some about naming, some about logic, some about style. The signal-to-noise ratio is poor. Dimensional separation solves this by giving each review pass a single focus area:

Dimensional separation: the PR diff fans out to three parallel reviewers — Correctness Review, Security Review, and Performance Review. All three feed into a Synthesis step that produces prioritized findings.

Each reviewer is a specialist. The correctness reviewer looks for logic bugs, off-by-one errors, null pointer risks, and incorrect assumptions. The security reviewer focuses on injection vectors, authentication gaps, and data exposure. The performance reviewer hunts for N+1 queries, unnecessary allocations, and algorithmic complexity issues.

A focused reviewer with a narrow scope outperforms a generalist asked to find everything. This is as true for agents as it is for humans.

Building a Correctness Review Prompt

The quality of the review depends entirely on the quality of the prompt. Here is a correctness review prompt that produces actionable findings:

Notice the structure: focus areas define what to look for, rules define how to report it, and context from CLAUDE.md gives the agent project-specific knowledge.

Building a Security Review Prompt

Security review requires different focus and expertise:

The key difference from the correctness prompt: the security reviewer must describe attack scenarios, not just point out code smells. "This input is not sanitized" is not useful. "An attacker could inject SQL via the search parameter because the input is concatenated directly into the query" is actionable.

The Synthesis Step

After dimensional reviews complete, a synthesis agent merges the findings:

Managing False Positives

The fastest way to kill an automated review system is to flood developers with false positives. When every PR gets a wall of non-issues, developers learn to ignore the output -- and then miss the one critical finding buried in the noise.

Strategies to control false positive rate:

• Raise the confidence bar -- tell the agent "only report findings you are confident about" and "if uncertain, skip it"
• Use CLAUDE.md for context -- many false positives come from the agent not understanding project conventions; CLAUDE.md eliminates these
• Filter by severity -- only post CRITICAL and HIGH findings as blocking comments; collect MEDIUM and LOW in a summary
• Track and tune -- when a finding is a false positive, note the pattern and add it to the review prompt as "do not flag X"
• Separate concerns -- style comments and genuine bugs should never be in the same review pass

False positive feedback loop: an agent finding is evaluated — if it is a real bug, it is posted to the PR for developer review, and the developer's fix-or-dismiss feedback improves the prompt. If it is a false positive, the team analyzes why, updates the review prompt, and the improved prompt produces better results next time.

An automated reviewer with a 90% precision rate is far more valuable than one that catches everything but is right only 50% of the time. Developers trust precision; they ignore recall.

Posting Results to Pull Requests

The final step is getting the review output where developers will actually see it -- on the PR itself. Use the GitHub CLI or API to post comments:

For richer integration, you can post inline comments on specific lines of the diff. This requires parsing the agent's output to extract file paths and line numbers, then using the GitHub review comments API to attach findings to the exact code they reference.

What Good Automated Review Looks Like

A well-tuned automated reviewer produces output like this:

CRITICAL -- Possible SQL injection in search handler src/handlers/search.ts:42 -- The search query parameter is concatenated directly into the SQL string. An attacker could inject arbitrary SQL. Use parameterized queries instead.

HIGH -- Missing null check on user profile src/services/profile.ts:18 -- user.profile.displayName will throw if profile is null. The database schema allows null profiles for newly created users.

It does not produce output like this:

Consider renaming x to something more descriptive.

You could use Array.map() instead of a for loop here.

This function is 40 lines long, consider breaking it up.

The first set catches bugs that would reach production. The second set is noise that wastes developer attention.

Summary

Automated code review with AI agents covers the quality layer that linters and type checkers cannot reach: logic bugs, security vulnerabilities, and architectural mistakes. The key to making it effective is dimensional separation (focused review passes for correctness, security, and performance), high-quality prompts that specify exactly what to look for and how to report it, and aggressive false positive management to maintain developer trust. A synthesis step merges findings into a prioritized report posted directly on the pull request. In the next lesson, we will explore how test-driven development gives agents something even better than review -- an unambiguous, machine-verifiable definition of success.