Qodo 2.2: Code Review That Learns From Your PR History

Today, we’re releasing the 2.2 version of Qodo’s code review platform, introducing a PR Knowledge System as part of our Context Engine, along with a new Finding Recommendation Agent that uses PR history context to ensure every issue Qodo surface is precise and relevant to the specific team and repo.

This feature is currently in Beta and supported for GitHub. GitLab, Bitbucket and Azure DevOps coming soon. 

Codebases Have Memory

Every engineering team has their own unique way of solving problems and every codebase has a history. Thousands of pull requests each carry small signals about how a team works. These signals form the collective memory of the repository. They explain why a function was refactored six months ago, why one library replaced another, or why reviewers consistently flag a certain pattern.

Over time these signals reveal what the team cares about, what patterns they follow, and what problems they try to prevent. That knowledge rarely becomes formal documentation, yet it plays a central role in how teams review code. Until now, AI code review has had no access to that context.

With this latest release, those buried insights become a functional source of context for high-precision code.

Introducing PR Knowledge and the Finding Recommendation Agent

Qodo 2.2 introduces two connected capabilities:

The PR Knowledge System indexes a repository’s pull request history and builds a structured understanding of how the team reviews code.

On top of that, the new Finding Recommendation Agent evaluates every potential issue against this historical context to determine which findings are most relevant to the team.

Together, these systems transform PR history from passive archive into active review intelligence.

More sources of context

Qodo’s PR Knowledge System expands Qodo’s best-in-class Context Engine, which gathers and organizes the data needed to understand code in its real environment. It analyzes the code changes, the surrounding codebase, and organizational standards so the review agents can reason about the change with meaningful context rather than just the raw diff.

Pull request history adds a deep layer of context that review agents can draw on from past PRs, review discussions, and decision patterns to understand how the repo has evolved over time. This gives the system visibility into the reasoning behind earlier changes and the standards that emerged through real review decisions.

With this context, Qodo’s new Finding Recommendation agent evaluates each issue surfaced against how the team has handled similar situations before. This helps prioritize or tune suggestions that are likely to lead to real code changes and reduces comments that developers typically ignore.

The result is a review experience designed for high-precision feedback, where developers spend less time filtering noise and more time acting on the issues that matter.

Reviews Without PR History

Without historical PR context, reviews tend to produce high volumes of findings but low signal. Developers see many comments, but fewer that clearly connect to how the team actually builds and maintains the system.

This lack of context leads to several common gaps.

Suggestions feel disconnected from the repository. The review may surface technically valid findings that do not reflect how the team structures code or resolves issues.

Past decisions are invisible. The system may suggest patterns that were already debated and replaced in earlier pull requests.

Recurring issues are harder to recognize. Without visibility into past reviews, the agent cannot easily identify patterns that have appeared before in the repository.

The outcome is predictable. Reviews begin to generate repeated or irrelevant comments, important patterns and regressions are harder to detect, and known issues can reappear in production unnoticed.

Without PR history, the review agent sees the repository as a snapshot of code.  With PR history, it understands the story behind it.

Turning PR History into Review Intelligence

The PR Knowledge System makes PR history a working part of Qodo’s review workflows.

The system begins by indexing merged pull requests across the repository. It captures metadata, code diffs, review comments, and discussion threads. Each of these elements contains signals about how the team evaluates code and resolves issues.

From this data, Qodo builds a structured knowledge base of past review activity. The system analyzes how developers responded to feedback, which suggestions resulted in code changes, and which comments were ignored. Some findings consistently lead to fixes. Others trigger discussion. Some rarely result in a change. These patterns reveal the standards that actually guide the team’s development process. Over time, this creates a behavioral record of the team’s review priorities. PR Knowledge uses these patterns to inform future reviews.

High-Precision Issue Finding

Automated reviews often generate a large list of possible issues. Many are technically correct, but only a small portion lead to code changes. Developers end up scanning through comments to find the few that matter. The goal of PR Knowledge is to produce the right findings that are most critical and relevant.

When Qodo analyzes a new pull request, the Finding Recommendation Agent compares each potential issue with similar situations in past PRs. The system looks for signals such as:

• Similar issues raised in past pull requests
• How reviewers responded to those issues
• Whether the team changed the code in response
• Whether the suggestion sparked discussion or was ignored

For every finding, the agent uses this context to evaluate whether the team is likely to act on it. Suggestions that align with past review decisions are prioritized.

Findings that historically receive little attention are deprioritized. Instead of presenting a long list of possible problems, Qodo focuses attention on the findings that match the team’s real review behavior.

A System That Learns With Your Repository

Qodo’s PR Knowledge System operates as a continuous learning loop. Each merged pull request becomes part of the knowledge base. New review discussions, decisions, and code changes update the system’s understanding of how the team reviews code.

As the repository evolves, the review system evolves with it. This allows the platform to adapt to new standards, architectural changes, and shifts in development practices without manual configuration.

The result is a system that captures the institutional memory of the repository, moving beyond deterministic, “one-size-fits-all” AI that treats every codebase the same.