GitLab migra su sistema de rate limiting con agentes de IA: 14 especificaciones y más de 30 merge requests

Un pequeño equipo de GitLab llevó a cabo un experimento: usar agentes de IA para migrar parte de su sistema heredado de limitación de solicitudes (rate limiting) a una implementación unificada en la biblioteca labkit-ruby, sin rebajar el listón de fiabilidad. El propio equipo califica el resultado del experimento como un éxito.

Cómo era el sistema antes de la migración

Durante años, GitLab mantuvo en paralelo dos vías para limitar solicitudes: el `Gitlab::ApplicationRateLimiter` de la capa de aplicación, con 121 claves, y un sistema independiente a nivel de Rack. El objetivo de la migración era unificar ambas vías en una única implementación en `labkit-ruby`, de modo que el sistema fuera observable, testeable y se comportara igual en todas las partes del producto. Cada solicitud al monolito de GitLab pasa por este sistema, así que sus fallos tenían que ser visibles y reversibles.

Quién trabajó en la migración y cómo

En el proyecto participaron tres ingenieros de GitLab y un conjunto de agentes de IA.

• Max Woolf, Staff Backend Engineer en el equipo de API Platform, se ocupó de la parte del monolito y gestionó la mayoría de los despliegues
• Bob Van Landuyt, del equipo de Scalability, se encargó de la propia biblioteca y de la arquitectura de la solución
• Varios ingenieros más se sumaron de forma puntual para ponerse al día con el contexto y ayudar con el código y las revisiones
• Se utilizaron GitLab Duo Agent Platform y GitLab Duo Code Review

Los agentes leían el contexto, preparaban borradores de especificaciones, implementaban cambios de alcance acotado, escribían tests y hacían una revisión preliminar de los merge requests. Las personas se reservaron el alcance, la arquitectura, los despliegues y la decisión final.

Cómo funcionaba el ciclo de trabajo

El equipo siguió un ciclo estricto: leer el epic, escribir la especificación, someterla a una revisión adversarial, empezar la implementación solo tras resolver los bloqueos, verificar el resultado con pruebas explícitas, someter el propio merge request a una revisión adversarial, escalarlo a revisión humana y solo entonces hacer el merge. La revisión adversarial se limitó a dos rondas; después, la decisión pasaba obligatoriamente a una persona.

• El equipo publicó 14 especificaciones numeradas para el proyecto
• Se enviaron más de 30 merge requests a la biblioteca `labkit-ruby`
• En la práctica, el rigor del ciclo variaba según el ingeniero: Bob Van Landuyt solía hacer por su cuenta varias rondas de especificación y revisión antes de mostrar un artefacto común al equipo

Qué significa esto

El experimento de GitLab demuestra que los agentes de IA ya pueden asumir la parte rutinaria de la migración de código heredado —borradores de especificaciones, implementación y tests—, pero son el flujo de trabajo estricto, la estructura del equipo y la revisión humana obligatoria los que determinan si el sistema sigue siendo tan fiable como antes. Los autores del experimento lo señalan sin rodeos: los agentes funcionan, pero también dejan al descubierto los puntos débiles en la forma en que el equipo suele organizar su trabajo. El ciclo de revisión y la observabilidad resultaron tan importantes como las capacidades de los agentes.

Preguntas frecuentes

¿Cuántas personas trabajaron en la migración del rate limiting de

GitLab?

En el proyecto participaron tres ingenieros de GitLab —Max Woolf, Bob Van Landuyt y varias personas más que se sumaron de forma puntual—, junto con un conjunto de agentes de IA basados en GitLab Duo Agent Platform.

¿Cuánto código y cuántas especificaciones produjo el equipo?

Durante el experimento, el equipo preparó 14 especificaciones numeradas y envió más de 30 merge requests a la biblioteca labkit-ruby.