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

Un pequeño equipo de GitLab hizo un experimento y, con ayuda de agentes de IA, migró parte de un sistema heredado de limitación de solicitudes (rate limiting) a una implementación única en la biblioteca labkit-ruby, sin bajar el listón de fiabilidad. El propio equipo califica el resultado de exitoso.

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

Durante años, GitLab mantuvo en paralelo dos vías de limitación de solicitudes: `Gitlab::ApplicationRateLimiter`, a nivel de aplicación y con 121 claves, y un sistema independiente a nivel de Rack. El objetivo de la migración era unir 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, por lo que sus fallos deben ser visibles y reversibles.

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

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

• Max Woolf, Staff Backend Engineer del equipo API Platform, se ocupó del lado del monolito y realizó la mayoría de los lanzamientos
• Bob Van Landuyt, del equipo Scalability, se encargó de la propia biblioteca y de la arquitectura de la solución
• Otros ingenieros se incorporaron de forma puntual para entender el contexto y ayudar con el código y las revisiones
• Se usaron 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 pruebas y hacían una revisión preliminar de los merge requests. Las personas conservaron el alcance, la arquitectura, los lanzamientos y la decisión final.

Cómo se organizó el flujo de trabajo

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

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

Qué significa

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 pruebas), pero que 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 señalan sin rodeos que los agentes funcionan, pero que además dejan al descubierto puntos débiles en la forma en que el equipo suele organizar su trabajo. El ciclo de revisión y la observabilidad resultaron ser tan importantes como las capacidades de los agentes.

Preguntas frecuentes

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

GitLab?

En el proyecto trabajaron tres ingenieros de GitLab (Max Woolf, Bob Van Landuyt y algunos más que se incorporaron 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 publicó el equipo?

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