An LLM reviewer earns its place when it catches the boring stuff a human skims past — missing null checks, a swallowed error, a test that asserts nothing — and stays quiet otherwise. It becomes a liability the moment it posts twelve comments per pull request, half of them restating what the diff already says. The difference is almost entirely in how you scope and gate it, not in which vendor you pick.
I've run LLM review on a few repos now, both hosted tools and a homegrown GitHub Action. The teams that kept it running past week two all did the same thing: they made the bot advisory, narrowed what it was allowed to comment on, and treated every false positive as a config bug to fix rather than noise to tolerate.
What can an LLM actually catch that linters miss?
Linters and type checkers already own the deterministic layer: formatting, unused variables, obvious type mismatches. An LLM is worth adding only for the fuzzy layer above that — the reasoning a static rule can't encode.
In practice the useful hits fall into a few buckets: error handling that looks fine but swallows or misclassifies failures, off-by-one and boundary logic in new code, tests that run green without actually asserting the behavior they claim to, and security-adjacent smells like unparameterized queries or secrets pasted into config. It's also genuinely good at "this function's name no longer matches what it does" — the kind of drift a human reviewer stops noticing after the third file.
