Automated Code Reviews with AI

At Copebit we built mr-agent: a GitLab CI/CD component that reviews every merge request against your team's own guidelines. Automatically, every time, no matter how busy everyone is.

What Is mr-agent?

mr-agent adds an AI review step to your merge request pipeline. Open a merge request or push a new commit, and about a minute later there's a review on it: concrete feedback, checked against the standards your team actually agreed on.

It doesn't replace your reviewers. Think of it as the colleague who always does the first pass, so the humans can spend their time on the questions that need real judgement.

How It Works

mr-agent is just another job in your GitLab pipeline. A few lines in your CI configuration and you're done. There's no extra platform to run and nothing new for developers to learn, and it uses the same infrastructure, permissions and audit trail as the rest of your pipeline.

When a merge request opens, mr-agent takes the diff and sends it to Anthropic's Claude (Sonnet 5.5) on AWS Bedrock. The interesting part is what it reviews against: your own guidelines, not a generic rulebook. At Copebit, those guidelines don't live in a wiki page or a spreadsheet. They live in a Git repository on our GitLab, written as Claude Code skills: plain Markdown files that describe how we write Terraform, Python and AWS Lambda code, what we expect on security, and how our Git workflow works. Our engineers install that repository as a Claude Code plugin, so the assistant they code with every day already knows our conventions. mr-agent pulls its review guidelines from the same repository.

When someone improves a guideline, they open a merge request on that repository, a colleague reviews it, and once it's merged it reaches the engineers' Claude Code right away through our Claude Marketplace and mr-agent with its next release. Nobody has to keep a Confluence page and a review checklist in sync.

It's also picky about what it reads. A Python change gets the Python and Lambda guidelines, a Terraform change gets the Terraform ones, and a README tweak gets just the basics. Reviews stay on topic, and you don't pay to send rules that don't apply.

To show what that looks like, we wrote a deliberately bad demo change: a nightly export job with a few classic mistakes baked in. mr-agent found three of them, all things a reviewer in a hurry could easily wave through:

The review shows up as an ordinary discussion thread on the merge request. You treat it like a comment from a colleague: reply to it, resolve it, or fix the code and push. Each push gets a fresh review and the old thread closes itself, so you're only ever looking at the latest feedback.

And when there's nothing serious to say? mr-agent says so and gets out of the way. The thread resolves itself, and the smaller suggestions are still there if you want them:

Why This Matters

Consistency. Five engineers or fifty, every merge request is held to the same standards. Review quality no longer depends on who happens to have time that afternoon.

Speed. Feedback arrives about a minute after you push, while the code is still fresh in your head, not three days later when you've moved on to something else.

Your standards, not generic ones. Terraform conventions, Python style, security policies, Git workflow rules. You define them once and mr-agent applies them to every change. When standards evolve, new guidelines are pulled and the reviews follow.

More time for the hard parts. With naming, style and the usual pitfalls already covered, senior engineers can spend their review time on architecture, business logic and helping people grow.

Data security. Everything runs through AWS Bedrock in the EU, and Bedrock doesn't use your data to train models. If you work in a regulated industry, you'll care about that.

A Gate, If You Want One

Every review ends with a verdict. If mr-agent finds something critical, the thread stays open. Turn on GitLab's "All threads must be resolved" setting and that open thread becomes a gate: the merge request can't go in until the author pushes a fix, or someone decides the finding doesn't apply and resolves it.

We kept that escape hatch on purpose. mr-agent sees the diff, not your whole system, so every now and then it will flag something your architecture already takes care of somewhere else. When that happens, a person makes the call.

What Does It Cost?

Less than you might think. We log the exact token usage of every review, so these are measured numbers, not estimates:

Two things keep it cheap. mr-agent only sends the guidelines that match the files you changed. And it uses prompt caching: when several reviews run within a few minutes of each other, the guidelines come out of the cache at a tenth of the price. A team doing a hundred reviews a month usually ends up somewhere around $10 to $20. That's less than fifteen minutes of a senior engineer's time.

(Prices based on Claude Sonnet 5.5 list pricing on AWS Bedrock at the time of writing. Check current Bedrock pricing for your region.)

Setup

Adding mr-agent to a GitLab project takes a few minutes. It authenticates to AWS through OIDC, so there are no static AWS keys to look after. The job runs next to your existing pipeline stages and never holds them up: if the review fails for whatever reason, the pipeline carries on as normal.

Our Experience

We run mr-agent on the infrastructure and application repositories we work in every day, and it didn't take long to notice the difference. Convention slips get flagged before a human even opens the merge request. It has also caught things that really matter, from IAM permissions that were far too broad to a provider upgrade hidden away in a lock file. Our own review discussions have shifted to design and trade-offs in place of style or established guidelines.

Building it taught us a few things too. Context is everything: the more the model knows about how you work, the sharper the review. The surprising part? Writing guidelines precise enough for an LLM made them clearer for the people on the team too.