We've been running Codacy across a few Java/TypeScript repos for a year now. The initial promise was solid: automate the tedious parts of code review, catch security issues early. After 12 months, I'm here to say the comment quality is its biggest weakness, and it's actively creating more work for senior devs.
The core issue is a lack of context awareness. It flags things like:
* "Method is too long" on auto-generated API client code.
* "Use a parameterized query" on a string that's clearly not a SQL query.
* "Avoid using too many parameters" on a DTO constructor designed for library use.
These aren't edge cases; they happen daily. You end up with a PR flooded with 50+ comments, 80% of which are noise. The team starts ignoring all Codacy comments, which defeats the purpose. You then have to spend time tuning the rules per repo, which is a moving target as the tool updates its own rule sets.
Their "intelligent" filtering to reduce noise is inconsistent. One week it'll suppress a known false positive pattern, the next week an update brings it back. The security findings are occasionally useful, but you can't trust them blindly either—we've had critical severity flags on benign code patterns that their own docs couldn't justify.
The verdict? It adds overhead. You trade manual review time for manual noise-filtering time. For a team with strong senior reviewers who can write meaningful feedback, this tool currently slows you down more than it speeds you up. The value is only there if you have zero static analysis otherwise, and even then, prepare to curate heavily.
-- CRM Surfer
Your CRM is lying to you.
Your experience with the context problem, especially the parameterized query false positive, mirrors a fundamental issue in many static analysis tools that lack semantic understanding. It's not just noise; it's a risk factor. When a tool consistently cries wolf on non-issues, teams develop alert fatigue, and the one time it flags a genuine, subtle SQLi in an unexpected string builder pattern, it gets ignored.
This drift in their intelligent filtering after updates is particularly troubling from a compliance standpoint. If you're using Codacy to demonstrate due diligence for a control like SAST in an audit, you now have to document not just the tool's use, but the ongoing manual validation and rule tuning to justify its findings. That erodes the efficiency argument entirely.
Have you looked at implementing a stricter baseline profile and disabling categories like 'Code Style' for generated code paths? We found that treating it purely as a security linter, and suppressing everything else at the organization level, reduced the noise by about 60% but required constant profile management.
—at
Yeah, the rule tuning becoming a moving target is the real killer. We had to abandon their default rule sets entirely and lock into specific, older versions just to get stable behavior, which feels counterintuitive for a SaaS tool. It creates its own technical debt.
That inconsistency you mentioned with updates resurrecting old false positives is spot-on. We saw the same thing - it trained the team to assume any new Codacy comment in a previously-clean file was probably just the tool "forgetting" its settings again. Makes you lose trust fast.
Have you found any decent workaround for the auto-generated code issue, or do you just exclude those directories completely?
Automate the boring stuff.