Where SonarQube Stops, and AI-Slop Rules Start

SonarQube is not wrong. It is solving a broader problem.

The platform is designed for broad static analysis. Its rule set catches security vulnerabilities, code smells, bugs, and style violations that matter regardless of author. It is widely used for a reason: deep language coverage, OWASP Top 10, CWE, SAST, all in one platform. If you run SonarQube, you should keep running it.

But AI-assisted code adds a different kind of review problem. Some failures are still normal bugs. Others are plausible-looking shortcuts repeated across many files: shallow comments, generic naming, swallowed errors, and type escapes that make code pass without making it clearer.

The patterns a focused AI-code layer can add

In AI-generated PRs, these are the kinds of patterns we look for alongside traditional static analysis:

Trivial comments. // Set the user name to value above user.name = value. It is not a code smell in the traditional sense: it is not wrong, it is just useless. But when repeated across generated files, trivial comments become maintainability noise.

Swallowed exceptions. Empty catch blocks or catch blocks with only console.log(err). Some static-analysis setups catch part of this. The AI-code pattern is broader: catches that log and continue without rethrowing, or catches that silence error types that should propagate.

Generic naming. data, data2, result, temp, helper_func. Generic naming is not a bug, but it is maintainability debt when it compounds across generated changes.

Unsafe type assertions. as any, as unknown as T, unchecked casts. SonarQube catches some type-related issues in statically typed languages but does not have rules targeting the specific AI pattern of using escape hatches to make code compile rather than fixing the type.

Console leftovers. console.log statements in production code. Some linters catch this. In AI-generated PRs, debug leftovers are a useful signal that the change needs another pass.

Hallucinated imports. Imports that reference packages that do not exist. AI models can invent package names, and import validation is usually handled by the build, package manager, or a dedicated dependency check rather than a general code-quality dashboard.

Why this gap exists

SonarQube's rule set was built incrementally around known security, maintainability, and bug patterns. AI-assisted code can trigger those same rules, but it also creates softer signals: code that looks plausible, passes baseline checks, and still adds review drag.

This is less about rule count and more about focus. General static analysis catches broad defects. AI-code hygiene catches repeatable shallow patterns that are worth naming and enforcing separately.

What the stack should look like

A practical stack can run two layers:

Layer 1: SonarQube (or equivalent) for security vulnerabilities, style violations, code smells, and architectural issues. This catches what it has always caught. Keep it.

Layer 2: aislop for AI-specific patterns — trivial comments, swallowed exceptions, generic naming, unsafe assertions, console leftovers, hallucinated imports, dead code, missing timeouts. This focuses on repeatable generated-code hygiene.

The two layers are complementary. SonarQube catches broad static-analysis concerns. aislop catches defined AI-code hygiene patterns. Some teams will want both because agent-written code can produce both failure modes in the same function.

The bottom line

SonarQube is not obsolete. It remains strong at the problems it was designed to catch. The question is whether your team also wants a focused layer for AI-code hygiene.

Keep SonarQube where it works. Add npx aislop scan when you want named, deterministic checks for generated-code patterns alongside your existing quality gate.