GitLab puts AI agents inside issues, code review and delivery workflows

GitLab adds AI to a place where software teams already record work: issues, repositories, merge requests and delivery pipelines. Duo Agent Platform can help move between those artifacts, from investigating a problem to preparing a change. The key decision is how much of that lifecycle the team wants to delegate while keeping the result reviewable in its existing development process.

01 / ProductDuo extends the development platform beyond a chat interface

The Agent Platform documentation describes agents and flows spanning software development. Agentic Chat, code suggestions and issue-to-merge-request workflows address different points in the process. A chat answer is advice; a flow that edits files creates a change that needs the same engineering scrutiny as other submitted work.

Availability depends on the GitLab offering, version, selected feature and enabled settings. The documentation separates generally available features from beta and experimental ones. It also describes access for Free users through purchased credits for eligible capabilities. Avoid assuming that the heading of a platform page, or the existence of a paid seat, grants every agent action in every installation.

The deeper integration is with the record of development. An issue can describe the expected behavior, a branch can hold the proposed implementation and a merge request can collect review and pipeline evidence. AI becomes more useful when those artifacts are coherent. It cannot reliably repair an issue whose acceptance criteria contradict the code’s intended behavior.

02 / AudienceTeams already working in GitLab can evaluate a complete development step

A good first candidate is a small maintenance change with an existing reproduction: a validation error, an incorrect response message or a failing test linked to a clear requirement. The change should be substantial enough to expose repository understanding, but narrow enough that a reviewer can judge every edited file without reconstructing an entire feature.

For a developer primarily seeking help during interactive editing, the Cursor blueprint gives a different starting point. For a team mainly trying to improve pull-request feedback, the CodeRabbit blueprint narrows the comparison to review. GitLab’s proposition is broader when the context and evidence already live across its software lifecycle.

A migration to GitLab solely to try an agent is a larger decision. Repository hosting, CI configuration, access control and developer habits carry their own costs. Evaluate the AI contribution within the existing platform first where possible. A compelling demonstration on a sample repository does not establish that a platform migration will improve a real team’s delivery process.

03 / WorkflowA proposed issue-to-change workflow makes the review evidence explicit

Choose a proposed pilot around a reproducible input-validation defect. The issue should include the failing input, actual response, expected response and a concise explanation of why the difference matters. Remove private customer payloads and replace them with representative fixtures. Preserve the behavior that must remain unchanged, especially accepted inputs close to the boundary.

Confirm that the selected development flow is available for the actual group and installation. Enable only the relevant capabilities and check the participating developer’s role. The platform documentation describes setup prerequisites and separate configuration for self-managed or self-hosted-model routes. A demonstration on GitLab.com should not be treated as evidence that an older private installation is ready.

Ask the agent to investigate the existing validation path and identify the smallest likely change. Require it to name the files and existing tests that support its explanation before treating the proposed fix as reliable. This is an opportunity to catch an incorrect theory early, particularly when the same error message is produced by several different layers.

Let the agent prepare a branch or merge request within the team’s normal process. Keep acceptance criteria in the issue and include a focused regression test that fails for the reported defect. Avoid a broad rewrite of unrelated validation rules. A larger diff makes it harder to distinguish the requested correction from incidental changes produced while exploring the repository.

Review the patch with the same standard used for human contributions. Inspect input boundaries, error handling and compatibility with existing callers. A passing test that merely encodes the generated implementation is weak evidence. The reviewer should verify that the fixture represents the original failure and that neighbouring valid inputs still behave correctly.

GitLab’s composite identity documentation explains how eligible flows combine the initiating human’s permissions with a service account, using the more restrictive role. It also attributes the resulting merge request to the initiating person. For the pilot, verify those identities and the projects they can access instead of assuming the agent is an unprivileged anonymous helper.

Keep merge approval and deployment in the existing protected process. The human who prompts a change should not treat the agent’s involvement as independent review. Record the final reviewer, pipeline result and any manual behavior check. The useful outcome is a smaller amount of engineering effort for a correct change, not simply a larger number of generated commits.

Evaluate several ordinary issues rather than one especially favourable example. Track rejected approaches, manual edits, review time and the reason a task needed intervention. A flow that generates a patch quickly but misreads the requirement can increase total work. These proposed measurements give the team a grounded basis for deciding which issue classes to delegate next.

04 / PricingSeat pricing and credit consumption need separate estimates

The current pricing page displays Premium at US $29 per user per month, billed annually, and custom pricing for Ultimate. GitLab Credits are listed at US $1 per credit, with billing depending on plan and commitment. The page labels the included Premium and Ultimate credit amounts as a temporary promotion. They should not be treated as a permanent contractual discount.

The usage billing documentation distinguishes individual included credits, a shared Monthly Commitment Pool and On-Demand usage. Included credits are not transferable between users, while purchased pool consumption is shared. A team cannot estimate capacity by assuming that every inactive employee’s included allocation automatically subsidizes the busiest developers.

For the pilot, measure the credits consumed by a completed, accepted change, including failed attempts and repeated investigation. Base platform seats and CI execution are separate considerations. A credit is a billing unit, not a fixed issue or merge request. The same task can consume more when it requires a larger context, repeated model calls or a longer sequence of actions.

Review the usage terms before enabling overage. The documentation states that accepting usage billing terms enables on-demand charging and can cover charges already accrued in the current billing period. Configure the applicable usage controls deliberately. This is especially relevant when a purchased shared pool opens access to more people than the initial pilot group.

05 / DistinctionsThe main distinction is continuity between the task and its evidence

GitLab can place the proposed change beside the issue, code discussion and pipeline result that explain it. That continuity helps reviewers inspect an agent’s work without moving between unrelated tools. It is most valuable when the team already maintains useful issues and meaningful automated checks; weak development records remain weak context when an agent reads them.

Integrated permissions also make the operating model more concrete. The organization can reason about which identity initiated a task and how the resulting change entered review. This does not prove that every proposed action is appropriate. It gives the team a clearer place to enforce and inspect the rules that already govern development.

Another distinction is the breadth of possible assistance. Pipeline investigation and code review involve different evidence from inline completion. Treat them as separate rollout decisions. A team can find one flow useful while leaving others disabled, and should preserve that granularity when allocating credits or interpreting adoption metrics.

06 / QuestionsSource access and changing feature status are consequential boundaries

GitLab’s data usage guidance says it does not train generative AI models and restricts model subprocessors from using inputs and outputs for training. The same page describes telemetry, optional usage-data sharing and other handling details. A no-training statement does not remove the need to inspect which source material is sent for a particular task.

The most important pilot question may be what the flow can read outside the immediate repository. Composite identities and service-account membership can make related projects available where both identities have access. A team should test the intended project boundaries with representative accounts, especially when different repositories contain separate customers’ code or deployment configuration.

Feature status is another moving boundary. Current documentation and commercial comparison tables can describe different stages of a rollout. Before relying on a flow, check its own availability page and the installed version. The proposed pilot avoids custom flows and experimental governance features so its basic review process does not depend on a preview promise.

07 / DecisionAdopt the flow that improves accepted changes

GitLab is worth evaluating when software work is already organized around its issues, repositories and merge requests. Start with one issue class, an explicit output and an ordinary reviewer. Keep enough evidence to explain both successful delegation and the cases where the agent misunderstood the task.

Broader adoption should follow a demonstrated reduction in the effort required to deliver correct changes. That includes investigation, review and correction, not just time to first patch. GitLab’s integration is useful when it makes this complete process clearer and easier to control.