Skip to main content
Beta Reviewer is one of the tools in the Agentic Toolbox. It enables your coding agent to review local changes before a pull request exists, using the same engine as Qodo Review. Reviewer enables AI agents to review local, committed, and uncommitted changes while they work on code. Your agent sends the working-tree diff to Qodo’s review engine and receives structured findings in the same session, allowing it to identify and fix issues in a continuous loop and produce higher-quality code. Reviewer combines your local diff, new untracked files, and the coding-session context you provide, including a summary of intent, key decisions, and links to the ticket, spec, or design that drove the change. This gives the review engine context that a forge-based reviewer typically does not have access to. The agent uses these findings as part of its development workflow, similar to how it would use post-pull request review comments, but while it is still authoring the code. This helps teams resolve issues during development and open cleaner pull requests.

​
Supported interfaces

​
What you can do

With Reviewer, you can:
  • Review local, uncommitted changes before a pull request exists.
  • Include new, untracked files in the review automatically.
  • Attach coding-session context, such as a summary, decisions, and ticket, spec, or design links.
  • Scope a review to specific files or directories using git pathspecs.
  • Choose a fast single-pass review or a deeper review per run.
  • Get machine-readable findings for use in automated or looping workflows.

​
Common use cases

​
Review changes before opening a pull request

Catch issues in your working tree while you are still editing, before a pull request reviewer sees the diff. Use it to:
  • Review your working tree against a base branch before pushing.
  • Catch issues while the change is still fresh in context.
  • Fix findings immediately instead of after a pull request review.
  • Confirm a diff is clean before opening a pull request.
Example questions
  • Review my changes before I open a pull request.
  • What issues would a reviewer flag in this diff?
  • Check this before I push.
Example workflow

​
Provide context a forge reviewer cannot see

Give the review engine the intent and decisions behind a change, not just the diff. Use it to:
  • Attach a summary of what changed and why.
  • Record deliberate decisions so the reviewer does not re-flag them as issues.
  • Link the ticket, spec, or design the change is based on.
  • Reduce false positives caused by missing intent.
Example questions
  • Attach my reasoning to this review.
  • Include the linked ticket in the review context.
  • Why would the reviewer flag something I did on purpose?

​
Scope reviews to specific files or directories

Limit a review to the part of the change that matters right now. Use it to:
  • Limit the review to a subset of the diff using git pathspecs.
  • Focus on hand-written code and skip generated files.
  • Review a large branch incrementally, directory by directory.
  • Combine path scoping with a specific base branch.
Example questions
  • Review only the changes under src/api.
  • Check just this directory before I commit the rest.
  • Review everything except the generated files.

​
Choose the right review depth

Match review thoroughness to how risky the change is. Use it to:
  • Run a fast, single-pass review during a tight edit loop.
  • Run a deeper review before a significant pull request.
  • Let the reviewer choose automatically when depth does not matter.
  • Balance thoroughness against latency and cost.
Example questions
  • Give this a quick check before I commit.
  • Run the most thorough review you can before I open this pull request.
  • What depth should I use for a small fix?

​
Frequently asked questions

​
What information does Reviewer use?

Reviewer uses your local Git diff, including new untracked files, plus any coding-session context you provide, such as a summary, decisions, and ticket, spec, or design links, to generate findings.

​
Does Reviewer require my changes to be pushed?

No. Only the base commit you are comparing against needs to be pushed, since the review engine clones it from your Git provider. Your local changes can remain uncommitted and unpushed.

​
Does Reviewer replace pull request review?

No. Reviewer helps catch issues before a pull request exists. Pull request review continues to validate the final, pushed changes and catch anything introduced afterward.

​
Does Reviewer modify code?

No. Reviewer returns findings for the agent to evaluate and act on. Applying a fix remains part of the agent’s editing workflow.

​
Is Reviewer available to everyone?

Reviewer is currently in Research Preview and gated behind an entitlement. Ask your Qodo organization admin to request preview access. Access activates automatically once your organization is enrolled.

​
Additional resources

  • Agentic Toolbox: Learn about the available tools, supported interfaces, and installation.