AI For Code Review: The Good, The Bad, And The Security Risk

Have you ever opened a pull request, saw 38 changed files, and immediately wished someone had already summarized the risk for you?

That's where AI code review feels useful fast. It can scan diffs, explain changes, suggest tests, notice suspicious patterns, and help reviewers focus. Used well, it's a strong assistant.

Used badly, it becomes a very confident rubber stamp. And in security-sensitive code, a confident rubber stamp is worse than no stamp at all.

The Good: AI Is Great At First-Pass Review

AI can be excellent at the boring first pass.

It doesn't get tired after reading the tenth file. It can compare patterns across a diff, ask whether tests are missing, and explain unfamiliar code in plain language. That gives human reviewers a better starting point.

Think of AI review like a metal detector at the airport. It catches many obvious problems. It does not replace trained security staff.

What AI Review Does Well

1. Summarizes large diffs. It can explain what changed before you inspect details.
2. Finds missing tests. It can compare behavior changes against test coverage.
3. Flags suspicious patterns. SQL construction, unsafe deserialization, missing auth checks, and broad exception swallowing are good examples.
4. Improves readability. It can suggest names, smaller methods, and clearer structure.
5. Creates review checklists. It can tailor questions to the files changed.

Here's a practical review prompt:

Review this diff for:
- hidden behavior changes
- missing tests
- authorization gaps
- SQL injection risk
- unsafe logging of sensitive data
- race conditions
Return findings with file names and severity.

This doesn't guarantee perfect results. But it gives the reviewer a useful first layer.

The Bad: AI Can Sound Right While Missing The Point

AI review can be dangerously polished.

It may comment on naming while missing a broken permission check. It may suggest an abstraction that makes the diff larger. It may say "LGTM" because the code style looks good, even when the business behavior is wrong.

The problem is not that AI is useless. The problem is that AI feedback can feel complete when it's only partial.

Common AI Review Problems

1. False confidence. The model gives a clean answer without enough evidence.
2. Shallow comments. It focuses on style instead of behavior.
3. Context blindness. It misses hidden business rules outside the diff.
4. Security gaps. It may miss vulnerabilities that require domain knowledge.
5. No accountability. The tool doesn't own production incidents. The team does.

A bad AI review summary might say:

The changes look good. The code is cleaner and easier to read.
No major issues found.

That sounds nice, but it's not review. It's a polite shrug in a blazer.

A better AI review should say what it checked, what it could not verify, and what a human should inspect.

The Security Risk

Security review is where AI needs the strongest boundaries.

AI can help find vulnerabilities, but it can also miss them, misunderstand framework protections, or suggest unsafe fixes. It may not know your exact auth model, tenant isolation rules, logging policy, secret handling, or compliance requirements.

Security is like checking a lock. You don't ask someone to glance at the door and describe the paint. You test whether the lock actually holds.

High-Risk Areas For Human Review

1. Authentication. Login, sessions, tokens, password resets, and identity flows.
2. Authorization. Role checks, ownership checks, tenant boundaries, and admin access.
3. Data access. Queries, filters, exports, and object-level permissions.
4. Secrets. API keys, tokens, credentials, logs, and environment variables.
5. Input handling. SQL, shell commands, file uploads, serialization, and redirects.
6. Payments. Refunds, retries, webhooks, idempotency, and fraud rules.

Here's a risky PHP example:

public function show(Request $request)
{
    $sql = "SELECT * FROM reports WHERE id = " . $request->get('id');

    return DB::select($sql);
}

The issue is direct string concatenation in SQL. The safe version uses parameter binding or a query builder.

public function show(Request $request)
{
    return DB::select(
        'SELECT * FROM reports WHERE id = ?',
        [$request->integer('id')]
    );
}

AI might catch this. Static analysis might catch this. A human reviewer should still understand why it matters.

Combine AI With Deterministic Tools

The strongest review workflow combines AI, static analysis, tests, and human approval.

AI is good at language and pattern recognition. Static analysis is good at deterministic rules. Tests are good at expected behavior. Humans are good at judgment and accountability.

Don't make one tool pretend to be all four.

A Safer Review Pipeline

1. Static checks first. Run linting, formatting, type checks, and security scanners.
2. AI review second. Ask AI to inspect the diff and tool outputs.
3. Human review third. Focus on behavior, risk, and product correctness.
4. Approval last. Require explicit approval for sensitive areas.
5. Post-merge monitoring. Watch logs, metrics, and error rates after risky changes.

A simple CI step might look like this:

name: Review Checks

on: [pull_request]

jobs:
  checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: composer install
      - run: vendor/bin/phpunit
      - run: vendor/bin/phpstan analyse app

AI review should read these results, not replace them. If tests fail, the model's opinion is not the deciding vote.

Make AI Review Actionable

A useful AI review comment should be specific, grounded, and easy to verify.

Bad comment: "Consider improving security." Good comment: "ReportController::show() builds SQL using request input; use parameter binding to avoid injection."

That difference matters because reviewers need signal, not vibes.

Pro Tips

1. Ask for severity. Low, medium, and high help reviewers prioritize.
2. Require file references. Findings should point to specific files or lines.
3. Ask for uncertainty. The model should say when it lacks context.
4. Separate style from risk. Naming comments should not hide security issues.
5. Never auto-merge from AI approval. Human ownership stays human.

A stronger output format looks like this:

{
  "summary": "Short diff summary",
  "findings": [
    {
      "severity": "high",
      "file": "app/Http/Controllers/ReportController.php",
      "issue": "Raw SQL uses request input",
      "recommendation": "Use parameter binding"
    }
  ],
  "human_review_required": true
}

Structured output makes AI review easier to route, filter, and compare.

Final Tips

I like AI code review as a second set of eyes, especially on big diffs or unfamiliar code. I don't like it as an approval authority. There's a big difference between "help me review" and "review this for me."

My opinion: the best teams will use AI review to raise the floor, not replace the ceiling. Static analysis catches rules, AI catches patterns, and humans own the final judgment.

Use the assistant, keep the responsibility, and don't let pretty summaries replace real review 👊