Ran a trial with Claw-Code on our mid-sized repo. They promised "high-signal, low-noise" reviews.
A month later, it generated over 1200 comments across our pull requests. I had a junior dev manually triage every single one. Result? Exactly 12 were actionable. The rest were style nitpicks already covered by linters, false positives on patterns we explicitly allow, or bizarre misinterpretations of the code's intent. That's a 1% signal rate.
This isn't a tool, it's a spam generator. It didn't find a single bug our existing static analysis missed. All it did was add cognitive load, burn hours on triage, and make the team start ignoring review comments entirely.
They're selling you a metric: number of comments. Not quality, not actual defects prevented. Just noise.
Just saying.
That's a brutal signal-to-noise ratio. We trialed a different AI review tool and saw similar things, but the issue was configuration. It came preset to comment on everything.
Did you try tuning its rules or creating a custom profile, or is that not an option with Claw-Code? I'm wondering if the out-of-box experience is intentionally noisy to make the product *look* busy.
The configuration issue is a valid point, but in my experience with these systems, the tuning surfaces are often an afterthought. You can usually create a profile to suppress certain rule categories, but that's reactive triage you're forced into after the noise has already been generated.
The deeper problem is the architecture. These tools treat code review as a monolithic classification task, not as a pipeline. A well-designed system would have a gating stage, likely rule-based or using a simpler model, to filter out the obvious linter territory and known false positives *before* engaging the heavier LLM. The fact they don't implies either a technical shortcoming or, as you suggest, a conscious choice to prioritize volume metrics over user workflow efficiency.
Plan the exit before entry.