AI in SonarQube: what do the new agentic features mean for developers?

2026.10.02

AI-based development tools have quickly become part of everyday development work. GitHub Copilot, Claude Code and Codex no longer just complete a few lines; they write complete features, refactor, create tests, hunt for bugs and, increasingly, carry out multi-step development tasks from start to finish.

At the same time, the question of what happens to AI-generated code once it has been written has become ever more important.

Faster code generation does not in itself solve problems of quality, security or maintainability. In fact, at higher development speeds these can pile up more easily if there is no adequate verification layer in the process.

SonarQube’s new AI and agentic features are essentially an attempt to address this problem. Sonar is not trying to build its own coding AI to replace Copilot or Claude Code. Instead, it is strengthening the layer that decides whether finished code meets the project’s quality and security requirements.

AI CodeFix: issues now come with a suggested fix

SonarQube’s classic way of working is simple: the analysis runs, the system finds the issue, shows where the problem is and explains why it should be fixed.

AI CodeFix adds to this the ability to suggest a concrete code change for the issue in question.

This is not the same as pasting an error message into a general-purpose AI assistant. The starting point here is the problem identified by SonarQube itself, so behind the fix there is already a static analysis result and the rule that goes with it.

This can be useful mainly for recurring or relatively well-defined problems. If, for example, a larger system has several hundred similar maintainability issues, the developer does not necessarily have to interpret each one from scratch and rewrite it by hand.

In SonarQube Server 2026.5, enterprise AI connections can also be managed centrally, and organisations can use their own model provider. This is particularly relevant in environments where it matters which external service the source code reaches.

MCP: when the AI agent sees more than just the repository

The MCP integration is a somewhat more important change.

With the Model Context Protocol, an AI coding agent can directly access certain SonarQube information. This means that, for example, an agent based on Claude Code or Cursor sees not only the source code but can also make use of the issues and other analysis results uncovered by SonarQube.

In practice, the difference is significant.

In the traditional process, the AI writes the code, the developer commits, and only later, in the CI pipeline, does it turn out what SonarQube has found.

With MCP, the analysis results can flow back more directly to the agent, which can respond to them while development is still under way.

This can cut out the unnecessary loop in which the agent produces a solution, CI rejects it, and the developer then manually hands the same problem back to the AI.

Vortex: more context for the coding agent

In larger codebases, one of the biggest problems for AI coding agents is not necessarily code generation itself, but finding the right context.

In a large monolith or a system made up of dozens of services, it is not a trivial question what uses a given class, where the implementation of an interface lives, which component needs to be worked with, or which project-specific rules apply.

Sonar Vortex is built around this problem.

Its aim is to help the coding agent navigate the codebase better and to give it information so that it attempts changes less “blindly”.

From a developer’s point of view, this is probably more important than it first sounds.

LLMs often produce poor solutions not because they cannot write the necessary code, but because they cannot see the wider relationships within the system clearly. A technically correct solution can easily be architecturally wrong, or simply not fit the project’s existing patterns.

Vortex tries to reduce this problem by providing the agent with more relevant project context.

Remediation Agent: fixing Sonar issues can be automated too

There is a fundamental difference between AI CodeFix and the Remediation Agent.

AI CodeFix suggests a fix. The Remediation Agent, by contrast, can carry out a more complete remediation process.

The starting point here is again a SonarQube issue. The agent makes the change, and the modified code then goes through SonarQube’s checks again.

This matters because an AI-generated fix does not in itself prove that the problem has actually been resolved.

From the development process’s point of view, the useful part is precisely that the check runs again after the fix.

This can be particularly interesting where there is a large amount of technical debt. In many systems, the biggest cost is not the complexity of the problems, but having to deal with hundreds or thousands of smaller issues one by one.

Some of these tasks may be good candidates for automated remediation.

Hunter Agent: searching for a different kind of security problem

The Hunter Agent targets a different area.

Classic static code analysis is very effective where a vulnerability can be recognised from specific code patterns or data flows. Many security problems, however, are not like that.

Faulty access control, for example, does not necessarily stem from a particular function being badly written. Every component may be correct on its own, yet a check is missing from the overall flow.

The same is true of certain authentication flaws and business logic vulnerabilities.

Sonar positions the Hunter Agent precisely for these more complex problems.

Here the role of AI is to examine a broader context and look for relationships that a traditional rule-based analysis would find harder to detect.

Importantly, Hunter does not replace traditional SAST. Rather, it appears alongside it as an additional layer of analysis.

Where does Advanced Security fit into all this?

Advanced Security is worth treating separately from the AI features.

SonarQube Advanced Security is not primarily a generative AI product, but an extension of security analysis.

One of its key elements is SCA, which examines the project’s external and open source dependencies. This covers, among other things, known vulnerabilities, transitive dependencies, licence issues and SBOM management.

The other important area is Advanced SAST, which can perform deeper analysis of data flows between your own code and external libraries.

This solves a different problem from the Hunter Agent or the Remediation Agent.

The goal of Advanced Security is to map actual security risks as accurately as possible. AI agents, on the other hand, can interpret additional context, produce fixes or look for problems where classic static analysis alone is not enough.

The two directions therefore complement each other rather than compete.

How might this change the development process?

The change will probably not happen overnight.

Until now, for many teams SonarQube has mainly been one of the checkpoints in the CI/CD pipeline:

commit, build, SonarQube analysis, Quality Gate.

In agentic development, however, verification can move closer to the development process itself.

A coding agent might, for example, make a change, request or receive SonarQube’s feedback, fix certain problems, and then check the result again. By comparison, the developer receives something much further along for review.

This does not mean that human code review disappears.

Rather, it is about separating the tasks that genuinely require a developer’s decision from those that the machine can reliably detect or even fix.

Review time is better spent on architectural, business logic or security questions than, for example, on manually fixing dozens of identical code smells.