Stop Pretending to Review Code: How to Use AI Without Being Lazy

We all do it. PR comes in, it's Friday, you glance at it for 30 seconds, see no obvious red flags, and hit approve. Ship it. Then Monday morning: production bug.

AI code reviewers get trashed for being lazy, but the real problem is we're using them like they're the intern. They're not. They're the partner who stays late and catches stuff you're too tired to see.

The Real Strength: Catch What Your Brain Skips

Your brain has a limited attention span. By the 10th file in a review, you're pattern-matching instead of actually reading. AI doesn't get tired. It catches:

Inconsistent error handling you missed
Deprecated API usage that shipped in v2 of that library
Security patterns that look okay but are actually vulnerable
Performance regressions from O(n²) loops that snuck in
Accessibility issues in UI components

I tested this last month. Threw a PR through Anthropic's models, Claude Haiku specifically (because it's fast and accurate for this work). Found 6 actual bugs in 200 lines of Python that three humans had already reviewed. Two were security-adjacent. Not a good look.

How to Actually Use This

Step 1: Stop using AI as a replacement. Use it as a first pass.

1. AI reviews the code automatically
2. AI flags specific lines with reasoning
3. Humans read *only* the flagged sections + context
4. Humans make the actual judgment calls

This takes your review time from "pretend reading 500 lines" to "carefully read 50 lines." Game changer.

Step 2: Ask it to check for specific stuff.

Don't just dump code and ask "anything wrong?" Be specific:

"Flag any SQL queries that might be vulnerable to injection"
"Check error handling in async functions"
"Does this follow our performance standards? (< 100ms p95)"
"Any concurrency issues in this state management?"

Specific questions get specific answers. Vague questions get vague hallucinations.

Step 3: Train it on your codebase patterns.

If you're using a tool that supports context, feed it:

Your actual error handling patterns
How your team structures async code
What "good" performance looks like in your stack
Common mistakes you've made before

Suddenly it's reviewing code like someone who's been on your team for six months, not a generic code bot.

Tools Worth Your Time

GitHub Copilot for enterprise — Built into your workflow, understands repo context, reviews PRs natively. Easy win if you're already there.

Claude (via API or Claude.dev) — Paste code, ask questions, get detailed reasoning. Good for security-focused reviews or complex logic.

Devin (for bigger refactors) — If you're reviewing a major rewrite, Devin actually understands the arc of changes across files. Slower, but worth it for architecture reviews.

Local models — If you need privacy or have GPU budget, grab Ollama + CodeLlama. Runs locally, no API keys, no rate limits. Slower than cloud but zero latency for huge diffs.

What AI Can't Do (Yet)

Design judgment — "Is this architecture the right call?" still needs a human who knows your business
Taste — Code style, readability, maintainability. AI will enforce standards, not define them
Tradeoffs — "We could cache this, but it adds complexity." Requires context beyond the code
Ownership — Reviews still need a human who's willing to be wrong and own the decision

Real Example: Caught a Bug Yesterday

Had a Go service where we were deferring a database connection close. Looked fine. AI flagged it:

db, err := sql.Open("postgres", dsn)
if err != nil {
    log.Fatal(err)
}
defer db.Close()  // ← AI flag: "Close called before operations complete?"

Turns out if sql.Open succeeded but the first query failed, we'd close the connection before the context got finalized. Subtle. Would've been a Friday afternoon production incident.

Did AI know that? No. Did it know "closing database connections at module level can cause issues with context managers and deferred operations"? Yes. That's enough to make a human look closer.