GitLab Migrated Rate Limiting to AI Agents: 14 Specs and 30+ Merge Requests

A small GitLab team conducted an experiment and used AI agents to migrate part of a legacy request rate limiting system to a unified implementation in the labkit-ruby library without compromising reliability — the team calls the experiment results successful.

What the system was like before migration

GitLab had two parallel paths for request limiting for years: the application-level `Gitlab::ApplicationRateLimiter` with 121 keys and a separate Rack-level system. The goal of the migration was to combine both paths into a unified implementation in `labkit-ruby` so the system would be observable, testable, and work consistently across all parts of the product. Every request to the GitLab monolith passes through this system, so its failures must be visible and reversible.

Who worked on the migration and how

Three GitLab engineers and a set of AI agents worked on the project.

• Max Woolf, Staff Backend Engineer on the API Platform team, was responsible for the monolith side and conducted most releases
• Bob Van Landuyt from the Scalability team was responsible for the library itself and the solution architecture
• Several other engineers were involved on a case-by-case basis to understand the context and help with code and reviews
• GitLab Duo Agent Platform and GitLab Duo Code Review were used

The agents read the context, prepared specification drafts, implemented scope-limited changes, wrote tests, and performed preliminary merge request reviews. The people retained scope, architecture, releases, and final decisions.

How the work cycle was structured

The team worked on a strict cycle: read the epic, write a specification, conduct an adversarial review, proceed to implementation only after blockers were cleared, verify the result with explicit evidence, conduct an adversarial review of the merge request itself, escalate to human review, and only then merge. Adversarial reviews were limited to two rounds — after that, the solution was obligated to be passed to a human.

• The team released 14 numbered specifications for the project
• Over 30 merge requests went into the `labkit-ruby` library
• In practice, the strictness of the cycle varied from engineer to engineer: Bob Van Landuyt often conducted several rounds of specification and review alone before showing the overall artifact to the team

What this means

GitLab's experiment shows that AI agents are already capable of taking on the routine part of legacy code migration — specification drafts, implementation, and tests — but the strict work process, team structure, and mandatory human review determine whether the system remains as reliable as before. The experiment authors directly note that agents work, but also expose weak points in how the team usually organizes its work — the review cycle and observability themselves turned out to be no less important than the agents' capabilities.

Frequently asked questions

How many people worked on the rate limiting migration at

GitLab?

Three GitLab engineers worked on the project — Max Woolf, Bob Van Landuyt, and several others who participated on an ad-hoc basis — together with a set of AI agents based on the GitLab Duo Agent Platform.

How much code and how many specifications did the team release?

During the experiment, the team prepared 14 numbered specifications and sent over 30 merge requests to the labkit-ruby library.