O cofundador da Databricks, Patrick Wendell, explica por que os custos de codificação com IA crescem exponencialmente e como líderes de engenharia podem mudar essa curva sem desacelerar suas equipes
por Catherine Brown
Nesta conversa, Catherine Brown conversa com Patrick sobre o que aconteceu quando a Databricks apostou tudo em agentes de codificação por IA: como os custos inicialmente dispararam com o aumento do uso, o que realmente reduziu os custos unitários em até 90% e por que toda organização de engenharia precisa de uma camada de controle entre seus desenvolvedores e seus modelos. Essa camada de controle começou como uma solução interna para a própria conta de IA da Databricks e se tornou a inspiração para o Unity Gateway.
Catherine: Você lidera os produtos de IA da Databricks e também tem sido o principal defensor interno da adoção de IA. Por que isso se tornou uma prioridade tão pessoal para você?
Patrick: Porque a capacidade de entrega da engenharia é o principal gargalo no nosso negócio. Toda empresa precisa que sua equipe de engenharia avance mais rápido e, se você puder oferecer a ela algo que melhore significativamente sua produtividade, isso vale muito. Os primeiros produtos de chat eram razoavelmente úteis. Mas o ROI realmente mudou há cerca de um ano, quando surgiram os primeiros modelos de código realmente bons.
Catherine: Como você sabe se está obtendo ganhos de produtividade com as ferramentas de IA?
Patrick: Acompanhamos uma série de métricas de entrega: pull requests, recursos lançados e linhas de código. Nenhuma delas é perfeita isoladamente. Penso na R&D como uma grande máquina. Você insere recursos, obtém funcionalidades e código do outro lado e pode medir o quanto a mais está saindo. No agregado, estamos perto de dobrar a entrega com a mesma equipe. As equipes que se reestruturaram em torno da IA estão avançando muito mais rápido do que isso.
Catherine: Quando a Databricks lançou as ferramentas de codificação por IA pela primeira vez, o que vocês fizeram de errado?
Patrick: É até engraçado, porque no começo tínhamos o problema oposto. Ninguém queria testar a novidade. Eu ficava insistindo com as pessoas. Então fizemos o que todo mundo fez: removemos todas as barreiras — o modelo mais caro, quantos tokens você quisesse. Acho que a intenção era boa. Você tenta ajudar as pessoas a superar a resistência inicial.
Aí as pessoas realmente começaram a usar, e vimos uma curva exponencial de custos. Hoje, todas essas ferramentas têm preço baseado no consumo, não por usuário, então um único usuário pode, em tese, gastar uma quantia ilimitada de dinheiro. Ele pode executar um pequeno loop no modelo mais caro e sair para almoçar. Talvez esse loop esteja fazendo algo muito valioso, mas talvez esteja apenas queimando tokens. Se seus custos crescerem exponencialmente e sua receita não, em algum momento você terá um problema. Chegamos ao ponto em que os custos ameaçavam anular os ganhos de eficiência, que eram o único motivo pelo qual fizemos isso.
Foi quando me envolvi pessoalmente. Troquei experiências com líderes de outras empresas de tecnologia que eu sabia estarem adotando IA em escala (Coinbase, Uber, Stripe e outras). Coletivamente, muitos de nós estávamos aplicando técnicas semelhantes. Hoje, na Databricks, nosso gasto de tokens por pessoa está praticamente estável, mesmo com o uso total e o valor gerado continuando a crescer.
Catherine: O primeiro instinto da maioria das empresas é definir um limite rígido de gastos. Vocês tentaram isso. O que aconteceu?
Patrick: É o passo mais óbvio, e você realmente precisa do mecanismo. Mas um bloqueio total é uma péssima experiência. Você interrompe a pessoa no meio de uma tarefa, e ela perde o ritmo de trabalho e, talvez, horas de dedicação. E as pessoas que atingem o limite costumam ser seus melhores usuários. Se você as bloquear, algumas vão usar uma conta pessoal, e aí você perde totalmente a visibilidade.
Por isso, passamos a aplicar restrições graduais, e o Unity Gateway cuida de tudo. Primeiro, um aviso, depois uma aprovação e, em seguida, mudamos você para um modelo mais barato para que possa continuar trabalhando. Bloquear alguém de fato é o último recurso. Também enviamos a todos um relatório periódico com o detalhamento de seus próprios gastos e sugestões de onde economizar. Só isso já representa cerca de 10% de economia. Uma empresa que conheço exibe o modelo e o custo diretamente em cada pull request. Ou seja, é praticamente uma exposição pública se você usar um modelo caro para algo simples. Adoro isso.
Catherine: Você escreveu sobre quatro alavancas para reduzir esses custos. Qual delas teve o maior impacto?
Patrick: A nossa favorita é meio sem graça: modelos melhores e mais baratos continuam surgindo, e você simplesmente redireciona o tráfego para eles. Há provavelmente uns cinco modelos lançados por semana entre fornecedores proprietários e open source. Nem todos trazem um avanço em custo, mas talvez um a cada uma ou duas semanas traga. É uma tendência constante. Você obtém o mesmo resultado por menos dinheiro sem que ninguém precise mudar nada. Sem roteamento sofisticado, sem nada.
Para você ter uma ideia de quão rápido isso evolui: um dos modelos baratos recentes atinge praticamente o mesmo desempenho que um modelo de fronteira alcançava há cerca de nove meses, custando cerca de 1% do preço por tarefa. É uma queda de 100 vezes em menos de um ano. Isso ainda é preliminar, mas é a direção.
O segredo é que você precisa realmente fazer a transição. Se um novo modelo for lançado e ninguém na sua empresa o utilizar, é como uma árvore caindo na floresta sem ninguém por perto. Por isso, nos tornamos bons em avaliar novos modelos rapidamente e migrar as cargas de trabalho quando um deles se mostra bom o suficiente. Como tudo passa pelo Unity Gateway, podemos fazer essa mudança em um único lugar, sem que os desenvolvedores precisem alterar nada. Essa foi a ação de maior impacto que realizamos, garantindo 50% ou mais de economia por si só. Adicione roteamento, visibilidade de gastos e eliminação do excesso de tokens e, em alguns casos, nossos custos unitários caíram até 90%.
Catherine: Sua equipe realiza benchmarks de agentes de código na própria base de código da Databricks, que tem milhões de linhas. Por que não confiar apenas nos benchmarks públicos?
Patrick: Os benchmarks públicos não dizem muito sobre o seu próprio código. As tarefas vazam para os dados de treinamento e não se parecem com a base de código de uma grande empresa. Então criamos os nossos próprios benchmarks a partir de pull requests reais no nosso repositório, e avaliamos executando os testes de fato. Não usamos um LLM como juiz, porque isso tende a premiar o que soa correto em vez do que está correto.
Alguns resultados surpreenderam. Um modelo open source, o GLM 5.2, empatou em qualidade com o Opus 4.8 custando cerca de um terço a menos por tarefa. Um modelo que era 1,7x mais barato por token custou mais por tarefa, porque consumiu mais tokens. E o harness — a ferramenta de codificação ao redor do modelo — teve quase tanta importância quanto o próprio modelo. Mesmo modelo, harness diferente: mais de 2x de diferença no custo. Só de ajustar nosso harness e as configurações de cache, economizamos quase 50%.
Catherine: A diferença entre os modelos mais baratos e os mais caros pode chegar a 100x. Como os líderes de engenharia devem encarar essa variação?
Patrick: Pense como se fossem carros. Existe a Lamborghini, o Honda e a bicicleta. Você não precisa da Lamborghini para qualquer trajeto, e a maior parte do trabalho de código não precisa do maior modelo.
O Astra foi um bom exemplo. Nós o disponibilizamos para todos os engenheiros, cerca de 3.500 pessoas, e, até onde sabemos, fomos a primeira empresa a compartilhar publicamente um lançamento como esse. Ele era claramente melhor para tarefas difíceis, como design de sistemas. No entanto, os gastos subiram cerca de 60%, e ele não estava ajudando de forma evidente nas tarefas do dia a dia, que os modelos existentes já resolviam bem. Muito disso foi desperdício, com pessoas usando o Astra para coisas em que deveriam ter usado outro modelo. Por isso, definimos um orçamento próprio para ele no Unity Gateway. Use-o para problemas difíceis.
A longo prazo, não sei para onde isso vai. Os modelos baratos continuam assumindo cada vez mais o trabalho de rotina, mas as pessoas também estão colocando problemas cada vez mais difíceis para a IA resolver. O objetivo é bem esse. Você quer ser capaz de direcionar para qualquer um dos caminhos.
Catherine: Você defendeu que o custo da IA é um problema de infraestrutura, não de compras. Por que orçamentos e políticas não conseguem resolvê-lo?
Patrick: Os orçamentos ajudam, mas um orçamento não pode decidir qual modelo deve processar uma determinada solicitação. Isso é roteamento. Renomear um componente vai para um modelo barato; um problema difícil e abrangente vai para um modelo avançado. Nosso Smart Router reduz o custo médio por tarefa em mais de 30% com uma qualidade similar à do modelo mais caro. Ele também está nos permitindo parar de pedir aos usuários para decidirem quando usar os modelos mais caros… isso simplesmente acontece de forma automática.
Para fazer qualquer uma dessas coisas, você precisa de uma camada entre seus desenvolvedores e os modelos. Criamos a nossa porque precisávamos. Todo o tráfego das nossas ferramentas de código passa por um único gateway, seja Claude Code, Codex, Cursor ou Omnigent, nosso meta-harness. Foi isso que nos permitiu ver para onde o dinheiro realmente estava indo. Depois, percebemos que todos os clientes tinham o mesmo problema, então transformamos a solução no produto Unity Gateway. Milhares de clientes o utilizam agora.
Catherine: O roteamento acabará sendo tão competitivo quanto os próprios modelos?
Patrick: Essa é a nossa visão. Conforme as margens dos modelos ficam menores, descobrir qual modelo usar para cada caso é algo bem interessante. Os modelos de roteamento precisam ser pequenos e rápidos. Também é difícil fazer isso bem-feito. Há muitos problemas de pesquisa em aberto no lado prático do uso desses modelos, e acredito que há uma propriedade intelectual real em acertar nisso.
Catherine: Se você pudesse dar um conselho a um CTO que está lidando com uma conta de IA cada vez maior, qual seria?
Patrick: Descubra para onde ela está indo. A maioria das empresas não sabe dizer quanto está gastando em IA por equipe ou por modelo, muito menos se isso está valendo a pena. Coloque um gateway na frente dos seus modelos para que todo o tráfego passe por um só lugar e você possa visualizá-lo. Todo o resto fica mais fácil depois disso. E não diminua o ritmo. Os ganhos de produtividade são reais. Mas isso se acumula e, se você esperar, a conta vai ser muito maior do que você pensa.
A mensagem de Patrick para os líderes de engenharia é que você não precisa escolher entre produtividade em IA e controle de custos. As empresas que estão se saindo bem mantêm amplo acesso aos melhores modelos, testam novos modelos em seu próprio código, mudam para opções mais baratas assim que forem boas o suficiente e oferecem visibilidade aos desenvolvedores em vez de barreiras. Por trás de tudo isso há uma camada de controle, um gateway, que torna os gastos com IA algo visível e gerenciável. Na Databricks, essa camada se tornou o Unity Gateway.
Para saber mais sobre como a Databricks gerencia seus próprios custos de codificação com IA, leia o blog do Patrick "Managing AI Coding Costs at Scale" e experimente o Databricks Unity Gateway.
(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original
Assine nosso blog e receba os posts mais recentes diretamente na sua caixa de entrada.