Uber monta fábrica de software onde agentes escrevem 70% dos PRs

Segundo uma apresentação de dois engenheiros da Uber, mais de 70% dos pull requests da empresa já são escritos por agentes locais ou na nuvem. O código entregue por engenheiro dobrou em um ano, enquanto mais de 250 migrações automatizadas reescreveram 9 milhões de linhas.

A plataforma antes da fábrica

A tese central é que esses resultados dependem menos dos agentes isoladamente do que de uma plataforma que lhes forneça contexto, ferramentas, modelos, ambientes e controles. A Uber estruturou seis componentes. O principal é um grafo de contexto com 40 milhões de entradas e 150 tipos de nós e relações, conectando aplicativos, backend, data lake, documentação, Jira, incidentes e bugs. Ele substitui consultas espalhadas por 20 a 30 sistemas e, segundo a empresa, reduz tokens, etapas e latência.

As habilidades reutilizáveis ficam em um registro gerenciado, que reúne 2.500 itens submetidos a lint e revisão automatizados. Um comando permite descobri-los e instalá-los, enquanto rastreamento de uso e avaliações contínuas ajudam a melhorar sua qualidade; o sistema registra mais de 20 mil execuções por dia. Um MCP gateway concentra ferramentas e APIs internas e de SaaS, trata autenticação e permite que um agente descubra ferramentas sob demanda. A combinação de descoberta dinâmica, respostas compactas e scripts gerados no momento reduziu em mais de 40% o uso de tokens, com mais de 1.000 ferramentas acessíveis.

Todo acesso a modelos passa por um LLM gateway. Ele autentica requisições, remove mais de 20 tipos de dados pessoais identificáveis, aplica verificações de segurança e política com cinco modelos menores e atribui cada chamada a projeto, usuário e equipe. A Uber afirma processar mais de 100 milhões de requisições por dia em mais de 800 projetos, mantendo essas verificações abaixo de 100 milissegundos. Pods Kubernetes pré-provisionados, com repositórios e índices de busca prontos, dão aos agentes ambientes isolados em segundos. Por fim, a assistente Cortana reúne esses recursos no Slack, na linha de comando e na web; em um mês, surgiram 300 versões específicas de equipes e mais de 20 mil sessões diárias.

Da ideia ao código mantido

Sobre essa base, a Uber encadeia fluxos de entrega. Uma ideia discutida no Slack pode virar, em uma sessão, pesquisa, estimativa de oportunidade e dois protótipos para teste A/B, com reaproveitamento de telas e serviços existentes. Depois, o agente de programação Minion altera frontend e backend em um ambiente aquecido, mas para em um pull request de rascunho. A empresa descobriu que enviar diretamente à integração contínua era aceitável para limpezas pequenas, porém desperdiçava recursos em funcionalidades ainda não validadas.

Por isso, análise estática, validação visual por simulador e testes de integração em ambiente de preparação foram movidos para o ciclo interno, antes da CI compartilhada. Após essa etapa, uma CI capaz de se corrigir sozinha resolve muitas falhas rotineiras; revisões rápidas ocorrem na máquina e revisões mais profundas, na CI. O pull request inclui a lista de verificações aprovadas e capturas de tela, permitindo que a pessoa revisora se concentre na qualidade da decisão.

A manutenção também é centralizada: habilidades removem flags ou variantes de testes A/B, executam aos domingos quando há capacidade e limitam a quantidade de alterações que chega à equipe na segunda-feira. Comentários e resultados dos diffs alimentam as habilidades, e revisões de incidentes geram novas rotinas mensalmente.

O limite muda de lugar

Com a fábrica funcionando, o problema deixa de ser apenas a capacidade de construir e passa a incluir capacidade de CI, número de experimentos e escolha do que vale a pena construir. A conclusão é que agentes sem grafo de contexto, registro de habilidades, gateways, ambientes e governança formariam apenas scripts frágeis. Para a Uber, a plataforma precisa vir antes dos fluxos visíveis de automação.