Skip to main content

​
How it works

Code review output answers the question: “how long would an expert engineer have spent producing this review?” For every reviewer on a PR, Weave reads the review they left — the diff they engaged with, the correctness concerns they raised, and the comments they wrote — and estimates the active, hands-on hours that work represents. It’s the review-side counterpart to code output: the same expert-engineer-hour unit, applied to reviewing instead of authoring. A reviewer’s output for a time period is the sum of their per-PR scores.

​
What it measures

The score is anchored to the comments a reviewer actually left, sized against the PR’s scope:
  • A bare approval or a rubber stamp on a large PR scores close to 0.
  • A careful security or correctness review on a small PR can score meaningfully higher.
  • Substantive threads (bugs, architectural pushback) earn more than trivial nits, and clusters of similar nits are batched rather than counted one by one.
It is a measure of review effort and impact, not comment volume — twenty shallow nits score far less than one comment that caught a real bug.

​
Human and AI reviewers

Reviews are scored as human-equivalent labor, so bots and humans land on the same scale. A comment is credited for the work it represents regardless of who (or what) produced it. This lets you credit AI code reviewers like Greptile, CodeRabbit, Copilot, and Codex alongside your engineers, and group code review output by AI tool to compare how much review work each tool is doing. See AI reviewer comments for a related view of AI reviewer activity.
  • Review quality — how much value a review added (depth, communication, practicality, and impact), scored 0–100.
  • Review depth — whether a PR got a full, rubber-stamp, or no review.
  • Code output — the authoring counterpart, in the same expert-engineer-hour unit.

​
Technical details

Weave evaluates each reviewer’s submissions on a PR — their inline comments plus any approval, request-changes, or commented review bodies — and estimates the hands-on hours a senior engineer would have spent on that work: reading the diff, reasoning about correctness, and writing the feedback. Later review rounds on the same PR are compressed, since the reviewer reuses context already loaded.
Common reasons a (PR, reviewer) pair scores ~0: the review was a bare approval or rubber stamp with no substantive feedback, the reviewer was also the PR author (self-reviews are excluded), or the PR itself is excluded — for example a draft PR or an ignored PR. About half of all (PR, reviewer) pairs land near zero.
Yes. Admins can override the code review output for a specific reviewer on a PR when the estimate doesn’t match your team’s judgment.
Code review output is computed from review activity on:
  • GitHub
  • GitLab
  • Bitbucket

​
Public API

Available from GET /metrics as code_review_output: reviewer effort in the same units as code output. Distinct from code_reviews, which is a count of reviews. Supports group_by=account (reviewer account ID) and weekly granularity.
Self-reviews (where the PR author reviews their own PR) are excluded from this metric.
Last modified on October 17, 2026