Ir para o conteúdo principal
Voltar aos artigos

Agentes aumentam a produção; a Uber mostra onde a conta reaparece

Gateway de modelos, custo por responsável e validação local ajudam a lidar com agentes. Volume de PRs, sozinho, não demonstra produtividade.

·3 min de leitura·2 visualizações

O relato de Uday Kiran Medisetty, engenheiro Distinguished da Uber, descreve uma adoção de agentes apoiada em anos de plataforma interna, observabilidade e ambientes de desenvolvimento.[8] A empresa usa um gateway de modelos independente de fornecedor e do ambiente de execução do agente, com auditoria e rastreamento de gastos por usuário.[8] A parte interessante não é a quantidade de código gerado. É o que precisa existir para absorver esse código.

O que muda para quem desenvolve

O gateway permite alternar provedores e modelos hospedados internamente, com uma camada de segurança para examinar requisições e respostas.[8] O wrapper AIFX preserva configurações, skills e plugins ao trocar entre Claude Code, Codex e OpenCode.[8]

Como análise de arquitetura, isso favorece manter políticas e contexto fora de uma ferramenta específica. Mas também cria uma camada que alguém precisa operar. Para uma equipe pequena, o objetivo não deveria ser reproduzir a plataforma da Uber, e sim escolher quais controles justificam sua manutenção.

O gargalo de validação merece atenção especial. Todos os PRs continuam passando por revisão humana, apoiada por IA e classificação de risco, segundo o relato.[8] As execuções de CI mais que dobraram em doze meses, exigindo uma resposta interna prioritária.[8] Produzir mais mudanças não elimina o trabalho de demonstrar que elas são aceitáveis.

Como aplicar

Comece com três registros por tarefa: responsável, gasto e evidência de conclusão. Defina faixas de consumo e um procedimento de exceção para trabalhos maiores. A Uber combina faixas de gasto com aprovação gerencial, em vez de apresentar um limite único para qualquer atividade.[8]

Depois, leve verificações baratas para o ambiente do agente. Lint e regras de build antes do PR foram uma das medidas descritas para reduzir desperdício na infraestrutura central.[8] Como experimento local, acompanhe por um período quantas falhas simples chegam ao CI antes e depois dessa mudança. Mantenha o mesmo critério de qualidade para não melhorar o indicador apenas deixando de executar verificações.

Classifique as entregas por finalidade e registre o esforço de revisão. A Uber distingue funcionalidades, correções, manutenção, testes e documentação para não confundir volume com resultado.[8] Em escala menor, essa separação já permite perguntar se a automação está resolvendo problemas ou apenas movimentando a fila.

Cuidados e limites

A redução de aproximadamente 50% nos custos de tokens é um resultado relatado pela empresa sobre meses recentes, já abordado em publicação anterior, não um experimento controlado desse episódio.[8] Não use esse número como previsão de economia para outra organização.

Centralizar acesso pode simplificar políticas, mas acrescenta uma dependência operacional. Distribuir tudo entre ferramentas reduz essa centralização, porém exige coerência por outros meios. O caminho útil é tornar gasto, qualidade e responsabilidade observáveis. Contar PRs é fácil; demonstrar valor por mudança aceita dá mais trabalho e informa muito mais.

Fonte

[8] Fonte: The Pragmatic Engineer

Continue lendo