Eis um joguinho divertido. Você é CTO. Você deu aos seus engenheiros um cartão de crédito sem extrato e agora a operadora do cartão gostaria de ter uma palavrinha. O CTO da Uber colocou um número na palavrinha no mês passado: o orçamento anual inteiro de codificação com IA, esgotado em abril. O interessante não foi o tamanho da conta. Foi a segunda frase — "voltei à prancheta porque o orçamento que eu achei que precisaria já foi pelos ares." O que, traduzido do executivês polido, significa: pagamos a fatura, sabemos exatamente quanto custou, não conseguimos dizer o que ela comprou e gostaríamos de parar de fazer isso.

Olha, a maneira moderna de comprar software é dar aos engenheiros uma coisa que cobra por token, dizer para usarem com critério, e então esperar. A The Information reportou no mês passado que o CTO da Uber, Praveen Neppalli Naga, fez a espera e descobriu que seu orçamento anual de codificação com IA para 2026 já havia se esgotado em abril, o que, em termos de cronograma, é ambicioso. O uso do Claude Code na empresa quase dobrou em um trimestre; em março, 84% dos engenheiros da Uber eram classificados como usuários de codificação agêntica, e bom para eles. O gasto por engenheiro ficava entre cerca de $500 e $2,000 por mês, com o próprio CTO queimando $1,200 numa demo pessoal de duas horas — o que é mais ou menos a tarifa horária de um associado júnior em um escritório de advocacia de Manhattan, o qual, no mínimo, entregaria uma planilha de horas. A linha geral de P&D da Uber foi de $3,4 bilhões em 2025, então não é que faltasse espaço. É que o modelo foi atrás de mais espaço do que tinham, encontrou um pouco e cobrou por ele.

O post que você esperaria de uma empresa de segurança e isolamento a esta altura é "use um sandbox." Não é este o post. Já escrevemos esse, porque é claro que escrevemos. Esta é a outra metade do mesmo problema, a parte em que a fatura chega, você consegue lê-la, e não consegue responder à única pergunta que alguém quer fazer, que é: ok, mas para quê.

A fatura está ótima. A fatura é o problema.

Cobrança por assento era muito fácil de pensar, e você deveria valorizar a era do assento agora que ela acabou. Você comprou 200 assentos do GitHub Copilot a $19 cada, recebeu uma linha de $3,800 por mês, e quando alguém perguntava "o que ganhamos com isso," a resposta era um dar de ombros no formato da indústria — "completações de tab, provavelmente" — e todo mundo voltava para suas reuniões. O legal de um dar de ombros é que ele escala. Um dar de ombros de $3,800 está ótimo. Um dar de ombros de $1,8 milhão começa a atrair atenção da parte do prédio que tem dever fiduciário.

Ferramentas agênticas precificadas por token têm outra forma, e você precisa pensar nelas com o rosto inteiro. Dois engenheiros do mesmo time, trabalhando no mesmo tipo de feature, podem diferir em gasto por um fator de quarenta. (Quarenta.) Um deles abre uma sessão nova, pede uma coisa, recebe a coisa, fecha a sessão — $50, pronto, vai para casa e faz macarrão. O outro deixa um bando paralelo de agentes martelar um refactor por seis horas, tenta de novo quando o build quebra, tenta de novo porque um modelo diferente achou que a primeira tentativa estava errada, tenta uma terceira vez porque a esta altura é pessoal. Os dois engenheiros entregaram código. Um entregou com $50 de tempo de modelo. O outro entregou com $2,000. A fatura não diz qual é qual. A IDE não diz qual é qual. Finanças recebe um único número agregado, engenharia recebe uma thread no Slack dizendo "Claude was amazing today," e nenhum dos dois, com todo o respeito, é uma medição.

O que torna isso difícil não é o preço. É que nada do gasto está ligado a algo que você possa auditar um trimestre depois. E aí um PR pousou. O PR tem um diff. O diff tem commits. Os commits têm autores. O autor é um humano. O humano usou um agente em algum momento — talvez. Usou qual agente? Qual sessão? Qual prompt? Por quanto tempo? Fazendo o quê? A trilha se perde em algum lugar lá pelo scrollback do terminal, que foi fechado, porque ninguém rola para cima. Há um nome para isso em finanças, e é "shrinkage", embora em software ainda não tenhamos nos dado ao trabalho de nomear.

A caixa do meio é tudo o que você comprou. É também a única coisa que você não consegue ver.

Como é maio de 2026 na maioria das áreas de engenharia: dólares saem da empresa por um cano grosso, trabalho sai do outro lado por vários canos finos, e o pedaço do meio — aquilo pelo qual você pagou de fato — é neblina. O CFO consegue ver a conta. O gerente de engenharia consegue ver os PRs. O que liga os dois é uma janela de terminal fechada e uma vibe.

De qualquer modo, o formato deste problema é mais antigo que a codificação agêntica, e se você já está nesta indústria há tempo suficiente para estar cansado, vai reconhecer na hora. Gasto em nuvem teve o mesmo arco. Cinco anos de "a conta da AWS é gigante e ninguém sabe por quê," aí uma geração de ferramentas de FinOps começou a ligar dólares a times, serviços e requisições individuais, e agora a conta da AWS é gigante e as pessoas sabem por quê, o que, modesto como soa, é o jogo inteiro. A solução não foi usar menos AWS. Foi tornar o gasto legível.

Codificação agêntica está hoje na nuvem pré-FinOps. O gasto é real, as ferramentas são boas, a produtividade está genuinamente lá — nada disso está em disputa. O que falta é o tecido conjuntivo entre "este engenheiro, neste repo, nesta sessão" e "estes tokens, estes comandos, estes arquivos, este PR." Até essa frase existir, cada dólar na fatura é pago na fé, e a conversa com o seu CFO é uma dessas conversas.

O que "visibilidade" tem que significar, além do dashboard com o número grande.

Todo mundo diz "observabilidade" e todo mundo balança a cabeça, e quase ninguém quer dizer a mesma coisa com isso. Fornecedores de agentes de codificação vão de bom grado te mostrar um dashboard. O dashboard tem medidores de tokens. Tem percentuais de adoção. Tem um gráfico pronto para slide que sobe para a direita, que é o formato-padrão de gráfico de todo software em 2026. Nada disso é uma resposta. "Seus desenvolvedores consumiram 2,3 bilhões de tokens de entrada nesta semana" não é uma resposta; é uma reformulação da fatura em fonte maior.

O que um CTO realmente precisa, para defender ou aumentar um orçamento, vem em quatro partes.

Adoção que dá para mostrar num slide

Quantos dos seus engenheiros de fato usaram um agente de codificação nesta semana. Por quanto tempo. Em quais projetos, em quais repos. Não licenças de assento emitidas, não portadores de API key, não "pessoas inscritas no programa" — sessões iniciadas, por um humano, em algo que a organização consegue nomear.

Cada arquivo que o agente tocou

Por sessão, por repo, por engenheiro — o conjunto exato de arquivos que um agente de IA criou, modificou ou apagou, com diffs, ligados ao engenheiro que iniciou a sessão e ao modelo que ele usou. A unidade de trabalho é "uma mutação de arquivo," não "um token." Tokens são como o fornecedor te cobra. Arquivos são o que você tem que entregar.

Cada comando, cada origem

Cada comando shell que o agente rodou dentro da sessão, cada arquivo que ele leu, cada ferramenta que ele chamou, cada API que ele acertou. Capturados ao vivo, retidos centralmente, consultáveis por time, por repo, por modelo. "O que o agente instalou ontem" vira uma consulta, em vez de uma escavação arqueológica com uma lanterna e um SRE júnior.

O diálogo completo, arquivado

Prompts, respostas do modelo, tool calls — a transcrição inteira. Em algum lugar estável. Revisável por segurança, amostrável pela liderança de engenharia, exportável para o mesmo arquivo de retenção que você já alimenta para e-mail e chat. A sessão agora é um registro, não a memória de algo que alguém um dia digitou.

Repare no que não está nessa lista. Contagens de tokens não estão na lista. Elas estão na fatura. A graça da lista é colocar a fatura ao lado da coisa que ela comprou, para que um time de finanças possa fazer a divisão, um time de engenharia possa parar de discutir por vibes, e todo mundo possa gastar a reunião na pergunta de verdade.

Como a Bromure faz o encanamento.

A funcionalidade de codificação agêntica da Bromure foi, para ser justo, originalmente construída para a metade de segurança desta conversa. Cada agente de codificação roda dentro de uma VM Linux descartável no seu Mac. A VM tem acesso apenas às pastas de projeto que você montou; ela não tem chaves SSH, nem credenciais AWS, nem token do GitHub jogado no disco. Um broker de credenciais no host troca tokens-stub por tokens reais, mas apenas no fio, apenas para endpoints permitidos. Essa é a história que já contamos, em que um pacote npm envenenado tenta sair andando com seus segredos e acaba batendo numa parede.

A história de observabilidade é o mesmo encanamento, usado por outra razão. O hypervisor fica entre o agente e tudo o que ele toca. O agente não abre um arquivo; a VM abre. O agente não roda um comando shell; a VM roda. O agente não faz uma chamada de API; o proxy no host faz. Cada uma dessas operações é — tem que ser, porque a metade de segurança do trabalho exige isso — um evento nomeado, com timestamp, ID de sessão, identidade do engenheiro e payload. A Bromure já registra tudo isso localmente. Chama-se Session Tracer e já vem com Agentic Coding hoje.

A peça que fecha o ciclo para os CTOs (e CFOs, e CISOs, e a pessoa de procurement que gostaria de saber o que foi adquirido) é o lado nuvem. Quando o cliente Bromure no Mac de um desenvolvedor é matriculado na sua organização, esses traces locais deixam de ser um auxílio local de depuração e passam a ser um registro estruturado, transmitido ao seu servidor enterprise da Bromure. Por engenheiro. Por sessão. Por projeto. Por modelo. Filtrável, exportável, retentível. O texto de produto na página de agentic coding chama isso de "AI usage monitoring" e hoje está rotulado como "em breve," o que, para evitar dúvidas, é em parte por causa deste post.

O mesmo quadro, depois que você coloca um hypervisor no meio. Cada sessão de agente roda dentro de uma VM por desenvolvedor. O hypervisor e o proxy de credenciais já enxergam cada comando shell, cada arquivo, cada requisição de saída — eles têm que enxergar, para fazer a metade de segurança do seu trabalho — e o servidor enterprise é onde esses eventos pousam em uma tabela pela qual você finalmente consegue dividir a fatura. Claude Code continua sendo Claude Code, Cursor continua sendo Cursor, Codex continua sendo Codex; os agentes não mudaram. A caixa do meio, aquela que antes era neblina, agora é um banco de dados.

A razão pela qual os eventos são confiáveis não é um sidecar dentro do agente, e não é um wrapper em volta da API do modelo, sendo que o agente poderia, em princípio, contornar qualquer um dos dois se quisesse. Os eventos são confiáveis porque o agente está rodando dentro de uma VM cujo hypervisor tem que conhecer cada comando e cada arquivo, independentemente de alguém estar pedindo isso ou não. A observabilidade é, em certo sentido, de graça. Você já pagou por ela. A conta dizia "isolamento." A coisa que você recebeu é também um log. E aí você obtém o mesmo registro independentemente de o engenheiro ter usado Claude Code, Cursor em modo CLI, Codex, Aider ou algum agente interno do qual nunca ouvimos falar — porque a unidade de gravação é "coisa que a VM fez," não "coisa que o fornecedor decidiu expor neste trimestre."

Como soa a conversa daqui a um trimestre, em vez disso.

O número da Uber é um número útil para pensar, porque nada nele é um fracasso. 84% de adoção. Código entregue. Um CTO que de fato arregaçou as mangas e usou a coisa, o que, aliás, mais CTOs deveriam fazer, mesmo a $1,200 por demo. O que quebrou foi a conversa um trimestre depois. "Devemos dobrar a aposta? Recuar? Tier dos nossos assentos? Empurrar pessoas para modelos mais baratos em alguns tipos de trabalho?" Nenhuma dessas decisões é tomável a partir de uma conta agregada de tokens. Todas são perfeitamente tomáveis a partir de uma tabela por engenheiro, por sessão, por repo. As decisões não ficaram mais difíceis. A tabela foi removida.

Algumas perguntas que se tornam respondíveis, mais ou menos na ordem em que ouvimos das pessoas que estão tentando defender uma linha do orçamento:

Quais engenheiros estão tirando valor desproporcional, e o que estão fazendo de diferente? Olhe para os engenheiros cuja razão gasto-por-arquivos-alterados está no canto bom da distribuição. Leia alguns dos traces de sessão deles. Parte do que estão fazendo bem é estilo, parte é técnica, parte é só qual modelo eles escolhem. Nada disso é visível sem o registro. ("Como a Alice entrega tanto código com tão pouco dinheiro" é o tipo de pergunta que produz um lunch-and-learn interno útil, mas só se as sessões da Alice não forem um terminal fechado em algum lugar.)
O gasto está concentrado em um time, um repo, um tipo de trabalho? Se 60% da sua conta de IA está vindo de um único serviço legado e o agente está em sua maior parte se debatendo em testes flaky, isso é um achado. E também não é um achado sobre IA.
Quais projetos são produtivos com qual modelo? "Claude é melhor que Cursor" é um tweet. "Claude entregou 3x mais alterações de arquivo por dólar do que Cursor no nosso repo de front-end no mês passado, e o inverso no nosso serviço Go" é uma conversa de procurement.
O que o agente instalou, e onde? Esta é a pergunta do time de segurança, e é a mesma consulta na mesma tabela. Cada npm install, cada pip install, cada apt-get que o agente rodou, por sessão, por repo, filtrável por nome de pacote. No dia em que um pacote envenenado aparecer num registry — o que, gesticula vagamente para a maioria das semanas do calendário — a pergunta "algum dos nossos agentes tocou nisso" é uma cláusula WHERE em vez de um drill de incêndio.

O ponto a tomar cuidado: nenhuma dessas perguntas é respondível de dentro do dashboard do fornecedor do modelo, e elas não podem ser. O fornecedor vê tokens. O fornecedor vê, às vezes, prompts e completions pela duração de uma requisição. O fornecedor não vê o seu repo, suas mutações de arquivo, seus comandos shell, ou qual engenheiro da sua organização digitou qual coisa. O fornecedor não pode. O fornecedor está do lado errado do fio. A camada de visibilidade tem que viver do seu lado — na máquina do desenvolvedor, na VM, no seu servidor enterprise — porque é aí que o trabalho está de fato acontecendo. Medidores de tokens são um cartão-postal vindo do campo.

Ressalvas, claro.

Algumas honestas, porque a pior versão de um post como este é a que promete um relatório de finanças do fim da história e então entrega um dashboard.

O registro da Bromure te diz o que o agente fez. Não te diz se o que o agente fez foi bom. Uma sessão que escreveu 40 arquivos e entregou um PR ainda pode ter entregue 40 arquivos ruins. O registro torna mais fácil encontrá-los, conversar sobre eles e reverter. Por si só, ele não os revisa. Revisão de diff continua sendo com você, com o humano no loop e com o engenheiro sênior muito cansado das 17h.

O registro da Bromure cobre o que o agente faz dentro da VM. Não cobre o que o engenheiro faz na cabeça antes de abrir o agente. A conversa de cinco minutos que um engenheiro tem com o Claude na IDE antes da sessão de fato começar não está nesta fita. É uma lacuna real. Não é uma que fingimos preencher, porque não dá para preenchê-la sem um produto muito mais estranho.

O registro da Bromure fica do seu lado do fio, que é o ponto inteiro — mas isso também significa que o seu lado do fio é onde a política de retenção, os controles de acesso e os contratos de tratamento de dados têm que viver. Prompts incluem código. Código inclui segredos que seus desenvolvedores não deveriam ter colado, mas absolutamente colaram. O registro é tão sensível quanto o trabalho, e você deve tratá-lo assim. O armazenamento é seu; a responsabilidade é sua. ("Há um nome para isso em finanças, e é 'shrinkage,'" só que agora a shrinkage é uma tabela SQL e você pode auditá-la.)

E, finalmente, esta é uma peça de uma história maior. A outra peça é a que já cobrimos — rodar agentes de codificação dentro de uma VM com um broker de credenciais é como você impede o próximo pacote npm envenenado de sair andando com suas chaves SSH. A história de segurança e a história de observabilidade são o mesmo encanamento. Elas só prestam contas em dias diferentes.

Pague a fatura. Mas pague sabendo o que ela comprou.

A frase da Uber — voltei à prancheta porque o orçamento que eu achei que precisaria já foi pelos ares — vai ser a frase de muitos CTOs neste ano. Sempre ia ser. Precificação por token em ferramentas cujo apetite só é limitado pelo quão ambicioso o modelo se sente às 14h vai produzir essa frase em toda empresa que adotar sem instrumentar. Os agentes não são o problema. O encanamento é.

Bromure Agentic Coding, a contragosto, é como o encanamento se parece quando faz o seu trabalho. Cada agente roda na sua própria VM, cada sessão é um registro estruturado, cada registro é transmitido para um lugar que o seu time de finanças e o seu CISO podem consultar, e os agentes que você já ama continuam exatamente como eram. Você ainda vai pagar a fatura. Vai só, finalmente, saber o que ela comprou — o que, da última vez que alguém checou, era o mínimo absoluto que uma operadora de cartão de crédito pede dos seus clientes.