GitLab a Migré la Limitation de Débit vers des Agents d\'IA: 14 Spécifications et 30+ Demandes de Fusion

Une petite équipe de GitLab a mené une expérience et utilisé des agents d'IA pour migrer une partie d'un système hérité de limitation de débit de requêtes vers une implémentation unifiée dans la bibliothèque labkit-ruby sans compromettre la fiabilité — l'équipe qualifie les résultats de l'expérience de réussis.

Comment était le système avant la migration

GitLab avait deux chemins parallèles pour limiter les requêtes depuis des années : le `Gitlab::ApplicationRateLimiter` au niveau applicatif avec 121 clés et un système séparé au niveau Rack. L'objectif de la migration était de combiner les deux chemins en une implémentation unifiée dans `labkit-ruby` pour que le système soit observable, testable et fonctionne de manière cohérente dans toutes les parties du produit. Chaque requête au monolithe GitLab passe par ce système, donc ses défaillances doivent être visibles et réversibles.

Qui a travaillé sur la migration et comment

Trois ingénieurs de GitLab et un ensemble d'agents d'IA ont travaillé sur le projet.

• Max Woolf, Staff Backend Engineer dans l'équipe Plateforme API, était responsable du côté monolithe et a dirigé la plupart des versions
• Bob Van Landuyt de l'équipe Scalabilité était responsable de la bibliothèque elle-même et de l'architecture de la solution
• Plusieurs autres ingénieurs ont été impliqués de manière ponctuelle pour comprendre le contexte et aider avec le code et les révisions
• GitLab Duo Agent Platform et GitLab Duo Code Review ont été utilisés

Les agents ont lu le contexte, préparé des brouillons de spécifications, implémenté des modifications de portée limitée, écrit des tests et effectué des révisions préliminaires de demandes de fusion. Les humains ont conservé la portée, l'architecture, les versions et les décisions finales.

Comment le cycle de travail a été structuré

L'équipe a travaillé selon un cycle strict : lire l'épopée, écrire une spécification, mener un examen contradictoire, procéder à l'implémentation uniquement après résolution des blocages, vérifier le résultat avec des preuves explicites, mener un examen contradictoire de la demande de fusion elle-même, escalader vers un examen humain, puis seulement fusionner. Les examens contradictoires ont été limités à deux tours — après cela, la solution était obligée d'être transmise à un humain.

• L'équipe a publié 14 spécifications numérotées pour le projet
• Plus de 30 demandes de fusion sont allées à la bibliothèque `labkit-ruby`
• En pratique, la rigueur du cycle variait d'un ingénieur à l'autre : Bob Van Landuyt a souvent mené plusieurs tours de spécification et de révision seul avant de montrer l'artefact global à l'équipe

Ce que cela signifie

L'expérience de GitLab montre que les agents d'IA sont déjà capables de prendre en charge la partie routinière de la migration de code hérité — brouillons de spécifications, implémentation et tests — mais le processus de travail strict, la structure d'équipe et l'examen humain obligatoire déterminent si le système reste aussi fiable qu'avant. Les auteurs de l'expérience notent directement que les agents fonctionnent, mais exposent également des points faibles dans la façon dont l'équipe organise habituellement son travail — le cycle d'examen et l'observabilité se sont avérés aussi importants que les capacités des agents.

Questions fréquemment posées

Combien de personnes ont travaillé sur la migration de limitation de débit chez

GitLab?

Trois ingénieurs de GitLab ont travaillé sur le projet — Max Woolf, Bob Van Landuyt et plusieurs autres qui ont participé de manière ad hoc — avec un ensemble d'agents d'IA basés sur la Plateforme GitLab Duo Agent.

Combien de code et combien de spécifications l'équipe a-t-elle publiés?

Durante l'expérience, l'équipe a préparé 14 spécifications numérotées et a envoyé plus de 30 demandes de fusion à la bibliothèque labkit-ruby.