Qodo Merge: what the PR review product became

Qodo Merge in the current product map

Qodo Merge was the branded commercial product for AI-assisted pull request review. It analyzed a proposed change, generated a description, reviewed risks, suggested improvements, answered questions, applied selected changes, labeled the pull request, and connected the output to GitHub, GitLab, or Bitbucket workflows. The product grew from the open-source PR-Agent project and kept its recognizable slash commands and .pr_agent.toml configuration style.

Qodo no longer uses Qodo Merge as a primary product name. Its current mapping page says Qodo Merge is now Git, Qodo Gen is now IDE, Qodo Command is now CLI, and Qodo Aware is now Context Engine. The current commercial story is one Qodo platform for code review, context, rules, governance, and developer tools. The 1.x documentation remains available through a version selector for customers and searchers who still operate the earlier workflow.

What Qodo Merge did

Qodo Merge treated the pull request as an interactive work surface. A review could run automatically when a pull request opened, reopened, became ready, or received another push. Developers could also invoke a tool in a comment. The result stayed attached to the pull request, which reduced context switching and made the bot available to authors and reviewers without a separate application.

The review tool could check for tests, estimate review effort, flag possible security concerns, assess whether a pull request should be split, and compare implementation with a linked GitHub or Jira ticket. Configuration could enable scores, labels, extra instructions, and automatic commands. The improvement tool served the author by returning more immediately actionable change suggestions, while review output was aimed at the person deciding whether the change was ready.

The commands were composable. A repository could run /describe, /review, and /improve on opening, then run description and review again when new commits arrived. This made the tool behave like workflow automation instead of a one-time chat request. It also created budget and noise implications because every trigger represented review work and another set of output on an active pull request.

How automation and configuration worked

The 1.x documentation used provider-specific sections in a .pr_agent.toml file. Teams could select which pull request actions triggered the app, which commands ran on open or push, which paths were ignored, how output appeared, and which extra instructions guided a tool. This file made behavior reviewable with the code and allowed repository-level control, while organization-level configuration could supply shared defaults.

[github_app]
handle_pr_actions = ["opened", "reopened", "ready_for_review"]
pr_commands = [
  "/describe --pr_description.final_update_message=false",
  "/review",
  "/improve",
]
handle_push_trigger = true
push_commands = [
  "/describe --pr_description.final_update_message=false",
  "/review",
]

[pr_reviewer]
extra_instructions = "Focus on authorization boundaries and missing tests"

The configuration file is powerful because it turns a bot installation into repository policy. It is also a compatibility surface. A renamed key, changed default, new product version, or provider difference can change review behavior. Pin expected output in a small test repository, review configuration changes like code, and keep a migration note that records the Qodo version and Git provider.

Extra instructions need the same discipline as engineering rules. "Review security" is broad and hard to evaluate. "For handlers under payments/, trace authorization before any state change and require an integration test for replay" is scoped, observable, and reviewable. Keep instructions concise enough that they guide the relevant tool without drowning the code context.

How Qodo 2.x changes the review model

Qodo 2.0, released on 4 February 2026, moved the commercial review architecture toward specialized agents. Qodo lists critical issue detection, duplicated logic, ticket compliance, and standards enforcement as separate responsibilities. The agents use repository context, repository structure, pull request history, and rules, then publish prioritized findings with remediation guidance. This replaces the mental model of one slash command producing one broad report with a system that can allocate review work by concern.

Qodo 2.1 added the Rule System for centralized standards. It can convert existing rules, generate structured rules from natural language, discover implicit standards, detect duplicates or conflicts, and apply scope at organization and repository levels. Qodo 2.2 added portal configuration and a beta PR-history relevance section for some GitHub enterprise deployments. Qodo 2.3 added a cross-organization Findings page in beta, with filters and 30-day analytics.

The value of the 2.x model is deeper context and more governable policy. The migration risk is semantic drift. A legacy /review section that reviewers understood may become several prioritized finding classes with different severities and visibility. Run both modes against historical pull requests where possible, compare true findings and noise, and update branch policy only after the new output is predictable.

Qodo Merge against PR-Agent

The shared origin makes this distinction easy to blur. PR-Agent supplied the open-source command model and codebase. Qodo Merge was the hosted commercial evolution with managed integrations and enterprise features. In 2026, Qodo donated the repository to the community. It now lives under The-PR-Agent, carries an MIT license, and describes itself as a community-maintained legacy project of Qodo that is separate from the commercial Qodo offering.

The open-source commands still resemble the legacy workflow: /describe, /review, /improve, and /ask, plus local CLI invocation. The repository documents GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea support across several tools and deployment forms. It can route to many models and lets operators change prompts and configuration deeply. Those strengths come with version, secret, webhook, permissions, and model-cost ownership.

Pricing after the Merge name

Searches for Qodo Merge pricing lead into the current unified Qodo price. Pro Team starts at $30 per month for 2,500 shared credits at $0.012 each, designed for up to 30 users. Qodo estimates that allowance at about 18 reviews and lists 5,000 and 20,000-credit options for higher volume. Review complexity changes consumption. Overage continues at the same credit rate until a customer-set monthly cap is reached, and unused credits expire at the cycle boundary.

The trial lasts 14 days, requires no credit card, and advertises unlimited credits and reviews during the trial. There is no permanent general free plan after it ends. Qualified open-source projects can apply to Qodo's open-source program. Enterprise is quoted and includes additional governance, identity, deployment, analytics, model, and support controls.

A migration should forecast credits from actual review triggers. Legacy installations that ran description, review, and improvement on open and then repeated two tools on every push may have a very different consumption profile from a current 2.x deployment tuned to prioritized findings. Count review events, incremental pushes, excluded paths, and accepted findings during the trial before selecting a pack.

Migration checklist from Qodo Merge to current Qodo

Migration is more than changing a product label. The review architecture, configuration authority, finding categories, rule system, portal, billing unit, and open-source relationship have moved. Treat the change as a review-policy migration and preserve evidence about old behavior until the new path has run through several real releases.

Run a shadow period after configuration mapping. Let the current Qodo review post advisory findings beside the legacy review on the same pull requests, then label matches, new true findings, new false positives, missing legacy findings, and severity changes. Keep both outputs from triggering fixes automatically, since parallel reviewers can otherwise edit the same branch and destroy the comparison. The shadow sample should include ordinary pull requests, a large generated change, a ticket-driven change, a security-sensitive path, and several rapid pushes. Record credits and elapsed time for the current path while the legacy path still provides a behavioral reference. End the shadow only when reviewers can explain the new finding model, branch protection has a tested outage path, and rule owners have accepted the mapped policy. Disable legacy triggers before removing old configuration, secrets, or app permissions. A staged removal preserves rollback and makes stale webhook deliveries visible. Archive a before-and-after review with its effective configuration, repository state, and final human disposition so future operators can diagnose why the migration produced a different decision. Check the archive again after the first material Qodo release or policy revision.

Where Qodo Merge belongs in an agent workflow

The review product belongs after a branch has a coherent change and before a person accepts it. Local review can move some checks earlier. Agent skills can fetch rules before code generation and resolve findings afterward. Those additions tighten the loop while preserving separate responsibilities: the coding agent produces, Qodo inspects under policy, deterministic systems test, and people approve intent and risk.

ticket and acceptance criteria
  -> coding agent works in an isolated branch
  -> tests, type checks, linters, scanners
  -> optional Qodo local review
  -> pull request
  -> Qodo Git findings and rules
  -> human review of intent and architecture
  -> branch policy and merge

Continuum covers the coding-agent operating stage for supported providers. Existing site content describes one git worktree per session and attached plan, transcript, diff, pull request, terminal, and artifact panes. Qodo covers review and rules around the change. A repository-level Qodo installation can review a pull request produced from a Continuum session through the ordinary Git provider workflow. This is a procedural pairing; no built-in integration is claimed.

Avoid wiring automatic fixes straight to automatic approval. Qodo's legacy /implement, current remediation flows, or the open-source project's improvement suggestions can shorten the fix loop, but the resulting code is a new change and deserves a fresh deterministic check plus review. A reviewer that edits its own finding can verify syntax; it cannot provide an independent judgment of the revised intent.

Questions people ask

Keep reading