--- title: "DoorDash usa múltiplos agentes de IA para limpar 60 mil flags esquecidas" author: "Lígia Lemos Maia" date: "2026-09-20 08:30:00-03" category: "Inteligência Artificial & Dados" url: "http://desbugados.scale.press/portal/desbugados/post/2026/09/20/doordash-usa-multiplos-agentes-de-ia-para-limpar-60-mil-flags-esquecidas/md" --- ## Resumo - A DoorDash automatizou a limpeza de mais de 60.000 feature flags em 623 repositórios. - O sistema considera obsoletas as flags sem modificação por 90 dias e lida com cerca de 2.300 novas flags por mês. - O processo reduziu o tempo de limpeza de 1 a 2 horas para aproximadamente 13,8 minutos, com custo de US$ 4,79 por operação. - Google Agent Development Kit e Model Context Protocol organizam a consulta de metadados e o fluxo de agentes. - Em um teste com 50 flags, 45 geraram pull requests utilizáveis, sem bugs ou regressões registrados. - A taxa de sucesso foi de 100% em casos simples, 94% nos médios e 85% nos complexos. - A revisão humana permaneceu necessária em cinco casos com cadeias de chamadas complexas. --- Em setembro de 2026, a **DoorDash** colocou em operação um sistema de múltiplos agentes baseados em modelos de linguagem para enfrentar um problema que cresce silenciosamente dentro de grandes bases de código: a permanência de funcionalidades antigas depois que deixam de ser necessárias. O fluxo alcança mais de **60.000 feature flags** em **623 repositórios** e reduziu o tempo médio de limpeza manual de uma ou duas horas para 13,8 minutos. Cada operação custa US$ 4,79, segundo os dados consolidados sobre o projeto. A pergunta que emerge é direta: quando um agente pode alterar código em nome de uma equipe, quais limites precisam existir para que velocidade não se transforme em risco? ## O acúmulo que transforma pequenas decisões em dívida técnica O tamanho do problema aparece nos números de criação e abandono. A DoorDash administra mais de **60.000 flags** espalhadas por **623 repositórios**, enquanto aproximadamente 2.300 novas unidades são criadas todos os meses. No sistema descrito, uma flag passa a ser considerada obsoleta depois de **90 dias sem modificação**, critério que oferece uma referência objetiva para procurar pontos de código que ainda existem, mas já não recebem alterações. Uma feature flag funciona, nesse contexto, como um ponto de controle usado para manter uma funcionalidade ativa ou inativa; quando permanece depois do experimento ou da mudança que a originou, ela adiciona uma camada de leitura e manutenção ao software. Esse acúmulo prepara o terreno para a automação apresentada pela empresa. O ganho mais visível está no relógio. Uma limpeza que antes consumia entre **1 e 2 horas** passou a levar cerca de **13,8 minutos**, ou aproximadamente 14 minutos, por operação. A diferença não vem de uma única resposta produzida por um chatbot, mas de uma sequência na qual os agentes consultam informações, propõem alterações e submetem o resultado a verificações. A [descrição técnica publicada pela InfoQ](https://www.infoq.com/news/2026/09/doordash-feature-flag-cleanup) apresenta o caso como uma tentativa de tratar a manutenção de código em escala, algo que muda a natureza da tarefa: em vez de esperar que uma pessoa encontre cada flag esquecida, o sistema percorre uma fila de candidatos e prepara mudanças para avaliação. O tempo economizado, portanto, está ligado à repetição organizada do processo. ## Como a arquitetura divide a tarefa entre os agentes O primeiro nível da solução usa o **Google Agent Development Kit**, conjunto empregado para estruturar o fluxo de agentes, e o **Model Context Protocol**, conhecido como MCP, para consultar metadados dos experimentos. Metadados são informações que ajudam a descrever uma unidade de código ou um experimento, como seu estado e seu histórico de modificação. Na prática descrita pelas fontes, o MCP funciona como uma ponte entre o sistema de agentes e os dados necessários para decidir se uma flag pode ser tratada como obsoleta. Essa separação reduz a dependência de suposições feitas apenas a partir do texto do código, porque a decisão também considera informações associadas ao experimento. O código deixa de ser lido como uma peça isolada e passa a ser examinado junto com seu contexto operacional. Depois dessa consulta, o trabalho é repartido entre dois modelos com funções diferentes. O **Claude Sonnet** participa da orquestração, isto é, da coordenação das etapas e da escolha do próximo passo, enquanto agentes baseados no **Claude Opus** realizam alterações em código isolado, executam testes e fazem análise estática. Código isolado significa que a modificação é preparada em um espaço separado antes de ser incorporada ao projeto principal, o que cria uma barreira entre a tentativa automatizada e a versão utilizada pela equipe. A análise estática examina o código sem executá-lo, procurando problemas estruturais que os testes podem não alcançar. Ao final, o sistema gera um pull request, proposta formal de alteração que pode ser revisada e incorporada pelos responsáveis. ## O que aconteceu quando 50 flags foram colocadas à prova O teste mais concreto envolveu **50 flags**. Dessas, **45 geraram pull requests utilizáveis**, e cada operação teve custo informado de US$ 4,79. As fontes também registram que não houve bugs ou regressões, termo usado para descrever problemas novos ou comportamentos quebrados depois de uma mudança. Esse resultado não significa que o agente tenha recebido autorização irrestrita para modificar tudo o que encontrasse. A utilidade da proposta está na combinação entre a produção automática da alteração e a existência de verificações antes que ela avance. O agente prepara o trabalho; o processo de validação decide se aquele trabalho está pronto para ser examinado por uma pessoa. A divisão por complexidade mostra por que uma média geral não conta toda a história. O sistema alcançou **100% de sucesso em flags simples**, **94% nas de complexidade média** e 85% nas complexas. Entre as 50 unidades avaliadas, 31 foram mescladas de primeira, 14 precisaram de revisões e 5 exigiram intervenção humana por causa de cadeias de chamadas complexas, ou seja, relações em que uma função depende de outras etapas do código e torna a remoção menos previsível. A diferença entre 100% e 85% não é um detalhe estatístico: ela mostra que a autonomia cresce quando o problema é delimitado e diminui quando a alteração atravessa mais dependências. É nesse ponto que a linguagem de eficiência encontra a realidade irregular do software. ## A velocidade encontra a revisão humana A arquitetura descrita pela DoorDash mantém a revisão humana como parte do circuito, especialmente nas situações em que a cadeia de chamadas impede uma decisão simples. A integração dos dados de experimentação pelo **MCP** fornece contexto, enquanto a revisão de uma pessoa funciona como uma camada de controle sobre a alteração proposta. A análise sobre governança de agentes que cita o projeto enfatiza justamente essa combinação entre acesso a metadados e avaliação humana. A [análise sobre a governança de frotas de agentes](https://theartofcto.com/insights/from-ai-pilots-to-agent-fleets-governance-becomes-the-platform) ajuda a traduzir o ponto: quanto mais um sistema consegue agir sobre ferramentas externas, mais a autorização precisa fazer parte da própria arquitetura. A pergunta deixa de ser apenas se o agente consegue escrever código e passa a ser quem valida o momento de aceitá-lo. O custo também ajuda a dimensionar a proposta. Com **US$ 4,79 por operação** e uma redução para cerca de 14 minutos, a automação cria uma forma mensurável de tratar uma tarefa repetitiva que alcança dezenas de milhares de flags. Ainda assim, os números de sucesso por complexidade mostram que a economia de tempo não elimina a necessidade de julgamento. O sistema pode preparar uma alteração em poucos minutos, mas cinco das 50 flags testadas precisaram de intervenção humana, e outras 14 foram mescladas apenas depois de revisões. O resultado mais interessante não é a fantasia de um programador invisível que resolve tudo sozinho, e sim a construção de um fluxo em que agentes lidam com a repetição enquanto pessoas concentram atenção nas exceções. ## O que o caso ensina para quem desenvolve software Para uma equipe que queira compreender o método, a sequência apresentada pelas fontes oferece uma ordem clara. Primeiro, é preciso estabelecer um critério para identificar o que ficou obsoleto, como os **90 dias sem modificação** usados no caso. Depois, os agentes precisam consultar os dados que dão significado à flag, preparar a mudança em ambiente isolado e executar testes e análise estática. O resultado deve chegar como uma proposta revisável, e não como uma alteração silenciosa no código principal. Essa ordem é mais relevante do que a simples escolha de um modelo, porque transforma a automação em um processo observável, com pontos nos quais uma equipe pode interromper, revisar ou aceitar a mudança. O projeto também foi aceito na trilha industrial da conferência **ICSME 2026**, registro que coloca a experiência no campo das práticas de engenharia de software e não apenas no das demonstrações experimentais. O teste com 50 flags, as taxas de 100%, 94% e 85% conforme a complexidade e a ausência de bugs ou regressões formam um conjunto de indicadores para avaliar a proposta. Eles não prometem que qualquer base de código terá o mesmo desempenho, mas mostram quais perguntas precisam ser feitas antes da adoção: quantas alterações o agente conclui sem revisão adicional, em que tipo de dependência ele falha e quanto custa cada operação. A tecnologia ganha contorno quando essas perguntas deixam de ser filosóficas e passam a ser medidas. ## A caixa de ferramentas para limpar código sem perder controle O caminho apresentado pela DoorDash pode ser resumido em quatro decisões práticas: definir quando uma flag envelheceu, conectar o agente aos metadados do experimento, manter cada alteração em código isolado e exigir testes, análise estática e revisão antes da incorporação. O sistema administrou **mais de 60.000 flags**, mas a escala não dispensou a separação de responsabilidades entre coordenação, alteração e validação. Para o leitor que trabalha com desenvolvimento, essa é a parte mais aplicável do caso: a automação não começa pela promessa de substituir uma equipe, começa pela escolha de uma tarefa repetitiva com critérios verificáveis e consequências que possam ser examinadas. O próximo passo anunciado pelos próprios resultados é continuar distinguindo tarefas simples das complexas, em vez de tratar todas as flags como equivalentes. As **5 intervenções humanas** registradas entre 50 testes mostram onde a autonomia encontrou seu limite, enquanto as 31 mesclagens de primeira indicam em que tipo de tarefa o fluxo já entregou uma mudança pronta para incorporação. A apresentação na **ICSME 2026** oferece o ponto de partida para essa avaliação pública, com custo, tempo, taxa de sucesso e necessidade de revisão colocados lado a lado. A DoorDash não apagou a presença humana do processo; ela deslocou essa presença para os pontos em que o código deixa de ser repetição e volta a exigir interpretação.