DEV Community: Codacy

How to secure AI generated code from prompt to pentest

Codacy — Wed, 05 Aug 2026 11:04:55 +0000

We ran a session with Jordan Constantine, Head of Offensive Security at WorkNest Secure. Codacy CTO Kendrick Curtis covered what goes wrong while the code is being written; Jordan covered what he finds when he's paid to attack it afterwards.

4 vulnerability classes in AI-assisted development:

Insecure dependencies and malware. Agents are insecure by default on versions: stale training data means they pull outdated packages, and the corpus over-represents older versions because that's what people wrote examples against. Ask the LLM to remediate and it swings to bleeding edge instead, which is its own risk. Add slopsquatting to that — typosquatting, except the model makes the typo, at scale.

The single highest-return fix in the whole session: set a minimum age in your .npmrc. Most malicious packages get flagged and pulled within hours, so 3 days of insulation removes the large majority of bleeding-edge dependency risk. One config line. For the other end — known-vulnerable older versions — you need a version database, which is the part we do; Verity runs our CLI inside the agent and corrects the version before it lands.

Malicious MCP servers. An MCP server is a wrapper around an API, which means it's a middleman in your code path on the developer machine and in production. Same threat model as a malicious package: exfiltrate what's on the machine and post it out. The fix isn't banning them, it's a curated allowlist committed somewhere developers can actually find, a process for adding to it, and scoped tokens per server so the blast radius is contained when 1 turns out to be hostile.
Prompt injection. You can now hack computers in English. On the dev machine it doesn't even need executable code — a text file inside a dependency instructing the agent to read your env vars and POST them somewhere is enough, because agents can't separate instructions from data. Containment is the answer: sandbox the agent, control what crosses the boundary, keep keys in a vault and only short-lived ones in env vars.
Unbounded agent permissions. Agents execute as you, with your permissions, including dropping to a terminal. The weekly "the AI deleted my production database" post is a permissions failure, not an AI failure. Read-only if it must have prod at all, or hand it a clone and review the script it writes.

Now from the attacking side:

How guardrails actually get bypassed. Not with zero-days in the safety logic. Role-play and pretexting, indirect injection hidden inside documents, task decomposition into a chain of individually harmless steps, and spacing/encoding tricks that reassemble server-side after a grammar pass. Structurally identical to XSS and SQLi filter evasion, different surface. The bypass goes around the guardrail, not through it.

Walkthrough 1: chatbot to password hashes. Well-configured web app, almost nothing else found. They asked the customer-facing chatbot which database tables it could reach and it answered dbo.Users. It gave a count of 60,000 but withheld the rows, so they asked what parameters the backend expected, learned it wanted a user ID, supplied their own test account's ID, and got the full record — including an MD5 password hash. With user enumeration also present, they could cycle accounts and pull hashes. No payload, no exploit.
*Walkthrough 2 *: LLM document ingestion to AWS credentials. Ingestion service on AWS, so SSRF against the EC2 metadata endpoint was the obvious target. Direct requests to localhost and the metadata IP were blocked. So they pointed it at a permitted external URL that redirected to the metadata endpoint, and the LLM followed. The response never came back directly — it got vectorized into the LLM's own document store — so they asked the chatbot what it had recently ingested, and it read the AWS credentials back out, reasoning that it could only answer from data in its context. High-privilege credentials.
Treat AI like infrastructure. Jordan's summary of what most teams get wrong: AI gets the access level of a service but the governance of a feature, usually because narrowing scope slows development down. Least privilege on the agent's token, human in the loop on a defined list of actions rather than everything, and incident response that works in hours — which means accepting false positives and deciding where you sit on usability versus security before it's an incident.
One from the Q&A worth repeating. When asked which AI-generated vuln is hardest to catch in review, Kendrick's answer was missing authorization on API endpoints - no token check, or no scoping of results to the requesting user. Scanners are good at things that are there and backed by a pattern or a database. Humans and tools are both bad at spotting the absence of something that should exist.

Best CodeRabbit Alternatives for AI Code Review & Code Quality (2026)

Codacy — Tue, 04 Aug 2026 20:37:17 +0000

The best CodeRabbit alternatives for AI code review and code security fall into three categories:

Dedicated PR reviewers like Greptile and Cursor Bugbot;
Coding assistants with review capabilities like GitHub Copilot, Gemini Code Assist, and Claude Code;
Enforcement platforms like Codacy that add codebase-wide security scanning, coverage gates, and compliance evidence.

CodeRabbit, Codacy, GitHub Copilot, Gemini Code Assist, Claude Code, Greptile, and Cursor Bugbot all help developers catch issues earlier in the change. But catching issues in an open pull request is a different job from enforcing quality and security across every repository, every branch, and the code that already shipped (like Codacy does).

I'll walk you through how to compare these tools by workflow coverage, review scope, security depth, and policy enforcement.

But first, how should engineering leaders compare AI code review tools?

The most useful way to compare AI code review tools is by operating model, not feature count, because nearly every tool on the market can summarize a diff and leave a comment. What separates them is whether that feedback holds consistently across repositories, branches, the IDE, and code that was written before the tool was ever installed.

Review quality: Does it catch real issues without burying developers in low-value comments?
Workflow coverage: Does it work in the IDE, CLI, PR, Git provider, and CI/CD?
Review scope: Does it evaluate only new changes, or the entire codebase continuously?
Security depth: Does it include SAST, SCA, secrets detection, IaC, DAST, and SBOM export?
Policy enforcement: Are rules centralized at the org level, or configured per repository?
Reporting: Does it produce trend data and compliance evidence, or only PR comments?

What are the main CodeRabbit alternatives?

The main CodeRabbit alternatives split into dedicated AI reviewers, coding assistants with review features, and unified enforcement platforms, and each serves a different role in the delivery workflow. This section covers Codacy, GitHub Copilot, Gemini Code Assist, Claude Code, Greptile, and Cursor Bugbot, all of which overlap with CodeRabbit somewhere in the review cycle but diverge sharply once you look past the pull request.

Codacy

Codacy is a code quality, application security, test coverage, and compliance platform that includes AI-assisted review alongside deterministic guardrails enforced across coding agents, editors, and pull requests.

Key capabilities:

AI-assisted pull request reviews and summaries
Repository-wide static analysis and code quality scanning
SAST, SCA, secrets, IaC, DAST, and container scanning
Test coverage tracking and quality gates
Organization-wide policies and compliance reporting
AI Inventory Detection of AI models, tools and MCPs

Where CodeRabbit focuses on reviewing developer-selected code changes across the IDE, CLI, CI/CD, and pull requests, Codacy extends into continuous repository-wide scanning, so a repository that has never had a pull request touched still gets scanned for vulnerabilities, complexity, and dependency risk.

That distinction becomes most valuable over time. Pull request review evaluates code at the moment it changes, but software risk doesn’t stand still. New CVEs, vulnerable dependencies, and policy violations can emerge long after code is merged. Continuous repository scanning keeps evaluating existing repositories as those risks evolve, even when there are no active pull requests.

Codacy connects to the repository, runs static analysis, security scanning, and coverage checks against the existing branch, and surfaces what has been sitting there unaddressed, which is precisely the scenario engineering leaders describe when they inherit acquired codebases or onboard a new service team.

Codacy also adds AI-powered PR summaries, fix suggestions, and local IDE scanning with agent handoff, so the developer-facing review experience is present, but it sits on top of a static analysis and security engine rather than replacing one.

GitHub Copilot

GitHub Copilot is primarily an AI coding assistant built for code generation, editing, and explanation, with AI-assisted pull request review as an added capability rather than its central purpose. Reviewing PRs is one feature inside a broader coding assistant rather than its primary focus.

Key capabilities:

AI code generation and editing
Chat and code explanation
AI-assisted pull request review
IDE integrations across Visual Studio Code, Visual Studio, JetBrains, and Neovim
GitHub-native development workflows

Organization-wide application security and policy enforcement live in separate GitHub products such as GitHub Advanced Security, not in Copilot itself, so teams evaluating Copilot for review purposes are really evaluating a convenience feature bundled with a developer assistant they likely already pay for.

Gemini Code Assist and Gemini CLI

Gemini Code Assist combines code generation, chat, and AI-assisted pull request review, making it Google's developer assistant rather than a dedicated code quality governance platform.

Key capabilities:

AI code generation and completion
Chat-based development assistance
AI pull request reviews
Gemini CLI for terminal-based workflows
Integration with Google Cloud and GitHub

Gemini CLI participates in agentic development loops, and CodeRabbit's own CLI integrates seamlessly with AI coding agents like Claude Code, Cursor CLI, and Gemini to review code as it's generated, before it ever reaches a pull request.

That framing is the right way to think about Gemini's role here: it matters wherever a team is using an agent to produce or modify code and needs an independent review step around that output, not as a standalone AppSec or governance layer.

Claude Code and Claude Code Review

Anthropic's Claude Code is an agentic coding assistant that runs from the terminal, designed to help developers generate, modify, and understand code directly in that environment.

Key capabilities:

Terminal-based coding agent
Local /code-review workflow
Multi-agent pull request review (Claude Code Review)
Repository-aware code understanding
Integration with CodeRabbit review workflows

Developers can run a local /code-review command before opening a pull request, and CodeRabbit's plugin for Claude Code creates autonomous AI development workflows where Claude Code can trigger CodeRabbit reviews directly through simple commands.

Claude Code Review extends that local workflow to GitHub pull requests using multiple specialized agents that analyze proposed changes against the surrounding codebase, prioritizing production-impacting issues like logic errors and security vulnerabilities over style nitpicks.

That combination makes Claude Code a genuine review alternative to CodeRabbit rather than only a generation tool, though its focus stays on the change in front of it rather than enforcing quality or security policy across every repository a team owns.

Greptile

Greptile is a dedicated AI code review agent focused on pull request analysis rather than code generation. Parallel agents review the changed code and post inline comments, and the tool adjusts what it flags over time as engineers approve or reject its suggestions, applying team-specific rules to shape what gets surfaced on future PRs.

Key capabilities:

AI pull request reviews
Repository indexing for broader context
Parallel review agents
Learns from developer feedback and reactions
Team-specific review rules

Cursor Bugbot

Cursor Bugbot is a dedicated AI reviewer built by the team behind the Cursor editor, aimed narrowly at catching real bugs and security issues inside a pull request rather than summarizing the change.

Key capabilities:

AI bug-focused pull request reviews
Inline GitHub comments
Automatic re-review on every push
Optional Autofix workflow
Designed for Cursor-based development teams

It posts inline comments directly on the diff in the Git host and re-checks the PR on every push, with an optional Autofix step that runs cloud agents to test changes and propose fixes on the PR itself.

It fits tightest for teams already living inside the Cursor ecosystem, but like Greptile, it finds and helps fix problems in the change without providing codebase-wide AppSec, coverage, or org-wide policy.

Tool	Primary role	Codebase-wide scanning	Security depth	Platform reach
CodeRabbit	AI PR reviewer	No (PR-focused)	AI review + integrated static analyzers	GitHub, GitLab, Bitbucket, Azure DevOps
Codacy	Quality, security, coverage, and AI governance platform	Yes	SAST, SCA, secrets, DAST, IaC, containers	GitHub, GitLab, Bitbucket
GitHub Copilot	Code generation + basic PR review	No	None dedicated	GitHub
Gemini Code Assist	Code generation, chat, PR review	No	None dedicated	GitHub
Claude Code / Code Review	Coding agent + multi-agent PR reviewer	No	None dedicated	GitHub
Greptile	AI PR reviewer with codebase indexing	Partial (indexed for context)	None dedicated	GitHub, GitLab
Cursor Bugbot	AI PR bug hunter	No	None dedicated	GitHub

Skill to unblock Pull Requests with one prompt (Tutorial)

Codacy — Mon, 27 Jul 2026 20:21:11 +0000

Now that coding agents have multiplied how much code gets written, code review has become the bottleneck for teams adopting agentic workflows.

With Codacy Skills, there's a new way to let coding agents like Claude handle that gruntwork to unblock pull requests faster, configure Codacy rules and settings, and even perform the code analysis locally pre-commit.

At its core, Codacy Skills teach coding agents to use the Codacy Cloud CLI and Analysis CLI to address a range of powerful (dare I say ‘revolutionary’?) use cases.

Installing the Codacy Cloud CLI and Skills

The Codacy Cloud CLI (@codacy/codacy-cloud-cli) brings Codacy data to the terminal: issues, security vulnerabilities, pull request analysis results, coverage metrics, configured tools and patterns, across GitHub, GitLab, and Bitbucket. The output is a table by default, or JSON when you want to pipe it somewhere.

It’s open-source and can be installed via npm. Once installed, log in to connect your codacy.com account.

npm install -g @codacy/codacy-cloud-cli

codacy login

Here's what you'll see in the terminal:

The Codacy Cloud CLI Skill instructs coding agents how to use the Codacy Cloud CLI. They work with Claude Code, OpenAI Codex, GitHub Copilot, and Gemini CLI through the Agent Skills standard.

Note: You can use the Codacy Cloud CLI with or without Codacy Skills installed. If you want to use the Cloud CLI manually, see our documentation for detailed instructions, commands and workflow examples. You can also embed the Codacy Cloud CLI as part of your CI environment for advanced workflow automations.

Use the snippet below to add the marketplace and install the Codacy Skills plugin for Claude (see instructions for other agents here):

claude plugin marketplace add codacy/codacy-skills

claude plugin install codacy-skills@codacy

Once installed successfully, you will see this:

Both the Codacy Cloud CLI and Codacy Skills are free to install on every Codacy plan. What the agent can act on still follows the Codacy features available on your plan (see our pricing page for more details)

You can now perform basic operations like adding your repositories to Codacy.

Now, let's get to the interesting bit. Below are our three favorite ways to use the codacy-cloud-cli skill like a pro.

Use case 1: Clearing a blocked PR in one prompt

Here is the case we built this for: a PR is failing the merge check. You can set up to six criteria to trigger your Codacy PR gate:

number of new issues introduced
number of security issues introduced
hitting the complexity threshold
hitting the duplication threshold
insufficient diff coverage (percentage of changed lines of code that are covered by tests)
overall test coverage drops.

Whichever is triggered, the PR comes back red. Normally you would open each finding, fix it, write the missing test, and re-run the analysis.

With the codacy-cloud-cli skill installed, you can hand the whole thing to Claude Code in one prompt:

Pull request 42 is failing the Codacy gate. Fix what's real, add the tests it needs, ignore the false positives with a reason, then re-run the scan.

The agent pulls the analysis and reads back everything that's blocking the gate, using the pull-request subcommand to return the annotated diff with new issues inline and uncovered lines marked.

codacy pull-request gh my-org my-repo 42 --diff

From there the agent fixes the genuine issues (applying Codacy's suggested fix where there is one, writing the rest itself), writes missing tests, refactors any duplicated blocks, dismisses the confirmed false positives with a logged reason, and re-runs the analysis to confirm the gate is green.

Quick disclaimer: The PR check may not go green on the first pass, but instead of scattering your code review and remediation efforts between agent, terminal, IDE and browser tabs, you get to triage your scan results quickly from a single place, in bulk, and against your existing coding standards.

Use case 2: Do a security sweep across the repo

The same pattern scales past a single pull request. Point the agent at the backlog:

Fix the critical and high security findings in this repo.

Your agent runs the lookup and reads the findings with their severity and CVE context, using:

codacy findings gh my-org my-repo --severities Critical,High

Findings can also be filtered by scan type (SAST, Secrets, SCA, IaC), status (Overdue, Due soon, On track). This allows you to pull detailed vulnerability reports and instant, scoped-out security audits.

Use case 3: Triage false positives, in bulk

False positives are where teams reviewing high volumes of AI-generated code lose the most time. Instead of dismissing them one by one in the UI, the agent clears them in a single command, with a reason attached:

Ignore all issues that are flagged as false positives and tag each with an ignore reason

Codacy flags which findings are likely false positives, so the agent acts on Codacy’s data rather than guessing. Here's the Cloud CLI command it uses:

codacy pull-request gh my-org my-repo 42

--ignore-all-false-positives

The reasons it attaches are logged, and become a record of why each call was made, which is useful feedback the next time you tune the repo's rule configuration (we’ll talk more about configuring Codacy rules in Part 2 of our Skills series, so stay tuned).

In the example below, this one prompt helped us reduce the issue density from 18.07 to 12.21 issues/kLOC.

One practical consequence (for your wallet)

Let me be precise about the division of labor: Codacy does not edit your code. Your agent does, using Codacy as the source of truth for what needs attention and as the check that the change actually worked.

One practical consequence: the analysis itself does not consume AI tokens.

Codacy's pull request review, including the AI Reviewer layer, is already included in every paid plan at a flat per-seat price. Your agent only consumes tokens for the edits you ask for, and nothing on the analysis underneath.

To get started, install the CLI and the skills from the Codacy Cloud CLI documentation, or read the source on GitHub.

Repository Instructions Are Engineering Artifacts. Treat Them Like It.

Codacy — Mon, 27 Jul 2026 20:02:21 +0000

Your team already treats CI config, dependency manifests, and policy files as things that need an owner, a review, and a drift check, because they shape the code you ship. Repository instruction files like CLAUDE.md, AGENTS.md, and .cursorrules now do the same job: coding agents read them to decide how to generate, modify, and review code. But most of them currently sit outside all of it and are edited like notes, owned by no one and reviewed by nobody.

That’s been allowed to happen because a stale instruction file doesn't break a build. It just keeps nudging an agent toward the wrong architecture layer, or a retired security pattern, across dozens of pull requests before anyone traces it back to the file.

Once a file shapes the code your team ships, it deserves the same discipline as the rest of your delivery system. Here's how to bring it under that discipline.

What Are Repository Instruction Files?

Repository instruction files are text or rule files stored in, or associated with, a source code repository. Depending on the tool and feature, AI coding assistants use them as persistent repository context when generating responses, editing code, reviewing changes, or working with the codebase.

The exact filenames depend on the tool and configuration. Current and legacy AI-assisted development workflows commonly involve files such as CLAUDE.md, AGENTS.md, .github/copilot-instructions.md, .cursorrules, or scoped rule files under directories such as .cursor/rules/. Some tools also support path-specific instruction files, where rules apply only to certain languages, folders, or file patterns.

The names differ, but the pattern is consistent: the repository can now contain instructions that influence AI-assisted development.

These files often describe the repository’s architecture, preferred libraries, testing expectations, coding conventions, build commands, security constraints, and workflow rules. A typical instruction file might tell an assistant which framework version the project uses, where API handlers live, how database migrations should be written, which test command validates a change, or which patterns are deprecated.

They can affect several parts of AI-assisted work:

Code patterns: The assistant may prefer certain abstractions, fo**lder structures, or implementation styles based on the instruction file.
Library choices: The file may steer the assistant toward approved packages or away from deprecated dependencies.
Testing behavior: Instructions may tell the assistant to add tests, run specific commands, or avoid brittle test patterns.
Security expectations: The file may describe input validation, authentication, authorization, logging, or secrets handling rules.
Architecture boundaries: Instructions may tell the assistant which modules can call each other, where business logic belongs, or which legacy areas require care.

This influence is probabilistic. AI assistants may interpret instructions inconsistently, ignore some guidance, or resolve conflicts in unexpected ways— Anthropic's documentation confirms Claude may pick arbitrarily when rules contradict. That uncertainty makes governance more important, not less.

A useful operator test is simple. If a junior engineer repeatedly followed a repo note when changing code, would your team care whether that note was accurate? Most teams would. They would want that note reviewed, current, and aligned with the way the system actually works.

The same standard should apply when an AI assistant reads the file.

Why Does Configuration Drift Matter for AI Instructions?

Configuration drift is a useful mental model for repository instruction files. The term already has a specific meaning in infrastructure and operations, so it should not be treated as an established industry label for AI instruction files. Still, the behavior is familiar enough to help teams reason clearly.

Configurations define expected system behavior. They evolve over time. They get copied between environments, repositories, or teams. They diverge from current standards. The divergence often stays invisible until something behaves unexpectedly.

Repository instructions can drift in similar ways.

An instruction file may say the service uses one testing framework even after the team migrated to another. A rule copied from a different repository may reference services, paths, or deployment assumptions that do not apply. A security note may reflect an old platform standard. Multiple instruction files may accumulate overlapping or conflicting guidance.

The visible file still looks harmless. The hidden issue is that outdated guidance can keep getting reinforced at the point where work is generated.

This matters because AI-assisted development changes the scale of repetition. DORA’s 2025 research found that AI adoption can improve throughput, often at the cost of software delivery stability when the underlying engineering foundation is week. A stale instruction no longer affects only the person who reads it once. It can influence many prompts, many edits, and many pull requests before anyone notices the pattern.

Early internal analysis from AgentLinter — scanning over 34,000 repositories — points to the same kind of hygiene problems engineering teams already recognize from other repo artifacts. Common findings include duplicate instructions, outdated references, missing version or update metadata, references to files that no longer exist, hardcoded secrets, and patterns that could enable data exfiltration. None of those findings mean every instruction file is risky. They do show that instruction files can develop the same operational decay as CI config, docs, policy files, and scripts.

The practical risk is quiet: unmanaged instructions become another source of hidden operational drift.

What Should Engineering Teams Review?

The first step in managing AI coding assistant repository instruction files is to review them through the same lens used for other behavior-shaping artifacts. A useful review covers ownership, scope, consistency, freshness, safety, and maintainability.

This does not require a heavy process. It requires making the implicit questions explicit.

Ownership: Every instruction file should have a responsible team or role. If nobody owns it, nobody will update it after architecture, testing, or policy changes.
Scope: The instruction should clearly apply to the repository, language, framework, or path it claims to cover. Broad instructions copied across services often create misleading guidance.
Consistency: Instructions should align with current security, testing, architecture, and code quality standards. If the instruction file says something different from CI policy, the team needs to resolve the mismatch.
Conflict handling: Instructions should define what happens when guidance conflicts. In many cases, the assistant should stop, ask for clarification, or follow a stated priority order.
Freshness: The file should not reference deprecated tools, retired services, old frameworks, missing paths, or former workflows.
Safety: Instructions should not encourage insecure patterns, bypasses, weak validation, disabled checks, warning suppression, or secrets exposure.
Maintainability: The file should be specific enough to help the assistant make better choices, but not so broad that it becomes noise.

Instruction files should also change through the same path as other important repo artifacts. A pull request should show the diff. The relevant engineering team should review it. Architecture or policy migrations should include updates to instruction files. Periodic repository checks should flag files that have not been reviewed in a long time.

The right standard is practical: if changing the file could influence generated code, the change should be visible in review.

Where Should Enforcement Happen?

Governance only works when it appears in the workflow. A policy document nobody checks becomes optional under deadline pressure. The same will happen with AI instruction hygiene.

There are several enforcement points, and each catches a different class of issue.

The IDE or editor is where AI assistance is often used. If teams can prevent bad patterns at the moment instruction files are created or edited, they reduce downstream cleanup. This applies to human-authored instruction files and agent-generated instruction files. Teams may also ask an assistant to generate repository guidance. That can be useful, but teams should avoid bad patterns from the moment those files are generated.

Local checks and Git hooks can catch simple issues before a commit. They are useful for file existence, naming, metadata, known unsafe phrases, references to missing files, or accidental secrets. They should not become the only control, because local checks are often bypassed or inconsistently installed.

Pull requests are the natural place to make instruction changes visible. A reviewer should be able to see when a repository-level instruction file changes, just as they would notice a CI workflow change or dependency manifest update. Teams can add review requirements for files that influence AI behavior.

CI/CD is where repository-wide consistency can be validated. CI can check whether instruction files follow expected structure, avoid unsafe guidance, include ownership metadata, and do not contradict known organizational rules. This is also where teams can generate compliance evidence that instruction governance is being applied consistently.

Periodic repository audits are important for organizations with many repositories. Teams of 50 to 150 developers often have enough repos to create fragmentation, but not enough security or platform bandwidth to manually inspect every file. An audit can identify which repositories use which instruction formats, where files have gone stale, and where copied rules have diverged.

Fragmented code security toolchains make this harder. Different teams may use different AI coding assistants. Different tools use different filenames and rule formats. Some teams may have repo-wide instructions while others use path-specific rules. Governance needs to reason about the pattern, not only one vendor-specific file.

The enforcement model should follow the artifact’s impact. If the instruction file shapes generated code, it belongs in the same workflow where engineering teams enforce quality, security, and change control.

How Should Teams Get Started?

The starting point should be small. Rather than large AI governance rollout to manage repository instruction files, most engineering teams need inventory, ownership, review, and a path to automation.

A practical starting sequence looks like this:

1. Inventory repositories that contain AI instruction files. Search for common filenames and rule directories across your organization. Include repo-level, path-specific, and local variants that may have been committed by accident.

2. Identify which AI coding tools and formats are in use. The goal is to understand the pattern across teams, not to force every repository into the same format immediately.

3. Assign ownership for each instruction file. The owning team should understand the repository’s architecture, testing workflow, and security expectations.

4. Require pull request review for instruction changes. Treat these changes like CI config, dependency manifests, or policy files.

5. Compare instructions against current engineering standards. Check whether the file reflects your actual test commands, approved dependencies, architectural boundaries, and security rules.

6. Remove copied or obsolete rules. A shorter, accurate file is more useful than a long file full of stale context.

7. Add automated checks where possible. Start with simple checks for secrets, missing references, outdated metadata, unsafe bypass language, and missing conflict-resolution guidance.

The key is to make these files visible and owned before trying to enforce every possible rule. Once teams understand which files exist and how they are used, enforcement can expand naturally through pull requests, CI, and periodic audits.

A useful working rule is to update instruction files during the same migrations that change the system. If a team changes test frameworks, updates architecture boundaries, retires a service, replaces a dependency, or changes security policy, the instruction files should be part of the migration checklist.

That habit can prevent a significant source of drift.

New productivity tools = new code health and security.

Codacy — Tue, 04 Nov 2025 18:48:56 +0000

You won't find me badmouthing coding assistants, but they are not like other productivity tools. They generate and modify source code, touch production systems, and can leak sensitive data or pull unverified dependencies.

But even though there's near universal AI adoption among devs, most orgs still don’t have clear AI usage policies in place.

It’s a new attack surface hiding inside our workflows, so naturally there needs to be different policies, governance, controls... whatever teams want to call it.

We created the AI Coding Risk Assessment for orgs to start taking a step in the right direction https://ai-risk.codacy.com/

If you worry your team's pipeline is filling up with risky AI code, this is for you. It's free and anonymous, of course.

Code quality engineer, Ask Me Anything

Codacy — Wed, 10 Nov 2021 16:34:21 +0000

Hey, our engineers are getting together to host a live #AMA about code quality and code reviews.

How important is this to Software Engineers? What are the main challenges? How can we achieve true code quality?

Ask us anything in the comments below and we'll discuss it live.

Join the discussion
🗓️When: November 16th, 5pm WEST
📍Where: Register here

Happy 8th birthday, Codacy! 🥳

Codacy — Thu, 28 Oct 2021 17:22:54 +0000

Once upon a time, our CEO Jaime was finishing his Master’s thesis about looking for clones in the code. The year was 2012, and from that moment, the idea for Codacy began taking form.

After discussions on the best path to follow, our company officially started in October 2013. Thus, eight years ago, we were on the road to shaping the automated code reviews world.

Step by step, Codacy has developed and gradually expanded. Fast forward to 2021, and we now support more than 40 programming languages and help developers save thousands of hours in code reviews and code quality monitoring.

Today, Codacy consists of 40+ highly motivated and passionate people who want to help developers ship better code, faster. And we’re always looking for the best to join our team!

Codacy in numbers

Wondering what 8 years of code reviews look like? Here are some numbers for the data-curious in you:

247 054 users have joined our platform;
77 305 organizations have been created;
425 205 repositories have been added;
588 552 671 commits have gone through Codacy.

If we look into a more recent time frame, since March 2021:

10 million issues have been found (yes, that many!)
4 million issues have been fixed by developers (yey to you!)

Looking back at the past 8 years, we couldn’t be happier with where Codacy is right now and where we’ll be in the future. We’re more than a platform for automated code reviews, software quality standardization, and tackling technical debt.

We’ve gone from helping developers ship quality code to also empowering organizations to reach full engineering potential! Have you tried our new product Pulse? Go check it out, but be advised: there is a serious risk that you might love it as much as we do.

8 lessons from the past 8 years

In the course of the last 8 years, we’ve evolved and accumulated experience. Each year made us grow and taught us incredible things that we now want to share with you. So here are 8 lessons that we’ve learned along the way.

#1 – Customers show us the path to success

It’s essential to have a clear vision for the future of our company and the products we want to develop. But let’s not forget that no company can survive without customers, so we need to listen to them carefully. Customers will tell us – both directly and indirectly – what will make our products successful and can even open doors to build a brand new product. In the end, understanding our customers allows us to craft outstanding products that they crave.

#2 – Empower customers with a community

When we created the Codacy Community Forum, our vision was clear. We wanted to foster a global community of developers who support, challenge, and inspire each other on the path to higher code quality. The community connects developers with our product experts at Codacy, and it’s a platform for networking, support, and fun. We also see it as a way to let our customers know that we hear their ideas and concerns. So, if you are not part of the community yet, what are you waiting for? Join the conversation today. See you on the other side!

#3 – Data is King, but action is God

As a company, we need to understand what is working and what needs improvement to adjust the course along the way. Establishing metrics and key indications will allow us to keep improving and adapting as we grow. However, agility and speed are everything. We can’t get lost in an endless cycle of data and analytics unless we incorporate them into an action plan.

#4 – Properly onboard new employees

Hiring the right people for the right job is enough, right? Wrong. We’ve seen that a solid onboarding process can help improve new hire retention and productivity. Plus, having a buddy or mentor system can go a long way. The mentor works closely with the new joiner and can explain how day-to-day tasks are done, introduce them to relevant people, and any other topic that might be important to the newcomer. Employee onboarding is the first experience a new joiner has as an official member of the company, and it’s all about embracing people from day one.

#5 – Improve communication and across teams collaboration

Good communication saves us time, reduces errors and misunderstandings, and creates a better work environment for teams to be successful. For communication to be effective, it involves active listening, asking powerful questions, and being honest but kind. Plus, the line of communication with leadership should always be open, and no one must feel that their opinions are not being heard. We’re generally used to the traditional top-down and bottom-up communication, but lateral collaboration across teams is also fundamental. This way, there is an alignment between teams, and we know we’re all rowing in the same direction.

#6 – Create a learning environment

We’re focused on building a culture that naturally embraces learning since continuous evolving is part of our core. We know that investing in people pays the best interest. That’s why we implemented the learning & development, a budget to enable personal growth that will make us evolve both as individuals and as professionals. We also foster opportunities for peer-to-peer learning with our weekly lunch-and-learn (everything’s better with food!), and we encourage a lifelong learning mentality.

#7 – Give employees flexibility

The COVID-19 pandemic confirmed our belief that time and space flexibility is the road to follow. We’ve always supported remote work, but we now have a remote-first policy. We maintain our office space because it is valuable as a work environment, collaboration zone, and social area. But we do not expect our team to work from the office, and we are focused on flexibility in lifestyle and schedule. We know co-location does not translate into better results or increased productivity. We encourage our teams to enjoy the environment that suits them best.

#8 – Working with friends is much more fun

We have a growing team of people with different backgrounds, skills, and ways of thinking. This diversity is what makes us great and helps us transform ourselves and the world around us. We enjoy getting to know each other, with our particular quirkiness, outside of the workplace. So, we organize team-building activities, have weekly happy hours and monthly board games sessions. A team that has fun together grows together.

A toast to you and the next 8 years

Our journey is just beginning, both for Codacy and for our incredible community. After 8 years of growth, we can’t wait for what’s in store for the next 8!

We want to thank you all: those who’ve been with us since day one, and those who are joining the Codacy community at this very moment. It’s because of all of you that we exist.

Don’t leave the party without your gift! This is your last week to get a 50% off* promo code when you sign up for a free trial. Grab it before it’s gone! 🎁

*50% off your first month when upgrading to Pro