Introducing the Findings Page: A new way for engineering leaders to see risk across their codebase

Code review used to happen one pull request at a time. A reviewer opened a PR, worked through the changes, left comments, and moved on. That model held up when humans wrote most of the code and shipped it at human speed. That assumption is starting to break down. AI now writes a meaningful share of the code moving through pull requests, and the volume keeps climbing. The people responsible for the health of the codebase, engineering managers and team leads, no longer have a clean way to step back and see what is actually entering their systems.

Today we are releasing v2.3 of the Qodo platform with a new view in the Qodo portal that closes this gap. This new findings page, available in beta for all Gits (GitHub, GitLab, BitBucket and Azure DevOps), consolidates every issue Qodo has surfaced across your reviewed pull requests. Users get analytics that give a high-level overview of risk across their codebase and can filter to dive deeper into specific issue types, repos and more.

Why PR-by-PR review is no longer enough

If you manage an engineering team right now, you can probably answer a question about any single pull request your team shipped this week. What you likely cannot answer, at least not quickly, is the version of that question that spans your whole org. How many issues did Qodo catch and fix across our repos this month? Which services are accumulating the most risk? Whether the quality of reviews on the payments team is improving or sliding. Whether the same issues are getting flagged for the same things over and over.

These are the questions that come up in staff meetings, in board prep, and in conversations with security. Answering them used to mean stitching together Slack threads, asking around, or pulling a spreadsheet together by hand. The Findings Page is built to answer them in seconds.

Inside the Findings Page: analytics 

The page has three parts, and they work together.

The analytics row sits at the top of the page. It shows total critical findings, the percentage of findings that have been resolved, and the average findings per PR. That gives you the high-level read on volume, throughput, and trend without having to open anything.

Below the analytics, a set of filters lets you cut the data the way you actually need it. Filter by repo to focus on a specific service. Filter by owner to look at a team or an individual contributor. Filter by issue type to pull up only security findings, only bugs, or whatever category matters in the moment.

Underneath the filters is the full list of every issue Qodo has surfaced across your reviewed pull requests, searchable and sortable. When something stands out in the analytics or in the filtered view, you can drill straight into the underlying PR.

What engineering leaders can do with it

The reason the Findings Page exists is to give engineering leaders three things they have been asking for.

The first is the ability to answer leadership questions without going on a fact-finding mission. How many issues has Qodo caught and helped fix. What is our resolution rate? The data is already there, and now it is in one place.

The second is risk-based triage. Volume by itself is not the right signal. The Findings Page lets you filter to security or critical issues only and then look at which PRs, which repos, and which owners are driving the most exposure. That is where attention should go first, and the page makes it easy to find.

The third is trend awareness across teams. Over time, you can see where review quality is improving and where it is not. You can spot the repos that consistently generate the most findings, the teams that are accumulating standards drift, and the patterns that suggest a coaching opportunity or a rule worth adding. The Findings Page turns review data into something you can actually manage with.

What this means for the future of code review

When AI started writing real volumes of code, it changed what code review needs to be. Review had to get faster, more contextual, and more consistent at the PR level, and that is most of what Qodo has been building. The Findings Page is the natural next step. As AI scales code production, review has to scale into a portfolio-level discipline, with leaders able to see across teams and repos the same way they see across any other part of their operation.

This is the first release in that direction, and there is more coming. For now, the goal is straightforward. Give engineering leaders a single view of every issue Qodo has caught, the analytics to make sense of it, and the filters to act on it.

Get started with the Findings Page

The Findings Page is available now in beta. If you are already using Qodo, your team can start exploring it in the portal. If you are new to Qodo and want to see the Findings Page in action, get in touch and we will set you up.