Read before you post: the case for dry-run AI code review

There is a predictable way that AI code review gets rejected by a team. Someone enables it across the organisation, it posts forty comments on the first substantial pull request, half are wrong, and within a week everyone has muted the bot.

The tool may have been good. It never got a fair hearing, because the first impression was noise on somebody's work in front of their colleagues.

What dry run does

A dry-run review runs the complete pipeline — same context, same model, same validation — and posts nothing. Findings appear in your dashboard. You read them, select the ones worth sharing, and publish only those.

Nothing reaches the pull request until you decide it should. Your team's first exposure to the tool is a handful of genuinely useful comments rather than everything the model produced.

Use it as a calibration tool

The confidence threshold is adjustable, and dry run is how you find the right value for your codebase. Run a few reviews, see what gets discarded and what gets posted, then set the threshold where the signal-to-noise ratio suits your team. A repository full of generated code needs different settings from a hand-written service.

The review log shows how many findings were dropped and why, so this is an informed adjustment rather than guesswork.

And for evaluating at all

You can run a dry review on any public GitHub pull request without installing anything or granting repository access. That is the honest way to evaluate a code reviewer: look at its output on code you know well, before deciding whether it deserves write access to your repositories.