The brief
SonarQube Remediation Agent (SQRA) in the alpha stage was generating suggested code fixes for pull requests that failed the quality gate. But the acceptance rate of these fixes was really low. The initial assumption was a quality problem.
What I did
I ran a multi-study investigation across the full remediation experience:
- Acceptance rate investigation: Mapped how developers were evaluating suggested fixes ā what they looked at, what made them hesitate, and where they abandoned the flow.
- Workflow mapping: Documented how developers moved across SonarQube Cloud, SonarQube Server, PR analysis, and the IDE plugin, and where AI CodeFix appeared (or didn't) relative to their actual working context.
- Moderated usability testing: Tested the current CodeFix experience alongside future concepts ā including opening a PR directly, committing to the current branch, and viewing fixes inline in the IDE ā to understand which delivery modes felt natural and which created friction.
- Agent enablement study: Separately, validated the UX for enabling the AI agent at the admin level in SonarQube Cloud ā focusing on whether admins understood provider choice, agent binding, project scoping, and what actually happened when they toggled the feature on.
What I found
Fix quality wasn't the main problem. The core issues were about trust, timing, and control:
- Developers wanted remediation to appear 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 as this aligns with their everyday workflow.
- While enabling the agent, admins generally understood the concept of choosing an AI provider ā but the project binding step confused almost everyone. Most interacted with the toggle before understanding what binding meant, and wanted a clearer multi-step setup flow.
The decisions this enabled
- Reframed the acceptance problem for the team: this wasn't a model quality issue, it was a workflow fit and trust design issue ā which pointed to a completely different set of solutions.
- Gave the product team a clear brief for what setup flows, in-context education, and system state visibility needed to look like to make the experience feel safe and controllable.
- Strengthened the case for bringing remediation further left in the developer workflow i.e., IDE/terminal.
- Insights were scaled to another remediation feature the team handles i.e., AI CodeFix. Directly informed the next set of iterations with specific recommendations on delivery modes, progressive disclosure, and admin setup clarity.