The "Code Review" Bottleneck

With the emergence of tools like Cursor, or Antigravity, writing code has become easier and faster than ever before. They can generate boilerplate, tests, and entire modules in seconds (provided you ask them nicely, of course).

However, there’s a catch: quality checks are still performed by humans. And our capacity to read and comprehend someone else’s code remains exactly where it was.

As a result, the volume of Pull Requests (PRs) is growing, while the throughput of the review team remains the same. Code review is turning into a bottleneck. It’s a cycle: AI created the problem of excessive code volume. It’s only logical to assume that AI should help us clean up the mess.

The Toolkit: Google Genkit & Go

Google recently introduced a new ecosystem of tools for AI development, including the Agent Development Kit (ADK) and Genkit. As a Go developer, the biggest news for me was that all these tools were launched with official Go libraries.

The Experiment: A DIY AI Reviewer

Just for fun, and to test drive the new libraries, I decided to run an experiment: build a simple CLI agent to act as a first-pass code reviewer.

The concept behind reviewer is simple:

• Fetch the diff from a Merge Request via the GitLab API.
• Feed this context to a model using Genkit.
• Ask the model to identify bugs, style guide violations, or potential security issues.
• Post the feedback as comments back to GitLab.

The source code is open and available here: gitlab.com/romanyx/reviewer

How it works in CI/CD

The key feature is the ease of integration. The tool runs as a standard binary, so it can be easily added as a separate stage in your .gitlab-ci.yml.

stages:
- review

review-code:
stage: review
image:
name: registry.gitlab.com/romanyx/reviewer:latest
script:
- /app/reviewer
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: manual
variables:
GITLAB_TOKEN: $GITLAB_TOKEN
GEMINI_API_KEY: $GEMINI_API_KEY
PROJECT_ID: $CI_PROJECT_ID
MR_ID: $CI_MERGE_REQUEST_IID
REVIEWER_PROMPT: |
You are a Principal Golang Engineer acting as a code reviewer.
Your task is to analyze the changes in this Merge Request and provide constructive feedback.
Follow https://github.com/uber-go/guide/blob/master/style.md guides, Golang best practices and SOLID principles.
If the code is good, don't do any comments.

The pipeline triggers whenever a Merge Request is created. The bot scans the changes and leaves comments directly on the lines of code where it spots issues.

The Result?

Here is a live example of the bot in action: Demo Merge Request.

The bot, on demand, walked through the changes and highlighted areas that needed attention. Of course, it won’t replace a deep architectural review (though maybe it could, with the right workflow and better context) or an understanding of the business context. But it works great as a first pass, catching simple mistakes so we don’t have to.

Is it worth using?

It depends. Traditional linters are deterministic: they are perfect for catching syntax errors, unused variables, or formatting issues. They are fast, free and 100% accurate based on their rules.

On the other hand, LLMs are probabilistic; they can hallucinate or miss things. They are not a "gatekeeper" like a compiler. But they serve as a "second pair of eyes" that runs 24/7 and never gets tired.

Conclusion

This experiment proved that integrating LLMs into our daily workflows is easy, especially with Go and Genkit. We can’t stop the flood of LLMs-generated code, but we can definitely build better tools to manage it, and if your Merge Request inbox is overflowing, maybe it’s time to delegate some tasks to a robot.