AI Code Review in Practice: What Copilot, Cursor, and Claude Miss That Humans Catch
Most development teams now run some form of AI code review. Copilot comments on pull requests, Cursor flags problems while you type, and Claude can read an entire diff and produce a review that looks like a senior engineer wrote it. The output is convincing. Whether it is complete is a different question. After reviewing AI-assisted codebases for clients, we have a fairly clear picture of the AI code review limitations that matter in practice. The tools are reliable in some categories and consistently blind in others, and the boundary between the two is more predictable than most teams assume.
This post lays out both sides: what you can safely delegate to a machine reviewer today, and where you still need a person who understands your domain.
What AI reviewers catch reliably
The good news first. For a whole class of problems, AI review is faster than any human and rarely wrong.
Common security patterns are the clearest win. String concatenation into a SQL query gets flagged every time, in every tool we have tested. The same goes for unescaped output that opens an XSS hole, and for an endpoint that lacks an authentication check when every neighboring endpoint has one. These are patterns with thousands of labeled examples behind them, and pattern recognition is exactly what these models do well.
Obvious performance problems come next. An N+1 query inside a loop is caught almost every time, especially in ORM-heavy code where the shape is visually distinctive. Ask Claude to review a Doctrine repository class and it will often point at the missing join before a human reviewer has finished reading the file. A filter on a column with no index gets flagged too, provided the schema is visible in the diff or the surrounding context.
Then there is the unglamorous layer: naming that drifts from the conventions in the rest of the file, a method that returns null in one branch and throws in another, a dereference with no null check two lines after a nullable assignment. None of this is exciting. All of it used to eat human review time, and it no longer has to.
If your pull requests come back from a human reviewer full of comments about formatting and missing null checks, an AI first pass will raise the level of the conversation. That part of the promise is real.
The AI code review limitations we see most often
The misses are just as consistent as the catches. Five categories come up in nearly every audit we run.
Business logic errors sit at the top of the list. Picture a billing module where the refund path recalculates proration against the current plan price instead of the price the customer actually paid. Every line is clean. Types check, tests pass, the AI review praises the error handling. The bug only becomes visible if you know the company has grandfathered pricing, which no model can infer from the diff. Domain knowledge is not in the training data, and it is not in the context window either.
Race conditions are the second reliable blind spot. Two request handlers each read a row, check a condition, and write back. Reviewed one file at a time, both are correct. Run them concurrently against the same row and you get double-spent credits or a duplicated invoice. The defect does not live in any single line, so a reviewer that reasons locally over a diff has nothing to latch onto. In our audits of AI-assisted codebases, unprotected check-then-act sequences are among the most common serious findings, and we almost never see a tool flag one unprompted.
Authorization boundaries are the miss that worries us most. The endpoint authenticates the user, validates the payload, and then updates whatever record ID was sent. Copilot and Cursor will confirm that authentication exists and the input is validated. Almost never does a tool ask whether user 4711 should be allowed to modify invoice 8102, which belongs to a different tenant. This is how a user edits another customer's data through a perfectly legitimate endpoint, and it looks exactly like working code. It passes tests. It passes AI review. It is a breach waiting for a curious user.
Fourth: interactions between two individually correct changes. One pull request adds a file export feature. Another, weeks later, relaxes filename validation for a customer who wanted spaces in report names. Each PR is fine on its own, and each got a clean AI review. Together they allow path traversal. No diff-scoped reviewer, human or machine, catches this without knowledge of the other change, but an experienced human is far more likely to remember that the export feature exists.
Finally, architecture. A change can be locally correct and still wrong for the system: a synchronous HTTP call added to a hot request path, a new direct dependency from a module that was deliberately kept isolated, a cache introduced in front of data that must be read-after-write consistent. AI reviewers evaluate the code in front of them. They do not know which of your constraints are intentional.
Why the misses cluster where they do
There is a pattern in that list. Every reliable catch is visible within the diff itself. Every reliable miss requires context the diff does not carry: the domain, the concurrency behavior of the deployment, the tenant model, the history of adjacent changes, the architectural decisions someone made three years ago for reasons that were never written down.
A reviewer can only judge what it can see. Current tools see the changed files plus whatever context retrieval pulls in, and retrieval is good at finding similar code, not at finding the invariant your business depends on. Human reviewers carry that invariant in their heads. That, more than raw code-reading skill, is what a senior review actually consists of. It is also why the gap does not close just because the models get better at reading code. The missing information is organizational, not textual.
This matches what we find when auditing codebases built heavily with AI assistance: the code is often cleaner line by line than typical human output, while the defects concentrate in exactly the categories above. We wrote about the testing side of this in our post on AI-generated tests that hide bugs.
A workflow that uses both well
The practical answer is to assign each kind of reviewer the layer it is good at.
Run the AI review first, before a person looks at anything. Let it clear the noise: injection patterns, N+1 queries, style drift, null handling. Fix those findings before requesting human review, so the human never spends attention on them.
Then have a person review for correctness. The question at this stage is whether the change does what the ticket actually meant, and what happens at the edges. This is where the grandfathered-pricing bugs die, and it requires a reviewer who knows the product.
For code that touches authentication, authorization, payments, or data access, add a second, security-focused human pass. This is a small fraction of most changesets and it carries most of the breach risk. The reviewer should ask one question relentlessly: can a valid, authenticated user reach data or actions that are not theirs? In our experience this single habit catches more real-world vulnerabilities than any tooling investment of comparable cost.
One caution: do not let a clean AI review create confidence it has not earned. A green first pass means the obvious problems are absent. It says nothing about the five categories above, and treating it as approval is how teams end up shipping the authorization bug with a reassuring review attached.
Knowing what your reviews have been missing
If your team leans on AI review today, the useful next step is finding out what it has been letting through. That is a bounded exercise: an independent pass over the concurrency, authorization, and business logic layers of an existing codebase, which is the core of our code quality consulting work. For teams building new products with heavy AI assistance, we also fold this review model into custom software development projects from the first sprint, which is considerably cheaper than retrofitting it after an incident.
If you want a second pair of eyes on what your current review setup misses, write to hello@wolf-tech.io or have a look around wolf-tech.io. A short conversation about your stack and your review process is usually enough to tell whether an audit would pay for itself.