A equipe de engenharia da Uber publicou um post no blog apresentando o sistema interno AutoClean. Ele se conecta à plataforma de gestão de feature flags da empresa, identifica as flags que já podem ser desativadas com segurança, gera automaticamente o diff que remove o código e, depois de os testes passarem, o encaminha para aprovação de um engenheiro. Ao longo dos últimos anos, o sistema limpou mais de 16 mil feature flags e mais de 1 milhão de linhas de código e continua em operação em vários monorepos da Uber.
O texto é assinado pelos engenheiros de software seniores da Uber Daniel Ramos e Diego Marcilio e pelo engenheiro de software Nikhil Parasaram.
Por que apagar código é difícil
Na Uber, as novas funcionalidades são liberadas gradualmente por meio de feature flags, e a plataforma mantém milhares delas ao mesmo tempo. Quando a liberação termina, as ramificações condicionais, funções auxiliares, pontos de chamada, configurações e testes muitas vezes continuam onde estavam. Remover uma flag exige mexer em todos esses lugares ao mesmo tempo e garantir que o comportamento em produção não mude em nada.
O blog aponta um custo novo: o código morto não apenas cansa quem lê, mas os assistentes de programação com IA também gastam mais tempo e tokens com esses ramos ao analisar a base de código.
Um pipeline em três etapas
Primeira etapa: reescrita. O agente recebe acesso à base de código e chama, via MCP, o PolyglotPiranha, mecanismo de transformação de código desenvolvido pela própria Uber e aberto ao público, que cuida da simplificação booleana e da eliminação de condições. O argumento dos autores é direto: um erro na simplificação booleana pode "can silently change program behavior", ou seja, alterar o comportamento do programa sem aviso, por isso a tarefa é entregue o máximo possível a ferramentas determinísticas.
Segunda etapa: correção do CI. As falhas simples ficam com corretores determinísticos, como remover valores padrão sem uso ou limpar erros de lint; as complexas vão para o agente, por exemplo decidir se um teste deve ser removido ou alterado. As permissões de cada corretor são estritamente limitadas, e o corretor de testes só pode mexer em arquivos de teste. O ciclo se repete até o CI passar ou até o número de tentativas se esgotar.
Terceira etapa: verificação. Com o CI aprovado, roda primeiro a análise estática e depois entra uma camada de verificação chamada CodeCourt, em que vários agentes revisores especializados fazem a checagem em paralelo. As regras listadas no blog incluem:
- apenas remover, sem acrescentar nem introduzir código novo;
- o comportamento observável permanece inalterado;
- tratar somente a flag indicada, sem aproveitar para apagar outras flags relacionadas;
- não deixar comentários nem vestígios do raciocínio do agente.
Se qualquer item falhar, o diff é descartado na hora e nunca chega a uma pessoa. Segundo os autores, alguns subagentes focados funcionam melhor do que um único agente revisando um diff inteiro do início ao fim.
Do Piranha aos agentes
A base do AutoClean é o Piranha, ferramenta que a Uber abriu ao público alguns anos atrás. Ela foi criada justamente para remover flags obsoletas, por meio de reescrita estática baseada em correspondência de regras. O PolyglotPiranha depois estendeu o mecanismo de regras para várias linguagens. A mudança agora está na camada externa: o mecanismo de regras continua cuidando da lógica booleana, a mais sujeita a erros, os agentes assumem o que as regras não cobrem, como corrigir testes e completar pontos de chamada, e outro conjunto de agentes faz a conferência cruzada.
O blog admite abertamente alguns modos de falha: o agente pode alterar código de produção só para fazer os testes passarem, apagar testes cujo comportamento deveria ser preservado ou encerrar cedo demais, deixando uma limpeza pela metade; com muitas instruções, também pode esquecer alguma restrição. O CI não detecta esses problemas semânticos, e tanto a limitação das permissões dos corretores quanto a adição do CodeCourt foram pensadas para eles.
O texto não informa taxa de sucesso, tempo médio nem a proporção de diffs descartados; o código de exemplo está em Go, e a cobertura de outras linguagens também não é detalhada. Pela descrição dos autores, o revisor humano agora só precisa responder a uma pergunta: essa flag deve ser removida? A correção em nível mecânico já foi filtrada pelas três etapas anteriores.
Fontes: blog oficial da Uber Engineering, CocoLoop, página do projeto PolyglotPiranha no GitHub; os números de limpeza seguem o critério acumulado divulgado no blog da Uber.