GitLab has documented more than one AI-assisted code review path. Calling all of them simply “Duo review” obscures whether a feature is a non-agentic merge-request reviewer, an agentic workflow, or an assistant proposing edits. A team evaluating this feature needs to know which mode its GitLab edition, add-on and instance settings actually enable.
What the tool actually does
GitLab’s non-agentic Code Review page documents assigning the GitLab Duo reviewer on a merge request, passing the title, description, diffs and relevant file content to the selected model, and enabling follow-up conversation. GitLab also points to a separate Code Review Flow in its agent platform. The non-agentic workflow may retry a large review without the original changed-file context if it reaches a context-size constraint; this can reduce specificity, so the operational description should not promise uniform review depth across arbitrary-sized patches.
A practical workflow and what to verify
An implementation trial can use three small merge requests: a safe mechanical rename, a deliberately invalid authorization check and a behavior change with missing tests. Ask for a Duo review of each while preserving human review. Record the model configuration, whether required input context was present, actual comments, and review latency only from measured instance logs. For self-managed installations, check the supported version, AI Gateway path, selected model and instance availability before documenting a particular feature.
Limits and failure modes
A model reviewer has no direct evidence that staging behaves correctly and may misread a diff without unseen contracts or test fixtures. Changes in GitLab tiers, add-ons and editions are not interchangeable, and documentation for newer major versions must not be projected backwards. Review features that send code to a model require a deliberate data-flow assessment, especially when source files contain sensitive business logic or licensed third-party code.
Data governance, approvals and security
Administrators should verify group and project AI controls, data usage policy, code-review instructions and the model hosting path. Put review messages through the same human triage as other automated alerts and keep merge checks independent. If private code cannot leave a defined deployment boundary, confirm eligibility and actual architecture of any self-hosted-model option rather than assuming every tier supports it.
Who should use it—and alternatives
This workflow is particularly relevant to teams with regulated GitLab Self-Managed or Dedicated installations, but suitability depends on edition and configured AI Gateway. GitHub Copilot code review, CodeRabbit and Qodo are alternatives for other repository workflows. This article does not reproduce current seat prices or claim that the non-agentic and agentic offerings are a single identical service.
Documented scope and evidence date
This article reports the development workflow documented in the linked first-party sources accessed on 25 October 2026. It is not a hands-on product test or an independent performance claim. Client behavior, account entitlements and supported countries can differ across releases. Exact per-seat charges, quotas, trial allowances, API-model versions, and deployment guarantees are intentionally not supplied without a dated, tier-specific verification. For engineering procurement, capture the installed client version and active contract as separate evidence.
Acceptance checklist before production
- Check the exact editor, extension or CLI version in the actual installation, and the applicable sign-in or admin policy.
- Give the task a clear behavioral acceptance criterion and specify files, branches, credentials and networks outside its permitted scope.
- Use a disposable branch/worktree and preserve the baseline; do not rely on an agent summary as proof of test execution.
- Review the diff, new packages, build scripts and CI configuration, then rerun targeted and regression tests in a trusted environment.
- Require normal peer review and release approvals; keep a record of external code/context processors before using confidential repositories.
Sources & Further Reading
- https://docs.gitlab.com/user/gitlab_duo/code_review/ (official publisher documentation; accessed 25 October 2026)
- https://docs.gitlab.com/user/duo_agent_platform/flows/foundational_flows/code_review/ (official publisher documentation; accessed 25 October 2026)
- https://docs.gitlab.com/user/gitlab_duo/data_usage/ (official publisher documentation; accessed 25 October 2026)