"AI code review" now covers at least five genuinely different products, and comparing them on price or speed is misleading because they do not detect the same class of problem. A tool that misses your bug is not a cheaper version of one that finds it.
Here is what each category is actually for.
The five categories
| Category | Catches | Structurally cannot catch |
|---|---|---|
| Linters (ESLint, Ruff) | Style, syntax, unused code, some unsafe patterns | Anything requiring understanding of intent or data flow across files |
| Static analysis / SAST (Semgrep, CodeQL) | Known vulnerability shapes, taint flows, injection patterns | Whether a missing authorisation check was intentional; correctness of business rules |
| LLM pull-request bots | Readability, naming, obvious defects, missing error handling | Consistency: the same defect may be flagged in one PR and missed in the next |
| Human review | Architecture, product intent, trade-offs, taste | Sustained attention across every line; degrades exactly where surrounding code is clean |
| Multi-specialist review | Security, reliability, performance and logic in parallel, graded by severity | Design intent and architectural judgement: it does not replace an engineer |
Why deterministic tools are necessary but not sufficient
Linters and SAST are excellent at what they do: fast, reproducible, no false confidence, effectively free. They should run on every commit and there is no argument for skipping them.
Their limit is structural rather than a maturity problem. A static analyser can see that a query concatenates user input and flag it, because that is a shape. It cannot see that an endpoint is missing an ownership check, because nothing in the code says which records belong to whom. To a parser, an endpoint that returns every invoice and one that returns your invoices are the same program.
Where LLM pull-request bots fit
These are a real improvement on nothing, and they are pleasant to work with: comments in-line, context-aware, often genuinely insightful about readability and structure.
The weakness is consistency. A single general-purpose model reviewing a large diff distributes attention unevenly, so the same category of defect gets caught in one pull request and missed in the next. For style feedback that is fine. For authorisation checks it is not, because a control that works 70 percent of the time is not a control. It is a source of false confidence, which is worse than no tool at all.
The category nothing automated catches by default
Business-logic errors. Code that is not defective, contains no vulnerability, passes every check, and computes the wrong answer.
If your discount should apply pre-tax and the implementation applies it post-tax, no tool in the first four categories will say anything, because there is nothing to say. The function is well written. It is simply not the function you needed. This is the failure mode that surfaces in a quarterly reconciliation rather than in an incident channel.
The only way to detect it is to supply the rule. Written down, in a sentence, so the reviewer can compare implementation against intent. That is why Nexdge takes business context as a first-class input rather than treating it as an optional field. It is the difference between reviewing code and reviewing whether the code does your job.
What to actually run
- Keep a linter and a static analyser in CI. They are cheap, deterministic, and catch a real class of problem on every commit.
- Add a review layer that receives your business rules, for the logic errors that are invisible to everything else.
- Keep human review for architecture and product decisions, and stop spending it on things a machine checks more consistently.
- Grade everything by severity so the pre-launch decision is a triage question rather than a reading exercise.
For the specifics of what to check in AI output before it ships, see the five-point checklist. For a feature-level comparison of Nexdge against other tools, the comparison page sets it out directly.