DEV Community

Manos Saratsis
Manos Saratsis

Posted on

SonarQube Flags AI-Generated Code as a Special Case. That's the Wrong Default.

Originally published on the Dromeas blog.

SonarQube has a feature called AI Code Assurance. When it detects that a project uses GitHub Copilot — checked via the GitHub Copilot Business org settings — it tags the project CONTAINS AI CODE and routes it through a dedicated quality gate built specifically for AI output, instead of the standard one (Sonar). More recently, they shipped a plugin that goes further: inside the GitHub Copilot CLI itself, an agent's generated code now gets run through an automatic verify-fix-reanalyze loop before it ever reaches a pull request (Sonar).

Both are sensible responses to a real problem — AI-generated code has roughly 2.74x more vulnerabilities than human-written code (Veracode 2025), so scrutinizing it more makes sense on paper. But look at the mechanism underneath both features: first you have to detect that a human didn't write this, then you route it somewhere stricter. AI-authored code is the exception you build a special lane for.

That's worth questioning, and not because the detection is badly built. It's because "detect, then route differently" only works as well as the detection does — and detection is inherently one step behind.

What AI Code Assurance actually checks — and what it misses

The detection step is worth being precise about, because its scope defines the size of the hole. SonarQube's autodetect mechanism evaluates Copilot usage patterns and code-contribution data through the GitHub Copilot Business organization API. Two consequences follow.

First, the wire it trips is GitHub Copilot-specific. A team running Claude Code, Cursor, or a local agent alongside (or instead of) Copilot doesn't necessarily trip that wire the same way. The special lane exists, but not every AI-authored line of code is guaranteed to be in it.

Second — and this is the part that makes the architecture question concrete rather than philosophical — Sonar's own docs now flag autodetect as deprecated in SonarQube Server 2026.1 LTA, with removal planned and manual project labeling as the remaining path (docs.sonarsource.com). Read that slowly: the vendor that built "detect AI code, route it to a stricter gate" is retiring the detection half of the design and asking humans to self-declare instead. Manual labeling is detection too — it's just detection delegated to the person least incentivized to do it carefully, at exactly the moment agent-written code is becoming the majority of new lines.

None of this is a knock on the feature's implementation. It's the predictable end-state of any architecture whose first step is "figure out whether a human wrote this."

The CLI plugin is the more interesting move

To be fair to Sonar, the GitHub Copilot CLI plugin (June 2026) is the smarter of the two ideas. It doesn't wait for detection at the project level — it runs an agentic loop right in the terminal: analyze the agent's output, fix what it finds, re-analyze (sonar analyze agentic) before the code reaches a PR. That's the right instinct: meet the agent where it works, and verify before merge rather than audit after.

Why "same rigor, no detection step" scales better

The alternative to a better detector is not needing one.

Every PR and every trunk commit that goes through Dromeas runs the same six-agent pipeline — quality, security, compliance, testing, docs, instrumentation — reviewed by the same multi-model council, regardless of who or what wrote it. There's no CONTAINS AI CODE badge, because there's no separate gate to route into. A junior engineer's Tuesday-afternoon commit and an autonomous agent's 2am commit get the identical bar.

That's not a philosophical stance so much as a practical one: as the share of AI-authored code climbs toward the 65% Sonar's own 2026 developer survey projects for 2027, "detect it, then scrutinize it more" is a rule that has to run correctly on a shrinking minority of code to matter, while "scrutinize everything the same way" doesn't have that failure mode at all.

There's a second-order benefit too. When there is no special lane, there is no lane-splitting argument — no "this was mostly agent-written, so the gate should have caught it" postmortem, and no quiet drift where one class of code quietly gets less review because nobody remembered to label the project. The bar is the bar.

If you're weighing the two approaches side by side, the full feature-by-feature breakdown — including AI Code Assurance and the new CLI plugin — is on the Dromeas vs SonarQube comparison page.

Top comments (0)