GitLab migra rate limiting com agentes de IA: 14 especificações e mais de 30 merge requests

Uma pequena equipe do GitLab fez um experimento e, com a ajuda de agentes de IA, migrou parte de um sistema legado de limitação de requisições (rate limiting) para uma implementação única na biblioteca labkit-ruby, sem baixar o nível de confiabilidade. A própria equipe considera o resultado bem-sucedido.

Como era o sistema antes da migração

Por anos, o GitLab manteve em paralelo dois caminhos de limitação de requisições: o `Gitlab::ApplicationRateLimiter`, no nível da aplicação e com 121 chaves, e um sistema separado no nível do Rack. O objetivo da migração era unir os dois caminhos em uma única implementação no `labkit-ruby`, para que o sistema fosse observável, testável e se comportasse da mesma forma em todas as partes do produto. Toda requisição ao monolito do GitLab passa por esse sistema, então suas falhas precisam 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 da equipe API Platform, cuidou do lado do monolito e fez a maioria dos lançamentos
• Bob Van Landuyt, da equipe Scalability, cuidou da própria biblioteca e da arquitetura da solução
• Outros engenheiros entraram pontualmente para entender o contexto e ajudar com código e revisões
• Foram usados o GitLab Duo Agent Platform e o GitLab Duo Code Review

Os agentes liam o contexto, preparavam rascunhos de especificações, implementavam mudanças de escopo limitado, escreviam testes e faziam uma revisão preliminar dos merge requests. As pessoas ficaram com o escopo, a arquitetura, os lançamentos e a decisão final.

Como o fluxo de trabalho foi organizado

A equipe seguiu um ciclo rigoroso: ler o épico, escrever a especificação, submetê-la a uma revisão adversarial, só iniciar a implementação depois de remover os bloqueios, verificar o resultado com evidências explícitas, fazer uma revisão adversarial do próprio merge request, escalar para revisão humana e só então fazer o merge. A revisão adversarial foi limitada a duas rodadas; depois disso, a decisão passava obrigatoriamente para uma pessoa.

• A equipe entregou 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 variava de engenheiro para engenheiro: Bob Van Landuyt costumava fazer várias rodadas de especificação e revisão sozinho antes de mostrar um artefato comum à equipe

O que isso significa

O experimento do GitLab mostra que os agentes de IA já conseguem assumir a parte rotineira da migração de código legado (rascunhos de especificações, implementação e testes), mas são o fluxo de trabalho rigoroso, a estrutura da equipe e a revisão humana obrigatória que determinam se o sistema continuará tão confiável quanto antes. Os autores afirmam abertamente que os agentes funcionam, mas também expõem pontos fracos na forma como a equipe costuma organizar seu trabalho. O ciclo de revisão e a observabilidade se mostraram tão importantes quanto as capacidades dos agentes.

Perguntas frequentes

Quantas pessoas trabalharam na migração do rate limiting no

GitLab?

Três engenheiros do GitLab trabalharam no projeto (Max Woolf, Bob Van Landuyt e mais alguns que entraram pontualmente), junto com um conjunto de agentes de IA baseados no GitLab Duo Agent Platform.

Quanto código e quantas especificações a equipe entregou?

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