SonarQube Remediation Agent: Going from 0 to 1

My title is Staff Product Researcher — but across Alpha and Beta, I initiated this work, drove the decisions documented here, and took on product responsibilities well beyond a typical research scope. This page is my case for that.

The context

Sonar already knew where the code issues were. The objective was simple: fix them automatically, without breaking developer trust. SonarQube Remediation Agent (SQRA) was built to do exactly that: an AI agent that analyses code, reasons about fixes, and acts. This is the end-to-end story of how went through Alpha, Beta to get to General Availability. In Alpha, my work focused on getting the product experience right, and in Beta it was all about how we can grow the customer base for the product.

Results at a glance

"After 45 days of using it, we reduced 1,000 hours of debt." — Tech Manager at an Alpha customer

Phase 1 — Alpha: Why Weren't Developers Accepting AI Fixes?

The friction

SQRA was generating fixes for Pull Requests (PRs) that failed the quality gate. But the acceptance rate was well below expectations. The assumption was a quality problem. It wasn't.

What I found

The core issues were about trust, timing, and control:

• Developers wanted remediation as early as possible, even before the PR is created. Fixes surfaced at the wrong time felt like interruptions, not help.
• Hesitation came from uncertainty about what would happen after accepting a suggestion. How much effort would still be required? Would it break something? The experience didn't answer those questions.
• Developers wanted to test every fix until they felt comfortable trusting the agent — this aligns with their everyday workflow.
• Admins understood the concept of choosing an AI provider, but the project binding step confused almost everyone. Most interacted with the UI before understanding what binding meant, and wanted a clearer multi-step setup flow. This was a critical enterprise adoption gap.

The decisions this enabled

• Reframed the problem: this wasn't a model quality issue, it was a workflow fit and trust design issue pointing to a completely different set of solutions.
• Gave the team a clear brief: setup flows needed to be sequential and guided, the resolution summary needed to show what the agent couldn't fix, and project-level enable/disable was essential before org-wide rollout.
• Strengthened the case for bringing remediation further left — and it went live in CLI 1.0 🥳

Phase 2 — Beta: Why Weren't Customers Activating?

The friction

SQRA moved from Alpha into open Beta. But activation numbers weren't hitting the key results needed to go GA. The team asked: "why aren't people using it?" My question was sharper: "It's free to try. Why aren't people activating it in the first place?"

Adoption is linked to desirability. If customers don't want the capability, no amount of engineering investment fixes it.

What I found

Adoption wasn't low because of a single missing feature. The real problem was a stack of compounding friction:

• 12% of the TAM sample had accounts that were delinquent, about to churn, or don't have projects the remediation agent can support — proving targeting was too broad and the TAM needed revising.
• Customers found automated backlog reduction a more impactful use case than tackling issues on PR — the opposite of where the team had been focusing.
• Many eligible customers hadn't heard of SQRA — indicating lack of awareness and discoverability within the product and through the beta marketing campaign.
• Positioning was unclear, internally and externally. Customers and Sales had the same questions.
• Customers didn't want to try the agent without a price estimate first. Considerable internal effort is required to enable an AI-powered feature in enterprise. It was about the missing cost-benefit analysis.

The decisions this enabled

• Shifted the internal conversation from "why is usage low?" to "who are the right customers, and what conditions need to be in place before they'll convert?"
• The squad aligned on focusing upcoming efforts on automated backlog reduction.
• Built a live GitHub-hosted resource using Claude that gave Sales a reliable, always-current answer to the most common customer questions, reducing time to review.
• Established an evidence base for revising the TAM and success criteria as we prepared for General Availability.

If I ran this again…

• Run product market fit signal testing across multiple use cases in Alpha. We would've prioritized backlog reduction at launch, not as a follow-on.
• Push to ship a cost-benefit calculator before open Beta. Enterprise customers make activation decisions based on perceived cost, not features.