Do not prompt your way around missing machinery.
Open Code Review describes a hybrid pipeline: deterministic code selects files, bundles related changes, matches language and path rules, and handles comment positioning and reflection; an agent handles contextual search and judgment inside those rails.[1] That split is more important than the product name. “Review everything carefully” is a wish. Enumerating the review set is a mechanism.
The project says it grew out of Alibaba’s internal tooling and has served tens of thousands of developers over two years. It also ships as an Apache-2.0 CLI, can review workspace changes, branch ranges, commits, or full files, and can emit JSON for another system to consume.[1] Those are maintainer claims and current interfaces, not an independent verdict on review quality.
Let the model hunt. Make the harness count the doors.
Precision is a product choice, not a trophy.
The project explicitly says it trades lower recall for higher precision and fewer noisy findings. Its published benchmark description covers 200 pull requests from 50 open-source repositories across 10 languages, with 1,505 annotated ground-truth issues cross-validated by more than 80 senior engineers.[1] The public dataset page currently exposes a 2.15k-row training split with fields for PR, path, line range, category, model source, and label.[2]
That is useful transparency, but the headline scores still belong to the project publishing the tool and benchmark. Before adopting the ranking, inspect sampling, annotation rules, model configuration, cost accounting, duplicated issue candidates, severity mix, and how “real defect” was adjudicated. Then replay it on your review history. A reviewer that is wonderfully quiet on framework code may be dangerously quiet on authorization changes.
The best setting is workload-shaped.
Zed 1.19.2 added effort-based reasoning controls for OpenRouter models. The feature is small, but the direction rhymes: model effort is becoming an explicit control surface rather than a hidden personality trait.[3] Review deserves more than one global “thorough” switch.
Use a low-noise lane for mechanical churn, a balanced lane for ordinary logic, and an escalation lane for auth, crypto, money, deletion, concurrency, migrations, and public contracts. Raising model effort can buy more search. It cannot prove all files were visited, make a drifting line coordinate stable, or decide your acceptable miss rate. Those belong to the chassis.
Build the loop that measures disagreement.
Pin the review set. Save the exact base, head, included paths, ignored generated files, and bundle map. Separate findings from comments. Keep every candidate and the filter decision, not only what reached the pull request. Sample silence. Human-review some “no finding” changes, because false negatives do not announce themselves. Track disposition. Record accepted, rejected, duplicate, stale, and escaped findings by severity and subsystem.
The dyno below replaces a single “AI review on/off” checkbox with a risk lane, an effort throttle, deterministic rail interlocks, and a copyable calibration receipt. It does not calculate quality. It makes the choices that quality depends on impossible to hide.