Uber queimou todo o orçamento de IA de 2026 com Claude Code em apenas 4 meses

• A Uber esgotou todo o orçamento de IA de 2026 em apenas quatro meses com a ampliação do uso de Claude Code e Cursor, e um experimento de produtividade acabou levando imediatamente a uma revisão do orçamento
• O CTO da Uber afirmou que o custo mensal de API por engenheiro ficou na faixa de US$ 500 a US$ 2.000, e 95% dos engenheiros estão usando ferramentas de IA todos os meses
• 70% do código com commit na Uber teve origem em IA, e as ferramentas de programação com IA passaram a fazer parte do fluxo central do trabalho de engenharia
• O Claude Code, distribuído para a equipe de engenharia em dezembro de 2025, teve sua capacidade de tarefas em múltiplas etapas confirmada, dobrou de uso até fevereiro de 2026 e, em abril, já havia consumido todo o orçamento anual
• Enquanto o uso do Cursor parou de crescer, o Claude Code se tornou a ferramenta dominante, e a Uber passou a ter de recalcular o custo das ferramentas de programação com IA dentro de seus US$ 3,4 bilhões em gastos anuais de P&D

---

Ampliação da adoção e revisão do orçamento

• A Uber viu o uso de Claude Code e Cursor crescer rapidamente e, mesmo com a disparada dos custos, os engenheiros passaram a ver tanto valor nas duas ferramentas que ficou difícil parar de usá-las
• Em dezembro de 2025, o acesso ao Claude Code foi distribuído para a equipe de engenharia e, após a comprovação de sua capacidade para tarefas em múltiplas etapas, o uso dobrou até fevereiro de 2026
• Em abril de 2026, os custos consumiram todo o orçamento anual de IA, colocando a liderança diante de uma decisão inesperada
• O CTO da Uber afirmou que a empresa voltou o planejamento do orçamento de IA para “back to the drawing board”

Mudanças no uso por ferramenta

• O Cursor era outra ferramenta importante na disputa por adoção, mas o crescimento de uso estagnou
• O Claude Code se tornou a ferramenta dominante no fluxo de trabalho de engenharia
• O que começou como um experimento de produtividade se expandiu rapidamente, consolidando de vez o uso de ferramentas de IA no trabalho interno de engenharia da empresa

O que significa a pressão de custos

• O esgotamento inesperado do orçamento na Uber mostra o quanto as ferramentas de IA são vistas como valiosas para a produtividade em engenharia
• O papel dessas ferramentas cresceu a ponto de restringir o acesso parecer até contraproducente
• À medida que mais desenvolvedores adotam o Claude Code, é possível que outras empresas estejam passando por impactos semelhantes
• Empresas de software passam a enfrentar pressão para controlar custos enquanto mantêm a velocidade de desenvolvimento
• Se ferramentas de produtividade para desenvolvedores foram valiosas o suficiente para que engenheiros consumissem todo o orçamento em quatro meses, a conclusão é que o problema não está nas ferramentas em si, mas no fato de o orçamento ter sido definido cedo demais para prever a curva de adoção

[picopress]

Diversão em torrar tudo

[GN⁺]

Comentários do Hacker News

• Quando dou uma olhada nos gastos da empresa uma vez por mês, fico confuso com como cada vez mais gente consegue gastar $1k por mês em tokens
  Mesmo usando LLM todo dia, com os modelos mais caros e até modo de raciocínio profundo, normalmente o teto fica em $200~$400. Não sou um ludita contra o uso em si; só quero dizer que é difícil entender como alguém queime esse valor por mês de forma responsável. Queria ver alguém que gasta $5k~$10k por mês mostrar como isso vira $50k~$100k de valor. Do ponto de vista da empresa, em vez de justificar $100k por ano em gasto com tokens, me parece melhor contratar um engenheiro júnior que use $100~$200/mês e ainda produza

  • Os casos em que se queima dinheiro assim “de forma responsável” parecem cair em três categorias. Iniciantes, por reutilizarem conversas longas, não criam compressão de contexto nem checkpoints resumidos, e seguem arrastando uma conversa única gigante porque sentem que o agente foi “treinado”
    Intermediários aprendem padrões como “suba 5 subagentes para analisar a solução por ângulos diferentes e resumir”, e é fácil ficarem viciados nisso. Não é um mau hábito por si só, mas sem cuidado estoura bastante os créditos. Já os experientes podem manter 10 árvores de tarefas rodando em paralelo e alternar entre respostas de agentes em multitarefa extrema, o que faz o custo crescer exponencialmente
  • Primeiro, existe a razão óbvia: “se a empresa permite, desperdiçam”. Isso inclui não limpar nem comprimir o contexto com frequência. A janela de contexto de 1M do Opus já existe, e até 200K a qualidade ainda é boa, então cada consulta queima muitos tokens até a pessoa decidir limpar
    Codebases grandes ou problemas complexos também pesam muito. Se você acabou de entrar no time e ainda não conhece várias partes, quando recebe uma tarefa pede para o Claude encontrar o código relevante e entender o fluxo existente antes de tentar mudar algo. Você constrói menos expertise, mas com o Claude faz em 1 dia algo que levaria 5, e se todo mundo fizer isso você não pode ficar para trás. Então escolhe um meio-termo: terminar em 2~3 dias em vez de 1 e tentar olhar um pouco mais o código. Especialmente por causa da IA, a velocidade de mudança no código ficou enorme, então também criamos ferramentas para fazer a LLM explicar pull requests em profundidade. Não é para revisão, é para acompanhar o trabalho do time. Ainda nem pensei tanto em como usar melhor LLM, e se eu já conhecesse bem a codebase provavelmente teria usado muito mais. O gargalo continua sendo testes e review adequados. Em código interno menos importante ou projetos pessoais, parece que eu deixo quase tudo para a IA, e se usar a skill “superpowers” até funções básicas queimam muitos tokens. Normalmente começo em 20~40K tokens e termino em 80~90K, então vários pedidos perto da conclusão acabam enviando quase 80K tokens cada. É desperdício, mas quando quem paga é outro, acontece
  • Já vi Claude Code escolher uma solução absurdamente ineficiente em tokens para um problema. Dividimos um problema complexo de ML/predição entre vários agentes, e cada agente usou, executou e leu notebooks Jupyter
    No começo estava tudo bem, mas um agente despejou centenas de milhares de linhas na saída de uma célula e criou um arquivo ipynb de 500MB; então o Claude tentou ler aquilo várias vezes e consumiu todo o limite de contexto. A solução foi definir uma estrutura de trabalho melhor, com scripts de análise via CLI e uma pasta para salvar resultados da pesquisa, mas eu, como operador, precisei planejar e desenhar isso. Fica difícil ver quem gasta $10k por mês em tokens como algo além de alguém resolvendo problemas de forma preguiçosa com Claude Code, que é um martelo caro. Por exemplo, fazer o Claude ler todos os e-mails todo dia, quando uma solução mais inteligente seria primeiro remover o ruído do HTML do corpo dos e-mails
  • Depende muito do repositório em que você está trabalhando. Se ele for muito grande e, especialmente, exigir referência a frameworks customizados e documentação de API com muitas ferramentas, você precisa de uma janela de contexto grande e os tokens acabam bem mais rápido
    Em contrapartida, se for pequeno ou usar frameworks comuns que o modelo já conhece, dá para fazer muita coisa com uma janela de contexto menor e o uso de tokens cai bastante
  • Pelo lado de cota, também não consigo entender. Tenho o plano de 200 euros do ChatGPT, então provavelmente é a cota mais alta, mas mesmo passando o dia todo praticamente só com programação por agente, usando o modelo mais caro, maior raciocínio e modo rápido, eu não chego perto do limite
    Desde que comecei a usar agentes de código, a única vez que cheguei perto do teto foi quando fazia desenvolvimento multiplataforma nas mesmas condições em 3 computadores ao mesmo tempo, e ainda assim só quase encostei no limite semanal. Normalmente eu caio até uns 20% da cota, mas quase nunca abaixo disso. Mesmo brincando e disparando muitos prompts e consultas, eu não sei como gastar mais

• Eu sei que estou respondendo para uma IA agora, mas a frase “descobrir se a empresa consegue sustentar esse nível de produtividade em escala” soa estranha. Se isso fosse realmente produtivo, a receita aumentaria, e a questão de ser sustentável nem existiria

  • Exato. Produtividade, por definição, produz alguma coisa, idealmente algo valioso. O que precisa ser visto é se o custo adicional com chatbots gera valor suficiente. Fica a dúvida se a Uber ficou dramaticamente mais eficiente e eficaz por causa desse enorme estouro de orçamento, ou se só deu às pessoas uma forma brilhante e cara de fazer a mesma coisa
  • A receita aumentou. Nos resultados recentes da Meta, mesmo nesta situação econômica, a receita subiu 33%. A questão não é sustentabilidade, e existe um motivo para empresas como a Meta não se importarem se um engenheiro gasta $1k por dia em tokens. Perto do que cada funcionário gera, isso não é tanto dinheiro assim
  • Nem toda mudança feita por desenvolvedores aumenta receita, e mesmo as que aumentam geralmente têm defasagem temporal
  • Na melhor leitura possível do argumento do outro lado, o contraexemplo seria o caso em que os concorrentes também usam as mesmas ferramentas e obtêm o mesmo ganho de produtividade
  • Se usada direito, isso é realmente extremamente produtivo. A ponto de eu ficar preocupado com o quão inteligentes esses modelos semelhantes vão ficar no próximo ano

• “95% dos engenheiros da Uber agora usam ferramentas de IA todo mês, e 70% do código commitado vem da IA” era algo previsível. Quando o uso de ferramentas de IA entra na avaliação de desempenho, é isso que acontece

  • É impressionante como se subestima a facilidade com que isso pode ser manipulado quando não desenvolvedores impõem KPIs a desenvolvedores. Vale tanto para IA quanto para contar pull requests ou linhas de código
  • No momento em que o KPI deixa de ser “o que você lançou” e passa a ser “quanto você usou IA”, o estouro de orçamento vira consequência natural. As pessoas vão tentar bater o número
  • Se gerentes e vice-presidentes dizem “se você não usar IA, não pode trabalhar aqui”, claro que as pessoas vão usar
  • Não entendo muito bem essa crítica. Não era justamente para isso que as pessoas eram pagas: fazer o que a empresa quer e o que a empresa considera produtivo? E também fico em dúvida se você acha que todo código gerado por IA é inútil

• Não entendo a parte de “descobrir se a empresa consegue sustentar esse nível de produtividade em escala”. O orçamento foi gasto e há 4 meses de dados; o ponto central é quais resultados há para mostrar
  Não sou hater de IA nem ludita, e uso o plano Max de $200. Mas a Uber liberou a ferramenta, incentivou todo mundo a usar, funcionou bem, e agora está confusa com o que aconteceu? Julgar que a produtividade da IA não compensa o custo é outra discussão. Dá até a impressão de que talvez eles tenham ficado sem saber o que construir em seguida

  • Os planos pessoais Max e Teams são um preço incrivelmente baixo comparado ao custo por uso da API no Enterprise. Então talvez eles realmente precisassem dos recursos de Enterprise. Senão, poderiam simplesmente ter mandado os usuários reembolsarem uma assinatura Max de $200. Mas empresa age como empresa
  • É possível que ainda não haja nada visível agora. Mudanças grandes visíveis para usuários externos demoram muito mais para serem amplamente implantadas. Internamente, várias funcionalidades provavelmente avançaram mais rápido
    Na Salesforce, eu vi mudanças que faziam coisas que antes levavam semanas parecerem levar dias. Isso não vira dinheiro imediatamente, mas aumenta o potencial de gerar dinheiro
  • Também vale perguntar o que a Uber ainda tem para construir. Ela já tem uma plataforma de corrida e ela funciona. Também expandiu para entrega de comida, mercado e “qualquer coisa que caiba num carro”. Não sei mais o que resta no domínio de alguém dirigindo um carro
  • Os mecanismos de controle de gastos existem, então não entendo por que não colocaram um teto. Também poderiam exigir que os engenheiros justificassem esse gasto
    Era preciso perguntar por que tantos tokens eram necessários e o que estava sendo obtido em troca. Se isso fosse AWS, todo mundo estaria apontando o dedo e perguntando “vocês nem olharam o gasto mensal?”
  • Parece que a discussão sobre IA chegou ao ponto em que, para qualquer crítica não ser tratada como heresia, a pessoa precisa começar dizendo “eu também sou membro do culto, não sou descrente”

• É interessante como, quando sai um texto desses, de repente muita gente passa a achar que medir produtividade de desenvolvimento é simples. É verdade que produtividade vira receita ou redução de custos, e receita pode ser medida, mas não é tão simples assim
  Você gasta dinheiro hoje para criar funcionalidades que vão gerar receita no futuro, então mesmo que o custo exploda hoje, ainda não existe receita para medir. Se você terminou uma funcionalidade hoje com IA, isso não permite dizer imediatamente se a IA foi produtiva ou improdutiva; é preciso estimar quanto teria sido feito sem IA e qual teria sido a receita nesse caso. Negócios muitas vezes são uma corrida da Rainha Vermelha: se você não melhora, perde receita para concorrentes. É bem possível que o uso de IA tenha misturado trabalho importante com “já que agora é fácil, vamos testar qualquer coisa”, e para medir ganho real de produtividade você precisa aprender a manter o primeiro e evitar o segundo. Não é uma defesa nem um ataque à IA; é só dizer para não soltar preguiçosamente que “se for produtivo, vai dar para medir”

  • Acho que o consenso principal é justamente que medir produtividade de desenvolvedores é muito difícil. Sempre que você tenta medir, a métrica vira o objetivo, e então, mesmo que originalmente fosse uma boa medição, ela perde o sentido
    Não sei de onde surgiu a ideia de que é fácil medir a produtividade de pessoas que não são operários de fábrica
  • Não me parece que novas funcionalidades ou software melhor vão aumentar muito a receita/lucro da Uber
  • A escolha não é só entre produtividade zero e alguma produtividade; pode ser produtividade negativa. Pela minha experiência usando Claude Code, suspeito disso porque despejar tantos tokens numa organização pode não apenas ser improdutivo, mas ativamente prejudicial
  • Mudanças pequenas de produtividade são difíceis de medir, mas grandes saltos teriam aparecido claramente. Se a IA está impactando produtividade, no máximo parece ser algo pequeno
  • Se fosse 10x de produtividade, isso teria sido mensurável ao menos indiretamente; na verdade seria impossível não medir. As alegações iniciais eram claramente falsas, e a pergunta real de pesquisa é se é maior que 1,0x
    Concordo que isso é muito difícil de medir. Mas considerando esse custo, a empresa precisa conseguir responder, e o multiplicador também tem de justificar a despesa

• Segundo [1], a organização de engenharia da Uber tem cerca de 5.500 pessoas. Usando o ponto médio do intervalo de gastos, $1.250, o gasto com IA em engenharia dá algo em torno de $6,8M, com intervalo de $2,75M~$12M. O texto diz que o gasto com P&D é de $3,4B
  O gasto com IA não é uma fatia grande do gasto de P&D. Em 4 meses dá 0,3%; anualizado, cerca de 1%. Se isso não estava planejado, não é troco no orçamento, mas no contexto também não é algo tão grande. A pergunta real é o que foi obtido com esse valor. O texto afirma que 70% dos commits de código são gerados por IA, então imagino que tenham passado por review e testes. O importante é saber se o número de funcionalidades aumentou, se houve menos problemas de qualidade ou outros benefícios. Infelizmente, o texto não fala de resultados além do aumento de gastos. Talvez 4 meses ainda seja cedo demais para avaliar benefícios. Por outro lado, no mundo ágil talvez não seja. [1] https://www.unifygtm.com/insights-headcount/uber

  • A fonte real https://www.theinformation.com/newsletters/applied-ai/uber-c... diz: “cerca de 11% das atualizações reais de código em produção nos sistemas de backend estão sendo escritas por agentes de IA, principalmente construídos com Claude Code, contra menos de 1% três meses antes”
    E também diz que “a empresa não divulgou números exatos do orçamento de software nem dos gastos com ferramentas de codificação por IA”
  • Tudo nesse texto parece simplesmente falso. Os números não fecham, não batem com o que foi reportado, e parece só ficção

• Como alguém tocando um negócio bootstrap, muitas vezes invejo engenheiros de grandes empresas, mas também me preocupo com incentivos quebrados
  Se eu fosse engenheiro da Uber, não haveria motivo para não colocar algo como gpt 5.5 pro @ very high thinking + fast mode no prompt até para pequenas mudanças. Não há incentivo para não usar o modelo mais poderoso e, portanto, mais caro. Num teste de conversão de imagem para HTML, experimentei um prompt assim e um único prompt custou $40. Se a pessoa estivesse pagando do próprio bolso, quase certamente nunca usaria essa configuração; mas em big tech, quando outra pessoa paga a conta, você provavelmente roda isso com frequência. A saída realmente foi melhor. Engenheiros são avaliados pelo que entregam, não pelo custo do processo. Há maneiras mais baratas de fazer, mas o engenheiro não tem incentivo para isso

  • Engenheiros de software são caros. O salário mediano é $133k, e isso sem contar plano de saúde, imposto sobre folha etc. Se $40 em créditos de LLM economizarem 1 hora de tempo de desenvolvimento, sai $26,50 mais barato do que não usar
    Ainda não estou convencido de que isso realmente aconteça na prática, mas teoricamente é assim. Tentar reduzir o custo com LLM também é uma faca de dois gumes. O valor economizado pelo desenvolvedor com LLM teria de ser maior que o custo de empregar essa pessoa. Se você passar um dia inteiro para economizar $1 por chamada, vai levar quase 2 anos só para recuperar o custo salarial. E a LLM muda rápido demais para ter confiança de que essa solução não vai quebrar antes de 2 anos. Daqui a 2 anos, nem o provedor de ponta sabe se ainda existirá chamada de ferramenta ou modo de raciocínio
  • Talvez a empresa primeiro queira ver o quão rápido consegue escalar o trabalho e depois reduzir por eficiência
  • Imagem para HTML é uma tarefa bem complexa. Na prática, é trabalho de desenvolvedor frontend, e $40 não compram nem 1 hora deles

• Quanto mais comum fica executivos acharem que podem substituir engenharia de software por agentes, mais eu me pergunto se as decisões não estão sendo tomadas com base numa visão irrealista do engenheiro de software médio
  Por um lado, existe o fator “garbage in, garbage out”. Um CTO brilhante pode ficar muito empolgado com o que agentes conseguem fazer e achar, por engano, que todos os engenheiros conseguem fazer o mesmo. Na prática, o engenheiro médio da organização talvez nem tenha a criatividade para imaginar onde pode eliminar trabalho. Então, se você tornar o uso de agentes obrigatório, a produtividade pode não subir e só o custo de IA aumentar. Por outro lado, usar IA deixa dois abismos ainda mais claros: quem vai dizer ao agente o que fazer, e como lidar com o ciclo de QA/review. Em muitas organizações, o pessoal de produto não é tecnicamente forte o suficiente para criar as especificações ou planos detalhados que a LLM usaria, e os desenvolvedores “engrenagem” não estão numa posição de criar especificações, só querem implementar. Se você espera que o desenvolvedor que usa agentes também faça a implementação, pode acabar criando mais gente ociosa esperando trabalho chegar. Sou a favor de adoção seletiva de LLM para elevar velocidade e qualidade dos desenvolvedores atuais, mas a ideia de “vamos reorganizar a empresa em torno disso” me parece bem arriscada, especialmente para empresas pequenas e médias

  • Mais do que isso, IA é um amplificador de força, e não se importa se essa força é positiva ou negativa. Se alguém com maus princípios de engenharia de software usar IA, consegue criar uma bagunça completa em pouquíssimo tempo
  • Sobre o ponto 2, nossa empresa está pressionando bastante para que desenvolvedores tenham mentalidade de produto e sejam menos apenas engrenagens
    Sou enviesado porque eu mesmo tenho mais mentalidade de produto do que outros desenvolvedores, mas acho que esse tipo de pessoa está numa posição melhor para ser mais produtiva com agentes. Conhecem tecnologia o suficiente para implementar com agentes, e conhecem produto o suficiente para saber o que deve ser implementado. Espero que outras empresas sigam por aí
  • No fim das contas, isso equivale a falar de grandes cortes de pessoal

• Não faço ideia do que a Uber ainda está desenvolvendo. Ela tem o app e o backend de despacho de carros, e os dois funcionam de forma razoável. Não entendo por que gastaria tanto
  Direção autônoma eles já abandonaram, então não é isso

  • Essa é uma pergunta realmente subestimada. Mostra bem o que empresas de tecnologia modernas afinal fazem com todos esses recursos. O Elon reduziu a maior parte do time do Twitter, e mesmo depois dos tropeços horríveis do começo, não ficou quase funcionando bem com 80% menos gente?
  • Seria bom se “os dois funcionam de forma razoável”, mas não é o caso. A otimização do algoritmo de matching piorou tanto a experiência do usuário que agora uso Lyft regularmente
  • Esse tipo de comentário “X é só Y, então por que é tão complicado?” é um dos mais batidos do HN. Escrever isso em todo post sobre big tech de que você não gosta é preguiçoso e cansativo de ler

• Com tokens de API, especialmente usando contexto de 1M, é muito fácil torrar centenas de dólares numa única sessão se você não limpar o contexto antigo com cuidado
  Ao mesmo tempo, assinaturas permitem esse mesmo nível de uso por algumas centenas de dólares por mês. Parece que a Anthropic ou cobra absurdamente caro de usuários de API, ou subsidia muito a assinatura, ou os dois

  • https://www.forbes.com/sites/annatong/2026/03/05/cursor-goes...
    “A Cursor estimou no ano passado que uma assinatura mensal de $200 do Claude Code permitia usar até $2.000 em computação, o que sugeria um subsídio significativo da Anthropic. Agora, esse subsídio parece ainda mais agressivo: um plano de $200 pode consumir cerca de $5.000 em computação”
  • A Anthropic tem um modelo de negócios bem “interessante”. Enquanto você tem 150 funcionários ou menos, cobram preço de assinatura; no momento em que vira 151, da noite para o dia todos os funcionários passam a pagar preço de API e a conta total multiplica imediatamente
    É o esquema de viciar você em tokens baratos e depois capturar quando ganhar escala. A Uber provavelmente ganha desconto sobre o preço cheio, mas certamente não paga perto do preço de assinatura para equipes com 150 ou menos pessoas
  • Eu olhei os preços e não consegui justificar o salto de Team para Enterprise. Quando você vai para Enterprise, a assinatura mensal desaparece por completo e você perde a capacidade de controlar custo
    Dá para colocar limite por usuário, mas sem um teto mensal acumulado você acaba tendo de dizer ao time: “sem IA pelo resto deste mês”. Do jeito que está estruturado hoje, eu vejo isso como um acordo bem arriscado