Skip to content
Esc
navigateopen⌘Jpreview
Sign up
On this page

Engineering Impact

Baz's effect on bugs caught, bugs reported, and how long changes sit in review.

The Engineering Impact dashboard, under Insights → Engineering Impact, answers whether adopting Baz changed anything measurable: how many correctness bugs get caught before merge, how many still get reported after release, and how long changes wait in review.

Four charts sit above a carousel of recent findings. Each chart carries a period-over-period indicator, so a number is always read against the previous week rather than in isolation.

Filters

A repository filter and a time range apply to the whole page, with the range offering 1 week, 2 weeks, 1 month, or 6 months and defaulting to 1 month. The reported bugs chart adds its own status filter, drawn from the bug statuses in your connected ticketing system.

Bugs detected by Baz

This chart counts the code correctness findings Baz produced over the selected range, aggregated by week, from the correctness agents such as Logical Bugs, Breaking Changes, and Type Inconsistency. Two lines are plotted: the total Baz detected, and the subset developers accepted, either through positive feedback or a commit that addressed the finding. Hovering a week breaks both numbers down by the agent that found them.

Reported bugs

This chart counts tickets classified as bugs in your connected ticketing system, which is the post-release view: issues users or QA found after the change shipped. It needs a ticketing integration, and an empty chart usually means bugs are not classified as Bug in the tracker rather than that no bugs exist.

Pick up time and time to merge

Pick up time tracks the median time from a change being opened until a reviewer picks it up, which is where review responsiveness and early bottlenecks show. Time to merge tracks the median time from opening to merge, which is overall cycle time.

Both charts shade the period before Baz was onboarded on the repository, so the medians after adoption can be read directly against what the team measured before. The shading only appears once enough pre-adoption history exists, so teams onboarded without prior tracked history see the live trend with no baseline.

Latest bugs detected

The carousel at the bottom shows notable bugs Baz surfaced recently. Each card names the agent that found the issue, when it was found, the finding itself, the developer response to it, and any 👍 reactions it received. Opening a card takes you to the discussion on the change, where the full thread lives.

FAQ

Which findings count as bugs here?

Only code correctness findings, from agents such as Logical Bugs, Breaking Changes, and Type Inconsistency. Style, convention, and security findings are measured in Evaluation instead.

Why is the reported bugs chart empty?

Either no ticketing system is connected, or the tickets in it are not classified as bugs. Baz counts items marked as Bug in your tracker, so check the issue classification before concluding there were none.

Why does a chart show no pre-Baz baseline?

The shaded pre-adoption period needs enough repository history from before Baz was onboarded. Without it, the chart still shows the live trend, just without a comparison band.

What does the percentage next to a chart title mean?

The change against the previous week, with the direction colored by whether it is an improvement for that metric. A drop in time to merge is an improvement; a drop in bugs detected is not necessarily one, which is why the two are read together.

Was this page helpful?