The problem I was hired to solve
SonarQube's AI CodeFix feature was generating suggested code fixes — but developers weren't accepting them at the rate the team expected. The initial assumption was a quality problem. I was tasked with finding out whether that was true, and if not, what was actually going on.
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 at the right moment in their workflow — not as a standalone feature they had to go find. 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.
- In the agent-enablement study, admins generally understood the concept of choosing an AI provider — but the binding step confused almost everyone. Most interacted with the toggle before understanding what binding meant, and wanted a clearer multi-step setup flow.
- Different AI capabilities were bundled behind a single provider decision, which created anxiety: enabling one thing felt like enabling everything, without visibility into what was actually being turned on.
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 closer to where developers already work — especially in the IDE and PR flow — rather than building it as a web-first experience and hoping developers would seek it out.
- Directly informed the product direction for the next iteration of AI CodeFix, with specific recommendations on delivery modes, progressive disclosure, and admin setup clarity.