Hello Devs 👋
When teams talk about engineering metrics, the conversation usually moves toward speed. We often look at things like pull request turnaround time, lead time, deployment frequency, and how quickly changes move through the system.
These are useful metrics because they tell us how efficiently work is flowing through the development process. But after spending time on larger projects and working across different teams, I started noticing that speed alone doesn't always tell the full story.
I've seen teams merge pull requests quickly and still spend a lot of time later dealing with repeated issues, hotfixes, and bugs that somehow escaped review. I've also seen teams with slower review cycles that ended up having fewer production issues because they consistently caught missing pieces earlier.
That made me think about whether we sometimes focus too much on how fast reviews move and not enough on whether reviews are actually helping improve code quality.
Let's get into it 🚀
⚡ Quick Verdict
Qodo is probably one of the better options if your goal is not just measuring review speed but understanding review quality across a team. Instead of only showing statistics around pull request activity, it tries to surface patterns that are easy to miss during day-to-day development. Things like recurring issues, repeated review findings, critical problems appearing across repositories, and whether developers are actually resolving suggestions start becoming visible.
That becomes more useful as projects grow because the challenge usually changes over time. In smaller projects, the focus is often on moving code quickly. In larger systems with more developers and more pull requests, the bigger challenge becomes understanding whether the same problems keep appearing repeatedly and slowly affecting quality.
The Problem With Looking Only at PR Velocity
Let's imagine two teams.
Team A has an average review time of around 15 minutes. Pull requests move quickly, deployments happen frequently, and every dashboard looks healthy.
Team B takes closer to 40 minutes on average to review pull requests. From the outside it initially looks like Team B is moving more slowly.
But after a few months, a different picture starts appearing.
Team A repeatedly runs into missing edge cases, production fixes, and review discussions that seem strangely familiar. Reviewers continue asking for missing tests, validation updates, and similar changes over and over again.
Team B, despite taking longer during reviews, catches many of these issues before code reaches production.
At that point the discussion becomes less about "Which team reviews faster?" and more about "Which team is preventing problems from repeating?"
That difference is important because pull request speed by itself doesn't tell us whether reviews are actually doing their job.
Metrics I Think Teams Ignore Too Often
I don't think these replace DORA metrics or existing engineering metrics. I think they help explain the things happening underneath them.
Repeated Review Comments
Most teams eventually start seeing the same comments appear repeatedly in reviews.
Things like:
Missing test coverage
Validation missing
Logging not updated
Missing null handling
If reviewers repeatedly ask for the same fixes, there is usually something deeper happening. It often means team standards are unclear, patterns are not consistently enforced, or reviewers are spending time doing repetitive work that could probably be automated.
Over time this also creates review fatigue because developers and reviewers start seeing the same discussions repeatedly.
Resolution Rate
This was one of the more interesting things I started thinking about.
Detecting issues isn't necessarily difficult. Most tools can generate findings and suggestions. The more important question is whether developers actually resolve them.
Let's imagine your team detected 150 review findings this month. That initially sounds useful.
But then imagine that only 50 of those findings actually got resolved.
Now the discussion changes. Instead of asking how many issues were found, you start asking whether developers trust the findings enough to act on them. If suggestions consistently get ignored, then the issue may not be lack of detection. The issue might be noise.
Average Findings Per Pull Request
This metric becomes interesting when you stop looking at it as a fixed number and start looking at trends.
Let's say your average findings per pull request increased from 1.4 to 4.8 over a few months.
That increase by itself doesn't automatically mean quality became worse.
Maybe AI-generated code started becoming part of the workflow. Maybe more developers joined the project. Maybe complexity increased as new services were added.
The actual number isn't usually the important part. The trend and the reasons behind it tend to reveal much more.
Critical Findings Across Repositories
Some issues never fail CI and never break builds.
Examples might include:
- Missing authorization checks
- Dependency-related risks
- Missing audit logging
- Breaking changes in shared services
If you see one isolated issue, it may not look important.
But if similar issues repeatedly appear across repositories and teams, they stop feeling like isolated bugs. At that point they start looking more like process problems or architectural patterns that need attention.
What Made Me Think About This
Recently I was reading about Qodo's Findings page and the idea behind it caught my attention.
Most review feedback today lives inside pull requests. Someone opens a PR, reviewers leave comments, fixes get pushed, and eventually the pull request gets merged. After that, the conversation mostly disappears.
The problem with that workflow is that patterns disappear too.
The Findings page tries to look across repositories and over longer periods of time by surfacing things like recurring findings, critical issues, resolution trends, and repeated review patterns.
What I found interesting wasn't really the feature itself. It was the way it changes the perspective.
If the same validation issue appears in thirty pull requests over two months, that no longer feels like an individual PR issue. It starts feeling like a signal that something larger is happening in the team's workflow.
You can read more about monitoing organization-wide pull request findings here: https://docs.qodo.ai/governance/view-all-findings-in-organization
A Practical Example
Let's imagine your team created 150 pull requests over the last month.
The dashboard initially looks healthy because review time is improving, deployment frequency has increased, and pull requests are moving smoothly.
But when you start looking deeper, you notice that 42 pull requests had missing test coverage, 28 repeated similar validation problems, and dependency-related risks kept appearing across multiple repositories.
The conversation naturally becomes more useful because people stop asking why reviews are slow and start asking why the same problems continue appearing repeatedly.
That usually leads to more meaningful improvements because now the focus shifts from speed alone toward improving the development process itself.
📚 Want to Read More?
If you want to explore this area further, Qodo has a learning hub with a few useful resources around AI-assisted review workflows and code quality.
Some good starting points are:
What is AI Code Review
A good introduction to how AI review works and the kinds of problems it tries to catch.
Reviewing AI-generated Code
Covers common patterns and mistakes teams are seeing as AI-generated code becomes more common.
AI Code Review Tools Comparison
Useful if you want to understand how different approaches and tools compare.
Final Thoughts
Metrics like deployment frequency and lead time still matter and they will continue to matter. But they don't always explain why teams repeatedly run into certain problems.
As development teams generate more code and AI continues increasing review volume, understanding review quality probably becomes more important too.
Questions around recurring findings, issue resolution, and repeated patterns often tell a more complete story than review speed alone because they reveal the hidden work that teams keep paying for repeatedly.
A fast pull request is useful, but a healthy review process is usually much more valuable over time.
Thank You!!🙏
Thank you for reading this far. If you find this article useful, please like and share this article. Someone could find it useful too.💖
Top comments (0)