A DoorDash construiu um sistema multiagente baseado em LLMs que automatiza a limpeza de feature flags obsoletas em mais de 60 mil flags distribuídas por cerca de 623 repositórios. Em uma avaliação com 50 flags paradas, o sistema gerou pull requests utilizáveis para 45 delas, com média de 13,8 minutos e custo de US$ 4,79 por limpeza, contra a estimativa interna de uma a duas horas de trabalho manual.
O trabalho foi aceito para a trilha industrial da conferência ICSME 2026 e detalha como a empresa combinou dados de experimentação, aprovação humana, worktrees isolados do Git e validação automatizada para atacar um problema clássico de débito técnico. A plataforma de experimentação da DoorDash cria cerca de 2.300 novas flags por mês, e mais de mil delas já foram classificadas como obsoletas.
# publicidade
Leia também
Entenda o que é o Model Context Protocol
Como a doordash classifica uma feature flag obsoleta?
Uma flag é considerada obsoleta quando não é modificada há 90 dias, continua referenciada no código, não foi arquivada ou aposentada e não está explicitamente excluída da limpeza. Um processo diário identifica esses casos e abre tickets no Jira automaticamente.
O desafio técnico é maior do que parece. A DoorDash usa injeção de dependência com wrappers, o que espalha a definição da flag, a chamada do cliente e a lógica de negócio por múltiplos arquivos. Uma flag booleana simples pode exigir alterações em cinco a 20 arquivos, incluindo testes. Esse cenário limita ferramentas tradicionais baseadas em sintaxe.
E por que ferramentas existentes não resolveram? O Piranha, projeto open source da Uber, remove código de flags obsoletas com transformações baseadas em árvores de sintaxe abstrata (AST). Segundo a DoorDash, a abordagem não cobre seus padrões de injeção de dependência, nos quais a relação entre flag e lógica é semântica, e não representada diretamente por correspondência de sintaxe.
# publicidade
Info: a comparação entre Piranha e o sistema da DoorDash ilustra dois paradigmas: regras determinísticas via AST versus raciocínio semântico via LLMs. Cada um cobre padrões de código que o outro não alcança.
Como funciona o workflow multiagente em duas fases?
O sistema usa o Agent Development Kit do Google e opera em duas fases. Na primeira, um orquestrador rodando Claude Sonnet recupera os tickets de flags no Jira, pesquisa os repositórios relevantes e consulta a plataforma de experimentação via 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.
Na segunda fase, agentes de limpeza baseados em Claude Opus operam em worktrees isolados do Git, com até quatro agentes concorrentes por repositório. Eles localizam referências à flag, definem a estratégia de limpeza, modificam código-fonte e testes, e rodam builds e análises. O pull request só abre depois de passar por cobertura de patch com JaCoCo e análise estática com Detekt.
Cada agente tem timeout de uma hora, e o Gradle roda sem daemon para evitar compartilhamento de estado entre worktrees. Mas o que acontece quando o agente falha? O humano entra no loop: o engineer review é etapa obrigatória antes do merge, não exceção.
Atenção: agentes concorrentes no mesmo repositório exigem isolamento rigoroso. Sem worktrees separados e Gradle sem daemon, o estado compartilhado corrompe builds e invalida a validação.
Quais foram os resultados com 50 flags avaliadas?
A avaliação produziu 31 merges na primeira tentativa, 14 com revisões e cinco intervenções de engenheiros. Flags simples tiveram 100% de limpeza em passagem única, contra 94% em complexidade média e 85% nas complexas. As cinco intervenções envolveram cadeias de chamadas profundas e passagem de parâmetros entre interfaces. A empresa não registrou bugs ou regressões nas 50 mudanças avaliadas.
| Complexidade | Limpeza em passagem única |
|---|---|
| Simples | 100% |
| Média | 94% |
| Complexa | 85% |
Arraste para o lado para ver toda a tabela.
A empresa planeja adicionar pontuação de confiança para limpezas de menor risco e uma etapa de qualidade pós-limpeza para detectar problemas como nomes de variáveis que ficam enganosos após a remoção da flag.
O que isso significa para equipes de engenharia?
O caso da DoorDash mostra agentes de IA resolvendo tarefas estruturais que ferramentas determinísticas não cobriam, mas com guardrails explícitos: aprovação humana antes da mudança, validação automatizada antes do PR e limites de tempo e isolamento por agente. O custo de US$ 4,79 por limpeza se paga rapidamente quando comparado à hora de um engenheiro sênior.
Na avaliação do Mercado de TI, o resultado mais relevante não é a velocidade, e sim a taxa de zero regressões combinada à aprovação humana obrigatória. O padrão se alinha ao que o LinkedIn já faz com revisão de código multiagente e sinaliza um modelo replicável para débito técnico em larga escala.
Dica: se sua base de código usa injeção de dependência extensiva, avalie primeiro a cobertura de testes e análise estática. Sem essas camadas, agentes de limpeza geram PRs que parecem corretos mas passam sem validação real.
As próximas etapas anunciadas pela DoorDash, com pontuação de confiança e revisão de qualidade pós-limpeza, indicam que a confiança operacional, e não a capacidade do modelo, é o gargalo para escalar esse tipo de automação. Vale acompanhar como o trabalho será recebido na ICSME 2026 e se outras plataformas de delivery adotam arquiteturas semelhantes.
Leia também:
Fonte: Infoq
