GitLab confie la migration de son rate limiting à des agents IA : 14 spécifications et plus de 30 merge requests

Une petite équipe de GitLab a mené une expérience et, avec l'aide d'agents IA, a migré une partie d'un système hérité de limitation de requêtes (rate limiting) vers une implémentation unique dans la bibliothèque labkit-ruby, sans abaisser le niveau de fiabilité. L'équipe elle-même juge le résultat réussi.

Le système avant la migration

Pendant des années, GitLab a fait coexister deux voies de limitation de requêtes : `Gitlab::ApplicationRateLimiter`, au niveau applicatif et doté de 121 clés, et un système distinct au niveau de Rack. L'objectif de la migration était de fusionner les deux voies en une seule implémentation dans `labkit-ruby`, afin que le système soit observable, testable et se comporte de la même façon dans toutes les parties du produit. Chaque requête vers le monolithe GitLab passe par ce système : ses défaillances doivent donc être visibles et réversibles.

Qui a travaillé sur la migration, et comment

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

• Max Woolf, Staff Backend Engineer dans l'équipe API Platform, s'est occupé du côté monolithe et a assuré la plupart des livraisons
• Bob Van Landuyt, de l'équipe Scalability, s'est chargé de la bibliothèque elle-même et de l'architecture de la solution
• Quelques autres ingénieurs sont intervenus ponctuellement pour prendre le contexte en main et aider sur le code et les revues
• L'équipe a utilisé GitLab Duo Agent Platform et GitLab Duo Code Review

Les agents lisaient le contexte, préparaient des brouillons de spécifications, implémentaient des changements de portée limitée, écrivaient des tests et effectuaient une revue préliminaire des merge requests. Les humains gardaient la main sur le périmètre, l'architecture, les livraisons et la décision finale.

Comment le cycle de travail était organisé

L'équipe suivait un cycle strict : lire l'epic, rédiger une spécification, la soumettre à une revue adversariale, ne commencer l'implémentation qu'après la levée des blocages, vérifier le résultat avec des preuves explicites, mener une revue adversariale de la merge request elle-même, escalader vers une revue humaine, et seulement ensuite fusionner. La revue adversariale était limitée à deux tours ; passé ce cap, la décision revenait obligatoirement à un humain.

• L'équipe a livré 14 spécifications numérotées pour le projet
• Plus de 30 merge requests ont été intégrées à la bibliothèque `labkit-ruby`
• Dans la pratique, la rigueur du cycle variait d'un ingénieur à l'autre : Bob Van Landuyt menait souvent seul plusieurs tours de spécification et de revue avant de présenter un artefact commun à l'équipe

Ce que cela signifie

L'expérience de GitLab montre que les agents IA peuvent déjà prendre en charge la partie routinière de la migration de code hérité (brouillons de spécifications, implémentation et tests), mais que ce sont le workflow strict, la structure de l'équipe et la revue humaine obligatoire qui déterminent si le système reste aussi fiable qu'avant. Les auteurs soulignent sans détour que les agents fonctionnent, mais qu'ils mettent aussi à nu des points faibles dans la façon dont l'équipe organise habituellement son travail. Le cycle de revue et l'observabilité se sont révélés tout aussi importants que les capacités des agents.

Questions fréquentes

Combien de personnes ont travaillé sur la migration du rate limiting chez

GitLab ?

Trois ingénieurs de GitLab ont travaillé sur le projet (Max Woolf, Bob Van Landuyt et quelques autres intervenus ponctuellement), avec un ensemble d'agents IA reposant sur GitLab Duo Agent Platform.

Quelle quantité de code et de spécifications l'équipe a-t-elle livrée ?

Pendant l'expérience, l'équipe a préparé 14 spécifications numérotées et soumis plus de 30 merge requests à la bibliothèque labkit-ruby.