[TL;DR Diário] Vou dizer em voz alta o que todos pensam: quando a conta mensal de IA de um engenheiro começa a soar como uma rodada Series A, isso deixa de ser apenas uma história de ferramentas e passa a parecer um experimento econômico. Então, o que estamos realmente vendo aqui—o próximo sistema operacional da engenharia de software, ou uma máquina muito cara para produzir lixo de IA em escala industrial? Provavelmente ambos. 🤖💸 🔥 A configuração: um flex de trilhão de tokens transformado em debate público sobre custos 📌 Os números principais são absurdos de propósito • O fundador do OpenClaw, Peter Steinberger, estimou que sua equipe gastou cerca de US$ 10 milhões em custos de tokens em um único mês para trabalho de IA, e imediatamente acrescentou: nem todo esse gasto foi útil. • Outro exemplo viral veio do perfil do Cursor de Lauren Tan, que mostrou cerca de 1,5 trilhão de tokens usados em 30 dias. • Usando uma referência aproximada de US$ 8 por 1 milhão de tokens, Peter Piekarczyk estimou isso em cerca de US$ 384 mil por dia, cerca de US$ 11 milhões por mês, ou US$ 132 milhões anualizados. • Mesmo com um desconto empresarial de 90%, a estimativa ainda fica em torno de US$ 1,1 milhão por mês, ou cerca de US$ 13 milhões por ano. 📌 Por que as pessoas se assustaram: o uso está muito além do comportamento normal de desenvolvedores • Dados da Jellyfish com 12 mil desenvolvedores sugerem que o usuário mediano consome cerca de 51 milhões de tokens por mês. • O percentil 90 é de cerca de 380 milhões de tokens por mês. • Isso torna o uso de 1,5 trilhão de tokens de Lauren cerca de 29.000 vezes a mediana, enquanto os 603 bilhões de tokens anteriormente compartilhados por Steinberger ainda eram cerca de 12.000 vezes. • Assim que o uso de tokens é traduzido para cálculos salariais, a narrativa muda rapidamente: isso não é mais “ferramenta de produtividade”, parece aristocracia de computação. 📌 A conta real é confusa, porque nem todos os tokens custam o mesmo • Contagens de tokens no estilo Cursor podem incluir entrada padrão, saída do modelo, gravações em cache e leituras em cache. Esses itens têm preços muito diferentes. • Com precificação no estilo Opus 5.5, 1 milhão de tokens de entrada pode custar cerca de US$ 4, saídas cerca de US$ 20 e leituras em cache apenas cerca de US$ 0,20. • Uma captura de tela de uso mostrou 73,3 bilhões de tokens custando cerca de US$ 30 mil no total, o que implica uma média de cerca de US$ 0,41 por 1 milhão de tokens porque o tráfego em cache dominava. • Aplicando essa taxa mista a 1,5 trilhão de tokens, o custo mensal cai para cerca de US$ 615 mil, não US$ 11 milhões. • No cenário mais otimista possível, onde tudo é cobrado ao preço de leitura em cache, 1,5 trilhão de tokens custariam cerca de US$ 300 mil por mês. • Piekarczyk depois suavizou sua própria afirmação também: mesmo que sua estimativa original fosse 10 vezes maior, o custo mensal ainda poderia ser de cerca de US$ 100 mil. 🔥 Então, o que todo esse gasto realmente comprou? 📌 Não “um chatbot”, mas toda uma organização de agentes • Steinberger descreveu esse estilo de trabalho como explorar como o desenvolvimento de software se parece quando o custo dos tokens já não é uma restrição. • Sua equipe de três pessoas estava executando cerca de 100 instâncias do Codex. • Esses agentes revisavam PRs, escaneavam histórico de commits em busca de bugs de segurança, mesclavam issues duplicados no GitHub, escreviam correções, monitoravam regressões de desempenho e até participavam de reuniões para gerar PRs a partir das discussões. • Lauren descreveu seu próprio setup como uma equipe de mais de 20 agentes: um agente chefe-de-gabinete, um agente PM e mais de 20 agentes de execução operando autonomamente. 📌 A principal ideia não é geração—é verificação • A afirmação de Lauren é que o gargalo na codificação por agentes não é escrever código, mas provar que o código realmente funciona. • Seu processo faz agentes executarem código, coletarem rastreamentos de CPU e instantâneos de heap, lançarem simuladores iOS e interagirem com aplicativos como usuários fariam. • O objetivo é criar um ciclo fechado: se um agente puder verificar sua própria saída, ele poderá continuar iterando até concluir a tarefa. • Se não puder verificar, ele devolve uma diferença para um humano e para—significando que o humano se torna a parte mais lenta do sistema. • Na escala que ela afirma—4.000 PRs por mês—even gastar 5 minutos de revisão humana por PR totalizaria cerca de 333 horas, basicamente um mês inteiro de trabalho para uma pessoa. Portanto, a revisão manual não pode ser a camada de validação. 📌 Isso muda o papel do engenheiro • Neste modelo, o engenheiro passa a parecer menos um programador e mais um gerente de engenharia para agentes. • O ponto de Lauren é direto: se você não confiar na saída de um agente, nunca escalará para cem. • Seu fluxo pstack empacota isso em playbooks estruturados—padronizando compreensão, design, codificação, revisão e validação entre múltiplos agentes locais e na nuvem. 🔥 Mas aqui é onde a história fica nítida: toda essa autonomia exigiu restrições brutais 📌 A base de código teve que ser reconstruída para ser amigável aos agentes • O GrokBot supostamente começou como software codificado rapidamente com poucas restrições arquiteturais e pouca leitura humana. • Isso tornava fácil para os agentes escolherem o caminho de menor resistência: mais código, fronteiras nebulosas, aumento do risco de desempenho. • Para corrigir isso, Lauren disse que usou mais de 600 PRs para refatorar o sistema em uma arquitetura interna chamada Dune. • As regras do CI se tornaram extremamente rígidas: proibir useEffect, banir comentários e validar gráficos de dependência para que o main e o renderer do Electron nunca se importem mutuamente. • Em outras palavras, a parte “inteligente” não era apenas modelos melhores. Era redesenhar o ambiente para que os agentes tivessem menos maneiras de serem descuidados. 📌 pstack pode ser poderoso, mas também pode ser profundamente não portável • Seu pacote inclui 23 playbooks e mais de 20 princípios de engenharia. • Isso soa menos como um fluxo universal de desenvolvimento e mais como uma gaiola comportamental altamente ajustada para modelos. • Tudo bem—até que alguém tente copiar e colar isso em equipes comuns com orçamentos comuns e bases de código legadas. Então a magia pode evaporar. 🔥 A reação contrária: isso é inovação ou apenas teatro computacional de rico? 📌 Críticos dizem que isso é uma fábrica de lixo de IA disfarçada como futuro • No Reddit e entre círculos de engenharia, muitos desenvolvedores argumentaram que mesclar milhares de PRs com gasto ilimitado em tokens não é uma revolução na engenharia de software. • Sua afirmação: isso é computação bruta sendo usada para inundar uma base de código com microalterações, ignorando o verdadeiro gargalo—manutenibilidade a longo prazo. • Dito de outro modo: a geração de código escala mais rápido do que o julgamento. E quando o julgamento é subfinanciado, a dívida é socializada para quem herdará o repositório. 📌 O valor comercial pode ser maior que o valor técnico • O fundador da T3, Theo, argumentou que o custo interno real pode estar mais próximo de US$ 25 mil–US$ 50 mil por mês. • Sua visão era simples: mesmo nesse nível, a exposição vale a pena. Algumas empresas gastam US$ 1 milhão em eventos e recebem menos atenção do que um único post viral da Lauren.• Do ponto de vista do Cursor, isso pode ser menos uma história de economia por unidade e mais uma manobra de comunicação brilhante. • A própria Lauren reconheceu claramente o privilégio: ela trabalha em um laboratório de IA com tokens efetivamente ilimitados, portanto, ela não afirma que todos devam copiar seu método exato. 📌 A questão mais profunda é econômica, não apenas técnica • Se o desenvolvimento agente só funciona suavemente quando os ciclos de validação são massivamente subsidiados, então o verdadeiro produto não é “codificação por IA”. É o acesso à verificação barata em escala. • E se isso for verdade, o AgentFi se torna o quadro mais interessante: não apenas o que os agentes podem fazer, mas quem pode arcar com o custo de permitir que eles operem de forma autônoma. • O futuro pode não pertencer às equipes com os melhores prompts. Pode pertencer às equipes que constroem os melhores sistemas de incentivos, limites e ciclos de verificação eficientes em capital. Minha interpretação? Essa história é útil justamente porque deixa todos desconfortáveis. • Melhor cenário: é uma visão inicial de uma nova pilha de engenharia onde agentes entregam, testam, corrigem e coordenam entre sistemas de software. • Pior cenário: é um espetáculo subsidiado por computação que confunde volume de saída com qualidade de produto. • Mais provável: a verdade está no meio. O software agente pode ser real, mas sem arquitetura disciplinada e economia razoável, pode se tornar apenas uma maneira mais rápida de fabricar dívida técnica. Então, aqui está a pergunta que gostaria de deixar com você: Se um agente pode escrever 4.000 PRs por mês, mas apenas uma pequena elite pode arcar com a conta de validação, esse é o futuro do software—ou apenas uma demonstração de poder?