OpenRouter code review example separates findings from proof

OpenRouter published a Python tutorial for reviewing code changes with a model and a hosted Linux sandbox. The example supplies changed files and a diff, lets the model run checks, and returns findings marked as confirmed or unconfirmed.

It can also propose patches and apply them to a local copy when requested. A significant limitation is explicit in the design: the investigation runs against the original code, so applying a proposed patch does not establish that the repair works. Tests still need to run against the modified version.

A finding should be reproducible

A useful review comment explains the affected behavior, the conditions that trigger it, and the evidence supporting the conclusion. A plausible story about a bug can help direct investigation, but it should not carry the same weight as a small test that demonstrates the failure.

The confirmed label also needs interpretation. A demonstration proves the behavior under the tested setup. It may not show that the same path is reachable in production or that the impact is as severe as the model suggests. Reviewers should connect the example to the application's actual environment.

Supplying complete relevant files can reduce guessing about surrounding code. It can also expose more information to the review service, so the input bundle should be deliberate. Include the context needed to evaluate the change and exclude unrelated secrets or private material that the tool does not need.

Verify the repair independently

A patch should be checked for both the original failure and nearby regressions. Run the reproducer again, then the appropriate existing tests. If the proposed fix simply removes the behavior under review, confirm that it has not also removed a required feature.

Teams should resist turning every model concern into a blocking check immediately. An overly noisy gate can encourage developers to ignore results or seek ways around it. Begin by recording which findings are accepted, which are rejected, and why. Use that evidence to choose a severity threshold.

The review process also needs an incomplete state. A tool failure, missing dependency, or exhausted budget should not look like a clean pass. Make that distinction visible in automation so that silence is not mistaken for successful inspection.

OpenRouter's example illustrates a useful progression from generated opinion to testable evidence. The strongest review workflow preserves that evidence, makes uncertainty visible, and treats a proposed repair as new code that must earn its own verification.