Qodo has introduced Review Effort Modes as a research-preview control for its automated pull request reviews. The feature gives engineering teams four ways to select how much analysis a review receives: Fast, Balanced, Deep and Auto. Balanced remains the default, while Auto attempts to choose an effort level from characteristics of the change.
The release addresses a practical tension in AI-assisted review. A small, routine change may not justify the latency and token use of an exhaustive analysis, while a dispersed or high-risk change may need more reasoning than a quick pass provides. Applying the same configuration to every pull request can either waste resources or leave important interactions under-examined.
Four review settings
Fast is intended for rapid feedback on simpler changes. Balanced is the standard setting and aims to preserve the current compromise between review coverage, response time and cost. Deep allocates more analysis to complex work. During the public research preview, however, users cannot select Deep directly; it is available only when Auto routes a pull request to that level.
Auto is the most consequential part of the release. Qodo says its router does not rely on changed line count alone. It considers logic complexity, how widely the changes are spread, and the potential blast radius across the codebase. That approach recognises that a short modification to authentication, shared state or a public interface can carry more risk than a large but isolated generated file.
Teams can configure modes globally or at repository level. Repository-specific settings may be useful where codebases have different risk profiles, release cadences or cost constraints. A service handling payments, for example, may warrant a more cautious default than an internal prototype.
A preview with measurable trade-offs
Qodo says it is evaluating precision, recall and F1 alongside latency, token consumption and cost. Those measures are important because a review system can produce more comments without producing more useful findings. Precision reflects how many reported issues are valid; recall reflects how many relevant issues the system finds. Neither measure alone captures whether developers trust and act on the feedback.
The company has not published a complete benchmark showing how each mode performs across languages, repositories and defect categories. Auto's routing rules also remain a modelled judgement rather than a guarantee that every risky pull request will receive the deepest review. Teams should treat the preview as an opportunity to collect their own evidence, not as a replacement for existing review policy.
Useful local measures include time to first review, accepted versus dismissed comments, escaped defects, reviewer workload and token consumption. Security-sensitive teams may also want to sample whether changes to permissions, secrets handling and dependency boundaries are consistently escalated.
Availability, cost and governance
Qodo says the research preview does not add cost. It has not stated what pricing, quotas or packaging will apply after the preview, so teams should avoid assuming that Deep or Auto will remain available on the same terms. They should also confirm which products and plans expose repository-level settings.
Effort controls can make automated review more economical, but they do not remove the need for human ownership. The routing decision itself can be wrong, generated comments can contain false positives and a deep review may still miss context held outside the repository. Branch protection, tests, security scanning and accountable human approval remain separate controls.
The preview is a meaningful step towards workload-aware code review. Its success will depend less on the names of the four modes than on whether Auto reliably directs compute to the changes where additional analysis produces better engineering outcomes.