Skip to main content
Qodo’s code review surfaces feedback directly inside your pull requests, structured incrementally from context to individual findings, so you can read, prioritize, and act on it without wading through noise. Each finding focuses on what requires attention and why, with clear links back to the relevant code. This page is a reference for that structure: each section below corresponds to a part of the pull request, in the order it appears.
New to Qodo? It’s recommended to read this reference page top to bottom. Already reviewing a pull request? Skip ahead to Unpack a code review finding.

​
Pull request summary

Before presenting individual issues, Qodo provides context to help you understand what changed and why it matters. For more information about how this context is generated and configured, see Generate a PR summary.
Pull request summary comment showing tags, walkthroughs, and file changes
This includes the following sections:
Qodo adds an AI-generated summary of the pull request’s intent and impact.
  • By default, the summary is posted as a standalone comment and your original pull request description stays unchanged.
  • You can also configure Qodo to merge the summary into the native pull request description.
This helps reviewers align quickly on the purpose of the pull request.
Qodo tags each pull request and estimates how long the review will take, so reviewers can prioritize before opening a single file. Tags include: Bug fix, Tests, Enhancement, Documentation, and Configuration changes.
Qodo breaks down the change in detail:
  • Description: A plain-language breakdown of what changed and why.
  • Diagram: An architecture diagram showing the flow and connections introduced by the change.
  • High-Level Assessment: Suggestions and alternatives for the author and reviewer to consider before or during review.
Expanded diagram walkthrough showing the architecture flow and connections introduced by a pull request
Qodo provides a file-level overview of the pull request.For each modified file, you can see:
  • The file path
  • The type of change (for example, Bug Fix or Enhancement)
  • Lines added and removed
This helps reviewers understand the scope of the change set before examining individual findings.

​
Code review findings overview

After providing context, Qodo presents a findings overview covering category counts, the context behind the review, and each finding’s quality impact and severity.
Code review findings overview showing category counts, severity groups, and resolved findings with strikethrough
This includes the following sections:
Findings are grouped by category, with counts for each type.This overview gives you an immediate sense of the review’s focus and severity.
When a review draws on additional context, such as rules, skills, or cross-repo context, Qodo displays a Context sources section listing exactly what was applied.The section also carries the review’s routing summary: a line such as “2 issues published inline · 3 in summary” showing at a glance how the findings were split between inline comments and the summary. Routing is controlled by the Comments settings.
Context sources section showing compliance rules, skills, and cross-repo context applied to the review
When web search contributes to a finding, the Context sources section also lists the external sources the agent referenced, such as official documentation, release notes, or specifications.
Web search results shown in a pull request finding
When cross-repo context contributes to a cross-repository conflict finding, the Context sources section also links to the relationship behind it. Each explored repository has a View relationship link. Click it to open that relationship in the Relationships tab. Access follows your organization’s portal permissions. For more information, see View cross-repository conflicts.Disable the Show context setting to exclude this section from the code review, for example if it adds noise for your own tooling that parses Qodo’s PR comments. For more information, see Configure Qodo using the portal.
In addition to categories, each finding includes a quality impact label. This label indicates which quality dimension is affected by the issue.Common labels include:These labels provide quick semantic context, helping you understand what kind of quality is impacted before diving into the full issue details.
Findings showing quality impact labels such as Rule violation, Reliability, Bug, and Correctness
Findings are grouped by severity, making it clear what needs attention first.High, Medium, and Low are the default severity labels. You can rename them using the Severity terminology setting. For more information, see Configure Qodo using the portal.This prioritization helps you focus on what matters most without losing visibility into the full set of findings.
Findings grouped into High, Medium, and Low severity groups, each showing quality impact labels
As you push new commits, Qodo marks the findings that no longer need action. A resolved finding is struck through and shows only its status, which keeps the focus on the open findings. Each resolved finding has one of these statuses:
  • ✓ Resolved: A later commit fixed the issue.
  • ✗ Dismissed: The finding was dismissed without a fix and no longer needs action.
  • ⊖ Outdated: The code the finding referred to was removed or rewritten. The finding no longer applies.
By default, resolved findings stay in their group. You can move them to a separate Resolved findings section after the open findings, or hide them entirely. For more information, see Track resolved findings.

​
Unpack a code review finding

Each finding can be expanded to reveal full details. You can access findings:
  • From the prioritized summary list
  • Inline, directly in the Files changed view
Collapsed findings list grouped by severity, before expanding an individual finding
Regardless of how you access it, each finding presents the same structured information. Click each tab below to see the different elements of a finding:
A clear, human-readable explanation of the issue and its potential impact.
Code review finding description explaining the issue and its potential impact
Findings from all pull requests are also tracked centrally in the Qodo portal. For more information about filtering and monitoring findings across all repositories, see Monitor organization-wide pull request findings.

​
Previous reviews (formerly Audit trail)

Qodo keeps a collapsible Previous reviews section in the comment, showing the history of past review runs on the pull request. It renders like the comment’s other collapsible parts (Context sources, Tip of the day) and sits between the daily tip and the footer:
  • A Review updated until commit line links to the commit the current review reflects.
  • Each earlier commit has its own collapsible Results up to commit entry.
  • A review-mode badge, for example 🚀 Fast or ⚖️ Balanced, shows which mode produced the review.
  • Expanding an entry surfaces the full set of findings from that earlier review run. Findings that were later resolved appear struck through with a resolved mark, reflecting the current state of every finding.
This helps reviewers see how the review evolved as new commits were pushed. Disable the Show previous reviews setting, under Comment parts in the portal’s Display tab, to hide this section from the review comment. For more information, see Configure Qodo using the portal.
Previous reviews section showing review history up to each commit

​
Native pull request labels

Beyond the review comment itself, Qodo can publish select signals as native labels directly in your Git provider’s pull request interface, for example in the Labels sidebar or the pull request list.