SonarQube for AI-Generated Code: Deep Analysis Beyond Linting

Why ESLint Is Not Enough for AI-Generated Code

ESLint is a linter. It parses your JavaScript or TypeScript file, checks it against a set of rules, and reports violations. Rules cover things like unused variables, inconsistent quotes, missing semicolons, and some common error patterns. ESLint is excellent at what it does, and tools like Bolt, Cursor, Lovable, and v0 typically generate code that passes ESLint cleanly.

That is part of the problem. AI-generated code is syntactically well-formed. It follows the patterns ESLint knows about. But ESLint does not understand cross-file dataflow, does not track whether a value from an untrusted source reaches a sensitive operation, and does not measure complexity or duplication across the whole project. It is a file-by-file rule engine, not an application-level analyzer.

SonarSource - the company behind SonarQube - published research showing that static analysis beyond linting catches 3.4x more bugs and 6.1x more security issues in typical JavaScript codebases than linting alone. For AI-generated code specifically, that gap is larger because AI tools produce code that is optimized for passing obvious checks while omitting the structural discipline that prevents deeper issues.

What SonarQube Actually Analyzes

SonarQube runs a suite of analysis engines against your codebase. For a Next.js or Node.js app, the key categories are:

SQ-BUG - Bugs: Code that will behave incorrectly at runtime. Examples include calling methods on potentially null values, using == instead of === in ways that cause type coercion bugs, and returning inside a finally block (which discards the exception). These are not style issues - they are defects.

SQ-VULN - Vulnerabilities: Code patterns that are directly exploitable. SQL injection via string concatenation, OS command injection via exec(), and using Math.random() for security-sensitive operations all appear here. Sonar's vulnerability rules overlap with OWASP Top 10 coverage.

SQ-SPOT - Security Hotspots: Code that requires human review because it could be a vulnerability depending on context. Use of eval(), cryptographic operations, file path construction, and HTTP redirects are flagged as hotspots. You decide whether each is exploitable, but SonarQube ensures you see them.

SQ-SMELL - Code Smells: Maintainability issues that make code harder to understand and change. Functions that are too long, too deeply nested, or have too many parameters; duplicated logic; variable names that shadow outer scope. AI code is especially prone to smells because it generates the most immediately functional structure, not the most maintainable one.

SQ-DEBT - Technical Debt: SonarQube converts the number and severity of smells into an estimated remediation time, giving you a "technical debt ratio" - the percentage of time it would take to fix all issues versus the time it took to build the code. For AI-generated apps, this number is often surprisingly high because AI generates a lot of code quickly.

SQ-DUP - Duplications: Blocks of code that are repeated across files. AI tools frequently copy patterns wholesale, creating duplicate logic that must be updated in multiple places. SonarQube reports both the percentage of duplicated lines and the exact file pairs.

SQ-COV - Coverage: Code coverage from your test suite, integrated into the quality gate. If you have tests (or lack them - which is common in vibe-coded apps), SonarQube shows uncovered lines and fails the build when coverage drops below your threshold.

ESLint vs SonarQube: Capability Comparison

Real Examples: What SonarQube Catches That ESLint Misses

Here is a typical pattern from AI-generated Next.js code. ESLint sees no problem. SonarQube flags two issues.

// ❌ BAD - passes ESLint, SonarQube flags SQ-BUG + SQ-SMELL
export async function getUser(req, res) {
  const user = await prisma.user.findFirst({
    where: { email: req.body.email }
  });

  // SQ-BUG: user may be null - calling .id will throw
  const posts = await prisma.post.findMany({
    where: { authorId: user.id }
  });

  // SQ-SMELL: function does too much, deeply nested logic follows
  if (posts.length > 0) {
    for (const post of posts) {
      if (post.published) {
        if (post.views > 1000) {
          await prisma.post.update({
            where: { id: post.id },
            data: { featured: true }
          });
        }
      }
    }
  }

  res.json({ user, posts });
}

// ✅ GOOD - null guard + extracted helper + early return
export async function getUser(req, res) {
  const user = await prisma.user.findFirst({
    where: { email: req.body.email }
  });

  if (!user) {
    return res.status(404).json({ error: 'User not found' });
  }

  const posts = await prisma.post.findMany({
    where: { authorId: user.id }
  });

  await flagHighPerformancePosts(posts);
  res.json({ user, posts });
}

async function flagHighPerformancePosts(posts) {
  const ids = posts
    .filter(p => p.published && p.views > 1000)
    .map(p => p.id);

  if (ids.length === 0) return;

  await prisma.post.updateMany({
    where: { id: { in: ids } },
    data: { featured: true }
  });
}

ESLint would not flag the null dereference because the type system (without strict TypeScript) cannot prove user is nullable at that call site. SonarQube's interprocedural analysis tracks the return type of prisma.user.findFirst(), knows it can return null, and flags every downstream property access without a null guard.

How to Add SonarQube to a Vibe-Coded Project

The fastest path for a solo founder or small team is SonarCloud, the hosted version of SonarQube. It is free for public repositories and has a generous free tier for private ones.

1. Sign up at sonarcloud.io and connect your GitHub, GitLab, or Bitbucket account.
2. Import your repository. SonarCloud auto-detects JavaScript, TypeScript, and most frontend frameworks including Next.js and React.
3. Add the analysis to CI. For GitHub Actions, add the SonarSource/sonarcloud-github-action step. It takes under five minutes to configure.
4. Set a quality gate. The default "Sonar way" gate blocks merges when new code introduces bugs or security vulnerabilities. This is the most valuable setting for AI-assisted development, because every AI-generated commit gets checked before it merges.

According to OWASP, organizations that implement static application security testing (SAST) in CI/CD pipelines reduce mean time to remediate security issues by 62% compared to finding them post-deployment.

How to Interpret SonarQube Results for AI-Generated Code

When you first scan a vibe-coded project, expect a high issue count. This is normal and not a reason to panic. Prioritize in this order:

1. Vulnerabilities first (SQ-VULN): These are confirmed exploitable patterns. Fix before any public launch.
2. Security hotspots second (SQ-SPOT): Review each one manually. Most will be false positives or acceptable risk, but some will be real vulnerabilities.
3. Bugs third (SQ-BUG): These cause runtime failures. Fix before the code goes to production users.
4. Code smells and debt (SQ-SMELL, SQ-DEBT): Address these iteratively. Do not try to fix all smells in one sprint.
5. Duplications (SQ-DUP): Track the percentage. If it is above 15%, you have meaningful architectural debt. Address before the codebase grows further.

Tools like VibeDoctor (vibedoctor.io) automatically scan your codebase for SonarQube-class issues and flag specific file paths and line numbers. Free to sign up.

FAQ