Measure Productivity

The Productivity tab connects spend to engineering output. It is where the question "is this actually making us faster?" gets a data point.

Throughput

• PRs assisted: Pull requests opened in the range whose head branch a coding-agent session worked on. Each counts once, however many sessions touched it.
• Opened, Merged, and Merge rate for the range.
• Still open and Awaiting review: The current backlog, not a count for the range.

Flow through the pipeline repeats the Overview's view of where merged pull requests slow down between coding and merge. See Read the Overview for how the stages and the worst jam are measured.

Time to Merge

Time to merge runs from a pull request being created to being merged, attributed to the merge date, at the percentile you pick. It covers coding, review wait, in review, and merge wait.

The trend line follows the window you choose. On 7-day rolling, each point is measured over the pull requests merged in the week ending there. On Daily, each point is measured over that day's merges alone, so a day that merged nothing has no point.

Time to merge by PR type splits the same measurement across PR types. This is where a headline number usually comes apart: one slow type can carry the whole percentile.

Review and Approval

• Time to first review and PRs awaiting first review: How long pull requests wait, and how many are waiting now.
• Review depth per merge: Merged pull requests grouped by how much human review each attracted, into rubber-stamp, single reviewer, multi-reviewer, auto-merged, and no review. Every merged pull request falls in exactly one bucket. Neither an automation's review nor the author's own review counts as human review. See Review depth per merge for what qualifies as a rubber stamp and why "no review" is a floor rather than an exact count.
• AI review agents: Comments, reviews, and the share resolved, per automation.
• Human reviews: Reviews submitted by people over time.

Read the two review panels against each other. A high resolved rate from an automation alongside a large rubber-stamp bucket means bots are carrying review, which is a deliberate choice for some teams and an accident for others.

Investment

• Where the work goes: Sessions split by Harness, Activity, Model, or Team.
• Investment distribution: Merged pull requests grouped by PR type.

Together these answer what your engineering capacity was actually spent on, which is often the most surprising view on the page: dependency updates and chores routinely outweigh features.

How to Use Measure Productivity

Fix the jam, not the average. If time to merge is slow and the worst jam is awaiting review, no model change helps. Review capacity is the constraint.

Check the mix before celebrating a number. Time to merge by PR type and investment distribution tell you whether a fast quarter reflects better delivery or a quarter weighted toward dependency updates.

Use review depth as a quality guardrail. Agent-assisted throughput that arrives alongside a growing rubber-stamp bucket is throughput bought by skipping review. Watch the two together.

Compare models on velocity, not just cost. A frontier model that costs more per token may deliver faster merges. Read Track Cost alongside time to merge here to understand throughput per dollar.

Further Reading

• Key Concepts: Definitions for time to merge, review depth, and PR type.
• Read the Overview: Flow through the pipeline and assisted vs non-assisted cycle time.
• Set Up AI SDLC Insights: Connect GitHub to populate this tab.
• Track Cost: See what you spend and which models cost most.