Jira and GitLab teams were left out of AI coding agents

2026 is the year AI coding agents moved into Jira. You can assign an issue to an agent, mention it in a comment, or fire it from a Jira Automation rule, and a pull request comes back. Unless your code is in GitLab.

Here is what we found when we checked each vendor’s own documentation in September 2026.

The Jira-native agents stop at GitHub and Bitbucket

GitHub Copilot for Jira became generally available in June 2026. GitHub’s documentation says it only works with repositories hosted on GitHub.
Atlassian’s Jira coding agent, launched as Rovo Dev, supports Bitbucket Cloud and GitHub Cloud.
Claude Agent for Jira, in beta, runs on your own Anthropic account and opens pull requests on GitHub.

For a team whose code lives in GitLab, none of these can open the merge request.

GitLab’s agents start from GitLab

GitLab Duo’s Developer flow takes an issue to a merge request, and it is generally available since GitLab 18.8. But every Duo trigger is a GitLab event, so a Jira issue has to be copied into GitLab first. The request to start from Jira issues, gitlab-org/gitlab#588660, is open with no milestone. A draft change would add a “Resolve with Duo” button to GitLab’s own list of Jira issues, behind a feature flag and without writing anything back to Jira.

The general-purpose agents can, with conditions

Cursor and Devin both take work from Jira and can open GitLab merge requests. Cursor’s GitLab support needs GitLab Premium or Ultimate and a Cursor Teams or Enterprise plan. Devin supports self-managed GitLab on its Enterprise plan. Both are general AI engineers; turning Jira issues into merge requests is one job among many.

The open-source route leaves GitLab to you

OpenAI’s Symphony, an open-source specification for running Codex agents on tracker issues, gained a Jira Cloud adapter in July 2026, so it can pick up Jira issues. It does not open merge requests itself: the specification leaves pull requests, comments and ticket updates to a prompt you write, and OpenAI’s example workflow opens GitHub pull requests. Someone also has to host and maintain the service, which OpenAI describes as prototype software intended for evaluation. The side-by-side comparison has the details.

What Jira and GitLab teams need

For a team in this position, four things matter:

Start where the work is tracked. The issue lives in Jira, and so do the people who filed it: QA engineers, support and product managers who may not have a GitLab account.
Land where the code is reviewed. A merge request in GitLab, running the team’s own pipeline, under its own branch protection.
Proof, not a plausible diff. A test that fails before the change and passes after it, so whoever approves it can trust the change without reading code.
A trail on the issue. The reporter should see what happened without leaving Jira, and nothing should be rewritten after the fact.

That is what we built Label2Prod to do, and it is free for early-access teams. For a side-by-side look at each option, see the comparisons.