How to combine Claude Code review with SonarQube verification

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? /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. The original r/ClaudeCode post (view on Reddit). User-reported experience, not a Sonar measurement. The 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. 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. 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. TLDR /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. Split the work. Deterministic checks handle what has a clear yes-or-no answer, like leaked secrets. AI review handles what needs judgment, like whether the change does what the ticket asked. Run them in that order: get the deterministic checks passing first, then spend review tokens on what's left. AI code review and deterministic analysis: What should each one find? Review findings come in two broad kinds: Issues a deterministic check can settle. Unchecked user input reaching a database query, hardcoded passwords, risky settings, overly complex functions, missing test coverage. Each has a clear yes-or-no answer. Issues that need judgment. Does the change match the issue or spec? Is that off-by-one really off? What breaks at the edges? An 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. Sonar's second-loop post 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. This Sonar walkthrough 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. The 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: Issue in the PR Found by 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) Pagination off by one page Agentic review (Gitar) Sort order reversed compared with the tests Agentic review (Gitar) Exports written to a /tmp folder any user on the machine can write to Deterministic analysis (SonarQube Cloud) A web route that doesn't declare which HTTP methods it accepts Deterministic analysis (SonarQube Cloud) The 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. As the write-up puts it: "Green CI and AI approval does not mean merge-ready!" Layered 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. 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. A setup that spends review tokens where they count Here'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. 1. Run deterministic analysis while the agent writes In your editor, SonarQube for 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. You'll need Node.js, Docker (or Podman), and a SonarQube account (a free SonarQube Cloud account works, per the setup guide). 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: /plugin install sonarqube@claude-plugins-official /sonarqube:sonar-integrate The 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, then run sonar auth login and sonar integrate claude for the same hooks and MCP server. Claude can then fix findings with the exact issue and line in hand, before anyone spends tokens on an open-ended review. 2. Gate every PR with checks that don't spend tokens Run your rule-based checks in CI and block merges when they fail; they use no AI tokens. SonarQube 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 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. Rule 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. 3. Run /code-review scoped, sized, and steered With 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 for details. Name the target every time: /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 Reviewing several PRs? Run one scoped review per PR rather than one sprawling request. Pick 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. Save /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 for current pricing. Then 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: ## Code review - Our CI checks (SonarQube) already run deterministic analysis: secrets, injection flaws, risky config, complexity, duplication, test coverage. - 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. 4. For high-risk changes, get a second opinion from a different model The thread's most upvoted reply hands reviews to a different model (Codex, OpenAI's coding agent) for a second opinion. That instinct is right: a model reviewing its own work shares its own blind spots. For 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. So back to the Reddit thread… is /code-review a “waste of tokens”? I 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. A 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. How are you running reviews in Claude Code? I’d love to hear what’s working for you in the comments 👇