Forem: Roman Budnikov

Too much code, too many PRs. AI, please send help!

Roman Budnikov — Thu, 25 Dec 2025 13:23:51 +0000

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.

Teaching AI Modern Go: Solving the "Stuck-in-the-Past" Problem with Antigravity

Roman Budnikov — Wed, 17 Dec 2025 09:40:45 +0000

Last month, I changed my workflow. I switched from vim as my primary code editor to Google's new Antigravity AI IDE. It's an agentic platform that has significantly boosted my performance in writing, testing, and modifying code.

Go is evolving fast. Recent versions introduced helpful features like integer ranges (Go 1.22 for i := range 10) and standard library improvements (Go 1.24 testing.B.Loop). Unfortunately, most LLMs suffer from a "stuck-in-the-past" problem. Because they are trained on older code, they often suggest outdated code that works, but are no longer "idiomatic" or preferred in modern Go.

Here is how I use .agent/rules to enforce modern best practices.

The Problem: Outdated Defaults

For example lets take LeetCode problem: 1. Two Sum. Here is an example solution in Go:

func TwoSum(nums []int, target int) []int {
    seen := make(map[int]int)
    for i, num := range nums {
        comp := target - num

        if idx, ok := seen[comp]; ok {
            return []int{idx, i}
        }

        seen[num] = i
    }

    return nil
}

If you simply prompt the Agent with: write benchmark for TwoSum function, it will likely generate a benchmark that looks like this:

func BenchmarkTwoSum(b *testing.B) {
    // Create a larger input for benchmarking
    nums := make([]int, 1000)
    for i := 0; i < 1000; i++ { // Old style loop
        nums[i] = i
    }
    target := 1997 

    b.ResetTimer()
    for i := 0; i < b.N; i++ { // Old style benchmark loop
        TwoSum(nums, target)
    }
}

The issues:

It uses for i := 0; i < 1000; i++ instead of the modern Go 1.22 for i := range 1000.
It uses b.N manually instead of the modern Go 1.24 b.Loop method.

The Solution: Agent Rules

To handle this, we can use Rules. In Antigravity, a Rule is simply a Markdown file where you define constraints, stack preferences, and style guides. (See the documentation for setup details).

We can create specific rule files to "patch" the LLMs knowledge base.

1. Modernizing Benchmarks (benchmark.md)

Create a file named benchmark.md to instruct the agent on the new testing API:

The `b.Loop` method is now the preferred way to write benchmarks in Go 1.24+.


func BenchmarkExample(b *testing.B) {
    // ... setup ...
    for b.Loop() {
        // optional timer control for in-loop setup/cleanup is handled automatically
        // ... code to measure ...
    }
    // ... cleanup ...
}

Always use b.Loop() instead of b.N in benchmarks.

2. Modernizing Loops (`loops.md`)

Create a file named loops.md to enforce modern iteration syntax:

Each iteration creates a new instance of the variable. There is no need to declare `v := v` inside the loop for closure safety.

for _, v := range data {
    go func() {
        // safe to use v here directly
    }()
}

`For` loops may now range over integers. We should use `for i := range 10` now.

for i := range 10 {
    fmt.Println(10 - i)
}

The Result

After creating these files, click the Reload Rules button in the editor. Now, retry the prompt: write benchmark for TwoSum function or be specific: apply benchmark and loops rules to generate a benchmark.

You will see the Agent's implementation plan acknowledge the new context:

[NEW] search_test.go
* Create `search_test.go`.
* Implement `BenchmarkTwoSum`.
* Use `b.Loop()` structure.
* Construct a large slice of integers and a target that is found near the end or not found to test worst/average cases.

The resulting code is cleaner, modern, and follows the latest Go specs:

func BenchmarkTwoSum(b *testing.B) {
    nums := make([]int, 1000)
    for i := range 1000 {
        nums[i] = i
    }
    target := 1997 

    for b.Loop() {
        TwoSum(nums, target)
    }
}

Going Further: Enforcing Style Guides

This feature is powerful because it keeps your code consistent. It forces the LLM to follow your team's rules instead of guessing or using random styles.

For example, you can feed the LLM the entire Uber Go Style Guide. Or use specific libraries.

Example: Enforcing Error Wrapping `errors.md`

If you want to ensure all errors are wrapped using cockroachdb/errors instead of standard returns or fmt.Errorf:

Do not simply `return err`. Always wrap errors using `github.com/cockroachdb/errors` to provide stack traces and context. Use `Wrap(error, string)` or `Wrapf(error, string, ...interface{})`.

func getUser(id int) error {
    if err := someDatabaseCall(id); err != nil {
        // Wrap the original error with added context
        return errors.Wrapf(err, "some database call id %d", id)
    }

    return nil
}

It is annoying when LLMs provide code that is stuck-in-the-past By using .agent/rules in Antigravity, you can stop fighting the LLMs old habits. Instead, you can collaborate with an Agent that understands your specific tools and style. Rules bridge the gap between what the LLM knows and the code you actually want.