Most Claude Code integration guides assume GitHub. If your team runs GitLab, self-hosted or SaaS, the workflow is a little different but no less solid: merge request review, pipeline debugging and issue triage all work through Claude Code's command-line and MCP integration once it's pointed at the right GitLab endpoints.
Setting up the connection
Claude Code talks to GitLab through the GitLab CLI (glab) or a GitLab MCP server, depending on how your team already authenticates. For a self-hosted instance, point the CLI at your own GitLab URL rather than gitlab.com, and confirm your personal access token has api and read_repository scopes at minimum. Teams on GitLab SaaS with SSO can usually use glab auth login directly; self-hosted instances behind a VPN need Claude Code running somewhere with network access to that instance, which for most AU teams means a self-hosted runner or a machine on the corporate network rather than a cloud sandbox.
What the workflow actually looks like
Point Claude Code at an open merge request and ask for a review; it reads the diff, the linked issue, and any prior review comments before commenting
Ask it to investigate a failing pipeline; it can read job logs directly rather than you copy-pasting error output into chat
Have it draft a merge request description from the branch's actual commits, rather than writing one from memory after the fact
Use it to triage a backlog of GitLab issues, grouping duplicates and flagging ones missing enough detail to action
Merge request review, done properly
The most useful pattern isn't asking Claude Code to approve or reject a merge request; it's asking for a structured review that a human then acts on. Have it check for the things reviewers skip when they're tired: does this change what it claims to change, are there tests for the new logic, does the commit history tell a coherent story. It won't catch every architectural judgment call a senior engineer would, but it reliably catches the mechanical stuff that eats review time.
Where self-hosted GitLab adds friction
Self-hosted instances on internal networks are the main complication. If Claude Code is running in a cloud sandbox rather than on a machine with direct network access, it simply can't reach an instance sitting behind a corporate VPN. The workaround most Australian engineering teams land on is running Claude Code locally or on a self-hosted runner rather than a hosted cloud environment, at least for the GitLab-touching parts of the workflow.
A worked example
A Melbourne fintech's platform team runs Claude Code against their self-hosted GitLab instance for first-pass merge request review on every change under 200 lines. The team estimated first-pass review previously took a senior engineer 15-20 minutes per merge request; the Claude Code pass now produces a structured comment in under two minutes, and the senior engineer's remaining review time is spent on the judgment calls, not the mechanical checks. Across roughly 30 merge requests a week, that's a meaningful chunk of senior engineering time redirected, worth well over $80,000 a year at typical AU senior-engineer rates once the reclaimed hours are counted across the team.
Pipeline debugging without the copy-paste loop
The other place this pays off fast is CI pipeline failures. Instead of an engineer pasting a wall of pipeline log output into a chat window, Claude Code with GitLab access reads the job log directly, correlates it against the recent commit diff, and proposes a fix. It's a small workflow change that removes a genuinely annoying manual step from a task that happens dozens of times a week on an active repository.
A quick audit you can run today
Look at your last ten merged merge requests and time how long each sat waiting for review before anyone looked at it. If the average wait is measured in hours rather than minutes, a fast automated first pass is likely to shrink that queue more than adding another reviewer would.
What this isn't
This isn't a replacement for a senior engineer's sign-off on anything non-trivial, and it isn't a way to merge code without human review. Treat every Claude Code review comment as a fast first pass, not the final word, particularly on anything touching security or data handling.
Getting started
Confirm whether your GitLab instance is reachable from where Claude Code will actually run
Set up glab or a GitLab MCP server with a token scoped to read and comment, not merge
Start with merge request review on small changes before trusting it on anything large
Track the time saved on first-pass review for a month to see if the pattern holds for your team
If your engineering team is on GitLab and wants Claude Code wired in properly, that's a setup we do regularly. Get in touch: https://www.automataai.com.au/contact
