All posts
Software factory for GitLab and Bitbucket
Most AI software factories assume GitHub. Here's how to run one on GitLab or Bitbucket while keeping your merge requests, pipelines and approval rules.
Ben Ong
October 29, 2026
ai-agents
product-development
GitHub, GitLab and Bitbucket logos in grey halftone on an orange background
A software factory for GitLab or Bitbucket is a setup where AI coding agents turn requests into merge requests or pull requests on the repos you already host there, while your pipelines and approval rules decide what ships. You don't have to move to GitHub to run one. LightSprint works with GitLab and Bitbucket as well as GitHub, so your whole product team can start agent work on your real codebase while engineering keeps the merge.
Here's what a software factory needs from your Git host, the native options on each platform, and how to run one on GitLab or Bitbucket without changing your release process.
Why most software factories assume GitHub
A software factory is a pipeline that turns requests into shipped code, with coding agents doing most of the implementation and people approving what merges. Many of the best-known examples grew up on GitHub. GitHub's own coding agents are started from GitHub issues, pull request comments and the repository's Agents tab.
Plenty of teams don't host their code on GitHub. Teams that run on Jira and Confluence often keep their code in Bitbucket. Teams that want source control, CI/CD and security scanning in one place often choose GitLab. For them, moving repositories just to try an agent means moving pipelines, permissions and history too. That's a migration project, and it's the opposite of what a software factory should feel like.
The good news is that nothing about a software factory is specific to GitHub. It needs a few things from your Git host, and GitLab and Bitbucket provide all of them under different names.
What a software factory needs from your Git host
- Scoped repo access. Agents need to read the codebase and push branches, without broader access than the job needs.
- One branch and one review request per change. Each piece of work becomes its own merge request or pull request, so it can be reviewed and reverted on its own.
- CI on every change. Your existing pipeline runs on agent work exactly as it does on human work.
- Approval rules that agents can't skip. Protected branches, required approvals and merge checks decide what reaches the main branch.
Here's what those pieces are called on GitLab and Bitbucket:
| GitLab | Bitbucket | |
|---|---|---|
| Review request | Merge request | Pull request |
| CI | GitLab CI/CD | Bitbucket Pipelines |
| Merge controls | Protected branches and merge request approval rules | Branch permissions and merge checks |
| Native agent features | GitLab Duo Agent Platform | Rovo Dev and Agentic Pipelines (beta) |
Software factory for GitLab
GitLab has invested heavily in agents of its own. The GitLab Duo Agent Platform became generally available in January 2026. Its foundational flows include a Developer flow that turns issues into merge requests, a Code Review flow, and a Fix CI/CD Pipeline flow. GitLab also supports external agents, including Claude Code and Codex CLI.
You can also run agents in your own pipeline. Anthropic's Claude Code GitLab CI/CD integration runs Claude in your GitLab runners when someone mentions @claude in an issue or merge request, and every change flows through a merge request so your approvals still apply.
These options are built for developers working inside GitLab: in the GitLab UI, the IDE or the terminal. That covers the engineering side of the factory well. What's usually missing is the rest of the product team. A PM, designer or ops lead still writes an issue, waits, and then meets the result as a diff.
A software factory for GitLab with LightSprint works like this:
- Connect your GitLab repositories. LightSprint works on the projects your team already ships from.
- Anyone describes the change. A PM, designer or engineer describes the outcome in LightSprint, or creates the task from Slack, Linear or Jira with updates synced both ways.
- The team agrees on a plan. LightSprint reads the codebase and turns the request into a visual plan the team reviews before any code changes.
- Agents build in an isolated sandbox. Each change gets a live preview, so people click through working behavior instead of reading a description.
- The change arrives as a merge request. Your GitLab CI/CD pipelines and approval rules run on it like any other merge request, and an engineer approves the merge.
Software factory for Bitbucket
Atlassian's agent work centers on Rovo Dev. Bitbucket's Agentic Pipelines, currently in beta, let you define agents in bitbucket-pipelines.yml and run them inside pipeline steps to review code, troubleshoot failing builds, fix flaky tests and more. You can choose Rovo Dev, Claude Code or Codex as the provider, and permission rules control which Bitbucket actions an agent may take.
Like the GitLab options, Agentic Pipelines are configured and run by engineers. They're a strong way to automate work inside CI. They don't give the people who request changes a way to start, shape and check that work themselves.
That matters on Bitbucket in particular, because Bitbucket teams usually plan in Jira. LightSprint creates tasks from Jira and syncs updates both ways, so the ticket your PM already wrote can become a plan, a preview and a pull request without anyone re-explaining it.
A software factory for Bitbucket with LightSprint follows the same flow:
- Connect your Bitbucket repositories.
- Start from Jira, Slack, Linear or LightSprint. Anyone on the product team can describe the change.
- Review a shared plan, built from your real codebase, before code is written.
- Check the live preview from the isolated sandbox.
- Merge through your existing rules. The change opens as a Bitbucket pull request, Bitbucket Pipelines runs on it, and your branch permissions and merge checks still apply.
GitLab and Bitbucket software factory options compared
| Option | Git hosts | Who starts work |
|---|---|---|
| GitLab Duo Agent Platform | GitLab | Developers in the GitLab UI, IDE or CLI |
| Claude Code GitLab CI/CD | GitLab | Mentions in issues and merge requests |
| Bitbucket Agentic Pipelines (beta) | Bitbucket Cloud | Pipeline steps and triggers |
| LightSprint | GitHub, GitLab and Bitbucket | Anyone on the product team, from LightSprint, Slack, Linear or Jira |
These aren't mutually exclusive. Many teams will use a native agent for CI chores like pipeline fixes and run a team-wide factory like LightSprint for product changes.
How LightSprint keeps engineering in control
The point of a software factory is more shipped changes without more risk. On any Git host, LightSprint keeps the same guardrails:
- Roles decide who can merge. A Builder, typically a PM, designer or ops team member, can propose changes and view previews but can't merge. An Approver, typically an engineer or lead, reviews and merges.
- Every change is isolated. Agents build in a sandbox, so nothing touches your main branch until it's approved.
- Your models, your subscriptions. Run changes with Claude, Codex or any model through OpenRouter, including your own API keys or existing subscriptions, with no markup on inference.
More detail is on our engineering page and security page. For why it matters that product people take part, see What is a multiplayer software factory?.
How to start a software factory on GitLab or Bitbucket
- Pick one kind of change where product people wait on engineering. Copy updates, UI fixes, onboarding tweaks and internal tools are good starting points.
- Connect the repositories that change touches. Keep your existing pipeline and merge rules as they are.
- Give two or three product people Builder access. Keep engineers as Approvers.
- Measure time from request to merged change. Compare it with the same kind of change done through tickets.
FAQ
What is a software factory for GitLab?
It's a setup where AI coding agents turn requests into GitLab merge requests on your existing repositories. Your GitLab CI/CD pipelines and merge request approval rules decide what ships, the same as for human-written code.
What is a software factory for Bitbucket?
It's a setup where AI coding agents turn requests into Bitbucket pull requests on your existing repositories. Bitbucket Pipelines runs on each change, and your branch permissions and merge checks still control what merges.
Do I need to move from GitLab or Bitbucket to GitHub to use AI coding agents?
No. GitLab and Bitbucket both offer native agent features, and LightSprint connects to GitLab and Bitbucket repositories directly.
Does LightSprint work with GitLab and Bitbucket?
Yes. LightSprint connects to GitHub, GitLab and Bitbucket repositories. Each change is built in an isolated sandbox with a live preview, then opened as a merge request or pull request for your team to review.
Can non-engineers merge code through LightSprint?
No. Builders propose changes and view previews but can't merge. Approvers, typically engineers or leads, review and merge through your existing approval rules.