QuickReview is a new open-source AI code reviewer for GitHub pull requests that bets on recall over speed. Posted to Hacker News on October 27, 2026 by its maker, it fans every change out to about a dozen narrow, read-only "lens" passes, merges duplicate findings, and has a validator re-derive each one before a single review goes up. Its authors report that on their own verified benchmark it finds 97% of high-severity defects, versus 90% for the best of six other reviewers, at roughly $2 and 17.5 minutes per PR. Those are the project's numbers, not an independent test, so this post separates what is claimed from what you can check.
Sources are the QuickReview README and the maker's Hacker News post. The HN thread had one comment, from the poster, when we read it, so there is no community verdict yet.
At a glance
| Question | Answer |
|---|---|
| What is it? | Self-hosted reviewer for GitHub PRs; daemon plus qcr CLI; beta since mid-August 2026 in the maker's own repo |
| How does it work? | Rule-planned narrow lenses, duplicate merge, adversarial validation, one posted review |
| Headline claim | 97% of high, 93% of medium, 84% of low severity defects on 185 PRs (520 verified defects) |
| Cost and time | About $2.06 and 17.5 minutes per PR on GPT-6.1 Sol |
| Weakness | Lowest precision on the Martian and Qodo benchmarks; about 6.9 comments per PR |
| Safe to try? | Yes: dry_run = true is the default, so a fresh install posts nothing |
| Independent verification | None yet |
Why "many narrow reviewers"?
The README's argument is simple: a single model asked to "review this PR" reads the diff once, from one angle, and stops when it has found something worth saying. QuickReview instead plans lenses with plain code, not a model. Each lens is a leaf agent with read-only tools, the diff and a worktree at the exact head; none can see another pass's output, spawn agents or run your code.
Two lenses run on every code change: a baseline pass and a tests pass. A sweep reads every changed file line by line. The rest are chosen by path, content and size: behavior delta, code quality, intent against the PR text, backward compatibility, security, data safety, concurrency, bounds, rollout and more. The PR's session may add a lens or raise its reasoning tier, but may never drop one.
Findings are merged so one root cause gets one comment anchored at its cause. Then a validator re-reads the code for every candidate and keeps, demotes, doubts or kills it. The README states the philosophy bluntly: "A plausible but wrong finding costs more than a missed nit." Severities map to tags by fixed rules, and any surviving blocker means the review requests changes.
A green magnifying lens inspecting a single tile in a mosaic, representing one narrow review lens checking one kind of defect in a pull request
The numbers, and who produced them
All the following come from the project's README and the authors' own reports.
AACR-Bench, verified defects. The authors built a key of 520 defects across 185 real PRs in 10 languages, each verified in the code and graded by consequence, because AACR-Bench's own reference comments "are mostly not real problems." On GPT-6.1 Sol, QuickReview finds 97% of high-severity defects, 93% of medium and 84% of low. The best other reviewer at each severity finds 90%, 82% and 52%. Their table lists Codex CLI at 90% high, the pi-review panel at 89%, Claude Code on Opus 5.5 at 81% and PR-Agent at 62%.
Cost. QuickReview costs $2.06 per PR and takes a median 17.5 minutes. The others list $0.07 to $0.53 and 0.7 to 2.3 minutes. On the same model it also beats the model maker's own reviewer at every severity, at 11 to 20 times the cost ($3.24 against $0.16 per PR on Opus), though the authors caution this "contrasts two tools, not a measured design effect."
Martian, 50 PRs. Highest recall (65.8) but lowest precision (16.2), because it surfaces about 12.8 issues per PR against roughly three "golden" comments. Auditing the goldens, the authors say it finds 75 of the 86 that describe real defects (87%).
Qodo PR-Review-Bench, 100 PRs. Best functional-bug recall of 13 tools (52.1%), second most issues overall, lowest precision, fourth on F1.
Cheaper models. On AACR-Bench (the public benchmark paper) it holds most of its recall on DeepSeek V4.1 Flash (92% high, $0.74 per PR) and GLM-5.3 Flash (92% high, $0.52), and "falls apart" on GPT-6 Luna (43% high). The authors flag those rows as a later build and "directional."
What to be careful about
- Authors graded their own homework. The 520-defect key, the severity grades and the judge setup are the project's. Two judge models agreed on the winner only 56% of the time on their pairwise tests, which is why they were pooled.
- Tuning overlap. The last changes were mined from misses on 145 of the 185 PRs. On the 20 PRs kept out, it finds 83% of all defects and "the next best 72%." That is the fairer number, and it is a small sample.
- Recall is not the same as usefulness. 42% of its comments are true but minor, and 6.9 comments per PR is a lot to triage. Our post on the HEAL benchmark shows how different benchmarks can reach very different conclusions about the same class of tools.
- Cost compounds. At $2 per PR, a team merging 100 PRs a day spends about $200 a day on reviews, before retries.
- Beta packaging. The README says setup has "rough edges" and the reviewer has run in production only on one busy commercial repository since mid-August.
Is the recall-first trade-off right for your team?
Code review tools sit on a spectrum. A precision-first reviewer posts two or three comments you almost always agree with, and trust builds quickly. A recall-first reviewer posts more, catches more real defects, and asks your team to triage the rest. QuickReview deliberately picks the second, and tries to soften it with severity tags: P0 to P2 blockers, questions and nits, a reachability gate, and a cap on nits in re-reviews. Items marked [check this] need a human to verify, and [deferred] marks a real issue that does not belong in the current PR.
The practical question is where your bugs escape today. If production incidents trace back to merged PRs that human reviewers skimmed, extra recall is worth a few dollars. If your reviewers already catch the big defects and complain about noise, a heavier bot may just add to the pile. Measure it on your own history before deciding.
What it does around the review
The daemon is a small deterministic TypeScript service with no model in its decision path. It takes GitHub App webhooks, runs a reconcile poll, keeps one sticky session per PR through pushes, replies and rechecks, and posts through one gated mutation path. Reviews trigger on a label or a team review request; bot-authored PRs never queue. Approval is withheld without green CI, and the only allowed verdict change after approval is approve to request-changes.
A "learning loop" lets [feedback] comments demote the validator's bar the same day, while rubric changes require human ratification. The reviewer reads code and never runs it; the README documents the guard layers in docs/exec-boundary.md as claims you can try to falsify. Only the model call and package names a PR imports (fetched from npm and PyPI) leave your infrastructure, and the latter can be disabled.
How to try it safely
- Install the wrapper from the public image on ghcr.io, or run
npm i -g @quickchatai/quickreview(Node 26 or later is supported). - Run
qcr login, thenqcr reviewto review your current branch against its base with no daemon, orqcr review 123for a PR. - Choose where the result goes: shown, saved as markdown and JSON, or posted as a comment-only review.
- Leave
dry_run = truefor the daemon until you have read a week of would-be reviews instate/dryrun/. - Compare against your current reviewer on 20 of your own merged PRs where you know a bug later escaped.
If you already run an AI reviewer, see how Claude Code's team code-review process frames risk tiers, and why AI coding agents produce more code, not more software, which is the review bottleneck QuickReview's "Why this exists" section describes.
Who it is for
- Teams drowning in agent-written PRs that want a recall-first second pass and can afford a few dollars per review.
- Teams with strict data control that want a self-hosted bot under their own keys.
- Not for cost-sensitive repos with high PR volume, or teams that want few comments; a precision-first tool will feel quieter.
The maker's pitch on HN was modest: it has "been reviewing all our PRs for many months now as part of our CI." Treat that as one team's experience and the benchmarks as a hypothesis to test on your own code.
Related reading
- HEAL benchmark: AI PR reviewers miss 70% of runtime bugs
- Claude Code team code-review process and risk tiers
- AI coding agents: more code, not more software
- Postgres 19 delayed over AI code review bugs
- Linus Torvalds on AI, vibe coding and kernel review
- GPT-6.1 Terra launch and pricing
Sources: QuickReview on GitHub and the Hacker News post.
Details are accurate as of October 27, 2026. The project is in beta and its benchmarks may be updated.