GitLab Migró Rate Limiting a Agentes de IA: 14 Especificaciones y 30+ Solicitudes de Merge

Un pequeño equipo de GitLab realizó un experimento e utilizó agentes de IA para migrar parte de un sistema heredado de limitación de velocidad de solicitudes a una implementación unificada en la biblioteca labkit-ruby sin comprometer la confiabilidad: el equipo califica los resultados del experimento como exitosos.

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

GitLab tenía dos caminos paralelos para limitar las solicitudes durante años: el nivel de aplicación `Gitlab::ApplicationRateLimiter` con 121 claves y un sistema separado a nivel de Rack. El objetivo de la migración era combinar ambos caminos en una implementación unificada en `labkit-ruby` para que el sistema fuera observable, comprobable y funcionara de manera consistente en todas las partes del producto. Cada solicitud al monolito de GitLab pasa a través de este sistema, por lo que sus fallas deben ser visibles e invertibles.

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

Tres ingenieros de GitLab y un conjunto de agentes de IA trabajaron en el proyecto.

• Max Woolf, Staff Backend Engineer en el equipo de Plataforma de API, fue responsable del lado del monolito y realizó la mayoría de las versiones
• Bob Van Landuyt del equipo de Escalabilidad fue responsable de la biblioteca misma y la arquitectura de la solución
• Varios otros ingenieros estuvieron involucrados de forma puntual para comprender el contexto y ayudar con el código y las revisiones
• Se utilizaron la Plataforma de Agentes GitLab Duo y la Revisión de Código GitLab Duo

Los agentes leyeron el contexto, prepararon borradores de especificaciones, implementaron cambios de alcance limitado, escribieron pruebas y realizaron revisiones preliminares de solicitudes de fusión. Las personas retuvieron el alcance, la arquitectura, las versiones y las decisiones finales.

Cómo se estructuró el ciclo de trabajo

El equipo trabajó en un ciclo estricto: leer la épica, escribir una especificación, realizar una revisión adversarial, proceder a la implementación solo después de eliminar los bloqueadores, verificar el resultado con evidencia explícita, realizar una revisión adversarial de la solicitud de fusión misma, escalar a revisión humana, y solo entonces fusionar. Las revisiones adversariales se limitaron a dos rondas: después de eso, la solución estaba obligada a pasar a un humano.

• El equipo lanzó 14 especificaciones numeradas para el proyecto
• Más de 30 solicitudes de fusión llegaron a la biblioteca `labkit-ruby`
• En la práctica, la rigidez del ciclo varió de ingeniero a ingeniero: Bob Van Landuyt a menudo realizaba varias rondas de especificación y revisión solo antes de mostrar el artefacto general al equipo

Lo que esto significa

El experimento de GitLab muestra que los agentes de IA ya son capaces de asumir la parte rutinaria de la migración de código heredado (borradores de especificaciones, implementación y pruebas), pero el proceso de trabajo estricto, la estructura del equipo y la revisión humana obligatoria determinan si el sistema se mantiene tan confiable como antes. Los autores del experimento notan directamente que los agentes funcionan, pero también exponen puntos débiles en cómo el equipo generalmente organiza su trabajo: el ciclo de revisión y la observabilidad resultaron ser no menos importantes que las capacidades de los agentes.

Preguntas frecuentes

¿Cuántas personas trabajaron en la migración de limitación de velocidad en

GitLab?

Tres ingenieros de GitLab trabajaron en el proyecto: Max Woolf, Bob Van Landuyt y varios otros que participaron de manera ad hoc, junto con un conjunto de agentes de IA basados en la Plataforma de Agentes GitLab Duo.

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

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