> ## Documentation Index
> Fetch the complete documentation index at: https://docs.weaveos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Code review output

> How Weave measures the effort a reviewer put into a PR — the expert-engineer time their review represents, scored the same way for humans and AI reviewers

## How it works

Code review output answers the question: <strong>"how long would an expert
engineer have spent producing this review?"</strong>

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](/metrics/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](/metrics/ai-reviewer-comments) for a related view of AI
reviewer activity.

## Related metrics

* [Review quality](/metrics/review-quality) — how much *value* a review added
  (depth, communication, practicality, and impact), scored 0–100.
* [Review depth](/metrics/review-depth) — whether a PR got a full, rubber-stamp,
  or no review.
* [Code output](/metrics/code-output) — the authoring counterpart, in the same
  expert-engineer-hour unit.

## Technical details

<AccordionGroup>
  <Accordion icon="circle-question-mark" title="How is the score calculated?">
    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.
  </Accordion>

  <Accordion icon="circle-alert" title="Why does a reviewer have an output of 0?">
    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](/analysis/ignored-prs). About half of all
    (PR, reviewer) pairs land near zero.
  </Accordion>

  <Accordion icon="pen-line" title="Can I adjust a score?">
    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.
  </Accordion>

  <Accordion icon="chart-line" title="What data sources are used?">
    Code review output is computed from review activity on:

    * GitHub
    * GitLab
    * Bitbucket
  </Accordion>
</AccordionGroup>

## Public API

Available from [`GET /metrics`](/api-reference/metrics/get-metrics) as `code_review_output`: reviewer effort in the same units as [code output](/metrics/code-output). Distinct from `code_reviews`, which is a count of reviews. Supports `group_by=account` (reviewer account ID) and weekly granularity.

<Note>Self-reviews (where the PR author reviews their own PR) are excluded from this metric.</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.