Software engineering metrics used to be a throughput story: more PRs, shorter cycle time. With agents opening a large share of PRs, throughput can look great while risk builds up underneath. Risk debt looks exactly like progress on a dashboard that only counts commits.
The numbers show the gap. Comparing each organization's periods of low and high AI adoption, median time in PR review rose 441.5%, the incidents-to-PR ratio more than tripled, and bugs per developer rose 54%, according to the Faros AI Engineering Report 2026, as cited in a Qodo webinar on August 25, 2026.
The Faros data is vendor telemetry and correlational, not a year-over-year trend.
I've built review scorecards for engineering orgs with hundreds of repositories, and measuring review is part of every type of code review I describe in my code review guide. Here are the 10 engineering metrics I'd put on a leader's scorecard:
- Time to first review (pickup time)
- Review time to approval
- PR cycle time
- Rework rate and code churn
- Escaped defects
- Review comment acted-on rate
- AI review signal-to-noise
- Standards violations merged
- Change failure rate and time to restore
- AI traceability and adoption
What Are Code Review Metrics?
Code review metrics measure how changes move through review and what review catches. They're a subset of engineering metrics, the wider group of measurements of how a software team plans, builds, reviews and ships.
Three terms get mixed up. Engineering metrics measure anything about the delivery system. Engineering KPIs are the few metrics with a target and an owner. Developer productivity metrics focus on output and experience, and are the easiest to misuse.
Engineering Metrics vs KPIs
A metric measures; a KPI commits. Time to first review is a metric. "Median time to first review under four working hours, owned by each team lead" is a KPI.
Software engineering KPIs should be few: three to five per level of the org. Pick them from the metrics below, give each one an owner, and review them monthly. Everything else stays a diagnostic metric that you look at when a KPI moves.
The 10 Engineering Metrics for Code Review
Each metric below has four parts: what it is, how to measure it, the vanity trap, and what a healthy signal looks like.
1. Time to First Review (Pickup Time)
Pickup time is the gap between a PR being ready for review and the first review action. Measure the median and the 75th percentile, split by PR author type: human, AI-assisted and agent.
The trap is a quick average hiding a long tail of agent PRs nobody wants to pick up. A healthy signal is a stable P75 across author types.
2. Review Time to Approval
Review time runs from the first review to approval. The time from review submission to approval rose after firms adopted AI agents, and so did the number of PRs opened, according to the Harvard and Jellyfish working paper by Chen and Stratton (November 1, 2026 version). The paper is observational and not peer-reviewed.
The trap is reading a shorter review time as a win when reviewers are skimming. Pair it with metric 5. A healthy signal is review time that holds steady as PR volume climbs.
3. PR Cycle Time
PR cycle time runs from the first commit to merge. Track review cycles until merge as a sub-metric: how many rounds of changes requested before approval. Cycle time is a big part of lead time for changes, one of the four DORA metrics.
The trap is optimizing cycle time by merging bigger PRs less often. A healthy signal is short cycle time with one or two review rounds for most PRs.
4. Rework Rate and Code Churn
Code churn is code rewritten or deleted soon after it merges, usually within two to three weeks. Rework rate is the share of merged changes that need a follow-up fix. Both show what review missed.
The trap is blaming authors, because churn often points to unclear specs. A healthy signal is falling churn on agent-written code.
5. Escaped Defects
Escaped defects are bugs found after merge, in staging or production, that review could have caught. Tag each incident and bug with the PR that introduced it. The trap is counting only production incidents, which arrive too late to learn from. A healthy signal is a falling share of defects traced to reviewed PRs.
6. Review Comment Acted-On Rate
The acted-on rate tells you whether review comments matter. The formula is simple: comments acted on divided by comments posted, where "acted on" means the author changed the code in response. Track it separately for human and AI comments.
The trap is chasing a high rate by posting fewer, safer comments. A healthy signal is a stable acted-on rate as coverage grows.
7. AI Review Signal-to-Noise
More review bots aren't the answer when every generic comment becomes one more thing a senior engineer has to read. Signal-to-noise measures how consequential AI findings are, not how many there are.
Measure the share of high-severity AI findings that get fixed, and the share dismissed. The trap is raw finding volume. A healthy signal is fewer, sharper findings.
8. Standards Violations Merged
A merged violation is a change that broke a written team standard and merged anyway. Count violations detected, violations fixed before merge, and violations merged. The trap is having no written standards, so nothing counts as a violation. A healthy signal is merged violations trending down while detected violations stay visible.
9. Change Failure Rate and Time to Restore
Change failure rate is the share of deployments that cause a failure in production, and time to restore is how long recovery takes. Both are DORA metrics, and review quality feeds them directly. The trap is treating them as an ops problem only. A healthy signal is a falling failure rate as review coverage grows.
10. AI Traceability and Adoption
AI traceability links AI activity, such as an agent session or a suggestion, to the code changes that came out of it. Only 45.0% of leaders said they have that traceability in Qodo's State of AI Code Quality 2026 survey.
Track the share of merged changes with a known origin. The trap is measuring AI adoption alone. A healthy signal is full traceability on high-risk repositories.
Pull Request Metrics vs Outcome Metrics
Pull request metrics, numbers 1 to 3, measure flow: how quickly changes move through review. Outcome metrics, numbers 4 to 9, measure quality: what review caught and what it missed. You need both, because flow without outcomes rewards rubber-stamping.
Qodo's glossary entry on engineering productivity metrics covers the wider list. PR size matters too, as an input to every flow metric.
Code Quality Metrics That Belong in a Review Scorecard
Most code quality metrics, such as complexity and test coverage, belong to static analysis dashboards. For a review scorecard, four are enough: escaped defects, rework rate, standards violation trends and code churn. Together they show whether review is catching what it should.
Qodo's list of code quality metrics for large engineering orgs covers the static analysis side.
How Code Review Metrics Connect to DORA
DORA's four key metrics are lead time for changes, deployment frequency, change failure rate and time to restore service. Code review sits inside two of them. Lead time includes every hour a PR waits for review, and change failure rate includes every defect review missed.
A worked example, with illustrative numbers: a team's lead time for changes is 30 hours. Pickup time is 10 of those hours, and review cycles add another 6. Cutting pickup time to 2 hours and review rounds from three to two takes lead time to roughly 20 hours, with no change to coding speed.
Don't cite "DORA 2026" figures. The DORA team announced in September 2026 that it wouldn't run a survey this year, according to LeadDev's report on DORA's next steps. Use the metric definitions, and your own data, as the benchmark.
The SPACE Framework
SPACE adds satisfaction, performance, activity, communication and efficiency to the picture. For review, the useful lens is satisfaction: ask reviewers whether review load is sustainable.
Metrics for AI and Agent-Written Code
Agent-written code needs its own slice of every metric above. Split pickup time, acted-on rate and escaped defects by author type, because an average across humans and agents hides the difference.
Visibility is the gap for most leaders. Only 39.3% of leaders said they have visibility into AI code-quality trends, and 29.7% said governance and visibility is where they risk losing control, in Qodo's State of AI Code Quality 2026 report. Censuswide surveyed 300 US leaders in August 2026, self-reported.
Confidence is a separate matter, with 90.0% of leaders in the same survey saying they feel confident reporting AI's impact to the board. Confidence and visibility measure different things, so report both.
Weight metrics by risk, not by line count. Most AI review applies the same effort everywhere, but effort should follow blast radius, ownership, incident history and how easily a change can be reversed. A metric that treats a UI copy change and an auth change the same will mislead you.
Qodo's Auto mode works the same way, picking Fast, Balanced or Deep review by the risk of each PR, so effort and metrics follow risk together.
Qodo's guide to AI code governance covers how platform teams connect these metrics to policy.
Measuring Review Across Many Repos
Metrics get hard at scale. Roll each metric up across repositories and Git providers, then slice by team and by risk tier. Track cross-repo changes separately: a change that breaks a consumer in another repository won't show up in that repository's own metrics.
Enterprise teams need one review layer that reports across the org. Qodo's code review analytics roll findings up across the organization in one dashboard, and Rules analytics covers GitHub, GitLab, Bitbucket Cloud and Azure DevOps.
Avoiding Vanity Metrics
Four metrics look good and tell you little on their own: lines of code, PR count, AI acceptance rate and comments per review. Each one climbs when agents generate more, whether or not the code is any good.
The pressure is real, with 60% of developers saying AI usage is treated as a productivity signal at their company, in Atlassian's State of DevEx 2026 survey. The figure is self-reported from a vendor survey.
How to Report Engineering KPIs to Leadership
A one-page scorecard works best in four blocks: flow (pickup time and cycle time), quality (escaped defects, rework and violations merged), risk (change failure rate and time to restore) and AI (acted-on rate, signal-to-noise and traceability). Show the trend over the quarter for each, with one line on what changed and why.
For the budget side of the conversation, Qodo has a guide to building a business case for AI code review.
My Experience Building a Review Scorecard
The scorecards I see ignored share one trait: they track everything. A dashboard with every metric gives leaders nothing to ask about. The ones that get read are short, grouped into flow, quality, risk and AI, with one owner for each number.
Each number on a good scorecard comes with a question a leader can put to a team lead, such as why merged violations rose in one repository this quarter.
How to Track These Metrics
Leaders can count PRs, but most can't tell whether review findings matter or whether standards hold. Git analytics and engineering intelligence platforms cover flow metrics 1 to 3 well. Metrics 6 to 8 have to come from the review layer itself.
Qodo Review reports metrics 6 to 8 in my stacks. Qodo's code review analytics show acted-on versus accepted findings by repository, PR author, severity, category and type, including bugs, rule violations, requirement gaps, security and cross-repo findings, over ranges of up to 365 days.
For metric 7, Qodo reports an acceptance rate on high-severity findings: findings accepted, not accepted or dismissed, with pending ones left out.
Qodo's Rules analytics show rules passed, violations detected, violations merged, and rules that Qodo deactivated because their findings were rarely fixed. Every finding is logged and exportable for audits as CSV, and severity routing keeps the signal-to-noise metric honest.
Before the PR, coding agents run the same review through the Qodo Agentic Toolbox, with Codebase Wisdom supplying the codebase context and Git history, via the qodo review CLI, MCP, and plugins for Claude Code, Codex and Kiro.
Choose Qodo if you need metrics 6 to 8 from the review layer itself, with findings broken down by severity and Rules analytics on GitHub, GitLab, Bitbucket Cloud and Azure DevOps. Pair it with your existing engineering metrics dashboard for flow and DORA metrics.
High-velocity teams use the same numbers to merge sooner and more safely: when acted-on rates hold and merged violations fall, reviewers can trust more PRs on the first pass.
Qodo isn't focused on test generation, even though some authors still point to it as a key strength. In my experience, Qodo is best at AI code review and code governance for turning review findings and rule outcomes into metrics leaders can act on.
For a longer take on measurement at scale, Qodo's blog covers measuring engineering productivity in distributed teams.
For how peer review itself works across time zones, see my guide to peer code review.
Summary
Track ten code review metrics in four groups: flow (pickup, review time, cycle time), quality (rework, escaped defects, merged violations), AI (acted-on rate, signal-to-noise, traceability) and risk (change failure rate and time to restore). Split each by author type, weight by risk, and report a handful as KPIs with owners.
FAQ
How do you measure engineering team performance?
Combine flow metrics, such as pickup time and cycle time, with outcome metrics, such as escaped defects and change failure rate. Pick three to five as KPIs with owners, and review them monthly alongside a short developer survey.
What are examples of software engineering metrics?
Common examples are PR cycle time, time to first review, deployment frequency, change failure rate, code churn, escaped defects and review comment acted-on rate. The DORA metrics are the best-known group.
What's the difference between engineering KPIs and engineering metrics?
An engineering metric measures something about delivery. An engineering KPI is a metric with a target and an owner, chosen because it matters to the business.
What is code churn, and why does it matter for review?
Code churn is code rewritten or deleted soon after merging. High churn often means review missed something, or the spec was unclear, so it's a useful signal for review quality.
How do you measure whether AI code review comments are useful?
Track the acted-on rate: comments that led to a code change, divided by comments posted. Split it by severity, and watch the share of high-severity findings that get fixed.
Are DORA metrics still relevant in 2026 without a new DORA report?
Yes. The four DORA metrics are still a sound way to measure delivery, even though the DORA team isn't running a 2026 survey. Benchmark against your own trend rather than an annual report.
Does Qodo measure test coverage?
No. Test coverage comes from your CI and static analysis dashboards. Qodo measures the review layer: which findings were acted on, which rules were violated and merged, and which rules Qodo deactivated because their findings were rarely fixed.
Top comments (0)