AI-assisted code review on self-hosted GitLab

The situation

I'm Tech Lead for the development team at an environmental-technology company. Code review ran the way it does in most teams past a certain size: merge requests waited on whoever had review capacity, feedback depth depended on who picked the request up, and the same avoidable issues kept reaching human reviewers. Nobody was asking for an AI tool. The problem people actually felt was slow, uneven review.

The constraints

• Self-hosted GitLab. No marketplace apps, no hosted review SaaS to plug in. Whatever shipped had to run against infrastructure we operate ourselves.
• No budget line, no project slot. Built alongside my normal tech-lead workload, in the gaps.
• Skeptical users. Developers had watched plenty of AI tooling over-promise. A reviewer that posts noise gets ignored quickly, permanently.
• No mandate. I set technical direction, but forcing a tool into people's review flow would have poisoned it. Adoption had to be earned merge request by merge request.
• Real production codebases. Multiple active projects with different stacks and conventions — not a demo repo where every suggestion lands cleanly.

What I built

A review pipeline that behaves like one more reviewer inside the existing flow, rather than a new tool people have to visit.

When a merge request is opened or updated, a pipeline job assembles the diff with surrounding file context, sends it to an LLM together with our review guidance, and posts the result back onto the merge request as ordinary review comments.

The shape of it:

• a GitLab CI job triggered by merge-request events
• context assembly: the diff plus the touched files
• one model call, prompted with team-specific review guidance
• comments posted back through the GitLab API by a dedicated bot account

Developers never leave GitLab. There is no dashboard, no separate login, no new habit to build. The pipeline meets people at the exact point where review already happens.

Time to first value

First useful review comments on a real merge request within the first sprint. It started narrow and grew from there — daily use across the team came later, as the comments earned trust.

What changed

Nineteen developers now have machine review in their daily loop. Every merge request gets a first pass before a human opens it.

The observable shift is in what human reviewers spend attention on. Mechanical findings — missed edge cases, inconsistent naming, dead code, the class of comment that is tedious to write and mildly embarrassing to receive — surface before anyone asks a colleague for a review. Human review moved up a level, toward design and correctness.

I didn't instrument review turnaround before introducing the pipeline, so I won't quote an improvement percentage. The honest claim is behavioural: the tool stayed in daily use on its own merits, in a team that was free to ignore it.

What I'd do differently

Two things, both about the early weeks.

I tuned the first version against my own sense of what a good review comment looks like, and burned early credibility on comments the team found noisy. The skeptics were right about several of them. I should have put the two or three most demanding reviewers in the tuning loop from day one — their taste was the real acceptance bar, and I found that out the slower way.

And I'd instrument from the first week. The pipeline's value is real but anecdotal, because I only decided later what questions I'd be asked about it. Even a crude signal — comments acted on versus dismissed — captured from the start would have made every later conversation about expanding the tool shorter.