5 Types of Bugs AI Code Review Catches (That Slip Past Humans)
Manual code review is great. It's also exhausting. After reviewing 20 pull requests, your eyes start skipping lines. By PR 30, you're approving obvious bugs just to hit your backlog.
That's when AI code review becomes your secret weapon.
We built CodeHawk specifically to catch the bugs that humans miss when they're tired or moving fast. Here are five categories of bugs that AI reviews catch consistently — and why they slip past human reviewers.
1. SQL Injection and Injection Attacks
Why humans miss it: The code looks syntactically fine. The query has parameters. Your type checker is happy. But there's a subtle string concatenation you didn't spot.
// Vulnerable — string concatenation sneaks in
const query = "SELECT * FROM users WHERE email = '" + userInput + "'";
db.query(query);
// CodeHawk flags it: Injection vulnerability detected
// Safe: Use parameterized queries
const query = "SELECT * FROM users WHERE email = ?";
db.query(query, [userInput]);
Injection vulnerabilities are silent killers. They pass tests. They pass code review. Then someone uses a malicious input and your database is compromised.
CodeHawk checks for this pattern specifically: string concatenation with untrusted input in SQL queries, shell commands, and templating engines. It flags it as an error-level issue.
2. Null Pointer Dereferences and Logic Errors
Why humans miss it: The happy path works. But the edge case where value is null? That line is easy to skip on a scan.
// Vulnerable — assumes value is not null
function processUser(user: UserType) {
const email = user.email.toLowerCase(); // Crashes if email is null
return email;
}
// CodeHawk flags it: Potential null dereference
// Safe: Check for null
function processUser(user: UserType) {
if (!user.email) return null;
return user.email.toLowerCase();
}
These bugs only surface when code hits the edge case — and they're expensive to debug because the stack trace doesn't always point to the real problem. CodeHawk catches the pattern immediately: dereferencing a property without checking if the parent object is null.
3. Missing Error Handling
Why humans miss it: The code looks complete. But what happens if the API call fails? What if the file doesn't exist? The reviewer might not think to ask.
// Vulnerable — no error handling
async function fetchUserData(userId) {
const response = await fetch(`/api/users/${userId}`);
const data = await response.json();
return data;
}
// CodeHawk flags it: Unhandled promise rejection potential
// Safe: Handle errors
async function fetchUserData(userId) {
const response = await fetch(`/api/users/${userId}`);
if (!response.ok) throw new Error(`Failed to fetch user ${userId}`);
const data = await response.json();
return data;
}
Operations that can fail silently are the source of production mysteries. The function returns undefined. The caller doesn't handle it. An error appears downstream, and you spend hours backtracking.
CodeHawk checks for unhandled promise rejections, missing try/catch blocks, and unchecked return values from operations that commonly fail.
4. Promise and Async Bugs
Why humans miss it: Async code is hard to reason about. Even experienced reviewers can miss the subtle mistakes: missing awaits, fire-and-forget promises, race conditions.
// Vulnerable — promise is not awaited
async function saveToDB(data) {
db.write(data); // Missing await — function returns before save completes
return true;
}
// CodeHawk flags it: Unawaited promise
// Safe: Await the operation
async function saveToDB(data) {
await db.write(data);
return true;
}
These bugs create race conditions that are nearly impossible to reproduce in tests. They surface in production under specific timing conditions. Debugging them is a nightmare because the error happens in a different function than where the problem originates.
CodeHawk flags missing awaits, unhandled promise chains, and fire-and-forget async operations.
5. Off-by-One and Boundary Condition Errors
Why humans miss it: Loop indices are boring. You scan past them. But off-by-one errors are surprisingly common in list processing, pagination, and array indexing.
# Vulnerable — off-by-one error
def get_page(items, page_number, page_size=10):
start = page_number * page_size
end = start + page_size
return items[start:end] # page_number=0 skips the first item
# CodeHawk flags it: Potential boundary error in indexing
# Safe: Use zero-based indexing correctly
def get_page(items, page_number, page_size=10):
start = (page_number - 1) * page_size if page_number > 0 else 0
end = start + page_size
return items[start:end]
Off-by-one errors don't usually break code — they silently skip an item or include an extra one. Users notice first. Then you're debugging a subtle indexing issue while the feature is live.
CodeHawk analyzes loop bounds, array slicing, and pagination logic to catch common boundary mistakes before they hit production.
The Real Win
All five of these bug categories share something: they're not caught by linters or type checkers. Your code is syntactically correct. Your tests pass. But the bugs exist.
That's where CodeHawk comes in. It reads your PR diff the same way a senior engineer does — looking for the logical mistakes that your tools missed. And it does it in seconds, every time, without fatigue.
Try it free during beta: Install CodeHawk at github.com/apps/codehawk-crossgen. It's free to install — no credit card needed.
Your PRs will never look the same.