GitLab Migrou Rate Limiting para Agentes de IA: 14 Especificações e 30+ Solicitações de Merge

Um pequeno time do GitLab conduziu um experimento e usou agentes de IA para migrar parte de um sistema legado de limitação de taxa de requisições para uma implementação unificada na biblioteca labkit-ruby sem comprometer a confiabilidade — o time chama os resultados do experimento de bem-sucedidos.

Como era o sistema antes da migração

O GitLab tinha dois caminhos paralelos para limitar requisições por anos: o `Gitlab::ApplicationRateLimiter` em nível de aplicação com 121 chaves e um sistema separado em nível Rack. O objetivo da migração era combinar ambos os caminhos em uma implementação unificada em `labkit-ruby` para que o sistema fosse observável, testável e funcionasse consistentemente em todas as partes do produto. Toda requisição ao monolito do GitLab passa por esse sistema, então suas falhas devem ser visíveis e reversíveis.

Quem trabalhou na migração e como

Três engenheiros do GitLab e um conjunto de agentes de IA trabalharam no projeto.

• Max Woolf, Staff Backend Engineer no time de Plataforma de API, foi responsável pelo lado do monolito e conduziu a maioria dos lançamentos
• Bob Van Landuyt do time de Escalabilidade foi responsável pela própria biblioteca e arquitetura da solução
• Vários outros engenheiros se envolveram de forma pontual para entender o contexto e ajudar com código e revisões
• Foram usados GitLab Duo Agent Platform e GitLab Duo Code Review

Os agentes leram o contexto, prepararam rascunhos de especificações, implementaram mudanças de escopo limitado, escreveram testes e realizaram revisões preliminares de merge requests. As pessoas retiveram escopo, arquitetura, lançamentos e decisões finais.

Como o ciclo de trabalho foi estruturado

O time trabalhou em um ciclo rigoroso: ler a épica, escrever uma especificação, conduzir uma revisão adversarial, prosseguir com a implementação apenas após remover bloqueadores, verificar o resultado com evidência explícita, conduzir uma revisão adversarial do merge request em si, escalar para revisão humana e apenas então fazer o merge. Revisões adversariais foram limitadas a duas rodadas — depois disso, a solução era obrigada a ser passada para um humano.

• O time lançou 14 especificações numeradas para o projeto
• Mais de 30 merge requests foram para a biblioteca `labkit-ruby`
• Na prática, o rigor do ciclo variou de engenheiro para engenheiro: Bob Van Landuyt frequentemente conduzia várias rodadas de especificação e revisão sozinho antes de mostrar o artefato geral ao time

O que isso significa

O experimento do GitLab mostra que agentes de IA já são capazes de assumir a parte rotineira da migração de código legado — rascunhos de especificações, implementação e testes — mas o processo de trabalho rigoroso, estrutura do time e revisão humana obrigatória determinam se o sistema permanece tão confiável quanto antes. Os autores do experimento notam diretamente que os agentes funcionam, mas também expõem pontos fracos em como o time geralmente organiza seu trabalho — o ciclo de revisão e observabilidade mostraram ser não menos importantes que as capacidades dos agentes.

Perguntas frequentes

Quantas pessoas trabalharam na migração de limitação de taxa no

GitLab?

Três engenheiros do GitLab trabalharam no projeto — Max Woolf, Bob Van Landuyt e vários outros que participaram de forma ad hoc — junto com um conjunto de agentes de IA baseados na Plataforma GitLab Duo Agent.

Quanto código e quantas especificações o time lançou?

Durante o experimento, o time preparou 14 especificações numeradas e enviou mais de 30 merge requests para a biblioteca labkit-ruby.