Codacy Review

Code review had a comfortable assumption behind it for twenty years: a person wrote the code, so a person understood it, and review was a second opinion on something already reasoned through.

Agentic coding breaks that. When an agent writes nine files in four minutes, nobody has reasoned through them — and the developer approving the pull request is reading code for the first time, at volume, under the same time pressure as before.

That makes automated review the primary control rather than a supplement, which is a genuine shift in what a tool like this is for. Codacy has repositioned around exactly that, and the interesting question is whether the repositioning is substantive or a change of wording.

What Does Codacy Enforce?

• Five security scan types in one platform: SAST, SCA for dependencies, secret scanning, infrastructure-as-code checks and DAST, alongside classic code quality analysis.
• It has repositioned around AI-written code — detecting AI policy violations and unapproved model calls, which is a genuinely new category of check.
• Codacy Guardrails embeds checks inside agentic workflows, so problems are caught as an agent works rather than after it has committed.
• It integrates where the code is: GitHub, GitLab, Bitbucket, VS Code, IntelliJ and Cursor, plus GitHub Copilot, Claude and Gemini.
• Audit-ready for SOC 2 and ISO 27001, with SBOM generation, a self-hosted option and a free tier for open source.

Why Does AI-Written Code Need Different Checks?

Codacy's newer capabilities — AI policy violation detection, unapproved model call identification, and Codacy Guardrails for agentic workflows — address problems that did not exist three years ago.

Unapproved model calls is the clearest example and the most immediately valuable. A developer or an agent adding a call to an external language model API introduces a data flow nobody reviewed: customer information may now leave your infrastructure, and the first time anyone notices is usually an audit. Detecting those calls in the codebase is a genuinely new class of check, and an obvious one in hindsight.

AI policy violations covers the organisational rules a company has now written and has no way to enforce — which models are permitted, what data may reach them, whether generated code needs marking. Policies without enforcement are documents, and most AI policies are currently documents.

Guardrails is the architecturally interesting piece. Embedding checks inside the agentic workflow means a problem is caught while the agent works rather than after it commits, and correcting an agent mid-task is far cheaper than reviewing and reverting.

The scepticism worth holding is that all of this is only as good as the policy you configure. A tool that enforces rules cannot invent them, and an organisation without a considered AI policy will get an enforcement engine with nothing to enforce.

This is why the pairing matters. A generator such as GitHub Copilot raises the volume of code entering review, and volume is precisely what a human reviewer handles worst.

When an agent writes nine files in four minutes, nobody reasoned through them. Review stops being a second opinion and becomes the first one.

Five Scan Types Beats Four Tools

Codacy covers SAST, SCA with insecure dependency detection, secret scanning, infrastructure-as-code security and DAST, alongside code quality, duplication, complexity and test coverage.

Consolidation matters here more than in most categories, for a reason that is about people rather than software. Each separate scanner has its own dashboard, its own findings format and its own noise profile — and developers respond to four sources of alerts by ignoring three of them.

One platform with one findings list, integrated into the pull request, is the difference between checks that change behaviour and checks that generate reports nobody reads.

Secret scanning deserves particular mention in the agentic context. Agents write configuration and test files, and a hardcoded credential in generated code is exactly the sort of thing that passes a quick human read. Catching it before merge is worth the whole subscription on the day it happens.

Where It Sits Determines Whether It Works

Codacy integrates with GitHub, GitLab and Bitbucket for version control, VS Code, IntelliJ and Cursor for editors, and GitHub Copilot, Claude and Gemini among AI tools, plus Jira, Slack, Docker, JFrog and Amazon ECR.

The editor integrations are the ones that change outcomes. A finding surfaced in CI after a push is a task; the same finding surfaced in the editor as the code is written is a correction. The cost of fixing a problem rises steeply with how long it has existed, and the editor is the cheapest possible point.

Including Cursor in that list is notable and current — it acknowledges that a meaningful share of developers now work in an AI-first editor rather than a traditional one, and a quality tool that does not run there is invisible to them.

The AI tool integrations imply something more interesting: checks that run against what Copilot, Claude or Gemini produce as they produce it, which is the Guardrails idea applied at the assistant level rather than the agent level.

The question to test is signal quality in the editor specifically. Inline warnings that are frequently wrong get disabled within a week, and once disabled they never come back.

Placement is the same lesson runtime tools like Sentry Seer learned from the other end: a finding that arrives where the work is happening gets fixed, and one that arrives in a weekly digest does not.

• Test the editor integration first, since that is where findings are cheapest to act on.
• Measure the false positive rate before rolling out — noisy inline warnings get switched off permanently.
• Confirm coverage for your actual languages, which the site does not enumerate.
• Check how findings appear in the pull request, because that is where the enforcement happens.
• Configure your AI policy before enabling policy checks, or there is nothing to enforce.

Compliance Is The Quiet Selling Point

Codacy states it is audit-ready for SOC 2 and ISO 27001 and generates SBOMs, with a self-hosted option available.

That combination addresses a problem most engineering teams meet for the first time during their first serious enterprise sale or funding round. A customer's security questionnaire asks how you ensure code quality, how you detect vulnerable dependencies, and how you know what is in your software — and the honest answer is frequently that nobody has documented it.

SBOM generation is the concrete part. A software bill of materials lists every component in your application, and it has moved from good practice to a procurement requirement in several sectors and a regulatory one in some jurisdictions. Generating it automatically from what is actually in your dependency tree beats maintaining a spreadsheet that is wrong within a month.

Audit-ready is a softer phrase and worth reading carefully: it means the tool produces evidence an audit would accept, not that using it makes you compliant. Compliance is a set of practices; this supports them.

The self-hosted option matters for the same buyers who need self-hosting anywhere — organisations where source code cannot reach a third-party cloud regardless of the vendor's own certifications.

Security-specific scanners such as Snyk Code go deeper on individual vulnerability classes. The trade you are making here is depth in one dimension against a single report covering five.

Trialling It Without Creating Alert Fatigue

The failure mode for any code analysis tool is not missing problems — it is finding so many that the team stops looking. A trial should be designed to avoid creating that on day one.

The bar is step three. A tool that produces four hundred findings on your existing codebase will be ignored, whatever those findings say.

1. Start with one active repository rather than your whole organisation. Enabling everything at once produces a wall of findings and a team that resents the tool.
2. Run it first in report-only mode against your main branch, and read the volume before deciding what to enforce.
3. Tune before you enforce: pick the small set of rules you would actually block a merge for, and turn the rest to advisory.
4. Test the editor integration on a real feature branch, and count how many inline warnings you would have acted on versus dismissed.
5. Enable secret scanning and dependency checks first, since those catch the highest-consequence problems with the lowest false positive rates.
6. Only then enable AI policy checks — and write the policy before you enable them, because the tool cannot invent your rules.

Trials, Tiers And The Open Source Exception

There is a 14-day free trial, a free tier for open source projects, and paid plans; amounts are not disclosed on the pages we read. A self-hosted option exists alongside the cloud platform.

Free for open source is a familiar and sound arrangement in developer tooling: it costs the vendor little, builds credibility where developers actually look, and converts when those developers reach a company that will pay.

In this category commercial pricing normally scales with contributors or repositories rather than with lines of code, so cost tracks team size. Self-hosting is usually licensed separately, and typically at a higher tier.

The company is headquartered in Lisbon, Portugal, which is worth noting for European buyers with data residency preferences, though hosting location is a separate question from company location and should be confirmed.

We do not publish amounts. Establish which languages your tier covers and whether the AI-specific checks are included at your level, since a newer capability is often gated to higher plans.