rocket-launchMigration from Legacy Qodo

circle-exclamation

This guide explains how customers using legacy Qodo can start using Qodo’s new code review experience safely and incrementally.

The goal is to let you test and validate the new review behavior before enabling it broadly across your organization.

To use the new code review experience, you update your repository configuration and enable new review commands. During migration, you can run the new review alongside existing commands for testing purposes, then remove duplicates once validation is complete.

Step 1: Update your repository configuration

Configuration for code review lives in your repository’s configuration. In the pr_agent.toml you can see which review commands are enabled and how feedback is generated.

Add the new review commands

In the git_provider section (varies depending on your provider), add the new review commands (prefixed with /agentic):

[github_app]
pr_commands = [
  "/agentic_describe",
  "/agentic_review"
]

The new commands combine and replace multiple legacy commands, including /improve /review /describe & /compliance

circle-info

During testing, both old and new review commands may run in parallel for comparison, but once migration is complete, older commands should be removed to avoid duplicate feedback and noise.

Optional: Test the new review manually

Manual testing is an optional way to preview the new code review experience before or during configuration.

In any pull request comment, enter:

This enables you to:

  • Validate the new review output on real pull requests

  • Compare results with existing review behavior

  • Test without changing repository configuration

circle-info

Manual invocation is intended for testing and validation.

Step 2: Enable on a pilot repository

Before rolling out the new code review experience across your organization, we recommend enabling it on a pilot repository.

This helps you:

  • Evaluate signal quality and noise levels

  • Confirm the new review behavior meets expectations

  • Adjust configuration if needed

  • Remove duplicate commands after validation

Configuration details

To learn how to configure options such as severity thresholds, display modes, verbosity levels, and ignore rules, see Configuration Fundamentals.

Step 3: Enable on entire organization

After you’ve validated the new code review experience in a pilot repository, you can roll it out across your organization by applying the configuration at the organization level.

To enable the new review commands across all repositories, define them in the global organization configuration:

  1. Create a repository in your organization named: pr-agent-settings

  2. Add a pr_agent.toml file to the root of that repository’s default branch.

  3. In the git_provider section, set the new review commands:

After this change is merged, the configuration applies as the default for all repositories in the organization (unless overridden by a repo-level or wiki configuration).

Step 4: Remove legacy configuration

Once you enable the new commands broadly, remove older review commands from any configuration location where they are still defined (wiki, repo-level, or global). See Configuration Fundamentals for more details.

What you’ll notice in your PRs

After rollout, review output will be consolidated and more structured:

  • Compliance and Code Suggestions will no longer appear as separate outputs (they are incorporated into the new review experience)

  • Issues are grouped by priority (for example, Action Required vs Remediation Recommended)

  • Findings include clearer explanations and direct references to relevant code

  • Reviews include agent-assisted fix prompts to help resolve issues faster

These changes are expected and reflect a more coordinated and prioritized review flow.

Last updated