DoorDash usa LLMs multiagente para limpar 60 mil feature flags em 13,8 min e US$ 4,79 por remoção

A DoorDash avaliou um sistema multiagente baseado em LLMs para remover feature flags obsoletas e gerou pull requests utilizáveis em 45 de 50 casos, com média de 13,8 minutos e US$ 4,79 por limpeza. A comparação da própria empresa estima de uma a duas horas para o trabalho manual equivalente, conforme reportagem da InfoQ.

O resultado é parte de um esforço para lidar com um inventário de mais de 60.000 feature flags distribuídas por cerca de 623 repositórios, com aproximadamente 2.300 novas flags criadas por mês. A companhia identificou mais de 1.000 flags obsoletas; uma flag é classificada como obsoleta quando não é modificada há 90 dias, continua referenciada no código, não está arquivada ou aposentada e não é explicitamente excluída. Um processo diário transforma essas flags em tickets no Jira.

O problema dos 60 mil flags e da injeção de dependência

A limpeza manual é dificultada pelo padrão de Dependency Injection usado na DoorDash. A definição da flag, a chamada do cliente e a lógica de negócio podem estar espalhadas por vários arquivos. Uma flag booleana simples pode exigir mudanças em 5 a 20 arquivos, incluindo testes.

A ferramenta open source Piranha, da Uber, tenta resolver parte desse problema com transformações baseadas em árvore de sintaxe abstrata (AST) para identificar e remover código de feature flags obsoletas. A DoorDash concluiu que essa abordagem não cobre seus padrões de injeção de dependência: a relação entre a flag e a lógica da aplicação é semântica, não diretamente representada por correspondência de sintaxe. Isso motivou a aposta em um sistema com LLMs no lugar de regras determinísticas.

O fluxo em duas fases com aprovação humana

O sistema usa o Google Agent Development Kit e é dividido em duas fases. Na primeira, um orquestrador rodando Claude Sonnet busca tickets de flags obsoletas no Jira, pesquisa os repositórios relevantes e consulta a plataforma de experimentação por meio do Model Context Protocol (MCP) para obter metadados como percentual de rollout e valor alvo. Um engenheiro revisa o relatório gerado e confirma o valor alvo antes de qualquer mudança de código.

A segunda fase coloca agentes de limpeza Claude Opus em worktrees isoladas do Git (git worktree), com até quatro agentes concorrentes por repositório. Cada agente localiza as referências da flag, define a estratégia de remoção, altera código-fonte e testes e executa builds, testes, cobertura de patch JaCoCo e análise estática Detekt. O pull request só é aberto depois que todas as validações passam. Há um timeout de uma hora por agente, e o Gradle roda sem daemon para evitar compartilhamento de estado entre worktrees.

Resultados por complexidade e as cinco intervenções

A avaliação com 50 flags gerou 31 merges de primeira passada, 14 revisões e 5 intervenções de engenheiros. Flags simples tiveram 100% de taxa de limpeza em uma única passada; flags de complexidade média alcançaram 94%, e as complexas, 85%. As cinco intervenções envolveram cadeias de chamadas profundas e passagem de parâmetros entre interfaces. A DoorDash não relatou bugs nem regressões nas mudanças avaliadas.

Ressalvas e próximos passos

A amostra de 50 flags é pequena diante de mais de 1.000 obsoletas identificadas; o material não indica que o sistema já foi aplicado em toda a base. As cinco intervenções manuais também mostram que a automação ainda encontra limites em casos com cadeias profundas de chamadas e parâmetros entre interfaces. O custo médio de US$ 4,79 e o tempo de 13,8 minutos são médias, sem detalhamento de variação por complexidade.

A empresa planeja adicionar pontuação de confiança para limpezas de menor risco e uma etapa pós-limpeza de qualidade de código para identificar problemas como nomes de variáveis enganosos após a remoção da flag. O trabalho foi aceito para a trilha industrial do ICSME 2026, conforme a apuração da InfoQ.