Build1 publisher2 min readPublished Updated
GitLab gives Duo Enterprise seat holders the single-pass AI reviewer by default
GitLab's v19.5 docs send AI reviews started by Duo Enterprise seat holders to the single-pass reviewer that reads only the merge request and its diffs. To check cross-file rules on every review, a group Owner has to move seat holders onto the credit-billed Code Review Flow.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Code Review Flow opens a review session in the activity feed and the project's sessions, so a review with no session came from GitLab Duo Code Review.
- Code Review Flow needs no add-on, runs on GitLab Credits, and reasons in several steps over repository structure and cross-file dependencies.
- When Code Review Flow runs, the GitLab Credits it uses are attributed to the user who initiated the review.
- Asking @GitLabDuo about a change in a comment thread runs on the model chosen for Code Review Flow and bills credits separately from the flow itself.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Teams that bought Duo Enterprise seats expecting the deeper review get the diff-only reviewer on every review their seat holders start, until an Owner overrides the default.
- exposure With both reviewers live in one project, a clean @GitLabDuo review does not show that cross-file rules were checked until someone confirms which reviewer ran.
- decision Standards have to be supplied as configuration up front, because GitLab says corrections do not shape later reviews of other merge requests; issue 560116 proposes changing that.
- cost Credit spend falls on whoever starts a review, so a group that moves everyone onto Code Review Flow has to budget per person, seat holders included.
A dev.to walkthrough of GitLab's documentation opens by saying the choice depends on who opens the merge request [1]. The rule it goes on to quote is narrower: the user who initiates the review decides which reviewer runs [5]. Both reviewers answer to one handle, @GitLabDuo, and both can run in the same project [2][5]. The seat logic and credit billing work the same way on Dedicated and GitLab.com as on Self-Managed [14].
On this one point, paying for the seat gets you a reviewer that sees less. The post gives two examples of standards that need more than the diff: "this interface must match the shared contract in another module" and "new endpoints need an integration test" [15]. By its reading of the docs, the single-pass reviewer is the one that stops at the file boundary [15].
The default that keeps seat holders on that reviewer is deliberate. Reviews they start stay on GitLab Duo Code Review even after a group Owner turns Code Review Flow on [8]. GitLab's reason, as the post relays it, is to stop seat holders from quietly burning GitLab Credits [8]. Without the default, a seat holder's reviews would use up credits on top of the seat [2]. I think GitLab chose correctly for a billing system. Nobody picks up a second charge they did not ask for. An Owner can still flip the default so Code Review Flow runs for everyone [6][8].
If a group has written its standards down, I would flip the override. Native review is configured per group, and interaction settings are configured per instance [9]. GitLab's Agent Platform documentation lists automatic reviews, custom instructions and custom comments as review capabilities [10]. It describes Code Review Flow as the flow that automates review tasks and enforces coding standards across the team [10]. That wording describes what the flow can see and do. The post does not report how often either reviewer catches a cross-file violation. The description can only hold on a given repository if two things are true: the rule is written into custom instructions, and Code Review Flow is the review that ran [10].
The resolve-discussion feature is a separate flow behind the same handle. In it, @GitLabDuo edits the source branch and pushes a fix [13]. It needs your own runners or GitLab hosted runners [13]. Counting it, @GitLabDuo covers three features with three different prerequisites: a Duo Enterprise seat, GitLab Credits and runners [1].
What to watch
- GitLab issue 560116, the proposal to let reviewer feedback influence later reviews of other merge requests.
- A GitLab docs release after v19.5 that changes the seat-holder default or labels which reviewer answered under @GitLabDuo.
- Any published comparison of how often Code Review Flow and GitLab Duo Code Review catch the same cross-file rule violation.