{"slug": "how-to-combine-claude-code-review-with-sonarqube-verification", "title": "How to combine Claude Code review with SonarQube verification", "summary": "A Sonar engineer demonstrated a two-layer code verification workflow that pairs an agentic AI reviewer (Gitar) with deterministic rule-based analysis (SonarQube Cloud) on a demo Flask API pull request. The AI layer caught an off-by-one pagination bug and a reversed sort order, while SonarQube flagged a world-writable /tmp export path and a route missing declared HTTP methods; both layers independently caught a path-traversal risk from a user-supplied filename. The write-up notes that green CI and AI approval still left the quality gate blocking the merge on issues the agentic layer missed.", "body_md": "A few months ago, a thread in r/ClaudeCode asked a question that I suspect plenty of people have muttered at their terminal: [is /code-review a big waste of tokens?](https://www.reddit.com/r/ClaudeCode/comments/1vtvo0b/) **`/code-review`** is Claude Code's built-in code review command: it asks Claude to look over your changes for bugs before you merge them.\n\n*The original r/ClaudeCode post ([view on Reddit](https://www.reddit.com/r/ClaudeCode/comments/1vtvo0b/)). User-reported experience, not a Sonar measurement.*\n\nThe original poster described a routine many developers will recognize: asking Claude to review their pull requests (PRs) in a fresh session. By their estimate, that took 10 to 20 minutes and 5–10% of a session's tokens (the units AI usage is measured and billed in). They then tried the dedicated `/code-review` command. About ten minutes in, they noticed it was reviewing a different set of changes than they intended, and they soon reached their session limit. They asked whether the command is only available on Max plans.\n\n*A note on the numbers: everything in this thread is user-reported. I haven't reproduced any of it, and the poster notes their build and unit tests are slow, which may account for some of that time. Review cost depends on your plan, model, effort level, and what you point the review at, so your results will differ.*\n\n*Disclosure: I work at Sonar, the company behind SonarQube, so I have a stake in one of the tools mentioned below. Most of this works regardless of which tools you use.*\n\n`/code-review` works on any plan and does find real bugs. What it reports depends on what you point it at and the effort level (how thoroughly it looks) you set, so name the target and pick the level on purpose. A rule-based checker (a tool that checks code against fixed rules) settles the issues a rule can decide, so the review can focus on the rest.\nReview findings come in two broad kinds:\n\nAn AI reviewer can find both, but paying a model to find a hardcoded password is like paying a senior engineer to read every file looking for one: it works, but it's slow and expensive.\n\nSonar's [second-loop post](https://www.sonarsource.com/blog/why-fable-5-still-needs-a-second-loop/) explains why you want both layers: an AI check can answer differently on each run, while a deterministic check gives the same answer every time. Neither replaces the other.\n\nThis [Sonar walkthrough](https://www.sonarsource.com/resources/library/multilayered-code-verification-with-gitar-sonarqube-cloud/) shows what that looks like in practice. It runs a small demo PR through **Gitar (agentic, AI-driven review)** and **SonarQube Cloud (deterministic, rule-based analysis)** as two layers of multilayered verification on the same PR.\n\nThe PR was a Flask API (a small Python web app) with two logic bugs and an untested CSV export endpoint. Between them, the two layers caught every issue below:\n\n| Issue in the PR | Found by | \n|---|---|\n| A user-supplied filename could write files outside the export folder | Both layers (SonarQube traced it from the request to the file write, with no AI tokens) | \n| Pagination off by one page | Agentic review (Gitar) | \n| Sort order reversed compared with the tests | Agentic review (Gitar) | \n| Exports written to a `/tmp` folder any user on the machine can write to | Deterministic analysis (SonarQube Cloud) | \n| A web route that doesn't declare which HTTP methods it accepts | Deterministic analysis (SonarQube Cloud) | \n\nThe layers also work in sequence. Gitar's fix commit re-triggered CI, and SonarQube rescanned automatically, so the path traversal finding cleared without a manual step. Gitar then fixed everything it had found and approved the PR, and CI (the automated checks that run on every push) went green, but the quality gate, SonarQube's pass/fail bar for new code, still blocked the merge on issues the agentic layer hadn't flagged.\n\nAs the write-up puts it: \"Green CI and AI approval does not mean merge-ready!\"\n\nLayered this way, the pair aims to catch as many issues as possible in the most efficient way: fast, deep analysis with high signal and low noise. Deterministic analysis settles the issues that have a clear answer, at no token cost, and agentic review spends tokens on what needs judgment.\n\n*Two caveats:**the agentic layer in that demo was Gitar, which Sonar acquired this year, not `/code-review`, so what carries over is the method, not the brand. And it's one small PR built for a demo, so read it as what each layer tends to catch, not a catch rate.*\n\nHere's what I'd do, cheapest layer first. Steps 1 and 2 work with any deterministic tools, such as linters, type checkers, and security scanners. I'll use SonarQube (Sonar's code verification platform, which runs deterministic analysis; SonarQube Cloud is the cloud-hosted version) for the examples because I work at Sonar and know it best, and it has free options.\n\nIn your editor, [SonarQube for IDE](https://www.sonarsource.com/products/sonarqube/ide/) is a free extension that flags issues as you type. In a Claude Code session, install the SonarQube plugin from Anthropic's official marketplace and run its setup.\n\nYou'll need Node.js, Docker (or Podman), and a SonarQube account (a free SonarQube Cloud account works, per the [setup guide](https://github.com/SonarSource/sonarqube-agent-plugins)). Keep Docker running, since the SonarQube MCP Server runs in a container. Run these one at a time, and if Claude Code asks you to run `/reload-plugins` after the install, do that first:\n\n```\n/plugin install sonarqube@claude-plugins-official\n/sonarqube:sonar-integrate\n```\n\nThe integrate step installs the SonarQube CLI (a command-line tool), walks you through signing in, and connects Claude Code to your SonarQube account. It also adds hooks that scan your prompts and the files Claude reads for secrets before they reach the model. Prefer the terminal? Install the [SonarQube CLI](https://cli.sonarqube.com/), then run `sonar auth login` and `sonar integrate claude` for the same hooks and MCP server.\n\nClaude can then fix findings with the exact issue and line in hand, before anyone spends tokens on an open-ended review.\n\nRun your rule-based checks in CI and block merges when they fail; they use no AI tokens.\n\nSonarQube Cloud is free for up to 5 users and 50,000 lines of private code, including analysis of PRs into your main branch with the default quality gate (its [quickstart guide](https://docs.sonarsource.com/sonarqube-cloud/quickstart-guides/quickstart-guide) covers CI setup). Public open source projects get a free OSS plan that analyzes every branch and PR. Prefer to host it yourself? SonarQube Community Build is free and open source, but it analyzes your main branch only; PR analysis starts at Developer Edition, which is paid.\n\nRule of thumb: don't run `/code-review` on a PR until those checks pass. There's no reason to pay a model to rediscover what they already reported.\n\nWith no target, `/code-review` reviews the commits on your current branch that its upstream branch doesn't have yet, plus anything uncommitted. Naming the target makes sure it reviews the changes you meant. It counts toward your plan's usage or API bill, so see [Anthropic's cost docs](https://code.claude.com/docs/en/costs) for details.\n\nName the target every time:\n\n`/code-review 1234` reviews PR #1234`/code-review main...my-feature` reviews one branch against another`/code-review low 1234` reports only the findings it's most confident in\nReviewing several PRs? Run one scoped review per PR rather than one sprawling request.\n\nPick the effort level on purpose. If you leave it off, `/code-review` reuses the last level you typed, even from an earlier session, so after one `/code-review max`, a plain `/code-review` runs at max too.\n\nSave `/code-review ultra` for changes that warrant it. It's a deeper review that runs several agents in the cloud, so it takes longer than a regular review and is billed differently. It's a research preview, so check [Anthropic's ultrareview docs](https://code.claude.com/docs/en/ultrareview) for current pricing.\n\nThen tell the reviewer what not to re-report. `/code-review` follows your `CLAUDE.md` (the project instructions file Claude Code loads in every session), so a short section steers it. Keep it brief, since every line costs tokens, and adjust the first bullet to match what your checks cover:\n\n```\n## Code review\n\n- Our CI checks (SonarQube) already run deterministic analysis: secrets, injection flaws, risky config, complexity, duplication, test coverage.\n- Don't re-report anything SonarQube already flags on the PR. Spend findings on what deterministic checks can't judge: does the change match the issue or spec, logic and edge cases, error handling, concurrency, API or contract changes, and whether the tests cover the cases that matter.\n```\n\nThe thread's most upvoted reply hands reviews to a different model (Codex, OpenAI's coding agent) for a second opinion.\n\nThat instinct is right: a model reviewing its own work shares its own blind spots.\n\nFor risky changes, a different model, or a fresh session told to hunt hard for problems, is worth the tokens, though either can still answer differently on another run. So let the rule-based check block the merge, and let a human make the final call.\n\nI think that’s the wrong question to ask about any single reviewer. `/code-review` does find real bugs, and it does its best work as one part of your verification setup. A more useful question is whether each kind of check is doing the job it’s best at.\n\nA rule-based check gives the same answer every time, so it should settle issues like leaked secrets and injection flaws and block the merge when they show up. An AI reviewer brings judgment, so it should focus on intent, logic and edge cases. In the demo PR above, neither one caught everything alone, and together they caught all five issues. If you get the deterministic checks passing first, Claude can spend its whole review on the questions that need judgment.\n\n**How are you running reviews in Claude Code?** I’d love to hear what’s working for you in the comments 👇", "url": "https://wpnews.pro/news/how-to-combine-claude-code-review-with-sonarqube-verification", "canonical_source": "https://dev.to/sonar/how-to-combine-claude-code-review-with-sonarqube-verification-4ib8", "published_at": "2026-11-06 23:06:19+00:00", "updated_at": "2026-11-06 23:22:38.877661+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Sonar", "SonarQube", "Gitar", "Claude Code", "Reddit"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-to-combine-claude-code-review-with-sonarqube-verification", "markdown": "https://wpnews.pro/news/how-to-combine-claude-code-review-with-sonarqube-verification.md", "text": "https://wpnews.pro/news/how-to-combine-claude-code-review-with-sonarqube-verification.txt", "jsonld": "https://wpnews.pro/news/how-to-combine-claude-code-review-with-sonarqube-verification.jsonld"}}