At a glance
Moving the SonarQube Remediation Agent to Claude Opus 5.5 improved every quality measure we track and cut the cost of each fix by roughly 58%.
- Issues fully resolved, no manual follow-up needed: up 11.9%
- Changes judged ready to merge as-is: up 15.8%
- Cost per fix: down about 58%
- Functional test pass rate: up 0.3%, so unchanged
- Wall-clock time per issue: up 4%
A cost cut that size usually shows up somewhere else, as more rework or more fixes that quietly break something. It was not here. Every quality measure improved, and the only figure that slipped was runtime, up 4%, which is small enough to read as flat.
What does the SonarQube Remediation Agent do?
The SonarQube Remediation Agent works on the backlog. You assign issues to it from the SonarQube Issues page, or set it to run on a schedule against your main branch. From there it works on its own. There is no prompting and no conversation.
The fixes themselves are written by an LLM, and it is your LLM rather than ours. You add an OpenAI or Anthropic API key to your SonarQube Cloud organization, up to three of them, and choose which key the agent uses. Sonar's remediation service sends the affected code snippet to that provider, so the request runs under your own account and your provider's usage agreement, and the inference is billed to you rather than bundled into your subscription.
What you pick is the provider. Sonar selects the model behind it and keeps that selection current, which is exactly what this post is about. On the Anthropic path, that model is now Claude Opus 5.5.
The part that matters most for this evaluation is what happens before you see anything. The agent generates a fix, applies it in a sandbox, and re-runs Sonar's analysis against the result. If the issue is still there, or the fix introduced a new one, that attempt is discarded and retried. Only fixes that clear the check become pull requests, which your team then reviews and merges through the normal workflow.
That loop is why model quality shows up in these numbers the way it does. A model that produces near-misses burns attempts inside the sandbox and eventually runs out of them, and from the outside that looks like an issue the agent did not finish. So the questions we ask of a new model are narrow. Did it finish the job? Would a reviewer take the result? Did it break anything? What did it cost?
Can an AI agent resolve SonarQube issues without human follow-up?
The share of issues the agent resolved end to end went up 11.9%.
Opus 5 left a small tail of issues it started and did not finish. Somebody had to go back through the run and pick those up. Opus 5.5 closes that tail, which means a run no longer needs a manual sweep behind it.
This is the result we care about most, and the reason is not subtle. An unresolved issue lands back on a person's desk no matter how fast or cheap the attempt was. Cost per attempt only matters once the attempt tends to work.
More fixes a reviewer can take as they are
This is where we saw the largest improvement, at 15.8%.
We want to be clear about how we measure this one. We are not counting how many pull requests reviewers actually merged. We score each change automatically against a single question: would a reviewer accept this as it is, or send it back for changes? That gives us the same read on every issue in the test, which counting real merges across real teams would not.
So we treat it as a strong indicator rather than a merge rate. What it tells us is that more of what the agent produces is not only working code, but close to the change a reviewer would have written themselves.
That is worth as much to us as the resolution rate. A fix that needs three rounds of review before it lands has already cost a team real time, whatever it cost to generate.
Does AI code remediation break existing functionality?
The functional test pass rate moved 0.3%, which is to say it did not move.
That is the point. Resolution rate and merge readiness both went up, and they did not go up because the agent started taking liberties with behaviour. The tests assert what the code is supposed to do, and they pass at the same rate they did before. The gains are real gains, not a quality trade dressed up as an improvement.
If this number had dropped while the other two rose, we would be having a different conversation about what the agent was actually optimizing for.
How much does AI-based SonarQube remediation cost per fix?
Average cost per fix came down roughly 58%, and that saving is yours rather than ours. Because the agent runs on your provider key, inference is billed to your own OpenAI or Anthropic account. A 58% reduction is 58% off your invoice, not off a number you never see.
Put that next to the higher resolution rate and the effective cost per successfully resolved issue falls further still, because a larger share of what you pay for now ends in a finished fix rather than a partial one.
The reason this matters is not the line item. It is that a 58% cut changes what you can reasonably do with the agent. At the old cost, running it across a large backlog was something you rationed and scoped carefully. At well under half that, pointing it at a whole backlog stops being a budget conversation. Teams with years of accumulated findings are the ones who feel this most.
What are the tradeoffs of using an AI agent for SonarQube remediation?
Average wall-clock time per issue rose 4%.
It is the only metric in the evaluation that went the wrong way, and we are calling it out rather than leaving it in a footnote. At 4% it reads as flat, and it is an easy trade for 58% less cost and better output on every other measure.
The one case where it would matter is a latency-sensitive path, where the agent is expected to return a fix inside a tight window. If that is how you plan to use it, this is the number to watch. For backlog work, which is most of how the agent gets used, 4% is noise.
What this means if you use the agent
Nothing changes in how you use it. The model behind the agent is our choice to make and ours to keep current, which is part of what you get from a managed agent rather than one you wire up yourself. You do not have to evaluate models, negotiate pricing, or migrate anything.
What changes is the economics, and with it the scope of what is worth attempting. More issues come back finished. More of the output is ready to merge. Each fix costs less than half what it did. If you previously looked at your backlog and picked the top slice the budget allowed, that calculation is different now.
We will keep publishing these evaluations as we move the agent between models. The Sonar LLM Leaderboard has our independent analysis of Opus 5.5 and every other model we measure, including the code quality and security profile of what each one writes from scratch. This post is the other half of that work: what a model does when the job is fixing code rather than producing it.
See what it does to your backlog
Every number above is measured on our benchmark. The one that matters to you is the one you get on your own code, against your own quality profile, in your own repositories.
If you already run SonarQube Cloud, the Remediation Agent is available through Sonar Agent Essentials on Team and Enterprise plans. Add a provider key, assign a category of debt from the Issues page, and the first verified pull requests arrive without anyone writing a prompt.
If you are not running it yet, the fastest way to judge it is to watch it work on a real codebase.
Request a demo · Learn more about the Remediation Agent · Read the documentation