Checking AI-written code with SonarQube AI Code Assurance

Picture a developer at a 20-person software house in Petaling Jaya who asks a coding agent to add a CSV export to the customer portal. Twenty minutes later, there is a 600-line pull request. The tests pass. The reviewer has three other pull requests waiting, skims the diff, and approves it.

The reviewer missed two things. The agent pulled in a new package to parse dates, and it built one database query by pasting user input into a string. Injection flaws like that query are one of the things Sonar recommends AI code be checked for.

SonarQube AI Code Assurance is how Sonar handles this. You label a project as containing AI-generated code, and SonarQube holds it to a quality gate built for AI-written code. A quality gate is the pass or fail check SonarQube runs on every analysis.

Below are the six conditions that gate enforces, starting with the one most likely to block your team in week one. Sonar's AI features change quickly, so everything here is as Sonar documents it in September 2026.

Why AI-written code needs its own gate

Sonar's default quality gates were designed around human developers, and AI makes mistakes in different places. Sonar's documentation says the traditional gates "were tuned for human developers", and that AI "often does better where humans fail but fails in areas that humans tend to do well".

Two academic studies point the same way, with caveats:

• In a 2021 study, researchers at New York University asked GitHub Copilot to complete 89 tasks tied to high-risk security weaknesses. Of the 1,689 programs it produced, they found "approximately 40% to be vulnerable".
• In a 2022 Stanford user study, people with an AI assistant "wrote significantly less secure code than those without access". They were also "more likely to believe they wrote secure code".

Both studies tested 2021 and 2022 models, and the NYU prompts were deliberately security-sensitive. Neither gives you a defect rate for your team today.

The second finding is the one to plan around. The developer who used the assistant was more confident in code that was less secure. That confidence arrives in the pull request with them.

Interest in AI code review has grown quickly, but a reviewer only forms an opinion about the diff. The gate decides whether this pull request can merge, using the same written conditions on every pull request.

What SonarQube AI Code Assurance does: label, gate, status

In Sonar's documentation, AI Code Assurance is made of a project label, a quality gate qualified for AI code, and a status badge you can publish. None of it asks a model to review your code.

1. Label the project. In Project settings, under AI-generated code, switch on "Contains AI-generated code". SonarQube Server 2026.1 can still detect AI code automatically from GitHub Copilot usage, but that feature is deprecated and will be removed, so plan on labelling projects yourself.
2. Apply a qualified quality gate. The project must use a quality gate marked as qualified for AI code. You can use Sonar's built-in gate. You can also copy it, change the conditions, and qualify your copy from the gate's Actions menu.
3. Check the status. A labelled project on a qualified gate shows its AI Code Assurance status on the Projects and Overview pages. A labelled project on an ordinary gate shows only the label.

Step 3 is the useful one for a team lead. A project marked as containing AI code but still on an ordinary gate is visibly not assured.

On SonarQube Server, AI Code Assurance appears in Sonar's feature table for the Developer, Enterprise and Data Center editions. Sonar's tooltip says it "Ensures AI generated code is fully understood and verified before reaching production". If you are not sure which of those editions your team needs, see our guide to SonarQube Community vs Developer vs Enterprise.

The "Sonar way for agentic AI" quality gate, condition by condition

Sonar's built-in gate for AI code is called "Sonar way for agentic AI". It replaces the older "Sonar way for AI Code" gate, and projects still on the old gate are now marked legacy. Sonar says it is for teams where "AI agents are generating or modifying code", and that it is meant to balance protection with development speed.

It enforces six conditions, all on new code only. New code means code recently added or changed; in a pull request, it is whatever the pull request changes.

• Reliability: no new reliability issues (bugs) at Low severity or above.
• Security: no new security issues (vulnerabilities) at Low severity or above. The pasted-string query from the opening is the kind of issue this condition is there to fail.
• Maintainability: no new maintainability issues at Medium severity or above.
• Dependencies: no new dependency risks (risky third-party packages) at Low severity or above.
• Coverage: at least 80% test coverage on new code.
• Duplication: no more than 3% duplicated lines in new code.

Two of these deserve a closer look before you switch the gate on.

Dependencies. Sonar's reasoning is that "agents may autonomously install packages without manual vetting". If the date package in the opening story carried a known risk, this is the condition that would flag it.

This condition needs SonarQube Advanced Security, a separate subscription. Without it, the condition is greyed out and skipped. Check your licence before you rely on the gate for dependencies.

Coverage. This is where teams get stuck. If your team does not write tests with each change, an 80% bar on new code can fail many AI-assisted pull requests at first. That can be the right outcome. If it is not, copy the gate, set a coverage figure your team can meet, and qualify the copy. Raise it later.

Using SonarQube as an AI code review quality gate on pull requests

A gate only protects you if it runs before the merge, and that depends on your edition.

The free Community Build analyses only the main branch and does not analyse pull requests. Sonar's comparison table lists "Quality gate status report on pull requests; Preventing merge when quality gate fails" for Server and not for Community Build. On Community Build, AI-written code is already on main when SonarQube first sees it.

On the Developer edition and above, the order changes:

• Every pull request is analysed, and the results include only "issues that have been introduced by the pull request itself".
• The quality gate status appears in the pull request itself, on GitHub, GitLab merge requests, Bitbucket or Azure DevOps. This is called pull request decoration.
• If the project is labelled and on a qualified gate, that status is the AI gate.

In practice, your reviewer sees a failed gate before reading a line of the diff. The human review then covers what a rule engine cannot judge: whether the change does what the ticket asked.

A gate and an AI reviewer do different jobs. The quality gate is a list of conditions you can read and change. For an AI reviewer that comments on pull requests, Sonar points to Gitar, which it describes as "a separate Sonar product". You can run both. In this setup, the gate is what blocks the merge.

Where SonarQube AI CodeFix fits

AI CodeFix suggests fixes for issues SonarQube has already found.

When a developer asks for a fix, "the affected code and issue description are sent to the LLM you define". AI CodeFix then "proposes an edit that resolves the problem without changing the code's functionality". Developers see the suggestion in SonarQube Server, or in VS Code and IntelliJ when those are connected to the server, and apply it in their next pull request.

Know these limits before you plan around it:

• Edition. On SonarQube Server, AI CodeFix is "only available in SonarQube Server Enterprise and Data Center editions". On SonarQube Cloud it is in the Team and Enterprise plans, with a monthly usage allowance.
• Languages. It covers "a select set of rules" in Java, JavaScript, TypeScript, Python, HTML, CSS, C# and C++. Other languages get no suggestion.
• Switching it on. A SonarQube Server administrator (Sonar calls the role Instance Admin) switches it on, for all projects or only selected ones.
• Model choice. On Server you pick Sonar's hosted OpenAI models, your own Azure OpenAI or AWS Bedrock model, or a self-hosted gateway such as Ollama or vLLM.
• Your code. Sonar says fully self-hosted setups can run "without outbound internet access". It also says its LLM service agreements "prevent your code from being used to train those models".

If a client contract says source code stays on your servers, as it might for the Petaling Jaya software house in the opening, the self-hosted route is the one to test.

Sonar is also adding agents on top. On SonarQube Cloud, as of September 2026, a failed gate on a GitHub pull request can trigger the Remediation Agent, which proposes fixes in a separate pull request. Sonar documents that agent for SonarQube Cloud only. On Server, the fixing feature to plan around is AI CodeFix.

Whichever you use, a suggested fix is still AI-written code. It arrives in a pull request of its own and has to pass the same gate as everything else.

Setting it up: a checklist for your first project

Pick one active repository where developers already use an AI assistant, and work through this list.

1. Confirm pull request analysis. On SonarQube Server you need the Developer edition or above, so the gate runs before the merge.
2. Label the project as containing AI-generated code.
3. Choose the gate. Start with "Sonar way for agentic AI". If 80% coverage is out of reach, copy it, lower that one condition, and qualify the copy.
4. Check the dependency condition. Without Advanced Security it is skipped, so cover dependency review another way.
5. Block merges on a failed gate in your DevOps platform, so the gate stops the merge rather than only posting a comment.
6. Decide on AI CodeFix. On Enterprise or Data Center, pick the model route your security team will accept.
7. Review after two weeks. See which conditions failed most, then adjust your own copy of the gate, not the built-in one.

What a quality gate will not catch

A quality gate checks code against rules. It does not know what your customer asked for.

An agent can write a clean, fully tested function that calculates Malaysian SST (sales and service tax) on the wrong base, and every condition will pass. Coverage shows that tests ran the code, not that they checked the right answer. Wrong business rules still need a person who knows the business.

The gate's conditions also apply only to new code. AI-written code already on main can carry issues and still pass, because SonarQube reports it under overall code instead.

Getting SonarQube set up in Malaysia or Singapore

Anchor Sprint is a Sonar reseller partner in Malaysia and Singapore. We set up the gates and pull request checks above, and can train your developers to act on what the gate flags.

Two related services, if they fit your situation:

• If you already have an app built mostly by prompting AI and it breaks in production, a gate on future pull requests will not fix what is on main. Our Vibe Code Rescue service audits apps built that way and tells you whether each is worth fixing before we fix it against written criteria.
• If you are planning AI agents that write or change code, design the gate in from their first pull request. Our AI agent development team can scope that with you.

Sonar runs its Asia Pacific regional headquarters from Singapore. If your team builds on GovTech's SHIP-HATS developer platform, it already offers SonarQube as a managed tool, so check what it gives you first.

To start, tell us your DevOps platform and roughly how many lines of code you have. Say whether your developers already use AI coding assistants. See our SonarQube Malaysia page, or our SonarQube Singapore page if you buy in Singapore.