Measuring the review loop before and after Baz

Every team that adopts an AI code review tool eventually gets asked the same question by someone above them: is this actually making review faster, or does it just feel that way. Comment volume and finding counts do not answer that. A tool can generate a large number of comments and still leave PRs sitting untouched for two days before anyone looks at them.

The honest answer requires two numbers most teams were not tracking cleanly before: how long it takes for a pull request to get picked up for review, and how long it takes to go from opened to merged. Engineering Impact tracks both, and now it can put them in context against what the team measured before Baz was in the loop.

Two measures of the same bottleneck

PR pickup time tracks the median duration between a pull request being opened and a human reviewer first interacting with it. This is the first place review cycles usually stall: a PR sits in a queue, everyone assumes someone else will look at it, and nothing happens until a Slack message forces the issue.

Time to merge tracks the median duration a pull request spends open, from creation to merge. It captures the full cycle, including pickup time but also everything after: the back-and-forth on findings, re-review after changes, and the final approval.

Both graphs show median duration over time, per-period counts, and weekly change, so a team can see whether a number is trending in a direction or just noisy from week to week.

Why a baseline changes the conversation

A live trend line answers "what is our pickup time right now." It does not answer "did it get better since we started using Baz," because that requires a comparison point that most teams never captured on their own.

That is what the pre-Baz baseline annotation adds. It draws a reference line for the period before Baz was adopted on a repository, alongside the live trend for the period after. The comparison is direct: the same metric, the same repository, before and after, without needing a separate spreadsheet or a manually reconstructed timeline from old PR data.

For VP Engineering and engineering ops audiences, this is the difference between a chart that looks fine in isolation and a chart that actually supports a claim. "Pickup time is down 30% since rollout, measured against our own pre-adoption baseline" is a statement backed by evidence. "Our current pickup time is two hours" is just a number.

Reading the change correctly

A few things are worth keeping in mind when interpreting the baseline. The comparison is only as good as the pre-adoption history available for a given repository, so newly onboarded repositories without much prior tracked activity will show the live trend without a meaningful baseline yet. And a single week of improvement is not a trend: look at the median and the weekly change together, not just the most recent data point.

Used well, the baseline turns Engineering Impact from a monitoring dashboard into an accountability tool: not just what review velocity looks like today, but whether the investment in Baz actually moved it.