GitLab Automates Full Merge Request Lifecycle with Developer Flow
GitLab 19.0 added Developer Flow — an agent operating throughout the MR lifecycle. Analyzes reviewer feedback, resolves conflicts, explores unfamiliar codebases

AI has accelerated code writing, but it hasn't improved the work around merge requests. Developers still assign reviewers, process feedback through multiple rounds, resolve conflicts, and rebase branches before merging. The bottleneck has shifted from code to process, but tools haven't adapted. GitLab 19.0 changes that.
Developer Flow Works Across the Entire MR Cycle
Previously, Developer Flow solved one task: turning an issue into a merge request. It automated the routine setup between "what needs to be done" and "here's the MR for review". But it was just one task, and once the MR was opened, everything else was manual — round-robin feedback, conflicts, branch rebuilds. Now the same AI-agent core works across the entire lifecycle of an MR. You can launch it from any stage: from an issue with a Generate MR button, assign the Duo Developer service account directly to an issue or MR, or simply write an @mention in any comment. The agent picks up the conversation context and works on the same MR instead of creating a new one.
What exactly does the agent do:
- Processes reviewer feedback across multiple rounds in a single MR
- Resolves merge conflicts on long-lived branches
- Explores unfamiliar codebases and recommends approaches
- Breaks oversized MRs into logical chunks
- Implements new features from scratch
Under the hood, Developer Flow works as a single agent loop with a full set of developer tools: file reading, grep, editing, and command execution. The agent itself decides which tool to use and when. This is the architectural foundation that allows a single agent to participate throughout the entire MR cycle.
How the Agent Learns About Your Project
This is the key moment that distinguishes Developer Flow from other AI code tools. The agent reads AGENTS.md — a file that describes non-obvious bash commands, project conventions, environment specifics, and architectural decisions. Together with agent-config.yml, the agent receives an environment with the right dependencies, tools, and configuration. It can run tests, invoke pre-commit hooks, and close the loop before committing. You give the agent a machine that knows your standards, and the result meets requirements instead of creating extra work.
Conflict Resolution and the Final Step
A merge conflict is one of the most painful tasks in the MR process. You need to simultaneously keep the intent of both branches in mind, parse the changes in a text editor without running tests. The larger the codebase, the higher the likelihood that bugs will appear in manual resolution. For teams working with backports and cascading MRs across different release branches, it's a constant tax on velocity.
GitLab 19.0 adds a Resolve with Duo button (in beta): the agent reads the intent of the MR, looks at both branches, selects a resolution strategy, edits the files, and pushes the result. It leaves a comment with a summary of the conflict and the solution path — the next reviewer doesn't need to reconstruct the solution, and the audit trail remains intact. Separately, for the end of the MR process, a one-click rebase and merge feature was added (also in beta). Previously, for teams with semi-linear history, it was: rebase, then merge. Now it's one click.
A New Category of Tools
This is part of a broader shift in the world of AI development tools. The first wave accelerated code writing. The second added a chat window. Now agents are being created that participate in the work process rather than help at a single moment. Developer Flow demonstrates this model: the developer remains above the cycle, managing and reviewing, while the agent performs the work.