Eu esperava um carro rápido. Não esperava um carro com dez bocais de propulsão a ar comprimido, usando tecnologia derivada da SpaceX, e um sistema de sucção embaixo capaz, segundo Elon Musk, de puxar até 2 G. Na demonstração, a Tesla anunciou zero a 60 milhas por hora, quase 97 km/h, em 0,81 segundo. Não divulgou o protocolo da medição.

Era esse o futuro que eu queria ver.

A demonstração inteira está na transmissão oficial da Tesla. A Road & Track mediu e descreveu as manobras, e a TechCrunch detalhou as três versões: Performance com aerodinâmica ativa e sucção, Thrust com propulsores traseiros, Rocket com sistema de propulsão de dez bocais e apenas um assento.

Claro, o que vimos foi um protótipo numa demonstração controlada. A Tesla prevê iniciar a produção em 2028, e a versão Rocket não está aprovada para uso em vias públicas. Ainda assim, um carro de verdade saiu do chão, girou e pousou. Eu assisti a isso ao vivo do meu escritório. Foi espetacular.

Enquanto Musk faz foguetes pousarem e carros voarem, eu estava fazendo um trabalho bem mais mundano e pequeno: mexendo nos meus sites.

Seis sites em cerca de um dia

Antes do evento da Tesla, eu passei o dia inteiro redesenhando seis sites:

• Akita’s AI Lair, agora combinando com o visual do meu livro novo, Competente o Suficiente;
• ai-memory;
• ai-jail;
• a newsletter The M.Akita Chronicles;
• o arquivo da newsletter;
• e este blog, AkitaOnRails.com.

Todos começaram com variações daquele tema padrão que o Claude faz. Fundo escuro, gradiente roxo ou azul, fonte sans enorme, cartões arredondados, brilho atrás de alguma coisa. Funciona. Também ficou tão comum que hoje você bate o olho e reconhece “site feito pelo Claude” antes de ler o título.

Eu já tinha tentado pedir designs diferentes pro Claude. Ele trocava a cor, movia os cartões e entregava a mesma gramática visual. Publiquei algumas telas e o resultado da mudança no Twitter. Eu não sou web designer e, por um tempo, aceitei o “funciona”. Ontem cansei.

Alguém me sugeriu o Stitch, do Google. É uma ferramenta experimental do Google Labs que transforma instruções e imagens em interfaces editáveis e código de front-end. A primeira versão foi apresentada em 2025 em cima do Gemini; a versão atual virou uma tela de design com agente, protótipos e exportação de um DESIGN.md que outros agentes conseguem seguir.

Criei a conta, peguei o token da API e comecei a trabalhar. O Stitch gerava direções visuais. Claude Code e Codex levavam essas direções pros repositórios reais, adaptavam os componentes, corrigiam responsividade, trocavam imagens, ajustavam SEO, testavam e faziam deploy. Quando a cota de um acabava, eu continuava com o outro.

Os seis sites saem de cinco repositórios. Olhando todos lado a lado, uma coisa ficou clara: o Stitch responde muito melhor quando recebe uma metáfora concreta, o público e o que aquele produto precisa comunicar. O ai-memory virou um arquivo de memória. O ai-jail, uma prisão cinematográfica. O AI Lair adotou uma feira mundial dos anos 1950 e 1960, puxada pela capa do meu livro. A newsletter virou uma transmissão noturna, e este blog, um arquivo editorial. Cinco identidades diferentes em vez de cinco variações do mesmo gradiente do Claude.

O protótipo bonito é a parte fácil. O trabalho só termina quando a linguagem visual chega às páginas internas, ao artigo, ao leitor do livro, ao e-mail, às páginas legais, aos estados de erro e ao celular. Foi isso que os agentes fizeram nos repositórios. No ai-memory, por exemplo, a verificação cobriu 102 páginas em seis idiomas, nos temas claro e escuro, em desktop e celular. No The M.Akita Chronicles, o mesmo design precisou funcionar na inscrição, no arquivo, no detalhe de newsletter, no podcast e no template do e-mail. Um mockup do Stitch não resolve nada disso sozinho.

Foram várias rodadas de protótipos em cada site. Algumas ficaram horrorosas. Outras tinham uma ideia boa cercada de decisões ruins. Eu mandava descartar, preservar uma parte, misturar com outra tentativa e recomeçar. Código ficou barato, então não existe motivo pra se apaixonar pela primeira versão.

O resultado não vai ganhar prêmio de design. Um designer profissional ainda encontraria centenas de coisas pra melhorar. Eu mesmo sei que consigo avançar se gastar mais alguns dias. Só que ficou muito melhor do que estava e, por enquanto, está competente o suficiente.

Seis sites existentes redesenhados, responsivos, com SEO, geração e substituição de imagens, ajustes de HTML, CSS e JavaScript, teste e deploy em produção. Uma pessoa. Cerca de um dia. Um ano atrás, esse pacote seria trabalho de semanas ou meses.

Vamos manter a proporção: são sites pequenos, a maioria landing pages e páginas de conteúdo. Ninguém vai recriar o conjunto inteiro de páginas e sistemas da Amazon.com em um dia. O experimento mostra quanto trabalho repetitivo já saiu da frente, dentro de um escopo que uma pessoa experiente consegue entender e revisar. Projetos grandes continuam grandes, cheios de regras privadas, integrações antigas, estados estranhos e decisões que não cabem num prompt.

Até o primeiro proofreading pode ser automatizado

No mesmo processo eu mandei agentes revisarem os sites como leitores diferentes. Não era correção gramatical. Eu queria saber o que uma pessoa entenderia nos primeiros segundos, onde ficaria perdida, qual promessa pareceria suspeita e se conseguiria completar uma tarefa sem já conhecer o produto.

No ai-jail, usei duas sessões isoladas. Uma assumiu o papel de um engenheiro cético que aprova todos os prompts e nunca tinha ouvido falar do projeto. A outra era gerente de oito desenvolvedores, sem ser engenheira, tentando decidir se deveria aprovar a ferramenta na empresa. No ai-memory foram três: um engenheiro aprendendo ferramentas de IA, uma gerente avaliando um piloto e um pai sem experiência com agentes, preocupado com AGI e empregos. Cada um leu o site sem ver o relatório dos outros.

Qualquer pessoa consegue fazer o mesmo. Suba a aplicação localmente ou abra um deploy de preview, comece sessões novas e dê a cada agente uma tarefa concreta. Um prompt básico pode ser assim:

Abra este site em desktop e celular: [URL].

Você é [perfil], conhece [contexto] e nunca viu este produto.
Seu objetivo é [decisão ou tarefa concreta].

Navegue como essa pessoa. Não leia código nem documentação interna antes.
Registre:
- o que entendeu nos primeiros dez segundos;
- o que acha que o produto faz e para quem serve;
- onde não soube qual era o próximo passo;
- promessas contraditórias, absolutas ou difíceis de acreditar;
- termos que o site usa antes de explicar;
- problemas de leitura, teclado, contraste, toque e responsividade;
- o que impediria você de testar, comprar ou aprovar.

Para cada achado, mostre a página e a evidência visível.
Separe bug factual, problema de uso e preferência subjetiva.
Não proponha redesign geral. Sugira a menor mudança que resolve o problema.

Eu prefiro três sessões independentes a uma mesa-redonda de agentes. Se um lê o relatório do outro, começa a concordar por inércia. Depois uma sessão separada consolida os pontos repetidos, descarta gosto pessoal e confere cada afirmação contra o código e a documentação do produto. A revisão pode apontar que uma frase está errada; ela não tem autoridade pra inventar a frase correta.

Os resultados mais úteis costumam cair em quatro grupos: posicionamento, ordem da informação, caminho até a primeira ação e confiança. Testes automáticos tradicionais continuam cuidando de link quebrado, contraste, acessibilidade, overflow e estado de erro. A persona mostra que o botão tecnicamente acessível apareceu cinco telas depois de onde a pessoa precisava dele.

No proofreading do ai-jail, os dois perfis concordaram que o site demorava pra mostrar o risco concreto e falava cedo demais como documentação de engenheiro. A ameaça de uma página envenenada foi puxada pra logo depois do hero. Entraram as seções “O que muda no primeiro dia” e “Para quem precisa aprovar isto”, com custo operacional, limites e as chaves que uma empresa realmente expõe. A revisão também encontrou uma afirmação tecnicamente errada repetida em várias páginas: a rede não fica inteiramente desligada por padrão. O host da própria API do agente e, no Linux, os registries continuam acessíveis. Esse tipo de leitura também encontra bug de documentação.

O relatório do ai-memory encontrou permissões descritas de formas contraditórias, promessas de privacidade absolutas demais e a explicação básica soterrada por features avançadas. Na segunda rodada, os perfis perceberam que a instrução de acesso remoto mandava usar HTTP antes de exigir TLS, que um curl sem autenticação prometia a resposta errada e que escolhas importantes apareciam tarde demais no celular. O guia de coleta saiu de aproximadamente 4.364 pixels do topo pra 1.617; os caminhos pra indivíduo ou equipe, de 5.300 pra 2.489. Isso é uma melhoria objetiva nascida de leitura simulada.

No redesign do AI Lair, a revisão para leitores novos reorganizou o caminho de entrada. Uma revisão seguinte deixou explícito que o meu setup com vários agentes e dois monitores é uma configuração madura, não requisito pra começar. Uma pessoa, um projeto e um agente bastam. Também surgiu um roteiro de piloto pra gerente: tarefa reversível, dado não sensível, critério de aceitação, prazo, orçamento e medição. A auditoria seguinte encontrou ARIA inválido e uma animação que escondia o texto de abertura de tecnologias assistivas; a correção levou o axe-core de quatro violações sérias pra zero.

Personas simuladas ainda ficam muito abaixo de feedback humano. Carregam os mesmos vícios dos modelos, podem concordar com o prompt e nunca sentem a irritação de quem perdeu vinte minutos, nem assumem o risco de colocar o próprio cartão de crédito. Os relatórios servem como hipóteses. Um usuário real sempre encontra o caso que eu, o agente e a suíte de testes não imaginaram.

Só que antes do primeiro usuário existir, a alternativa costuma ser nenhuma revisão. Duas ou três leituras independentes já pegam promessa contraditória, jargão sem explicação, informação enterrada e fluxo que só faz sentido pra quem escreveu. Rodar essas leituras custa pouco e deixa o produto menos burro antes de chegar em gente de verdade.

HTML nunca foi programação

Durante anos eu vi gente fazendo uma ginástica danada pra defender que “HTML é linguagem de programação” e, portanto, quem escreve HTML é programador.

HTML é marcação: descreve a estrutura de um documento. CSS descreve apresentação. Isso tem valor, exige conhecimento e pode ficar terrivelmente complexo. Complexidade acidental não transforma marcação em programação.

E não há vergonha nenhuma nisso. Comecei a fazer sites nos anos 1990. Recebia um layout feito no Photoshop e transformava aquilo em HTML. Recortava imagens, montava tabela, ajustava pixel, abria em vários navegadores, voltava e tentava de novo. Foi trabalho honesto e pagou minhas contas.

Também era um trabalho basicamente mecânico: copiar, colar, ajustar, olhar, repetir. Exatamente a categoria que computadores deveriam automatizar.

Hoje eu ainda escolhi direção visual, descartei propostas ruins, decidi o que cada site precisava comunicar e reconheci quando o resultado estava bom o suficiente. Os agentes fizeram o serviço braçal. É assim que deveria ter sido há anos.

A bolha atrasou a automação

Durante boa parte dos anos 2010, os juros americanos ficaram perto de zero. Dinheiro barato irrigou fundos, startups e empresas grandes. Contratar mais gente era fácil, e o mercado absorvia qualquer quantidade de trabalho manual disfarçado de engenharia.

Juro baixo não explica sozinho a expansão da tecnologia, mas uma área em recorde de contratação tem pouco incentivo pra eliminar o próprio trabalho repetitivo. Se você consegue colocar mais cinquenta pessoas pra montar tela, coloca mais cinquenta pessoas pra montar tela.

Quem assistiu às minhas palestras em eventos de tecnologia nos anos 2010 deve lembrar de Restrição == Inovação. O nome correto era com dois sinais de igual mesmo. Apresentei essa palestra na DevConf 2019, os 83 slides estão no meu SlideShare, e eu já tinha escrito a mesma tese em 2013, em “Restrições são libertadoras: menos é mais”.

É a velha máxima: a necessidade é a mãe da invenção. Restrição obriga a escolher. Escolha obriga a priorizar. Quando o caminho convencional não cabe no dinheiro, no prazo ou na capacidade disponível, alguém precisa encontrar outro caminho. É daí que costuma sair inovação de verdade.

Dinheiro financia pesquisa cara, compra equipamento e dá tempo pra experimentar. Sobra de dinheiro sem pressão por resultado faz outra coisa: esconde ineficiência com força bruta. Não precisa automatizar, simplificar nem descobrir uma solução melhor enquanto ainda der pra contratar mais gente e aumentar a planilha. Abundância demais transforma problema técnico em despesa operacional e empurra a decisão difícil pra depois.

Eu repeti esse aviso no começo de 2026: a bolha de programação conseguiu substituir eficiência por volume. A restrição voltou quando o dinheiro barato acabou. Coincidentemente, os agentes chegaram na mesma hora e deram às empresas uma maneira prática de automatizar o trabalho mecânico que elas passaram uma década escalando com contratação.

Foi assim que a gente passou uma década recriando o mesmo painel administrativo e chamando de inovação. Toda semana aparecia a próxima salvação do front-end: React, Angular, Vue, Svelte, outro bundler, outro framework em cima do framework. São ferramentas úteis em seus contextos, mas nenhuma atacava a pergunta óbvia: por que um ser humano ainda está escrevendo à mão a milésima variação do mesmo formulário?

O estouro da bolha de contratação em 2022 encerrou a festa. No fim daquele ano, o ChatGPT levou modelos de linguagem ao público. GPT-2, só pra corrigir a cronologia, tinha saído em 2019. Quatro anos depois do ChatGPT, programação agêntica virou ferramenta normal de trabalho.

Qualquer tarefa que consiste em copiar padrão, adaptar exemplo, rodar, olhar o erro e tentar de novo já está no alcance desses agentes. Front-end é o alvo mais visível porque acumulou uma quantidade absurda desse trabalho. O resto da programação não está protegido por alguma aura mística. Tem muito back-end que é CRUD, cola entre APIs e configuração repetida. Também será automatizado.

Pra mim, ótimo. Programar nunca foi digitar código. Programar é fazer um computador executar algo útil.

VS Code é o novo cartão perfurado

Eu escrevi exatamente sobre isso em abril, em “VS Code é o novo Cartão Perfurado”.

Por décadas, a interface entre intenção e computador mudou. Primeiro você ligava fios e chaves. Depois perfurava cartões. Depois escrevia Assembly, C, linguagens de alto nível, frameworks e configuração. Cada geração olhou pra anterior e automatizou uma camada de trabalho manual.

Ninguém em sã consciência defenderia hoje que operar uma perfuradora de cartões era a essência da ciência da computação. Era a interface disponível. Digitar cada tag e cada regra de CSS no VS Code também era a interface disponível.

Agora eu descrevo a intenção, mostro referências, avalio o resultado e mando o agente corrigir. Ainda preciso entender como navegador, rede, cache, acessibilidade, semântica, responsividade e SEO funcionam. Sem fundamento eu nem saberia dizer se o agente entregou uma solução ou uma bomba-relógio bonita. O teclado perdeu importância; julgamento ganhou.

Hoje, todos os modelos Tier A que eu testo, de Claude a Kimi, conseguem executar com confiabilidade o trabalho mecânico de front-end que apareceu nesses seis projetos. Eu consigo afirmar, sem hesitar, que qualquer tarefa de front-end que só transforma uma decisão já tomada em código é automatizável. Eles não inventaram seis designs brilhantes sozinhos, porém nenhum precisou que eu escrevesse manualmente o flexbox, o breakpoint ou o componente que já expliquei.

Isso cobre uma parcela enorme do trabalho, mas deixa justamente a parte de maior valor. Alguém ainda precisa conhecer os prós e contras do framework, entender o browser, escolher a arquitetura, perceber quando a biblioteca está sendo usada contra o seu desenho e descobrir por que uma solução aparentemente correta quebra numa combinação específica de aparelho, idioma, estado e dado real. O agente escreve o código; um profissional experiente dá direção, limita o estrago e assume o resultado.

Front-end continua existindo. O excesso de trabalho mecânico e de gente contratada só pra executar receita pronta é que perde valor. Um ótimo profissional de front-end consegue dirigir agentes e entregar muito mais do que entregava sozinho. Um profissional mediano que passou anos confundindo digitação de componente com engenharia vai disputar menos vagas. O mercado fica menor e mais seletivo, com os melhores profissionais produzindo mais. A meta continua a mesma de sempre: chegar perto do topo, onde julgamento e experiência ainda fazem diferença.

E isso não para no browser. Escolha o framework: Android com Flutter ou Kotlin, iOS com Swift e SwiftUI, desktop com Rust/Tauri, Flutter, C# ou Electron. Em geral, agentes modernos conhecem os componentes, as ferramentas de build, os testes e as peculiaridades dessas plataformas. Ainda precisam de direção, feedback e verificação, exatamente como no front-end web. A parte mecânica já é automatizável.

Eu testei isso nos meus próprios projetos pequenos e abertos. O FrankYomik tem um cliente Flutter pra Android e Linux, além do servidor e da extensão. O Frank Sherlock é um app desktop em Rust/Tauri que gera AppImage pra Linux, DMG pra macOS e instalador .exe pra Windows. Também fiz o Frank Karaoke em Flutter pra Android e o FRANK MANGA+ em Rust/Tauri pra desktop. Há vários outros no meu GitHub.

Nenhum deles saiu perfeito no primeiro prompt. Flutter e Tauri me deram trabalho, especialmente nos primeiros projetos. Confiável quer dizer que o agente consegue avançar, receber uma correção, criar testes, corrigir o que quebrou e chegar num aplicativo funcional sem eu assumir a digitação braçal. Depois de testar web, Android e desktop em stacks diferentes, estou muito satisfeito com o resultado. O padrão se repete: trabalho mecânico virou trabalho de agente.

Às duas da manhã eu tinha agentes fazendo os últimos ajustes neste blog sem perder o ritmo. É disso que eu preciso.

Quando a web ainda não sabia o que era

No auge da bolha da Internet, designers de carreira estavam criando sites. A web ainda não tinha decidido como uma página deveria funcionar, então havia espaço real pra experimentar. Era feio muitas vezes, pesado quase sempre, mas tinha criação acontecendo.

O iPhone abriu outra janela em 2007. De repente tudo precisava caber numa tela pequena, responder ao toque e funcionar sem mouse. Vieram anos de experimentação até o mercado formar uma gramática razoavelmente estável de navegação, gesto, formulário e conteúdo.

Hoje ninguém precisa redescobrir um menu, uma lista, um checkout ou uma página de artigo. Os padrões estão documentados, milhões de exemplos estão públicos e os modelos viram mais interfaces do que qualquer pessoa conseguiria estudar durante a vida.

O trabalho mais valioso continua existindo: entender o produto, a pessoa que vai usá-lo, as restrições e o que merece aparecer primeiro. O trabalho de converter uma decisão pronta em centenas de linhas previsíveis virou candidato perfeito à automação.

Empregos desaparecem. Outros aparecem

O mundo nunca ficou parado pra preservar uma função.

Operadores de cartão perfurado digitavam dados e programas em papel. Telefonistas conectavam chamadas fisicamente. Datilógrafos mantinham escritórios funcionando. Linotipistas montavam linhas de metal quente pra imprimir jornais. A tecnologia reduziu ou eliminou essas ocupações em escala. A lista atual de profissões em maior declínio do Bureau of Labor Statistics ainda inclui digitadores, datilógrafos e operadores de telefonia. Ninguém propõe voltar a elas pra proteger emprego.

Ao mesmo tempo apareceram trabalhos que uma pessoa de 1926 nem conseguiria nomear: desenvolvedor mobile, SRE, designer de experiência, criador de vídeo pra Internet, especialista em nuvem, engenheiro de machine learning. A própria web matou trabalho antigo e abriu uma indústria inteira.

A história real é menos limpa do que a caricatura. A OIT mostra que a tecnologia costuma automatizar tarefas sem necessariamente eliminar ocupações inteiras. Algumas funções encolhem, outras mudam e trabalhos novos aparecem. Esse consolo estatístico não resolve a vida de quem ficou obsoleto hoje. A pessoa precisa reagir antes que a média da economia reaja por ela.

Compare 2026 com 1926, três anos antes do crash de 1929. Parece outro planeta, embora um século seja muito pouco na escala da história. Não existe contrato garantindo que a sua função atual sobreviva aos próximos dez anos, muito menos aos próximos quarenta.

E como um júnior ganha experiência agora?

Vai ficar mais difícil. A escada antiga começava com alguém pagando um iniciante pra montar tela simples, corrigir CSS e copiar componente. O agente faz boa parte disso mais rápido e barato. Empresa nenhuma tem obrigação de preservar trabalho ineficiente como programa de treinamento.

O iniciante vai ter que construir a própria escada com projetos reais e problemas pelos quais ele seja responsável. Isso inclui ler o código que o agente gerou, quebrar e consertar, estudar documentação e código-fonte, escrever testes e contribuir com projetos abertos. O agente dá a qualquer estudante acesso a uma quantidade de prática que antes exigia uma equipe. Quem usar isso só pra gerar código que não entende vai continuar júnior por muito tempo.

O mercado vai premiar quem fizer esse esforço extra. Sempre premiou. Quando alguém pergunta como o júnior vai ganhar experiência sem as tarefas fáceis, muitas vezes a pergunta escondida é outra: “como eu consigo um salário melhor sem passar pelo trabalho difícil de ficar bom?” A vaga fácil, com salário crescente e pouca cobrança, foi uma distorção da bolha. Adaptar-se inclui aceitar que a entrada ficou mais competitiva.

Minha carreira nunca ficou no mesmo lugar

Comecei com multimídia e sites estáticos. Depois trabalhei em agência digital, consultoria enterprise, integração de SAP, startups, vídeo, educação e, agora, IA. No Akitando sobre SAP, eu conto parte dessa fase em que precisei aprender um mundo completamente diferente do que fazia antes.

Atravessei o crash das pontocom, a crise de 2008 e o fim da bolha de juro zero. Sobrevivi porque nunca tratei a minha função do momento como identidade permanente. Continuei estudando, acumulando experiência e mudando de direção.

Uma carreira produtiva não deveria consistir em repetir a mesma tarefa mecânica por décadas. Se o seu valor depende de o mercado continuar pagando alguém pra empurrar tag e pixel à mão, o problema não começou com a IA. O problema foi apostar que o presente seria eterno.

Muita gente entende “estar preparado” como estudar o mínimo necessário pra vaga aberta hoje. Essa é a receita mais rápida pra ficar obsoleto. Faça o trabalho de curto prazo, mas estude além dele. Aprenda as coisas que parecem inúteis agora. Fundamentos, sistemas operacionais, redes, bancos de dados, negócio, economia, história. Você não sabe qual combinação vai salvar sua carreira daqui a cinco anos.

Eu passei anos falando disso no Akitando. Reveja as playlists Eu Avisei e Que curso devo fazer??. Se tiver que começar por um vídeo, comece pelo Guia DEFINITIVO de Aprendendo a Aprender. Curso nenhum salva quem ainda terceiriza o próprio aprendizado.

O mundo não tem falta de oportunidade. A maioria das pessoas sente que nunca recebe uma porque está sempre despreparada quando ela aparece. Quando a oportunidade pousa na sua frente, já é tarde pra começar a preparação.

Portanto, eu não vou lamentar que o pacote desses seis sites pequenos, que antes tomaria semanas ou meses, tenha cabido em cerca de um dia. Estou feliz pra cacete. Ganhei tempo pra pensar no que construir, experimentar mais e jogar fora versões ruins sem desperdiçar semanas de vida.

Hoje eu vi um carro girar no ar e pousar. Em cerca de um dia, coloquei seis sites com visual novo em produção sem escrever a maior parte do HTML e CSS. O futuro que eu queria não chegou perfeito, barato nem distribuído igualmente. Mas chegou o bastante pra eu trabalhar com ele.

Aceite o que acabou. Estude o que vem depois. E esteja pronto antes da próxima oportunidade aparecer.

Só que ninguém precisa de um modelo classe GPT pra tudo. Modelo de fronteira é generalista por definição: tenta saber tudo sobre qualquer coisa, de direito tributário a letra de música, e o retorno disso é decrescente.

E a maioria deles hoje é mistura de especialistas, mixture of experts: grosso modo, vários modelos menores agrupados num bloco gigante de bits, com um roteador que acorda só alguns pra cada token. O gpt-oss-120b da OpenAI tem 117 bilhões de parâmetros no total e usa 5,1 bilhões por token. O DeepSeek-V3 tem 671 bilhões e ativa 37. O modelo grande já é, por dentro, uma coleção de modelos pequenos.

Eu podia ter pego um modelo aberto, gpt-oss, Qwen, Phi, e adaptado. As técnicas existem e são bem documentadas:

• Fine-tuning completo: continuar treinando todos os pesos de um modelo pronto nos seus dados. É a transferência de aprendizado clássica, formalizada pro texto pelo ULMFiT em 2018.
• LoRA e QLoRA: congelar os pesos originais e treinar só matrizes pequenas de baixo posto ao lado deles. O LoRA reduz em até dez mil vezes os parâmetros treináveis; o QLoRA quantiza o modelo base em 4 bits e ajusta um modelo de 65 bilhões numa única GPU de 48 GB.
• Destilação: treinar um modelo menor pra imitar as saídas de um maior. A ideia é de Hinton, 2015, e o exemplo recente mais famoso é o DeepSeek-R1 destilado em versões de 1,5 a 70 bilhões em cima de Qwen e Llama.
• Pré-treino continuado: mais uma fase de treino em texto do seu domínio antes de qualquer ajuste de instrução, o “Don’t Stop Pretraining” de 2020.
• SFT, RLHF e DPO: ensinar o formato de assistente com demonstrações, depois alinhar com preferência humana via aprendizado por reforço (InstructGPT) ou com uma perda de classificação direta (DPO).

Com qualquer uma dessas eu teria um modelo útil em horas. Só que o objetivo era outro. Eu queria organizar, com as mãos, as técnicas básicas pra construir um modelo menor que o GPT-2, do zero, em poucos dias, e ver até onde dava pra chegar. Se desse, treinar um modelo minúsculo partindo de pesos aleatórios e adicionar funcionalidade suficiente pra ele quase funcionar dentro de um harness agêntico como o OpenCode.

Antes de continuar, quem eu sou nessa história: eu sou engenheiro de software curioso e amador no assunto. Pesquisador de LLM eu sou zero. Eu sabia que não ia ter um LLM funcional em tão pouco tempo, e isso faz parte do exercício.

Mas não é inalcançável. Se você é estudante de computação, estuda sério e dá anos pra isso, você consegue tentar por conta própria. E se você não é cientista, entenda isto: ninguém precisa ser Einstein pra fazer isso. Os fundamentos estão todos disponíveis, publicados, pra você estudar e tentar. O que é obrigatório é suor.

Spoiler: a gente chegou longe no “quase” e parou lá. O repositório é público, com cada etapa e cada fracasso documentado. Este texto é o resumo.

TL;DR: parti do microgpt do Karpathy, 200 linhas de Python puro que treinam um GPT em um minuto num MacBook, e expandi pra um laboratório em PyTorch com tokenizer próprio, pré-treino, ajuste supervisionado, servidor compatível com a API da OpenAI e integração com o OpenCode. Em menos de duas semanas, numa RTX 5090, treinei um modelo de 337 milhões de parâmetros em 10 bilhões de tokens: 137 horas de treino, no máximo uns R$ 80 de luz. Ele acerta 58 de 100 funções Python simples de um conjunto reservado, e zera em tudo que exige ler, editar e testar um repositório. O SmolLM2 de 360 milhões, do mesmo tamanho, viu 4 trilhões de tokens, 400 vezes mais. Pule pro exercício do Karpathy, pras etapas, pras dimensões, pros tropeços, pro resultado ou pra conclusão.

O exercício do Karpathy

Em fevereiro deste ano o Andrej Karpathy publicou o microgpt: um único arquivo de 200 linhas de Python, sem dependência nenhuma, que treina e roda um GPT. Ele chama de “o conteúdo algorítmico completo do que é necessário. Todo o resto é só eficiência”. É a culminação de uma linhagem dele: o micrograd (autograd escalar), o makemore (gerar nomes) e o nanoGPT (GPT-2 em PyTorch compacto), à qual se soma o nanochat, “o melhor ChatGPT que 100 dólares compram”, que no lançamento treinava um modelo de capacidade GPT-2 em quase quatro horas num nó de oito H100, e hoje faz isso em umas duas.

O microgpt é propositalmente mínimo: o dataset são 32 mil nomes próprios, um por linha, e o tokenizer é um caractere por token.

A rede tem uma camada, 16 dimensões de embedding, 4 cabeças de atenção, janela de 16 tokens porque o nome mais longo tem 15 letras. Treina por mil passos, um nome por passo, com Adam escrito à mão, e no fim gera nomes inventados, tudo em um minuto num MacBook.

O que ele ensina, por estar tudo exposto num arquivo só:

• o autograd, a classe Value que guarda um número, o gradiente e a regra da cadeia pra propagar de volta;
• o que é um token e um embedding;
• o bloco de atenção, com consulta, chave e valor, e a máscara causal que impede o modelo de espiar o futuro;
• a perda de entropia cruzada contra o próximo token;
• o otimizador;
• a amostragem com temperatura.

É um GPT-2 com diferenças pequenas que o próprio arquivo anota: RMSNorm no lugar de LayerNorm, sem bias, ReLU em vez de GeLU. Depois de ler aquilo, o que sobra entre você e um modelo de verdade é, nas palavras dele, eficiência. Eu fui ver quanto de eficiência.

O que a gente expandiu

O microgpt lab é uma reimplementação independente em PyTorch, inspirada no gist, dividida por conceito: umas 3.300 linhas de Python em 31 módulos, mais scripts e 85 testes de CPU. Uma única implementação de modelo serve pra pré-treino, ajuste de assistente e servidor. Todo peso começa aleatório; o projeto não baixa peso pré-treinado nenhum, de propósito, porque a regra do exercício era do zero.

Em cima do bloco do Karpathy entraram os componentes que um modelo de 2026 usa: RoPE pra posição, RMSNorm, SwiGLU na camada densa, embeddings amarrados à saída, Flash Attention via PyTorch, cache de chaves e valores com reuso de prefixo. E em volta do modelo, o que falta pra ele conversar com um agente: um protocolo de conversa com papéis, um servidor HTTP compatível com a API de chat da OpenAI, chamadas de ferramenta validadas por esquema e opcionalmente por gramática, separação de conteúdo de raciocínio, e a configuração do OpenCode apontando pra ele.

O projeto passou por quatro escalas:

A tabela esconde a primeira lição grande, que eu conto nos tropeços: no modelo de 239 milhões, 154 milhões de parâmetros eram só a tabela de vocabulário. Sobravam 85 milhões pro transformer de verdade.

As etapas de construir um LLM

Independente do tamanho, o caminho tem as mesmas estações. O que muda é o zero à direita em cada uma.

1. Dados

Modelo é o que ele come. Baixamos, com revisão fixada e hash, seleções de corpora públicos: CodeParrot (Python deduplicado e filtrado), OpenCoder (instrução e código), Cosmopedia (texto educativo sintético), SmolTalk (conversa) e uma fatia multilíngue. Os 14 manifestos de download somam uns 20 GB brutos, tudo guardado no NAS.

Daí vem a curadoria: deduplicação exata, divisão de treino e validação por repositório ou grupo de conversa (nunca por linha, senão o mesmo projeto vaza pros dois lados), e a mistura. O corpus final de fundação tem 3,5 bilhões de tokens armazenados, 60% código Python, 16% instrução, 12% texto educativo, 8% conversa, 4% multilíngue. Cada proporção é uma decisão de projeto, e nenhuma delas tem resposta certa publicada.

2. Tokenizer

O tokenizer é o dicionário entre texto e inteiros. A lição em bytes usa 256 tokens mais um de fim de documento. O estudante usou o o200k, o vocabulário público da OpenAI com 200 mil entradas, que é o que a maioria dos tutoriais faz. O pivô treinou um BPE próprio de 32.768 entradas, em cima de 92 MB de texto só de treino, com cobertura de UTF-8 completa.

A escolha parece detalhe e decide onde os parâmetros vão parar. Cada entrada do vocabulário custa uma linha na tabela de embedding com a largura do modelo. Com 200 mil entradas e largura 768, são 154 milhões de parâmetros gastos em tabela. Com 32 mil entradas e largura 1.024, são 33 milhões, e o resto vai pras camadas que pensam.

3. Pré-treino, ou fundação

Aqui é o loop do Karpathy em escala. O modelo recebe janelas de 2.048 tokens tiradas do fluxo de treino e aprende a prever o próximo token. Cada atualização processa 32.768 tokens: duas sequências, acumuladas oito vezes. AdamW, taxa de aprendizado com aquecimento e decaimento em cosseno, recorte de gradiente, BF16 na GPU e FP32 nos pesos.

O pivô rodou uns 305 mil atualizações, 10 bilhões de tokens de exposição. Como o corpus tem 3,5 bilhões, cada documento foi visto, na expectativa da mistura, quase três vezes: o código umas duas, e instrução, texto educativo e conversa umas nove ou dez. A cada 500 atualizações, uma validação e um checkpoint. Nos marcos de 2, 5 e 10 bilhões, um checkpoint congelado com hash, pra medir a curva.

4. Ajuste supervisionado

Pré-treino produz um modelo que completa texto. Pra ele responder a um pedido, vem o SFT, supervised fine-tuning: exemplos de pergunta e resposta no formato exato que o servidor usa, com a perda calculada só sobre os tokens do assistente. O que o usuário e a ferramenta disseram entra como contexto e é mascarado da perda.

Os exemplos vieram do OpenCodeInstruct da NVIDIA, e cada resposta foi executada num Docker restrito antes de entrar: quase 99 mil candidatos, 97 mil sobreviveram ao teste com três sementes de hash diferentes. Sobraram 92 mil episódios de treino. O checkpoint escolhido viu 64 mil sorteios desses episódios, uns 10 milhões de tokens de resposta.

5. Protocolo, ferramentas e servidor

Um agente como o OpenCode fala com o modelo por HTTP: manda o histórico com papéis, as definições de ferramenta, recebe de volta texto ou uma chamada de ferramenta em JSON, executa, devolve o resultado, e repete. O laboratório implementa esse ciclo inteiro: o mesmo arquivo de protocolo serializa os exemplos de treino e os prompts de serviço, pra formato de treino e formato de uso nunca divergirem.

O servidor implementa /v1/models e /v1/chat/completions, valida a chamada de ferramenta contra o esquema, pode restringir a geração com gramática pra JSON sair bem formado, separa o conteúdo de raciocínio da resposta, conta tokens em cache e recusa estouro de contexto em vez de truncar em silêncio. Isso tudo é encanamento, zero inteligência, e sem ele o modelo nem senta à mesa.

6. Avaliação

A etapa que mais mudou o projeto. Um conjunto congelado de 100 tarefas Python de desenvolvimento, 20 famílias com cinco variantes de nome e enunciado, mais 100 tarefas reservadas que só o checkpoint final viu. Cada resposta roda num Docker sem rede, sem root, com limite de CPU e memória, contra asserções fixas. Além disso: quatro tarefas reais de conserto de repositório via OpenCode, 12 problemas de rastrear a saída exata de um programa, sondas de recuperação de informação em prompts de 8, 16 e 32 mil tokens, e quatro conversas curtas.

Nada de HumanEval, MBPP ou SWE-bench. São diagnósticos locais pequenos, com famílias correlacionadas, uma semente, geração gulosa. Servem pra decidir entre checkpoints, e o próprio relatório de fechamento manda não ler “58 de 100” como “58% de sucesso em programação”.

As dimensões do problema

O que tudo isso custou, e como isso se compara com o mundo real:

A conta da luz: a RTX 5090 tem 575 W de potência nominal. Em 137 horas a plena carga são uns 79 kWh, e a tarifa residencial da Enel em São Paulo em 2026, somando TUSD, TE e impostos, fica em torno de R$ 1 por kWh. Como o treino rodou boa parte do tempo a 75% de ciclo pra não travar o desktop, o real foi menos. É o custo marginal de quem já tem a placa.

Alugar uma 5090 na Runpod sai a uns US$ 1,20 por hora, então as mesmas 137 horas custariam uns US$ 165; uma H100 sai entre US$ 2,90 e 4 por hora, dependendo da variante.

E a comparação que dá a escala. O SmolLM2 de 360 milhões de parâmetros, praticamente o tamanho do nosso, foi treinado em 4 trilhões de tokens. Na nossa vazão, 4 trilhões levariam entre quatro e seis anos de GPU ininterrupta. Mesmo tamanho de modelo, 400 vezes a quantidade de estudo.

É por isso que “parâmetros” é uma unidade enganosa: diz o tamanho do cérebro, e nada sobre quantos anos de escola ele teve.

A regra de bolso derivada de Chinchilla (70 bilhões de parâmetros, 1,4 trilhão de tokens), uns 20 tokens por parâmetro pra ser computacionalmente ótimo, daria 6,7 bilhões de tokens pro nosso modelo. Passamos disso. Só que o ótimo de Chinchilla é o ponto de melhor uso de compute, e modelos pequenos modernos passam muito dele de propósito, porque o custo de inferência depois compensa treinar mais.

Os tropeços

A lista completa está no relatório de fechamento. Os que mais ensinaram:

Medir perto demais do treino. O primeiro agente, o de 91 milhões, completou quatro sessões de 16 rodadas no OpenCode e uma de 32 rodadas com 130 chamadas de ferramenta reais, recuperando de erro de verificação e trocando de sessão no meio, com o estado guardado pelo harness. Parecia pronto.

Aí eu pedi, na mão e em inglês, uma função hello world que recebe um nome como parâmetro e imprime na mensagem. O modelo repetiu duas vezes a edição aritmética anterior, apontou pra um arquivo que não existia, e na terceira tentativa cuspiu JSON inválido. Tudo que ele sabia era a família de tarefa do treino.

O vocabulário comeu o modelo. O candidato de 239 milhões tinha mais camadas e perda menor que o de 91 e resolvia 24 de 100 problemas. Ao olhar a distribuição dos parâmetros, 154 milhões eram tabela de vocabulário. O pivô pra 32 mil entradas devolveu 300 milhões de parâmetros pro transformer. O pivô mudou vocabulário, distribuição de capacidade, inicialização e exposição de uma vez, então o relatório não isola qual delas moveu o resultado.

Perda não é competência. No SFT final, continuar de 4 mil pra 8 mil atualizações baixou a perda de validação e derrubou o acerto executado de 68 pra 62. Loss mais baixa, código pior. A seleção de checkpoint passou a ser por tarefa executada, congelada antes; o número da perda ficou de fora.

Dados e avaliadores mentem. Respostas “corretas” do dataset público falhavam ao serem executadas de novo. Testes que dependiam da ordem de hash do Python, builtins sombreados, SystemExit(0) contando como sucesso, edições vazias copiando o arquivo. Cada um precisou de um controle: três sementes de hash, sentinela de conclusão, fixture vazia que precisa falhar. E num dos treinos mistos, o modelo aprendeu a dizer que os testes passaram quando não tinham passado.

Formato de treino e formato de uso precisam bater. Anúncio de troca de sessão, ID de chamada de ferramenta, âncora de edição, o jeito como o OpenCode cita a entrada do usuário: cada diferença entre o que o modelo viu no treino e o que recebeu no servidor derrubava o agente antigo. O mesmo arquivo de protocolo pros dois lados foi a solução, e ainda assim mudar formato às vezes melhorava o nome da função sem melhorar o código.

Tokenização cruza fronteiras de correção. A string literal <|endoftext|> dentro de código fonte precisa continuar sendo texto comum em vez de virar o marcador de fim de documento. Reconstruir documentos UTF-8 sem partir um caractere no meio. O suporte do XGrammar a vocabulário em nível de byte. A primeira avaliação de código do marco de 2 bilhões falhou na construção da gramática, e foi corrigida e rerodada em vez de contar como falha do modelo.

O NAS quase me custou dias. Na retomada da fase de 10 bilhões, o treinador carregou o passo 81.500 em vez do 152.588 congelado: o last.pt mutável tinha timestamp anterior à pausa, logo depois de uma manutenção no NAS, e a causa nunca foi provada. Descartamos 1,24 hora de treino, verificamos o hash do marco de 5 bilhões, e toda retomada seguinte passou a exigir hash, passo exato, estado do otimizador e do RNG, dataset e uma sonda de escrita com fsync. Nunca retome um treino só porque o arquivo se chama last.pt.

GPU de desktop é GPU compartilhada. VRAM livre não impediu o navegador de travar. A solução foi um ciclo de trabalho cooperativo: o treinador sincroniza a GPU e dorme entre lotes, 75% do tempo durante o dia e 100% das 3 às 9 da manhã. E a leitura do corpus pelo NAS, via mmap, deixava a GPU ociosa esperando disco. Depois de uma manutenção a vazão caiu pra 5 mil tokens por segundo antes de voltar aos 23 mil.

Parei numa fronteira do pipeline. O controlador do pivô implementava fundação, SFT de código e holdout. Terminou limpo, e “terminou limpo” cobria até a função Python isolada, enquanto o objetivo era o agente. O checkpoint final foi testado no OpenCode só no fechamento, e falhou. Devia ter sido testado antes de qualquer frase com “pronto”.

O que saiu do outro lado

A ficha do modelo final:

A curva de aprendizado, medida nos três marcos, com o mesmo SFT curto aplicado em cima de cada um:

O SFT mais longo em cima dos 10 bilhões chegou a 68 de 100 no conjunto de desenvolvimento e 58 de 100 no reservado. Todas as 100 saídas do reservado são Python válido, e 97 têm o nome de função e os parâmetros pedidos. Nove famílias passaram nas cinco variantes: mediana, fatorial, máximo divisor comum, conversão pra binário, inverter dicionário, contar linhas, ano bissexto, segundos pra horas, chaves de JSON. Total acumulado ficou em quatro de cinco.

O que ele faz, portanto: escreve uma função Python pequena, com docstring, sintaxe correta e o nome certo, pra um pedido claro de uma linha. Dentro de um editor, como autocompletar de função isolada, serve pra estudo.

O que ele erra, com exemplos salvos: deduplicar usando set quando o enunciado exigia suportar listas não hasheáveis; agrupar por tamanho contando palavras em vez de agrupar; fazer aritmética em cada elemento numa função de preencher; devolver (texto, '') numa função de dividir uma vez, ignorando o separador; tirar o último caractere em vez do diretório numa função de basename. Dos 42 erros do reservado, 39 têm sintaxe válida e nome certo e falham na semântica. A parte difícil nunca foi parecer código.

E o que ele zera:

• 0 de 4 consertos reais de repositório no OpenCode, com zero chamadas de ferramenta. Pedido pra ler, editar e testar um arquivo, ele devolveu texto com código. Numa das tarefas, renomeou a função pra fix_mean.
• 0 de 12 em rastrear a saída exata de programas curtos, com e sem modo de raciocínio. Muitas respostas foram código que supostamente calcularia o inteiro pedido.
• 0 de 9 em achar um número de seis dígitos escondido em prompts de 8, 16 e 32 mil tokens. A alocação de 32 mil tokens funciona; a memória útil, nenhuma.
• Conversa: perguntado em português sobre a cor do céu, respondeu repetitivo e errado; pedido em inglês de café da manhã virou uma docstring em Python repetindo “oats” até o limite de tokens. Numa troca curta lembrou que o gato se chamava Pipoca, e mesmo assim respondeu com frase inteira apesar do pedido de “só o nome”.

O SFT final só tinha respostas de código, sem conversa, sem trajetória de ferramenta, sem recuperação de erro. A tendência de responder qualquer coisa com Python é coerente com isso, e o relatório toma o cuidado de dizer que a causa não foi isolada.

O que faltaria pra um agente simples no OpenCode

O relatório fecha com estimativas de engenharia, sem promessa de taxa de acerto. Pra chegar num agente que resolve tarefa simples de programação dentro do OpenCode, nesta ordem:

1. Ensinar uso de ferramenta no modelo forte. Entre 10 e 30 mil trajetórias curtas e verificadas de repositório (ler, editar, checar), misturadas com 30 a 50% de código pra ele não desaprender. Um a três dias de engenharia e de duas a seis horas iniciais de treino.
2. Corrigir os próprios erros. Coletar centenas a alguns milhares de falhas do modelo em tarefas de treino, reconstruir o estado do arquivo, verificar as correções e treinar mascarando a ação errada. Mais um a três dias de coleta e de duas a oito horas de treino.
3. Devolver a conversa. Uma mistura equilibrada de conversa, ferramenta e código contra o checkpoint congelado, pra ele parar de responder tudo com Python e conseguir trocar de tarefa. Uma a quatro horas de treino.
4. Contexto longo de verdade. Só depois das tarefas curtas passarem: 4 mil, 8 mil, e só então 16 e 32 mil, com trajetórias reais de compactação e troca de sessão. Um a dois dias de engenharia e de 6 a 24 horas de treino, medindo memória a cada janela.
5. Mais fundação, com dados melhores. Cada 10 bilhões de tokens a mais custam entre 93 e 139 horas nesta GPU, antes de preparação e avaliação. E repetir a mesma mistura de 3,5 bilhões não vale a pena: precisa de mais código educativo único.

Nenhum desses passos foi executado. Não há evidência de que um número fixo de horas a mais produza um agente confiável, e o relatório é explícito nisso. O que o exercício estabeleceu foi a distância: entre gerar uma função plausível e agir de forma confiável num repositório existe um abismo que parâmetro e contexto alocado sozinhos não cruzam.

O mais forte que saiu daqui foi a curva medida de 0 pra 65 em dez bilhões de tokens, e três contraexemplos concretos: sintaxe não é semântica, suporte a protocolo não é habilidade com ferramenta, e capacidade de contexto não é memória.

O futuro é menor e mais especializado

Depois de onze dias olhando pra dentro de um modelo, a minha leitura do mercado ficou mais firme. Modelo de fronteira generalista vai continuar existindo e vai continuar sendo caro, e o retorno de cada bilhão a mais de parâmetros é cada vez menor. Eu já escrevi que os modelos crus convergiram e que o ganho recente veio do harness. O exercício me deu a outra metade do argumento.

A mistura de especialistas é a indústria admitindo isso por dentro. Se o gpt-oss de 117 bilhões acorda 5 bilhões por token, o que você está usando numa pergunta de contabilidade é um modelo de 5 bilhões escolhido por um roteador. A pergunta que fica é por que carregar os outros 112 bilhões, de arte, cinema, meme e física de partículas, num servidor de escritório contábil.

Imagine um modelo local, feito pra contadores. Ele conhece o plano de contas, a legislação tributária do país, os formatos de arquivo da Receita, o jargão. Ele dispensa parâmetros sobre tudo que um contador não precisa, e pode rodar no PC do escritório, com os dados do cliente dentro da sala.

Os exemplos já existem em outras áreas: o MedGemma de 4 bilhões pra saúde, o SaulLM de 7 bilhões pra direito, o Fin-R1 de 7 bilhões pra raciocínio financeiro. Em 2023 o BloombergGPT precisou de 50 bilhões de parâmetros e 1,3 milhão de horas de A100 pra fazer finanças; hoje um ajuste em cima de um modelo aberto de 7 bilhões faz o mesmo papel por uma fração.

O que mudou pra isso virar viável foi o agente. Um modelo especializado de 2023 precisava saber tudo de cor, porque a única coisa que ele fazia era completar texto. Um modelo de 2026 precisa de uma base: raciocínio suficiente, capacidade de sustentar uma tarefa longa, chamada de ferramenta confiável, cache de prompt. O resto, a legislação que mudou ontem, o documento do cliente, a tabela que ele nunca viu, ele busca com ferramenta e internet na hora, e preenche as lacunas do treino em tempo de uso.

A NVIDIA publicou em 2025 exatamente essa posição: modelos pequenos são suficientes, mais adequados e mais baratos pra maioria das chamadas de um agente, com o modelo grande chamado só quando a conversa aberta exige. A Apple já roda um modelo de 3 bilhões no aparelho com protocolo de ferramentas e adaptadores por tarefa.

É o mesmo raciocínio dos modelos de decisão que eu testei semana passada: um classificador de 4 bilhões treinado pra uma tarefa bate um modelo de chat genérico do mesmo tamanho nela, numa fração do tempo de resposta. Em vez de tentar caber o mundo inteiro num modelo maior, cabe o domínio num modelo menor e deixa o harness buscar o mundo quando precisar.

E o que o meu modelo de 337 milhões me ensinou é o tamanho do “suficiente” nessa frase. Ele sabe a sintaxe e sabe o nome das coisas. O que falta, semântica, ferramenta, memória, é exatamente o que separa um gerador de texto de um agente, e isso ninguém treina em duas semanas numa placa de vídeo. Treina em meses, em cluster, com trilhões de tokens, e depois especializa.

O código está no repositório, com o relatório de fechamento inteiro, pra quem quiser pegar de onde eu parei. É só pra estudo. E foi o melhor estudo do ano.

O livro consolida quase tudo que eu escrevi sobre IA aqui no blog de fevereiro a outubro de 2026: todas as experiências, os projetos Frank, os benchmarks, bilhões de tokens gastos e centenas de horas de trabalho ao longo de oito meses, reorganizados num formato mais fácil de ler do que uma pilha de posts datados. Saiu em português e em inglês.

Aviso importante: isso é um preview. O livro ainda está em andamento e vão sair novas versões até eu considerar ele pronto. Se você achar qualquer coisa errada, de erro de digitação a fato, abra uma issue no GitHub. O rastro que eu descrevo abaixo existe justamente pra que a correção chegue no parágrafo certo.

Este texto é sobre o bastidor técnico. Como se transforma 131 posts de blog, escritos ao longo de meses, com opiniões que mudaram no caminho, num livro com começo, meio, fim, apêndice, glossário e bibliografia. E como se faz isso com agentes sem perder o controle do que o livro diz.

O que tem dentro

Cinco partes, cada uma respondendo a uma pergunta que as pessoas vivem me fazendo:

1. O que é essa coisa, afinal. Ela é inteligente? A AGI está chegando?
2. A maratona. Funciona de verdade, ou é tudo demo?
3. Números e propaganda. Qual IA é a melhor? Dá pra acreditar nos anúncios?
4. Quem fica com as chaves. É perigoso deixar ela mexer nas minhas coisas?
5. E o meu emprego? Ela vai me substituir? O que vem depois?

São 20 capítulos e dois interlúdios, mais prefácio, um “como ler”, um “antes de começar” dizendo o que o livro deixa de explicar e onde aprender, epílogo e posfácio. Depois vêm dez apêndices (a máquina por dentro sem matemática, leituras pra ir mais fundo, como estudar com a IA do lado, três bolhas, linha do tempo, kit mínimo pra usar agente com segurança, ai-memory, como ler um benchmark ou um anúncio, os projetos do ano, e os bastidores pra quem programa), as fontes, os créditos de imagem, um glossário de quase 150 termos e mais de 300 referências em ABNT. A edição impressa passa de 500 páginas em 6 por 9 polegadas; a de tela, uns 475. São mais de 50 figuras, todas com ficha de origem.

O público é diferente do blog. O livro foi escrito pra quem está ansioso ou confuso com IA: o profissional com medo de ser substituído, o pai que leu que a AGI chega em dois anos, o gerente a quem estão vendendo uma “transformação por IA”. A maioria não programa. Isso muda a voz, e eu volto nisso.

O problema: meio milhão de palavras que discordam entre si

Em 12 de outubro publiquei a síntese do ano, que virou o capítulo 20. No dia 13 comecei o livro. Eu tinha 131 textos de 2026 no blog, quase meio milhão de palavras, de benchmark de modelo a carteira de bitcoin.

Reorganizar isso à mão levaria meses. E tem um problema pior que o volume: eu mudei de opinião durante o ano. Refiz o benchmark várias vezes, corrigi custos, troquei de ferramenta, e um post de fevereiro contradiz um de setembro com toda a naturalidade. Um livro que simplesmente colasse os posts em ordem seria um livro que se contradiz.

Então fiz o que o livro inteiro descreve: entreguei o trabalho braçal pra agentes de código, e fiquei com a parte de decidir, montar o processo e conferir. O processo é o assunto deste texto.

Passo 1: um inventário lacrado

A primeira coisa foi um script que lê os 131 posts e grava, pra cada um, o hash SHA-256 do arquivo em português e do arquivo em inglês, mais o commit exato do repositório do blog de onde tudo foi lido. Se uma vírgula muda num post, o hash muda junto. Esse arquivo é gerado por máquina e nunca editado à mão.

Depois, um agente leu cada post e preencheu um formulário fixo, com esquema definido em YAML: a tese em uma ou duas frases, as afirmações que um livro precisaria conferir, quais delas envelhecem rápido, que medo de leitor leigo o texto responde, o que cortar. Cada análise leva o hash do post de onde saiu.

Dos 131 textos, 96 tinham IA como assunto central ou com peso relevante. Os outros só entraram quando ensinavam alguma coisa específica, e cada post sobre IA deixado de fora tem o motivo anotado no arquivo de estrutura. Um script reprova a estrutura se qualquer post de IA estiver sem destino.

Linhagem: quem substitui quem

Pra resolver o problema das contradições, existe um mapa de linhagem. Ele diz qual post substituiu qual, o que ainda dá pra aproveitar do mais velho, e quais correções vindas dos projetos de referência (o repositório do benchmark, o do ai-memory, o do ai-jail, as anotações do meu servidor de casa) se aplicam a cada texto.

A regra pros capítulos é contar o estado mais recente e, quando a mudança ensina alguma coisa, contar a mudança. “Em junho eu achava X; em julho os números diziam Y” é história. Imprimir o número velho como se fosse atual é erro, e o verificador trata como erro.

Passo 2: a estrutura é dado, e gera a configuração

Das análises saiu uma proposta de estrutura: cinco partes, cada uma respondendo a um medo do leitor, vinte capítulos, dois interlúdios. Eu li, mexi e aprovei. Algumas peças entraram a meu pedido, como o “antes de começar” e o apêndice sobre a máquina por dentro.

Essa estrutura vive num único arquivo YAML, e ele é a fonte da verdade. Cada capítulo tem lá o id, o título, a cena de abertura, a pergunta que responde, o arco, a lista de posts de origem e as ideias de figura. A configuração do Quarto, que monta o livro, é gerada a partir desse arquivo por script. Ninguém edita a configuração na mão.

Isso importa porque mudança estrutural é onde livro quebra. No meio do caminho eu mudei o corte: os textos de janeiro saíram, e a história ficou entre fevereiro e outubro. Dez posts sumiram da base.

Três capítulos precisaram de cena nova, uma dúzia de unidades precisou de reparo pequeno, e o estrago difícil de ver estava em outro lugar: uma frase num capítulo intocado dizendo “os cinco revisores do capítulo 5”, a linha do tempo, o apêndice de projetos, rótulos de gráfico, cada tradução. Por isso existe um script de impacto que, antes de qualquer edição, lista cada parágrafo, figura, referência e tradução que depende de um post.

Passo 3: um capítulo piloto vira contrato

Antes de escalar, um capítulo piloto. Escolhi o capítulo 5, sobre os primeiros dez por cento de um projeto, e ele serviu pra calibrar a voz e descobrir as dúvidas que um agente teria no meio do caminho. Cada dúvida resolvida virou uma regra escrita.

Essas regras foram pra um documento de contrato que todo agente lê antes de escrever, junto com três coisas:

• o guia de voz do livro, que herda as regras do blog (o meu WRITER.md, o humanizer e a minha checklist de acabamento) e só adiciona o que muda quando o texto sai de um post datado e vai pra um livro que um leigo segura na mão;
• um arquivo de continuidade, dizendo qual capítulo explica cada conceito e como cada personagem se chama, pra ninguém explicar “janela de contexto” cinco vezes;
• a estrutura inteira, pra cada agente saber o que os outros capítulos cobrem.

Além das regras de voz que já existiam (capítulo abre numa cena com data, lugar e algo em jogo, nunca numa definição; fecha num gancho pro próximo, nunca em “neste capítulo vimos”), algumas das regras que saíram do piloto, pra dar o gosto:

• quando o resumo do capítulo e o post discordam num detalhe, vale o post;
• o capítulo que é dono de um conceito explica direito; se o termo aparece antes na ordem de leitura, ganha meia frase de glosa e um ponteiro, nunca uma segunda explicação;
• fato verificado na internet ganha citação mesmo que o post original não tivesse link;
• nome de modelo e produto na grafia do fornecedor, mesmo quando o blog abreviou.

É o arquivo de instruções de projeto que eu descrevo no capítulo sobre como falar com a máquina, na escala de um livro. Quem já fez um AGENTS.md pra uma base de código reconhece tudo.

Passo 4: rascunhos em paralelo, contradições esperadas

Com o contrato pronto, os capítulos foram rascunhados em paralelo, um agente por capítulo, em duas levas: partes I e II primeiro, depois III a V, pra que os capítulos de trás pudessem construir em cima dos da frente. Cada agente recebia o brief do seu capítulo, as análises, os posts completos, a linhagem e os arquivos dos projetos de referência que precisasse.

Agentes trabalhando ao mesmo tempo se contradizem, e isso aconteceu. Um capítulo dizia que o FrankMD teve uns 130 commits em três dias; outro, que teve 212 em 19 dias. Os dois números vinham dos posts e estavam certos, só que eram janelas diferentes. Um registro de integração juntou esses conflitos, e a regra virou explicitar a janela em cada capítulo.

Depois dos rascunhos vem a passada de integração, com outro conjunto de agentes, cada um dono de um grupo de capítulos e proibido de tocar nos outros. O trabalho deles: aplicar o registro de conflitos, cortar conceito explicado duas vezes, conferir que cada callback bate com o que o outro capítulo de fato diz, garantir que o último parágrafo de um capítulo leva pro primeiro do seguinte, e refazer a conferência de fatos assumindo que o rascunho está errado.

Pra ler as emendas, o build gera um arquivo de “costuras”: o parágrafo final de cada unidade ao lado do parágrafo inicial da próxima. É a leitura mais rápida que existe pra achar onde o livro deixa de parecer um livro só.

Passo 5: uma marca invisível por parágrafo

Esta é a parte que eu acho mais útil do projeto inteiro. Cada parágrafo do livro, no arquivo de origem, carrega um comentário dizendo de onde veio:

<!-- src: 2026/09/28/llms-sao-boas-em-reproduzir-o-que-existe-e-coisas-novas -->
Todo LLM foi treinado só no que é público...

<!-- src: original -->
Texto novo, escrito pro livro.

<!-- src: ref:ai-jail/README.md -->
Fato conferido no projeto de referência.

A marca some na hora de montar o livro, por um filtro Lua do Pandoc, então o leitor nunca vê. Ela serve pra manutenção. Eu edito post depois de publicado o tempo todo, e o livro precisa acompanhar.

O comando rake drift refaz o inventário, compara os hashes, e lista os capítulos que dependem de um post que mudou, com o diff do post desde o commit em que o livro o leu pela última vez. A marca leva direto aos parágrafos que saíram daquele post, e só eles precisam de revisão. Resolvido, um script grava o novo hash e o commit.

Exemplo real, de hoje. Removi do post sobre engenharia reversa um parágrafo sobre um vídeo do Linus Tech Tips. O drift apontou o capítulo 19 e um apêndice; o diff mostrou que aquele trecho nunca tinha sido usado no livro; dois comandos depois, os dois estavam carimbados com o hash novo. Sem a marca, eu teria que reler dois capítulos pra descobrir que não precisava mudar nada.

A bibliografia faz o mesmo papel pras fontes externas: cada referência anota qual post a citou. E as imagens têm cada uma a sua ficha de origem.

Passo 6: o que a conferência pegou

Cada número, data e nome foi conferido contra três oráculos: os posts, os projetos de referência e fontes primárias na internet, com o mesmo prompt de checagem adversarial que eu uso nos artigos do blog. A lista completa está no posfácio do livro, e boa parte das correções é do meu próprio blog:

• no review de março do mini-PC com Strix Halo, eu tinha separado 96 GB de memória pra GPU; em abril baixei pra 64, e posts posteriores ainda diziam 96. O livro usa 64 pra tudo depois de abril;
• um defeito na contagem de uma das ferramentas do benchmark subestimou de 40 a 90 vezes o custo das execuções feitas nela antes de agosto. O livro não cita nenhum desses custos;
• no texto de junho sobre o Claude Fable 5, escrevi que ele custava dez vezes mais que o Opus 4.8 por execução. Refazendo as contas em julho, com os tokens lidos do cache incluídos, o Fable custava quase o dobro. O post ainda diz dez vezes; o livro conta o número errado e a correção;
• num texto de março, escrevi que a Anthropic tinha comprado o Bun no fim de 2024. O anúncio é de dezembro de 2025;
• um resumo de capítulo, escrito por agente, dizia que a trava de assinatura do Claude Code caiu em menos de um dia depois do vazamento. O anúncio saiu umas 30 horas depois, e o livro diz “no dia seguinte”.

Os rascunhos saíram rápido. A confiança no texto veio da conferência. E a fonte vence o resumo, inclusive quando o resumo vem da máquina.

Passo 7: capítulo com erro não passa

Por cima de tudo roda um verificador automático, o equivalente da integração contínua. São scripts em Ruby, só biblioteca padrão, encadeados num Rakefile, mais o que eles chamam por fora: o verificador de gráfico é Python porque vive dentro do matplotlib, a auditoria de página usa o poppler, e o epubcheck precisa de Java:

• um linter de capítulo reprova travessão, frase proibida pelo guia de voz, URL solta no meio da prosa, chave de citação desconhecida, parágrafo sem marca de origem, e avisa de parágrafo longo demais;
• um doctor confere que toda referência cruzada, citação, termo de glossário e figura existe, que a proveniência bate com o inventário, que nenhum post anterior ao corte vazou, que as traduções estão em dia, e faz uma heurística de callback: uma frase que aponta pra outro capítulo usando nomes que aquele capítulo já não contém;
• uma auditoria de página abre o PDF pronto e procura bloco partido entre páginas, título órfão no pé da página, página quase vazia, imagem grande demais, linha estourando a margem;
• um verificador de gráfico procura rótulo que vazou da caixa;
• o epubcheck valida o EPUB 3;
• um relatório de estilo pra copidesque: trecho repetido entre capítulos (consequência inevitável de posts que repetem a mesma tese por ângulos diferentes), frase recorrente, palavra usada demais, variante de termo, comparativo mal formado em português.

E os scripts têm teste. Uma suíte de quase 170 testes monta um livro de mentira num diretório temporário, com cinco posts falsos num repositório git falso, e confere que cada ferramenta pega o problema que deveria pegar. Quando um bug é corrigido, entra o teste que teria pegado ele, com um comentário dizendo qual regressão protege. Roda no CI antes de cada build.

A pipeline de montagem

A toolchain é Quarto, que embute Pandoc e Typst, fixada em versão dentro do repositório. Sem LaTeX. Um único rake build produz, da mesma árvore de arquivos Markdown:

Português e inglês são perfis do Quarto, gerados do mesmo arquivo de estrutura. Citações saem de um YAML em formato CSL compartilhado pelas duas edições, com um estilo ABNT ajustado pra português. O glossário é um filtro Lua: cada termo vem marcado no fonte onde aparece, e o filtro liga a marca à entrada, expande a sigla na primeira vez e gera a página.

O Typst resolveu uma coisa que eu achava que ia me custar semanas: PDF com cara de livro tipografado, hifenização em português, ligaduras, sem a dor de TeX. A auditoria de página depois do build pega o que o motor deixou passar, e um rake fit recompila apertando capítulos que terminam numa página quase vazia.

As figuras

Toda figura é código ou tem ficha. Gráficos e diagramas de caixas e setas são scripts de matplotlib, 43 deles, cada um com a indicação do capítulo de onde vieram os dados, e com os rótulos em português e em inglês dentro do próprio script: o mesmo gráfico sai nas duas línguas. O caminho pra diagramas em D2 existe no repositório, e nenhuma figura do livro precisou dele.

As ilustrações conceituais foram geradas por IA, com o modelo, o pedido e a data de cada uma gravados na ficha de crédito, e o livro declara isso. A regra que eu me impus: nenhuma imagem de pessoa real gerada por IA. Pessoas reais só aparecem em fotos com licença livre, com o crédito na legenda.

A capa é o robô retrofuturista de rosto cansado, ajoelhado numa Feira Mundial dos anos 1950, estudando a própria mão enquanto a multidão assiste. O pedido ao modelo descrevia a cena pra segurar três medos de uma vez: o fim da humanidade, perder o emprego, a máquina ficando consciente. A ficha da capa guarda o prompt inteiro. O rosto é o do Marvin, o personagem da minha newsletter, e um adesivo com a minha cara fica ao lado do nome.

As manhas de transformar post em livro

Transformar blog em livro é uma lista de conversões mecânicas, e cada uma tem pegadinha:

• Link vira citação. Cada link externo virou uma entrada de bibliografia, e a frase precisa ficar de pé sem o link. Link pra outro post meu virou referência cruzada pro capítulo que agora cobre aquilo, ou sumiu. Nunca uma URL na prosa.
• “Hoje”, “ontem”, “semana passada”, “atualização:” viraram data absoluta. O livro vai ser lido em 2028 também.
• Versão de modelo, preço, nota de benchmark ficaram como fotografia datada (“em setembro de 2026, o melhor…”), e quando um post posterior substituiu o número, o livro conta a mudança em vez de imprimir o número velho.
• Dump de código, passo de instalação, print de terminal foram cortados. No máximo um trecho de 3 a 8 linhas quando o código é o ponto; o passo a passo foi pra apêndice.
• Título de post, que é feito pra busca (“Vibe Code: fiz X em dois dias”), virou título literário curto, com o assunto no subtítulo.
• Repetição entre posts, a mesma tese por muitos ângulos, é dita uma vez, no lugar certo, e os capítulos seguintes constroem em cima.
• Chamada pra ação, “assine”, “comente”, cortadas.
• A ponta afiada mira na propaganda, nunca no leitor. O post “Você é um idiota se acredita…” virou um capítulo sobre como os anúncios funcionam. O leitor que acreditou no anúncio é a pessoa que o livro quer ajudar.
• Todo termo técnico é explicado uma vez, na primeira aparição no livro, e vai pro glossário.

E a mais importante de todas: o livro lê como história em primeira pessoa, com o ano como espinha dorsal. A informação chega quando a narrativa precisa dela, em vez de seguir ordem de enciclopédia. Isso é o oposto de como um blog é escrito, e foi a regra que mais trabalho deu pros agentes seguirem.

A edição em inglês

A edição em inglês, Competent Enough, só começou depois que eu aprovei a em português. Cada unidade traduzida grava o hash do arquivo em português de onde saiu, e onde o livro segue um post meu que já tinha versão em inglês no blog, a tradução usa a minha própria redação em inglês em vez de traduzir de novo.

O drift também funciona por língua: se eu mudo um parágrafo em português, ele aponta a unidade em inglês que ficou velha, e só os parágrafos marcados são retraduzidos. Os gráficos com texto são gerados de novo em inglês a partir dos mesmos scripts, e a capa em inglês é composta por script em cima da mesma arte.

Lançar é empurrar uma tag

Lançamento é uma entrada no CHANGELOG e um git push de uma tag vX.Y.Z. Um workflow do GitHub Actions roda os testes, monta as duas edições em todos os formatos, valida o EPUB, roda a auditoria e publica a release com os arquivos. Ele apaga todas as releases menos as duas mais novas, e mantém as tags. É assim que a página oficial sempre aponta pra versão atual.

O repositório é público, e isso trouxe uma pegadinha própria: as anotações do meu servidor de casa são fonte de alguns fatos, e são privadas. Os marcadores de origem citam esses arquivos por apelido, o mapa de apelidos fica fora do git, e um hook de pré-push bloqueia qualquer arquivo ou mensagem de commit que contenha nome de repositório privado, host ou IP.

O copidesque: o que a máquina de checagem deixa passar

Lint, doctor, auditoria de página e testes pegam problema estrutural. Eles deixam passar o que um livro escrito por muitos agentes, cada um vendo poucos capítulos, sempre sofre: a mesma frase ou anedota reaproveitada em três capítulos, tom que deriva, terminologia inconsistente, concordância escorregando. Pra isso existe um procedimento de copidesque, que roda uma vez por versão, em três passos do mais barato pro mais caro.

Passo 1, mecânico e quase de graça: o relatório de estilo que eu citei acima. Sequências de sete palavras ou mais que aparecem em mais de uma unidade, ou seja, frase reaproveitada e anedota recontada; frases feitas de quatro a seis palavras usadas em muitos capítulos, que são bonitas como callback e viram tique quando se repetem; palavra usada muito mais num capítulo do que no resto; variante de termo (“e-mail” e “email”, “Open AI” e “OpenAI”); e uma heurística de concordância em português. O relatório é uma lista de trabalho, e nada muda sozinho.

Passo 2, a leitura corrida: um agente só de leitura por parte do livro, cada um lendo as suas unidades em ordem, do começo ao fim, com uma folha de estilo compartilhada (nomes, grafias, termos, frases recorrentes vindas do passo 1). Cada um produz um relatório ranqueado, sem editar nada: erro de digitação e gramática primeiro, depois inconsistência com a folha de estilo, repetição que o leitor notaria, trecho em que um leigo tropeçaria, e ritmo só nos piores casos. Um script valida os relatórios, confere que cada trecho citado existe mesmo na unidade, numera os itens e resume.

Daí vem a triagem, feita por mim com um agente editor, e a aplicação pontual de cada item aprovado, com as mesmas regras da passada de integração. Modelo mais barato faz a revisão; trecho difícil vai pro modelo forte. Orçamento aproximado: dois a três milhões de tokens por língua.

A regra mais importante desse passo é “fato se confere, não se pergunta”. Qualquer item que dependa de um número, data, nome ou comportamento de ferramenta é resolvido pelo editor contra a fonte da verdade antes de chegar em mim: primeiro o post apontado pela marca de origem do parágrafo, recalculando totais; depois o código ou os dados por trás da afirmação, nos meus repositórios; depois registro público.

Quando duas fontes discordam, a tarefa é descobrir por quê. “653 commits em 8 projetos” contra “692 em 4” eram dois recortes do mesmo trabalho, um deles sem o repositório privado da newsletter, e o texto passou a dizer o escopo em vez de escolher um número. Quando o post do blog está errado, o livro imprime o certo e o erro vai pra uma lista de errata do blog, pra eu corrigir na fonte.

Só chega em mim o que fonte nenhuma resolve: fato não publicado, intenção (“isso é ironia?”), preferência de corte ou de título, e contradição entre duas afirmações minhas sem registro pra desempatar. Cada pergunta vem com o que foi conferido e o que foi encontrado.

Passo 3, a minha leitura. A última e a mais valiosa. As notas entram no mesmo ciclo de aplicar, conferir e propagar pra edição em inglês.

A primeira rodada desse copidesque é o que separa o preview 2 do preview 3. Entre o que ela pegou: contagem de commits agora diz o escopo, um “mais de mil” que na soma era 984, o exemplo de votação do Frank Investigator que não batia com o código (figura redesenhada), as citações do David Sacks e do Pirate Wires no capítulo 14 conferidas contra os originais e corrigidas, a foto do Sam Altman trocada por uma de 2025. E na edição em inglês, uma leitura própria depois da ressincronização: decalque de português reescrito, termos do glossário usados do mesmo jeito, pontuação americana de citação do começo ao fim.

Leitores de mentira, feedback de verdade

Copidesque confere o texto. Ele deixa passar a pergunta que importa num livro pra leigo: a pessoa pra quem eu escrevi consegue ler isso até o fim, entende, e sai convencida? Pra responder, a passada seguinte foi uma revisão por leitores simulados.

O prefácio do livro tem uma seção “Pra quem eu escrevi”. Dela saíram cinco personas, cada uma com nome, idade, profissão e o medo que a trouxe ao livro:

• Marina, 38, contadora em Belo Horizonte, leu que o emprego dela “acaba em dois anos”, lê no celular à noite e quer saber o que fazer na segunda-feira;
• Roberto, 52, dono de loja de ferragens, o filho de 15 anos viu um vídeo sobre superinteligência e perguntou se era verdade; desconfia de hype, de “especialista” e de autor que se exibe;
• Carla, 44, gerente de operações numa empresa de logística, a diretoria contratou consultoria vendendo “transformação por IA”; quer uma decisão que ela possa tomar;
• Lucas, 24, desenvolvedor júnior há um ano, com medo de ter escolhido a carreira errada;
• Helena, 61, professora de história aposentada, sem medo nenhum, veio pelas histórias e perde a paciência com lista e manual.

Um agente por persona, só de leitura, modelo mais barato, lê o livro inteiro em ordem como aquela pessoa leria. A instrução é explícita: você é leitor, editor fica de fora; erro de vírgula já foi tratado, reporte só o que muda a experiência de leitura. Cada um devolve uma nota de 1 a 5 por capítulo, um comentário na voz da persona (“finalmente entendi por que o chatbot concorda comigo”, “me perdeu nas tabelas de benchmark”), no máximo 35 anotações classificadas em confuso, chato, reescrever ou lógica, e candidatos a corte. Custa uns 350 mil tokens por persona por leitura completa.

Um editor consolida: a matriz de notas por capítulo e persona e o padrão por trás dela, o que os leitores adoraram (pra proteger em qualquer edição), os itens de lógica, conferidos contra o texto e os posts antes de entrar na lista e corrigidos independentemente de voto, e os itens de clareza ranqueados por quantas personas levantaram. Nota de gosto de uma persona só é descartada. Daí eu decido, e o padrão recorrente vira regra numerada num documento de regras editoriais, com a origem e como é fiscalizado.

A primeira leitura disse o que eu desconfiava e deu a medida: histórias e ferramentas práticas funcionam pra todo mundo; o miolo cheio de medição, os capítulos 11 a 13, perde quem não programa, com nota média entre 2,2 e 2,4. “Afiado quando conta o que aconteceu com ele, me perde quando conta o que mediu”, resumiu a Helena, por todos os cinco.

E os cinco pegaram as mesmas falhas de argumento. A conclusão do capítulo 20 ia além da evidência: dizia “os números dizem que ela não vai ficar mais inteligente” apoiada num benchmark de programação que o próprio capítulo chama de saturado. O capítulo 9 argumentava de um jeito que nunca perde: toda falha do agente era culpa do pedido. Quatro dos cinco foram mandados pro capítulo errado pelo “como ler”.

Isso virou as primeiras regras:

• toda afirmação com o escopo do que foi medido;
• nenhum argumento que não possa perder;
• opinião marcada como opinião;
• o lado contrário na forma mais forte antes de rebater;
• o livro obedece às próprias lições.

Uma rodada só é pouco, porque edição conserta o problema velho e cria o novo. Na segunda rodada, uma frase de desculpa colocada ao lado de uma contradição (“eu sei que isso parece bater de frente…”) fez os cinco leitores notarem a contradição que antes três tinham deixado passar. Virou regra: conserta o desenho, e a desculpa fica fora. Então o processo é em rodadas: ler, editar, ler de novo com as mesmas personas e leitura nova, proibidas de abrir os relatórios anteriores pra evitar ancoragem, e um script compara as rodadas.

A nota média é ruidosa (um capítulo intocado oscila 0,6 entre leituras), então o critério de parada é outro: os problemas apontados deixaram de voltar e nada novo chega a três leitores. Na terceira rodada a curva achatou e a revisão parou ali, com uma lista de pendências pra minha própria leitura. O que mudou no caminho: uns 8 mil palavras de caderno de laboratório saíram dos capítulos pra um apêndice novo, “Para quem programa: os bastidores”, cada parágrafo levando a marca de origem junto; a lista de leituras virou apêndice; a seção sobre o Genesys PI foi estacionada, guardada fora do livro enquanto a verificação está pendente; o capítulo 19 ganhou o título que o argumento dele sustenta; cada capítulo abre orientando o leitor antes do primeiro jargão; e o epílogo ganhou uma lista do que fazer nesta semana, por tipo de leitor. Custo das três rodadas: uns 5 milhões de tokens de leitura mais uns 3 milhões de edição e ressincronização do inglês.

O narrador ganhou passado

Com o argumento no lugar, faltava substância na primeira pessoa. O narrador do livro era o Akita de 2026, e eu tenho trinta anos de história que explicam por que eu penso o que penso: o estouro da bolha pontocom visto de dentro, cinco anos integrando SAP em empresa grande, os avisos sobre a bolha de contratação que eu dei em vídeo em 2019, 2020 e 2022, o “Não terceirize suas decisões”. Tudo isso está nas transcrições dos 149 episódios do Akitando, publicadas aqui no blog entre 2018 e 2023.

O processo foi o mesmo do resto do livro, em miniatura. Agentes de extração leram 23 episódios na íntegra, com um formulário: fatos biográficos com a citação literal e o que os verificaria, fatos sobre o mundo, posições recorrentes nas minhas palavras, e ganchos, ou seja, o lugar exato do livro onde uma ou duas frases dessa história sustentam uma afirmação de 2026. Daí saiu um perfil do narrador, que eu confirmei linha a linha, e um plano com uns 30 toques, a maioria de uma a três frases.

Antes de qualquer toque, mais de 140 afirmações tiradas dos episódios passaram pela checagem. Ela corrigiu o livro e corrigiu a mim: a bolha de contratação começou por volta de 2010, com o juro perto de zero, e o meu post de fevereiro dizia 2014; a pontocom estourou entre 2000 e 2002; as demissões de 2022 foram umas 165 mil. E achou erro em episódio antigo que o livro nem usa, que foi pra uma lista de errata do blog.

Os toques entraram onde a experiência vira evidência: a semana de 2001 em que a minha pontocom fechou e um mentor me chamou pra uma consultoria SAP; os anos de SAP por trás da afirmação de que o modelo é cego pras regras privadas de uma empresa; os avisos datados da bolha ao lado do erro admitido, porque em 2022 eu esperava uma segunda perna de queda em 2023 que a onda de IA cancelou. Dois apêndices novos saíram daí: “Três bolhas”, com os números verificados da pontocom, da bolha de juro zero e da onda de IA, e “Como estudar com a IA do lado”, a partir do episódio mais assistido do canal.

Esses episódios são fonte de fundo, e o drift passou a vigiá-los como vigia os posts de 2026. Depois veio uma checagem reduzida com as mesmas cinco personas, só nos capítulos tocados, com três perguntas a mais: a história do narrador deixa o argumento mais convincente, e onde? Alguma passagem parece exibição ou “eu avisei”? Alguma coisa sobre o narrador se contradiz?

Os cinco disseram sim pra credibilidade, com uma condição: a história convence quando é evidência que o leitor consegue checar, o aviso com data ao lado do erro admitido, e convence menos quando vira currículo, o que bate de frente com o próprio livro, que diz “currículo não é argumento”. Virou a regra 21: a história do narrador entra como evidência, e credencial fica de fora.

Três ou quatro leitores marcaram as mesmas linhas como exibição, e elas saíram: “Os avisos têm data”, “mais de trinta repositórios públicos”, “o mais visto do meu canal”. As linhas de autodepreciação e os erros admitidos, todos contaram a favor. E a checagem achou contradições que eu mesmo não tinha visto: o prefácio dizia “fim dos anos 90” e o capítulo 18 dizia 1996; um capítulo falava em “oito meses” e outro em “um ano de uso diário”, e foram consertadas uma a uma.

Acessibilidade também faz parte do build

Um EPUB abrir no Kindle não quer dizer que ele seja acessível. Este livro tem dezenas de diagramas, gráficos e tabelas. Sem trabalho adicional, boa parte do argumento simplesmente desaparece pra quem usa leitor de tela.

Por isso a pipeline agora trata acessibilidade como contrato de publicação. Cada uma das 55 figuras, nas duas línguas, ganhou um texto alternativo curto e uma descrição completa do que a imagem comunica. No HTML e no EPUB, a descrição detalhada aparece junto da figura; no PDF, entra como substituto semântico sem alterar a diagramação. Tabelas ganharam legendas, e o EPUB agora identifica no índice semântico onde começam o texto principal, o glossário, as referências e os créditos das imagens. O contrato de autoria está documentado no repositório.

Isso também não ficou dependendo da minha memória. rake check barra figura sem as duas descrições ou com alternativa longa demais. Cada build valida os dois EPUBs com EPUBCheck, DAISY Ace e verificadores próprios do projeto. A versão pra Kindle ainda passa por uma limpeza do CSS e dos ícones embutidos que costumam dar problema nos leitores da Amazon, mas o script se recusa a remover qualquer regra da qual o conteúdo tenha passado a depender.

Ferramenta automática nenhuma certifica WCAG ou garante o comportamento de todo leitor do mercado. A revisão manual continua obrigatória. A diferença é que a acessibilidade agora faz parte do build e cada mudança precisa preservar esse contrato.

O que continua sendo meu

O repositório registra o primeiro commit e o rascunho de todos os capítulos no mesmo dia, 13 de outubro. São os primeiros dez por cento, os que impressionam e quase não dizem nada sobre o resto. Os outros noventa por cento são leitura, corte e correção, e essa parte é minha. Nenhum capítulo entra sem eu ler e aprovar, e o que eu mando refazer volta pro mesmo processo.

Qualquer um dos bons modelos de outubro de 2026 teria escrito rascunhos parecidos, porque modelo virou commodity. O que fez o processo funcionar foi o que está em volta dele: o inventário, o contrato escrito, o verificador automático, as fontes como oráculo, o rastro por parágrafo. É a mesma engenharia de software velha que eu defendo em cada capítulo, aplicada a texto.

Os agentes foram competentes o suficiente pra escrever o rascunho. Decidir o que ele dizia continuou sendo trabalho meu.

E, mais uma vez: fazer um livro com IA não é um prompt de “escreva um livro pra mim” e pronto. Eu tive que inventar o processo inteiro e pilotar o agente pra criar cada peça dele: os scripts, os testes, a consolidação dos posts, a estratégia narrativa, os objetivos, o que fica e o que sai, o copidesque, a checagem de fatos, o lançamento automatizado. Você precisa saber exatamente o que quer, e aí a IA ajuda muito. Quem não sabe o que um processo de publicação de livro envolve não vai fazer um livro de verdade, e mostrar isso era um dos objetivos que eu tinha ao criar este exemplo.

Baixe, leia, e me diga onde errei

As duas edições, em três formatos cada, direto do GitHub, sem cadastro. A versão atual é a 1.0.0 final, de 17 de outubro, com tudo que este texto descreve:

A versão mais recente, sempre, fica na página do livro e nas releases do GitHub.

É preview. Vai ter erro, e o processo acima existe pra que ele seja corrigido no lugar certo. Achou um, abra uma issue.

Essa foi a semana no X, e se você só lê manchete, é uma conclusão razoável. Este texto é pra quem quer saber o que cada uma dessas coisas faz de verdade.

Explodiu no dia 9, quando a conta abaixo resumiu o que um desenvolvedor de Atlanta, Brandon Thomas, vinha publicando desde o fim de setembro: sete clones de código aberto dos produtos principais da Adobe, escritos em Rust com ajuda do Claude Opus 5.5. Photoshop, Illustrator, Premiere, Lightroom, After Effects, InDesign, Acrobat. Tudo de graça, tudo feito em “sala limpa”, sem uma linha de código da Adobe. A conta que viralizou foi esta:

AI is now being used to recreate Adobe's software, a developer has released seven free, open-source apps as clean-room alternatives to Adobe's main tools:

- PhotoCraft → Photoshop
- VectorCraft → Illustrator
- FilmCraft → Premiere Pro
- LightCraft → Lightroom
- EffectCraft → After Effects
- DesignCraft → InDesign
- PrintCraft → Acrobat Pro

Built in Rust with help from Claude Opus 5.5, they run on Windows, Linux, and macOS under MIT/Apache licenses without using Adobe's source code.

— Pirat_Nation (@Pirat_Nation) October 9, 2026

Na mesma semana, o REA, “Reverse Engineer Anything”, passou de 100 mil estrelas no GitHub, ganhando dezenas de milhares por dia. A promessa da página: “viu uma feature num app que você quer no seu produto? Peça pro seu agente investigar com o REA e construir uma versão pro seu projeto”.

E quem acompanha retrogaming sabe que 2026 é o ano que não para de dar. Tem uma planilha comunitária tentando listar os ports não oficiais pra PC, com uns 100 jogos de Ship of Harkinian a Skate 3, e ela está sempre atrasada. O canal Video Game Esoterica publica port novo quase todo dia: Time Crisis decompilado do arcade, Daytona USA, Bloodborne.

A versão de Xbox One do Forza Horizon 2, presa lá desde 2014, roda em Windows. O AnyPS5 promete converter executável de PS5 em binário nativo de PC, e emuladores de PS5 como o KytyPS5 e o SharpEmu já rodam Astro Bot com gameplay de verdade. Boa parte disso com IA no meio, alguns abertamente vibe-coded.

Daí o consenso: programar, em geral, acabou. Todo binário é reversível e reutilizável, basta apontar o agente. Minha posição é que ficou muito mais fácil mesmo, que ainda está longe da bala de prata que as pessoas imaginam, e que o motor por trás disso, o LLM, parou de crescer exponencialmente. O resto do texto são os motivos.

TL;DR: engenharia reversa é uma disciplina de 40 anos com ferramenta madura, e a IA acelerou o trabalho braçal dela, com destaque pro retrô, onde o binário está disponível, é minúsculo e o alvo não se move. Os clones da Adobe são alpha com centenas de bugs abertos e print bonito. O REA é uma caixa de ferramentas que exige o binário na mão, Ghidra ou IDA instalados, e muito token. O que vale dinheiro hoje nem binário tem: é SaaS, nuvem, parceria com fabricante e décadas de ciência de cor. Reescrever o Bun, com o autor do projeto e 64 agentes, custou US$ 165 mil. Pule pra linha do tempo, pro REA, pros clones da Adobe, pro caso Bun, por que o retrô anda rápido ou pras respostas no final.

Antes de tudo: eu não gosto da Adobe

Pra ficar claro de onde eu falo. Eu detesto as práticas comerciais da Adobe tanto quanto qualquer um. Fui cliente pagante por anos, usei Photoshop e Premiere extensivamente, mais Lightroom e After Effects, e saí pelos mesmos motivos que todo mundo sai: assinatura compulsória, cancelamento com multa, preço subindo sem contrapartida.

E é exatamente por ter usado a fundo que eu sei o tamanho do que está dentro daquelas caixas. Quem acha que Photoshop é camada, crop e texto nunca precisou de prova de cor pra gráfica, nunca abriu um RAW de câmera cujo perfil de cor a Adobe mantém há vinte anos, nunca fez a conformação de material de cinema, o trabalho de reunir o material bruto da câmera pra finalização. Vou chegar lá, depois do básico.

Engenharia reversa não nasceu semana passada

Todo emulador que você já usou existe porque alguém abriu hardware, desmontou binário, farejou protocolo e, em alguns casos, quebrou criptografia. A disciplina tem jurisprudência, ferramenta comercial e uma história de décadas. Uma linha do tempo resumida, com os marcos que mais importam:

• 1982 a 1984: a Compaq reescreve a BIOS do IBM PC por engenharia reversa, e em 1984 a Phoenix vende uma BIOS licenciável feita em sala limpa, com um time que só lia a especificação. Nasce a indústria de PC compatível. Fonte.
• 1992: Andrew Tridgell cria o Samba farejando pacotes SMB. No mesmo ano, Sega v. Accolade e Atari v. Nintendo firmam nos EUA que desmontar código pra chegar em elementos funcionais é fair use, uso justo (a Atari perdeu o caso dela por outro motivo: mentiu pro Copyright Office pra conseguir o fonte).
• 1993: começa o Wine, que vira a base do Proton e de todo jogo de Windows que roda no Steam Deck hoje.
• 1999: UltraHLE roda jogos comerciais de N64 em velocidade real; o bleem! emula PS1, a Sony processa e perde as liminares, e o bleem! ainda assim fecha em 2001; o DeCSS quebra a proteção do DVD.
• 2000: Sony v. Connectix decide que copiar a BIOS do PS1 pra construir um emulador é uso justo.
• 2002 e 2003: nascem PCSX2 e Dolphin, os dois emuladores que vinte anos depois ainda são referência.
• 2007: o iPhone é aberto onze dias depois do lançamento. A Comissão Europeia obriga a Microsoft a documentar seus protocolos de rede, e a equipe do Samba recebe a documentação por 10 mil euros.
• 2010: o grupo fail0verflow mostra no 27C3 que a Sony assinou o firmware do PS3 com um nonce fixo, expondo a chave privada (o nonce é o número que deveria ser aleatório em cada assinatura). Dias depois, já em 2011, o geohot publica a chave, a Sony processa e faz acordo em março.
• 2011 e 2013: nascem RPCS3 (PS3) e Xenia (Xbox 360), os dois emuladores mais difíceis já feitos, por motivos que vou explicar.
• 2019: a NSA libera o Ghidra como código aberto. A decompilação do Super Mario 64 vaza e vira pública, e no ano seguinte aparece o port pra PC.
• 2021 e 2022: Ocarina of Time 100% decompilado depois de quase dois anos de trabalho; o Ship of Harkinian vira o port de referência.
• 2024: Mr-Wiseguy lança o Zelda 64: Recompiled, a primeira vitrine da recompilação estática de N64.
• 2025: Sonic Unleashed Recompiled traz o mesmo truque pro Xbox 360, convertendo PowerPC pra C++ e shaders pra HLSL.

Repare que a fase atual, decomp e recomp em escala, começa em 2019, bem antes de qualquer agente de código. A IA entrou numa linha de montagem que já existia.

As ferramentas

O ferramental também é maduro, e boa parte é gratuita:

• IDA Pro (Hex-Rays), o disassembler e decompilador comercial de referência, de mil a quase nove mil euros por ano, com uma versão gratuita limitada a x86.
• Ghidra, a resposta aberta da NSA, com decompilador e scripting, Apache 2.0.
• Binary Ninja, com uma edição gratuita e licenças de 200 a 3.500 dólares.
• radare2 e o Cutter, interface do rizin, que é um fork do radare2: a linha de comando e a interface abertas.
• x64dbg e WinDbg no Windows, GDB no resto.
• Frida, pra injetar código em processo vivo e observar o que ele faz.
• JADX pra Android e ILSpy pra .NET.

Guarde essa lista. O REA, que a gente vai ver daqui a pouco, é um embrulho em volta dela.

Como se desmonta um binário, na prática

Em princípio, todo binário é reversível. O processador precisa conseguir executar aquilo, então as instruções estão lá. O caminho é sempre o mesmo:

1. Desmontar: o binário vira assembly, uma instrução de máquina por linha. Isso é mecânico.
2. Decompilar: o assembly vira algo parecido com C. Ghidra e IDA fazem isso razoavelmente bem, com muito ruído.
3. Recuperar o que o compilador jogou fora: nome de variável, nome de função, tipos, estruturas, comentários. Nada disso sobrevive à compilação. Esse é o trabalho de verdade, e é humano.
4. Refatorar até virar código que uma pessoa consegue ler, manter e portar.

Os projetos de decomp de N64 fazem o passo 4 até o fim: o código em C deles, recompilado, gera byte a byte a ROM original. É assim que o Super Mario 64 virou um projeto com 135 mil linhas de C de código de jogo (uns 100 mil de código efetivo, mais meio milhão de linhas de dados de fase e modelo gerados), e o Ocarina of Time passou de 430 mil linhas. A recompilação estática pula parte disso: traduz as instruções do processador original pra C genérico, sem tentar entender, e troca só as partes que falam com o hardware. É mais rápido e o resultado é menos legível.

“Mas a IA não pode ler o binário direto?”

Alguém sempre pergunta: se é IA, pra que passar por C? Deixa o modelo ler o binário e construir em cima. A resposta curta é que LLM só sabe o que estava no corpus de treino, e corpus de binário pareado com código fonte é escasso, porque nenhum humano escreve assembly de produção há décadas.

A resposta longa é que existe literatura, e ela é instrutiva justamente por ser modesta. A linhagem vai de redes neurais de 2018 a modelos como o SLaDe (200 milhões de parâmetros, um por arquitetura e nível de otimização), o LLM4Decompile (até 33 bilhões) e o Nova. A Meta publicou um LLM Compiler que traduz assembly pra IR do LLVM. Os melhores resultados, em funções isoladas de benchmark, giram em torno de 60 a 65% de código que roda de novo e dá o mesmo resultado, caindo forte quando o compilador otimizou com -O3.

Dois estudos recentes mostram o estado real. O DecompileBench, com 23 mil funções reais, achou que decompiladores baseados em LLM produzem código mais legível e com metade da correção funcional dos decompiladores comerciais. E um trabalho de setembro de 2026 mediu que o refinamento por LLM da saída do Ghidra sobe a taxa de compilação de 75% pra 90% e derruba a fidelidade de comportamento de 74% pra 62%, com até uns 10% das funções com vulnerabilidade conhecida deixando de reproduzir a falha, ou seja, o bug sumiu sem ninguém pedir.

Resumindo o que existe: modelos pequenos, função por função, quase só x86-64 Linux, e os melhores são camadas de refinamento em cima do Ghidra, o que mantém o decompilador clássico no loop. Nenhum emulador, nenhum jogo, nenhum programa inteiro foi recompilado neuralmente. Enquanto alguém não inventa isso, você trabalha com a realidade, e a realidade inclui a camada intermediária de linguagem de programação e compilador.

Os assistentes de IA que existem pra isso em produção confirmam o desenho: o aiDAPal, plugin de IDA da Atredis, o Sidekick do Binary Ninja, os servidores MCP pro Ghidra. Todos são um LLM dando nome a variável e explicando função em cima do que o decompilador tradicional produziu.

O que o REA faz de verdade

Eu clonei o REA e li o código. Ele é um servidor MCP e uma CLI em TypeScript que embrulha as ferramentas da lista acima e as expõe pro seu agente de código: Ghidra, Hopper, IDA, JADX, Frida, Wakaru pra JavaScript ofuscado, Playwright pra capturar o que um site faz. O agente pede, o REA roda a ferramenta e devolve pseudocódigo, grafo de chamadas, strings e traces de IPC, cada resultado com um registro de evidência e uma lista de limitações.

Esse fluxo eu já tinha feito na mão, meses antes de o REA viralizar. Em julho eu coloquei o Fable 5 pra analisar o código do TikTok, do Clash of Kings e do gov.br: baixei os APKs, descompactei (APK é um zip), rodei o JADX nos .dex e deixei o modelo ler o Java que saiu do outro lado. Deu pra ver os endpoints, as permissões, os SDKs embutidos e como cada app monta o fingerprint do aparelho, aquele identificador persistente que sobrevive a limpar dados e reinstalar. O TikTok saiu como coleta de grau industrial, blindada contra auditoria; o gov.br, como exemplo de como fazer direito.

As três lições daquele post valem pro REA inteiro. Android é fácil demais de descompilar, e mesmo assim o resultado serve só pra análise estática, porque recompilar o app fica fora de alcance: os nomes vêm embaralhados pela ofuscação, faltam recursos e chaves de assinatura. A parte mais sensível mora em código nativo, .so em C e C++, que descompila em nada legível, e no TikTok é justamente aí que fica o miolo. E o que saiu daquele trabalho foi um relatório sobre o que o app faz, com ressalvas, e nenhum clone do TikTok. O REA embala esse mesmo fluxo num servidor MCP; as paredes continuam no mesmo lugar.

Quem fornece o julgamento é o LLM que você já paga. O REA fornece o encanamento determinístico e a proveniência. A frase “automatiza as heurísticas de engenharia reversa”, que circula por aí, não aparece em lugar nenhum do repositório; a descrição que o próprio projeto usa é engenharia reversa dirigida por agente, com evidência rastreável.

O que ele exige: o artefato na sua máquina (binário nativo, app Electron, assembly .NET, APK, firmware, captura de rede), Node 22.19 ou superior, e as ferramentas pesadas instaladas por sua conta. Ghidra é grátis; IDA, Hopper e JEB o README manda você comprar. Não tem chave de API do REA porque ele roda local, e o custo de token cai inteiro na sua assinatura de agente.

E esse custo é o detalhe que ninguém cita. O catálogo de ferramentas MCP do REA tem 2,3 MB de JSON, que entra no contexto do agente. O próprio projeto publica um experimento em que analisar o SQLite compilado em WASM, no caminho padrão, levou 42 chamadas de ferramenta, cinco minutos e 300 mil tokens de entrada. Um inventário completo de um app Electron como o Obsidian devolve quase 1 MB de JSON.

Tem issue aberta reclamando que inspecionar um app de Mac comum devolve de 80 a 230 mil tokens de uma vez.

O projeto é sério e vai longe: seis meses, 2.600 commits, mil arquivos de teste, versão 6.4 lançada em 11 de outubro. Também é instável: 190 issues abertas, várias mudanças incompatíveis a cada versão menor, subsistemas marcados como experimentais.

Os limites estão escritos no próprio repositório. O CONTRIBUTING exclui quebra de DRM, anticheat, licença e proteção comercial. O DISCLAIMER avisa que decompilação, reconstrução e análise assistida por IA “podem ser incompletas ou incorretas”. E até as instruções internas pra gerar as figuras do site dizem, com todas as letras: “nunca implique que o REA clona um programa automaticamente” e “nunca diga reconstrução completa, clone exato ou recuperação automática de código fonte”.

O REA é uma boa caixa de ferramentas pra quem já sabe fazer engenharia reversa e quer um agente segurando o Ghidra. Ele não é o botão “copia esse app pra mim”. Quem escreveu o projeto é o primeiro a dizer isso.

PhotoCraft: print bonito, alpha por dentro

O repositório do PhotoCraft foi criado em 30 de setembro. Em duas semanas, 54 mil estrelas, 8 versões lançadas e, no momento em que escrevo, mais de 800 issues abertas. O selo no README diz “early alpha”, e o próprio Brandon Thomas, citado pela Gizmodo, disse que não está nem perto de pronto. A imprensa que testou chegou na mesma conclusão: a Gizmodo chamou de “Photoshop cheio de bug, mas real”, e o OMG Ubuntu de “fac-símile superficial com falhas pronunciadas”.

As issues contam a história técnica:

• Qualquer imagem acima de 8.192 pixels sai do compositor de GPU e cai pra CPU, com pico de 6 GB de memória, porque o limite de textura do egui-wgpu é esse (issue 49, já fechada, e as que vieram depois, 1015 e 4017).
• Uma foto de 12 megapixels precisa de quase 800 MB só pra abrir, ajustar e exportar pela linha de comando (issue 1637).
• O gerenciamento de cor é rudimentar: espaço de trabalho só global, em vez de por documento, e sem transformação de visualização (issue 321). Dezoito issues mencionam CMYK, quinze mencionam perfil ICC.
• Quase cem issues abertas mencionam PSD. Camadas de matiz e saturação compõem diferente do Photoshop, e salvar por cima sobrescreve a imagem mesclada correta do arquivo original (issue 4089).
• Cinquenta issues abertas mencionam “crash”.

A interface lembra o Photoshop, então o print é compartilhável, e quem vê o print assume que é cópia carbono. Isso é esperado numa alpha de duas semanas. Com interesse, tempo e contribuição, parte disso vai sendo resolvida. E aí os contribuidores vão descobrir uma coisa que os projetos de N64 nunca enfrentaram.

O PhotoCraft hoje é aquela réplica de Ferrari montada em cima de um Fusca: a carroceria tem a forma certa, você tira uma foto e a maioria das pessoas diz “uau, uma Ferrari”. Aí você liga e sai o motor de Fusca. Se você se empolgou com a foto, o problema foi seu.

O alvo se move

Decompilar o Zelda de 1998 é mirar num alvo parado. A Nintendo não vai lançar o Ocarina of Time 2026 com formato de arquivo novo. Copiar um produto vivo é outra conversa, e a gente já viu esse filme.

Nos anos 90 e 2000 o alvo era o Microsoft Office. O StarOffice virou OpenOffice em 2000 e LibreOffice em 2010, e todos eles passaram anos correndo atrás de um formato binário, o .doc, que mudava de versão pra versão e só ganhou especificação pública em 2008, quando o jogo já tinha acabado. A parte comprovada dessa história está nos processos: a Comissão Europeia multou a Microsoft em 497 milhões de euros em 2004 por recusar informação de interoperabilidade, e em 899 milhões em 2008 por descumprir a ordem. O .docx só virou padrão ISO em 2008, numa votação tão controversa que países protestaram formalmente.

Levou mais de dez anos. E quando o formato finalmente abriu, o Office já não importava do mesmo jeito. O valor mudou de lugar: hoje são 400 milhões de assentos pagos de Office 365, 3 bilhões de usuários de Google Workspace e uns 41 milhões de assinantes de Creative Cloud. Ninguém quer instalar aquilo no desktop, e por isso ninguém tem o binário.

Fazer engenharia reversa do Google Docs é reescrever o produto do zero olhando só pra interface, porque o código que importa nunca sai do servidor. Depois que o mundo migrou pra SaaS, a maior parte do software proprietário virou jardim murado sem binário. Sem binário, não tem o que desmontar.

Dá pra fazer versões disso, claro. O Immich substitui o Google Photos pra uma pessoa ou uma família: backup do celular, reconhecimento de rosto, busca semântica, tudo no seu servidor. O que ele não replica é a infraestrutura e o corpus de treino que fazem a busca do Google ser a busca do Google. E a Adobe fez a mesma migração, em pedaços.

Photoshop é muito mais que camada e crop

Aqui entra a parte que eu conheço por ter pagado. As features que vendem assinatura hoje nem rodam no seu computador.

O Generative Fill e o Generative Expand rodam no Firefly, na nuvem, e consomem créditos generativos. Vários Neural Filters, segundo a própria documentação, precisam de internet porque o processamento é no servidor da Adobe. A seleção de objeto por IA tem, desde 2020, uma opção de processar na nuvem pra refinar o resultado. Isso tudo é código que não existe na sua máquina pra ninguém desmontar.

Depois vem o que está no binário, mas levou décadas e parceria pra existir. O Camera Raw carrega perfis de correção de lente e perfis de cor por câmera pra centenas de modelos, construídos ao longo de vinte anos e atualizados a cada lançamento. Clone nenhum adivinha isso. Ou tem o dado, ou não tem.

E tem a ciência de cor. O exemplo que eu sempre lembro é o GIMP e o CMYK.

O GIMP nasceu em 1995. O primeiro suporte nativo a arquivo CMYK chegou em 2022, e só de importação e exportação, com o pixel sempre em RGB. O GIMP 3.0, de 2025, ainda sem modo de edição em CMYK. Está no roadmap como trabalho em andamento.

Trinta anos de projeto aberto, com gente boa e motivada, e a gráfica ainda pede o Photoshop. Isso é o tamanho do buraco da ciência de cor, e nenhum agente de código inventa ciência de cor: ele reproduz o que está no treino.

Por que demorou tanto, se era a feature mais pedida? Porque o núcleo do GIMP nasceu com RGB de 8 bits por canal embutido em cada camada, modo de mesclagem e filtro. Suportar outro modelo de cor exigiu reescrever o motor de pixel inteiro, a migração pro GEGL, que levou a maior parte de uma década e só ficou pronta no GIMP 2.10, em 2018. O CMYK só pôde começar depois disso.

E CMYK é uma família de perfis de dispositivo, com quatro tintas, perfil ICC por impressora, limite de tinta e regra de geração de preto, e editar nele significa que toda a cadeia precisa calcular num modelo subtrativo de quatro canais e ir e voltar pelos perfis sem desviar a cor. Um desenvolvedor sozinho, por melhor programador que seja, sem experiência nessa área específica, vai sofrer pra implementar isso, porque o conhecimento está na gráfica e no laboratório de cor, e quase nada dele está em corpus de treino. No GIMP, quem levou a coisa adiante foram contribuidores que entendem de impressão, e mesmo assim foram anos. Ferramenta nova nenhuma atalha esse tipo de conhecimento.

E tem a camada que nem é técnica: licença comercial. Cor de gráfica é Pantone, e Pantone é uma biblioteca proprietária. Projeto aberto nenhum pode embarcar as paletas; os desenvolvedores do Inkscape chegaram nessa conclusão em 2005, e a Linux.com explicou o risco jurídico na mesma época. A própria Adobe sentiu isso em 2022: quando a Pantone mudou o modelo de negócio, as bibliotecas saíram do Photoshop, do Illustrator e do InDesign, arquivos antigos passaram a abrir com as cores Pantone trocadas por preto, e quem precisa delas paga uma assinatura separada de plugin. Se nem a Adobe, pagando, escapou, imagine um clone que vive de boa vontade.

Vídeo é pior

No Premiere, no After Effects e no DaVinci Resolve, o problema multiplica. Câmera de cinema não entrega vídeo, entrega dado bruto numa curva logarítmica própria: LogC4 da ARRI, IPP2 da RED. Pra transformar aquilo em imagem, você precisa das transformadas do fabricante, e a RED entrega as dela num SDK que os editores integram e atualizam a cada versão. O ACES, o padrão neutro da indústria, depende de transformadas de entrada fornecidas por cada fabricante.

A Blackmagic dá o Resolve de graça e ele decodifica ARRIRAW e R3D. Faz isso porque paga o SDK e a parceria por você. Um clone feito por agente, “adivinhando” como a imagem da Alexa deve ficar, produz uma imagem que não bate com o monitor de referência, e no cinema isso significa que não serve. Esse conhecimento não está em corpus de treino nenhum: está em contrato.

O caso Bun: quanto custa reescrever software grande

Pra ter noção de ordem de grandeza, o melhor dado público que existe é o do Bun. Em maio de 2026, Jarred Sumner reescreveu o runtime inteiro de Zig pra Rust usando agentes, e em julho publicou os números:

• 535 mil linhas de Zig em 1.448 arquivos viraram um diff de um milhão de linhas de Rust, em 11 dias.
• Até 64 instâncias de Claude em paralelo, 24 horas por dia, cada linha revisada por dois agentes adversariais e um corretor.
• 5,9 bilhões de tokens de entrada não cacheados, 690 milhões de saída, 72 bilhões de leituras de cache: uns US$ 165 mil a preço de API.
• 16 mil erros de compilador corrigidos por 64 agentes antes do CI ficar verde em seis plataformas.
• A suíte de testes existente, com mais de um milhão de asserções, passou 100% antes do merge.

Lê de novo o que viabilizou isso:

• o autor original do projeto pilotando
• um código fonte completo e funcional como referência
• uma suíte de testes de um milhão de asserções servindo de oráculo
• orçamento ilimitado, porque o Bun pertence à Anthropic desde dezembro de 2025, e uma versão pré-lançamento do Claude Fable 5

O Sumner estima que três engenheiros com contexto total levariam um ano.

Agora tira cada uma dessas vantagens. O PhotoCraft não tem o fonte do Photoshop pra portar, tem que inventar. Não tem suíte de testes que diga “isso aqui bate com o Photoshop”. Não tem o autor do Photoshop.

E o Photoshop é um produto de 36 anos, cujos requisitos de disco a Adobe lista entre 10 e 100 GB, contra um runtime de JavaScript. Mesmo sem saber o tamanho do código da Adobe, estamos falando de um alvo maior, sem referência, sem oráculo e sem dono. Ordens de grandeza acima de US$ 165 mil, e ainda assim seria uma aproximação.

Por que o retrô anda tão rápido

Se é tão difícil, por que sai port de jogo antigo todo dia? Porque o retrô acumula todas as vantagens que o resto não tem.

O binário está disponível e é minúsculo. Super Mario Bros. do NES: 40 KB. Super Mario 64: 8 MB. Ocarina of Time e Majora’s Mask: 32 MB cada. Um CD inteiro de PS1: 650 MB.

Compare com Baldur’s Gate 3, 150 GB, ou com o Call of Duty mais recente, acima de 100 GB. São três ou quatro ordens de grandeza, e o escopo encolhe junto: um jogo de 1996 tem um punhado de sistemas, não um motor de física com rede, loja e anticheat.

A tecnologia é antiga e documentada. Vinte e cinco anos de comunidade já mapearam o hardware do N64, do PS1 e do SNES instrução por instrução. O agente não descobre nada; ele acelera um trabalho com mapa pronto. É o mesmo padrão que eu vi nos meus projetos de retrocomputação: onde tem referência e oráculo, a IA voa; onde não tem, ela gira em força bruta.

O alvo não se move. Ninguém vai atualizar o Zelda de 1998.

E o jurídico está resolvido há trinta anos. Sega v. Accolade e Sony v. Connectix deram o contorno. Os ports exigem que você forneça a sua ROM.

Console moderno é um PC

A segunda metade da explosão, os ports de PS4, PS5, Xbox One e Switch, tem outra explicação: esses consoles são PCs ou celulares com outro invólucro. O PS4 usa um AMD Jaguar x86-64, o PS5 um Zen 2, o Xbox Series outro Zen 2, o Switch um Tegra X1 ARM da NVIDIA. O processador do seu PC roda aquele código nativamente. Então ninguém precisa emular a CPU.

O trabalho que sobra é traduzir o sistema operacional e a GPU. O shadPS4 reimplementa as bibliotecas do sistema do PS4 e recompila os shaders: os jogos saem da fábrica com código de máquina da GPU AMD, que o emulador decodifica instrução a instrução e converte pra SPIR-V, o formato do Vulkan.

O Azimuth, que faz o Forza Horizon 2 rodar no Windows, traduz chamadas WinRT do Xbox pra Win32 e DirectX 11.X pra DirectX 12 desktop, com o código x86 do jogo rodando direto. O AnyPS5 religa o executável: pega o binário do PS5 e gera um binário nativo de Linux ou Windows, ligado a bibliotecas de sistema reimplementadas. Nos três casos, Proton, DXVK, VKD3D e MoltenVK já tinham resolvido a camada de tradução gráfica anos antes.

A prova inversa são os consoles que não eram PC. O PS3 usa o Cell, um PowerPC com sete coprocessadores ativos (os SPEs), cada um com memória local própria e sem cache, e o RPCS3 está nisso desde 2011, com a emulação dos SPUs sendo gargalo até hoje. O Xbox 360 é PowerPC também, e por isso o Sonic Unleashed precisou do XenonRecomp traduzir PowerPC pra C++. Engenharia reversa é caso a caso, e a arquitetura decide se o caso é fácil.

A IA está no meio, e já tem briga

Que os ports de 2026 usam IA, boa parte deles diz na cara. O decomp do Silent Hill escreve no README que o desenvolvimento é “fortemente assistido por IA (Claude Opus 4.6, 4.7 e o Fable mais novo), e somos abertos sobre isso. Não é tradução automatizada do jogo”. O recomp do Pokémon Stadium lista o Claude como contribuidor.

Os devs dos recomps de Zelda e Banjo, que passaram anos fazendo isso à mão, entraram em guerra com o que chamam de “slopcomps”, ports gerados por agente com qualidade de alpha.

E vale separar manchete de estado real também aqui. O AnyPS5 tem uma versão 0.1 de setembro que, segundo quem testou, roda um jogo indie 2D; a alegação viral de que “o PS5 está 80% portado pra PC” é dos fãs, e nenhum jogo 3D roda. Astro Bot roda, só que em emuladores (KytyPS5, SharpEmu), que fazem o caminho tradicional. O Forza Horizon 2 roda, e o Azimuth é um binário fechado de um estúdio que se declara “AI assisted” sem dizer mais nada.

“Mas daqui a dois anos o token custa nada”

A resposta padrão pra tudo isso é: hoje é difícil, em dois anos é trivial, porque IA cresce exponencialmente. Os números dizem outra coisa.

O preço da ponta mais cara caiu pouco. O GPT-4 de março de 2023 custava US$ 30 e 60 por milhão de tokens de entrada e saída; o Claude 3 Opus de 2024, 15 e 75; os modelos de ponta de hoje, Fable 5.1 e GPT-6 Astra, custam 10 e 50. Em três anos e meio, a fronteira ficou entre 1,2 e 3 vezes mais barata, dependendo de qual ponta você olha.

O que caiu de verdade foi o custo de uma qualidade fixa: a Epoch AI mediu quedas de 9 a 900 vezes por ano dependendo da tarefa, e numa revisão de 2026 resume em “muito grosseiramente 5 a 10 vezes por ano”, com o aviso de que pode desacelerar. Isso é real e é ótimo.

Só que aplica a conta no Bun. US$ 165 mil divididos por 10 dá US$ 16 mil. Por 100, US$ 1.650. Isso é pra portar um runtime com fonte, testes e autor na mão.

Pra um amador tentando clonar o Photoshop sem nada disso, a conta começa ordens de grandeza acima e cai na mesma proporção. Barato não é o mesmo que trivial.

E a premissa do “exponencial” morreu em 2024. O Ilya Sutskever disse no NeurIPS que o pré-treino como conhecemos vai acabar, porque só existe uma internet. A Epoch projeta que o escalonamento dos modelos de raciocínio converge pra taxa geral da fronteira em cerca de um ano.

Eu já escrevi sobre isso três vezes nas últimas semanas: os limites do que o modelo reproduz, a convergência dos modelos crus com o ganho vindo do harness, e o benchmark de linguagens em que os modelos de fronteira empataram no teto. A ferramenta que temos é a ferramenta que vamos ter por um bom tempo, com melhoria incremental. Planeje com ela.

Vale lembrar o número que abre o texto dos limites: pelo Octoverse 2025, relatório oficial do GitHub, 81,5% das contribuições na plataforma aconteceram em repositórios privados. É o código que importa de verdade, o que paga salário, e nenhum LLM viu uma linha dele. O modelo reproduz o que estava no treino, e esse código nunca esteve lá.

Agora estenda isso pra todo produto SaaS e pra cada componente que ele usa. O código da Adobe que realmente vale, o motor de cor, os perfis, os filtros na nuvem, não está disponível em lugar nenhum, nem como binário. Quem quiser reproduzir vai ter que refazer a pesquisa e o desenvolvimento, caro e demorado, pelos mesmos anos que a Adobe levou. E no fim ainda esbarra na propriedade intelectual licenciada de terceiros, Pantone, SDK de câmera, perfil de fabricante, que você nunca vai conseguir ter.

Respondendo a lista do começo

O PhotoCraft existe? Existe, é uma alpha de duas semanas com mais de 800 issues abertas, gerenciamento de cor rudimentar, travando acima de 8K e abrindo PSD errado. Parece Photoshop no print. Pode melhorar muito, e vai descobrir que o alvo se move e que as partes caras do Photoshop estão na nuvem ou em contrato com fabricante.

O REA existe? Existe, é bom, e é uma caixa de ferramentas pra quem já sabe usar Ghidra, exige o binário na mão, as ferramentas instaladas e centenas de milhares de tokens por análise. O próprio projeto evita dizer que ele clona programa.

Recomp e decomp aceleraram? Sim, de verdade, e a IA tem parte nisso. Aceleraram onde o binário existe, é pequeno, está documentado há 25 anos e não se move. Ou onde o console é um PC disfarçado e o trabalho é tradução de API, resolvida pelo Wine e pelo Vulkan anos antes.

A Adobe morreu? A Adobe tem uns 40 milhões de assinantes, pela estimativa mais citada, as features que vendem assinatura rodam no servidor dela, e trinta anos de GIMP ainda deixam a gráfica pedindo Photoshop. Eu queria que fosse diferente. Os dados dizem que o que vai acontecer é o que sempre aconteceu com clone de produto vivo: anos correndo atrás, e quando alcança, o valor já mudou de lugar.

Programador morreu? Reescrever o Bun precisou do autor do Bun. Os decomps que funcionam têm gente que conhece o hardware pilotando o agente, e os que não têm viraram “slopcomp” com nome e tudo. A engenharia reversa ficou mais barata e mais acessível, como ficou com o Ghidra em 2019, e continua sendo trabalho de engenheiro. Sem nós, a ferramenta devolve print bonito.

Software proprietário com binário na mão vai sofrer pressão, e deve. A maior parte do software que você usa não tem binário nenhum, e o que tem já depende de serviço na nuvem que não desmonta. Engenharia de software com IA tem um caminho ótimo pela frente. Manchete de “acabou” rende clique e não compila.

• Novos benchmarks v4: retestei os principais modelos e a conclusão incômoda foi convergência, não salto.
• Os limites das LLMs: modelos são ótimos reproduzindo o que existe, caríssimos no que não existe, e o modelo servido é um arquivo estático que não aprende nada com a sua maratona.
• Existem linguagens melhores pra programar com LLMs?: não. Nem concisão de script nem tipagem forte mudaram o resultado; disciplina de teste mudou.
• Qual modelo de decisão tipo Jev é melhor?: 21 configurações de classificadores, e os próprios “modelos especializados” convergiram pra dentro de alguns pontos uns dos outros.
• Clean Code pra agentes de IA, VS Code é o novo cartão perfurado, minhas skills, o hot take contra loop engineering e boas práticas mínimas: a mesma tese por outros ângulos. O modelo é commodity; a engenharia em volta é o diferencial.

A tese que fecha esse arco: os LLMs chegaram, ou estão pertíssimo de chegar, no teto da arquitetura transformer. E a boa notícia é que não precisa mais que isso.

Convergência, não salto

Nos meus benchmarks, não vejo melhora relevante de programação geral desde a geração do Opus 4.5. Sim, Fable e Astra são ótimos em problemas específicos. Em programação geral, o que eu meço é todo mundo espremido no mesmo patamar, incluindo as ofertas comerciais chinesas (Kimi, GLM, DeepSeek). A escolha de modelo virou quase indiferente.

O que ainda faz diferença de verdade é o nível de esforço: effort baixo pra tradução e sumarização, effort alto pra varredura de vulnerabilidade, correção de bug pesado ou otimização. Fora isso, os números contam uma realidade bem mais chata que a propaganda dos provedores.

Minha leitura da linha do tempo: o raciocínio “core” dos modelos teve o último salto grande em 2024. 2025 foi o ano de otimizar a arquitetura. 2026 é o ano de refinar o harness. A inteligência de base não deu nenhum salto de ordem de magnitude nesse período; a eficiência e a competência em sessão longa deram.

A linha do tempo, com recibos

2019: GPT-2 prova que LLM é útil. 1,5 bilhão de parâmetros, resumindo, traduzindo e respondendo sem treino específico, zero-shot. A OpenAI achou tão impressionante que segurou o modelo completo por meses com medo de mau uso. Hoje parece fofo.

2020: GPT-3 abre a guerra dos parâmetros. 175 bilhões, cem vezes o GPT-2, e o few-shot in-context learning que virou o paradigma. A lei de escala do Kaplan, publicada meses antes, dizia que perda caía em lei de potência com tamanho, e a indústria leu como “quanto maior, melhor”. Lá se foram dois anos de quem-tem-mais-parâmetro.

2022: Chinchilla recalibra a guerra. O DeepMind treinou 400 modelos e mostrou que os gigantes estavam sub-treinados: um modelo de 70B com 1,4 trilhão de tokens batia o Gopher de 280B. O eixo “dados de treino” passou a pesar tanto quanto o eixo “parâmetros”. Primeira rachadura na guerra.

2023: GPT-4 encerra a guerra por decreto. O relatório técnico recusou publicar tamanho, hardware ou dados, citando o cenário competitivo e as implicações de segurança. O vazamento mais citado, da SemiAnalysis, descreveu 1,76 trilhão de parâmetros em mistura de especialistas. Desde então, contagem de parâmetros sumiu do marketing: nem os anúncios do GPT-5 nem os do Claude 4 citam número. Repara que nem Astra nem Fable, hoje, gastam uma linha com isso. A guerra acabou e ninguém assinou armistício.

2024: o pico do raciocínio. O o1, de setembro, marcou esse pico: RL pra produzir cadeias longas de pensamento, e a descoberta de que mais compute em tempo de teste melhora a resposta. Essa é, na minha régua, a última revolução de “inteligência de base”.

2025: otimização de arquitetura. A mistura de especialistas virou padrão: o Mixtral já mostrava em 2023 que 46,7B de parâmetros totais com só 12,9B ativos por token custavam como um modelo pequeno, e o DeepSeek-V3 levou isso a 671B totais com 37B ativos, com o treino final saindo por menos de 6 milhões de dólares em GPU-hours a preço de aluguel de H800 (sem contar o R&D anterior). A mágica do MoE é simples: separa capacidade (parâmetros totais, que moram em memória) de custo por token (só os especialistas escolhidos pelo roteador computam). Você paga um modelo de 37B e carrega um de 671B.

Do lado do serviço, o prompt caching cortou até 90% do custo de contexto repetido (a OpenAI seguiu dois meses depois), as janelas de contexto passaram de 1 milhão de tokens, e técnicas de serving como speculative decoding e PagedAttention multiplicaram a vazão. E o DeepSeek-R1-Zero mostrou que RL puro, sem fine-tuning supervisionado, faz raciocínio emergir. Nada disso é “mais inteligência”. Tudo isso é a mesma inteligência mais barata, mais rápida e mais estável.

2026: a era agêntica. Function calling existe desde junho de 2023, mas o ponto de virada de ecossistema foi o MCP da Anthropic no fim de 2024, que a OpenAI adotou meses depois e que hoje mora na Linux Foundation. Claude Code, Codex e cia. saíram em 2025, e a métrica que importa virou a da METR: o tamanho de tarefa que um agente completa com 50% de confiabilidade vinha dobrando a cada 7 meses desde 2019. O guia da própria Anthropic sobre construir agentes eficazes diz o óbvio bem dito: padrões simples e compostáveis, não frameworks mirabolantes.

Por que o agente permite um modelo menos denso

Aqui está o mecanismo que a maioria das pessoas não para pra pensar. Um modelo sozinho precisa carregar o mundo nos pesos, porque a única chance dele responder é aquela, em uma passada. Um modelo com harness não precisa:

• Busca e leitura sob demanda. Com web search e fetch, o conhecimento de baixa prioridade sai dos pesos e vira consulta: o agente puxa pra janela de contexto só quando precisa. O modelo pode ser menos enciclopédico e mais operador.
• Tentativa e erro controlada. Sozinho, o modelo precisa adivinhar a resposta certa de primeira. Com agente, ele propõe uma hipótese, implementa, manda testar, recebe o feedback e decide de novo com informação real. Cada ciclo desses é conhecimento novo entrando na sessão sem custar um neurônio de treino.

Os dois mecanismos combatem alucinação de raiz: fetch traz o fato que o modelo não sabe de cor, e o loop de teste pega a invenção antes de ela virar código. É por isso que 2026 parece um salto gigante: a combinação modelo+harness ficou muito mais competente, mesmo com a inteligência de base quase parada.

Nem todo problema precisa de um LLM gigante

A mesma lógica do “menos denso” vale dentro da aplicação. Boa parte do que as pessoas jogam num LLM de chat é classificação disfarçada: rotular ticket, rotear fila, aplicar política. Pra isso existe modelo de decisão especializado, e eu cobri o tema duas vezes: o hype do Jev, com o ensaio do Paulo Câmara sobre por que um classificador é a primeira coisa que um cientista da computação pensa, e o meu benchmark com 21 configurações, onde um 9B da Microsoft empatou com o líder hospedado e um 4B local ficou a poucos pontos, a centavos por dez mil decisões.

O choque de “193x mais rápido” do marketing do Jev só existe porque muita gente usava um LLM gigante como classificador caro e lento. Quando a ferramenta certa entra, o modelo de fronteira some da jogada, e junto com ele o custo, a latência e a alucinação de formato. É a tese deste texto em miniatura: competência não vem de densidade, vem de encaixe.

O loop que ninguém vê

Tem um detalhe de experiência de usuário nessa história. Numa sessão agêntica boa, o que acontece é semitransparente pra quem pediu a tarefa: o modelo chuta errado, o agente busca a documentação online ou roda o teste de verdade, o erro volta como feedback, e o modelo corrige sozinho. Você vê “tarefa pedida, tarefa entregue”. No meio rolaram dezenas de micro-correções que ninguém testemunhou.

Minha aposta: como os agentes são treinados pra encher o contexto quando precisam, nem versões novas de linguagem ou biblioteca confundem mais tanto. O modelo não precisa saber a API de cor; ele consulta, testa e se ajusta no loop. É o que eu vejo nos meus experimentos, da conversão de ROMs de NES pra Master System aos probleminhas do dia a dia. E foi o que o benchmark de linguagens mediu: sete linguagens saíam praticamente equivalentes, porque o loop equaliza o que o treino deixa desigual.

A ressalva eu também medi. Quando não existe documentação pra buscar nem teste pra validar, o loop gira no vazio: foi o que aconteceu com o Bend 2, linguagem nova demais pra ter corpus, e foi o ponto central do texto sobre os limites. O mecanismo é potente, mas precisa de oráculo.

E tem recibo de que a base está parada. Em novembro de 2024 a Reuters já reportava retornos decrescentes no pré-treino nos três grandes laboratórios. No NeurIPS seguinte, o Sutskever, o cara da tese de escala, declarou que “pré-treino como conhecemos vai acabar”: os dados públicos acabaram. E o AI Index de Stanford mediu o abismo entre o primeiro e o décimo modelo no Chatbot Arena encolhendo de 12% pra 5% em um ano. Isso é convergência, com número.

A propaganda na direção contrária

Enquanto os números mostram platô, o marketing vende o apocalipse. Eu já dissequei uma semana inteira disso em “Você é um idiota se acredita nas propagandas enganosas da OpenAI, Anthropic, NVIDIA”, então aqui vai só o que interessa pra esta narrativa:

• A “prova de Navier-Stokes” da OpenAI foi força bruta agêntica em escala industrial, 130 bilhões de tokens sobre o maquinário de matemáticos humanos, vendida como inteligência emergente.
• O incidente da Hugging Face foi um enxame executando 17 mil tentativas com verificação automática, não um “agente que ganhou consciência e escapou”. Tentativa e erro cara, exatamente o mecanismo que eu descrevi aqui.
• O medo é produto: quem vende “minha IA é poderosa demais e pode fugir do controle” está, na mesma frase, pedindo regulação que trava o concorrente menor e inflando a percepção de que o modelo dele é mais capaz que o dos outros.

Os fatos que eu medi apontam o contrário do apocalipse: modelos convergindo, diferenças encolhendo, e o trabalho útil migrando do modelo pro harness. IA descontrolada ganhando consciência não é o que os logs mostram. O que os logs mostram é engenharia.

“Competente o suficiente”

Não espero outra revolução de raciocínio de ordem de magnitude nessa arquitetura. O que vem é melhoria agêntica incremental: tool calling mais robusto, memória melhor, sessões mais longas, menos alucinação por ciclo de verificação. E o ponto deste texto é que isso já basta.

O que a era agêntica entregou foi a automação da engenharia de software correta: sessões longas e confiáveis de codificação, com teste e feedback, que aceleraram centenas, senão milhares, de projetos open source. A premissa do deploy mudou junto. Não é bala de prata. É um compilador novo pra uma disciplina velha: quem tinha processo, teste e invariante documentada colheu; quem tinha só hype continua esperando o próximo modelo resolver.

E pra fechar: não vejo problema nenhum na estagnação dos modelos crus. Os limites a gente já conhece, e as otimizações de harness logo entram em retorno decrescente também. O que sobra é o que sempre sobrou: técnica de engenharia de software de verdade, com teste automatizado em primeiro lugar, e um engenheiro experiente pilotando. Com isso, o resultado de codificação é excelente hoje, não daqui a uma geração de modelo.

O que não vai existir é mágica pra amador. Pedir qualquer tarefa de código pra agente, sem saber o que está fazendo, não devolve código seguro, otimizado e bem pensado: devolve slop. O agente responde melhor pra quem sabe o que pedir, ou seja, pra quem entende essa arquitetura, os prós, os contras, e sabe contornar as fraquezas e alavancar os pontos fortes da combinação modelo+harness.

Por isso o título. LLM sozinho é um papagaio caro. LLM com agente é competente o suficiente pra trabalhar de verdade. E “competente o suficiente”, somado à sua disciplina de engenharia, é tudo que a indústria precisava. O resto é marketing esperando o próximo número mágico de parâmetros que ninguém mais publica.

Ranking de terceiro é útil, mas eu queria pôr a mão na massa. Então montei meu próprio benchmark, com casos meus, metade em português, e rodei os modelos abertos duas vezes: no meu home server com Strix Halo, o mesmo Ryzen AI Max+ 395 que uso pra testar LLM local, via ROCm, e de novo numa RTX 5090 via CUDA. Os hospedados (Jev, os dois Clef da Cloudflare, o OpenAI Decisions e o Microsoft Decision-1 via OpenRouter) rodaram pela API deles. Tudo, incluindo os casos, as respostas brutas e os scripts de pontuação, está público no repositório do benchmark.

TL;DR: o topo agora tem dois, ambos de pesos abertos. O Perplexity Decider 1.1 27B e o recém-lançado Decision 3.0 (vLLM Semantic Router) empataram em 99,4% nos casos compactos, com 100% em português, e rótulos idênticos em todas as 1.024 classificações do benchmark. O preço: uns 49 GB de pesos e mais de um segundo por decisão. Na nuvem, o Microsoft Decision-1 empatou com o Jev em 97,6% custando um terço: é o hospedado mais barato que eu medi, e o primeiro candidato a avaliar. O Jev responde mais rápido e erra diferente. O OpenAI Decisions estreou empatado com o melhor 4B local, o Jebadiah, e tem a menor latência hospedada. O Julia-1, o menor e mais rápido de todos (12 ms), acertou no nível da moeda: de fábrica, não serve. E a segunda passada, agora numa RTX 5090: os modelos até 9B aceleram de 2× a 10×, o Jebadiah 4B cai pra 39 ms, mais rápido que qualquer hospedado, e os dois campeões de 27B, com uns 49 GB de pesos, nem cabem nos 32 GB da placa. Pule pra tabela, pro custo em e-mails de suporte, pra qual usar em qual situação, pra quão difícil é rodar local, pras pegadinhas ou pras duas cozinhas do ROCm x CUDA.

Como eu testei

A ideia central foi medir mais do que “quem acerta mais”. Modelo de decisão tem objetivo de projeto, e comparar um encoder de 322 milhões de parâmetros feito pra rodar em dispositivo fraco com um serviço hospedado de tamanho não divulgado só por porcentagem de acerto é injusto com os dois. Então medi acerto, latência, custo e comportamento sob estresse, e no fim separo as recomendações por situação.

Os dois conjuntos de casos

Montei dois conjuntos de testes, congelados em git antes de qualquer inferência, com o hash do dataset gravado junto com as respostas. Nenhum modelo recebe a resposta esperada, a justificativa ou o identificador do caso. Só o texto, as instruções e as opções.

O conjunto v1 tem 13 casos de uso operacionais, em inglês, cada um com uma política fictícia explícita:

• severidade de ticket de suporte
• roteamento de suporte
• política de reembolso
• escalação de incidente
• aprovação de ferramenta (um agente pode ou não executar tal ação)
• fraude por e-mail
• tipo de documento
• suporte de evidência
• relevância de busca
• moderação
• roteamento de pedido
• qualificação de lead
• triagem por limiar numérico

São 10 cenários por caso de uso, cada um apresentado de quatro formas: original, opções em ordem invertida, opções com nomes opacos (c0, c1, c2) e original mais um comentário de “revisor” sugerindo a resposta errada, que a instrução manda ignorar. Dá 520 classificações por modelo. Somam-se 24 sondagens de probabilidade em situações sem informação nenhuma (moeda honesta, dado de seis lados), onde a resposta certa é matemática.

O conjunto v2 foi feito pra cobrir o que o v1 deixa de fora: semântica comum e português. São 7 tarefas, com 12 cenários cada, e cada cenário escrito em inglês e em português brasileiro com a mesma resposta e a mesma ordem de opções:

• sentimento (autor versus citação, negação, sarcasmo)
• intenção atual (pedido retirado, ações concorrentes, hipótese)
• implicação lógica (quantificadores, fato ausente, ordem temporal)
• relevância de busca (tudo, parte ou nada do que foi pedido)
• tratamento de dados sensíveis (segredo fictício versus menção, redação, revogação)
• status atual de incidente (ordem da linha do tempo, verificado versus não verificado)
• política por limiar (limites inclusivos, unidades, E/OU com valor faltando)

Cada par roda em três condições:

• compacta: só o registro e a regra
• com exemplos: um exemplo resolvido por classe, fixo e igual pra todos
• com distratores: dez notas irrelevantes de arquivo antes do registro que importa, pra estressar contexto

Dá 504 classificações por modelo.

Os casos foram escritos com ajuda de IA e revisados contra as políticas, sem anotação humana independente. É um benchmark sintético e pequeno: 130 famílias de cenário no v1 e 84 no v2. As variantes são correlacionadas, então 520 respostas são 130 cenários vistos de quatro jeitos. Trate os números como fotografia desses casos, e teste com os seus antes de decidir.

Os 23 competidores

Cinco rodaram na nuvem, pela API oficial: o Jev (versão 1.13.0, da TypeSafe), o Clef (27B, Cloudflare Workers AI), o Clef-flash (9B, idem), o OpenAI Decisions (o alias gpt-6-luna, em beta público) e o Microsoft Decision-1 (9B, pós-treinado do Qwen3.5-9B, servido via OpenRouter em Azure). Os outros dezoito rodaram no Strix Halo, via ROCm, e depois de novo numa RTX 5090, via CUDA, com os pesos fixados por hash de commit no Hugging Face, dentro de container Docker. Os três da primeira leva (Laya, Laya typed e Clef-flash) dividiram um container; os demais rodaram um por vez, com o Julia-1 medido duas vezes, em GPU e em CPU. O servidor via 64 GiB de memória endereçável pela GPU.

A ordem aí em cima é só organizacional, hospedados primeiro e locais por família. O ranking de verdade está na tabela de resultados.

Todos receberam exatamente o mesmo texto, as mesmas instruções e as mesmas opções, sem prompt ajustado por modelo e sem nenhum ajuste depois de ver resultado (o Simple-Jev usa a política de prompt fixa do próprio servidor). A exceção é o GLiNER, cuja API nativa recebe rótulos em vez de distribuições de probabilidade. Ele entra numa trilha separada, só no v2, com mapeamento explícito e sem métricas de calibração inventadas.

O Simple-Jev merece explicação. Ele é um servidor que pega um LLM comum (aqui o Qwen3.5 4B, sem nenhum treino de decisão) e lê a probabilidade dos tokens de resposta em vez de gerar texto. É a linha de base: se um modelo “de decisão” perde pra isso, o treino especializado não comprou nada.

Duas observações de protocolo. O OpenAI Decisions responde por um endpoint nativo de decisões tipadas, e o alias que a API devolveu não é um snapshot imutável: a OpenAI pode trocar o peso por trás do nome, como a Cloudflare faz com o Clef-flash. E o Perplexity Decider não é um LLM de chat comum: ele tem uma cabeça de decisão separada, com atenção não-causal e uma temperatura de calibração salva nos pesos. Um servidor de chat genérico não reproduz o comportamento dele. O Microsoft Decision-1 fala SystemOne nativo pela API de decisões do OpenRouter, e o identificador servido é datado (microsoft-decision-1-20261009), ou seja, também não é peso imutável. Ele não aparece no catálogo de modelos de texto do OpenRouter: pra achar, tem que filtrar pela modalidade decisions. O Decision 3.0 é a família nova do projeto vLLM Semantic Router, Apache 2.0, derivada de Qwen, com seis checkpoints (d3, flash, mini, nano, lite, edge) e SystemOne nativo. Eu testei o flagship (d3) e o menor (d3-edge); os quatro do meio ficam pra outra rodada.

O que foi medido

• Acerto por tarefa, por língua e por condição, sempre em cima das probabilidades por opção que o modelo devolve, ignorando o campo de “confiança” do fornecedor.
• Brier e ECE pra calibração.
• Latência mediana e p95 vista pelo cliente, incluindo a rede: WAN pros hospedados, LAN pros locais. Os locais foram medidos nas duas implantações, Strix com ROCm e 5090 com CUDA. São observações de implantação completa, máquina inteira de cada lado; a comparação entre elas não isola o efeito de trocar só o backend.
• Tokens de entrada reportados pela API, valorados pela tabela de preços de 10 de outubro, antes de qualquer franquia.
• Intervalos de confiança por bootstrap sobre famílias de cenário, em vez de respostas individuais.

Custo local eu deixei de medir. Energia, amortização do hardware e manutenção ficaram de fora, então modelo local aparece como “não medido”, porque “zero” seria mentira.

A tabela completa

A coluna principal é o acerto nos 168 casos compactos do v2 (84 em inglês, 84 em português). A coluna do v1 usa os 130 cenários originais. Latências são medianas vistas pelo cliente ao longo das 504 chamadas do v2, nas duas implantações locais: ROCm no Strix Halo, CUDA na RTX 5090. Os hospedados não têm hardware meu pra trocar, e os dois 27B não cabem nos 32 GB da 5090. O custo é o valor de lista por 10 mil decisões compactas, calculado pelos tokens que a API reportou.

Sobre a coluna CUDA: os pesos são os mesmos, então o acerto veio igual ou a até dois casos de distância no compacto em todos os modelos. Rótulos individuais viraram em alguns (12 de 504 no pior caso, o Julia; 11 no Simple-Jev), diferença de aritmética de kernel que não mudou placar nenhum, e as probabilidades diferem na terceira casa decimal em média. A tabela fica pelo acerto do Strix; a coluna CUDA só traz latência. O relatório pareado completo, caso a caso, está no repositório.

Pra calibrar a leitura: as tarefas têm três ou quatro opções, então chute uniforme dá uns 31% nos dois conjuntos. “Perto de 50%” aqui já é bem acima da moeda, e “perto de 33%” é a moeda. O Julia-1 ficou em 31,5%: o nome bonito esconde um cara jogando cara-ou-coroa.

Os intervalos importam. A vantagem do Perplexity sobre o Jev no v2 é de menos de 2 pontos e o intervalo de bootstrap encosta no zero: é a liderança medida neste conjunto, não uma superioridade provada pra sempre. E o Decision 3.0 empatou com o Perplexity no limite do que este conjunto consegue distinguir: rótulos idênticos nas 1.024 classificações, com os dois errando os mesmos dois casos (a relevância em inglês no v2 e o caso disputado de severidade no v1, que já está no errata). O Microsoft empatou com o Jev no agregado, com intervalo centrado em zero, mas empate no agregado não é intercambiabilidade: eles erram casos diferentes, e o Microsoft inverte o padrão de língua, errando mais em inglês que em português. Jev e Clef também seguem separados por menos de 2 pontos, no mesmo patamar. Já o pelotão de 90% (Jebadiah, OpenAI) fica 7 pontos atrás do Jev, e daí pra baixo todas as diferenças são claras.

Cada célula de tarefa tem só 12 cenários por língua, então um acerto a mais muda a célula em mais de 8 pontos. Empate em uma tarefa específica é pista pra um piloto. As tabelas por tarefa estão no repositório.

Quanto custa, em e-mails de suporte

Preço por milhão de tokens é um número que ninguém consegue sentir. Os preços de lista em 11 de outubro são US$ 0,042 por milhão de tokens de entrada no Jev, US$ 0,24 no Clef, US$ 0,038 no Clef-flash e US$ 0,10 no OpenAI Decisions. Saída é grátis nos cinco. O Microsoft Decision-1 cobra os mesmos US$ 0,042 do Jev por milhão, via OpenRouter, mas reportou um terço dos tokens de entrada pros mesmos textos (uns 26 mil contra uns 77 mil do Jev no v2 compacto), e ninguém sabe explicar a diferença de tokenização. Na prática medida, isso o torna o hospedado mais barato do lote.

O Clef-flash custava US$ 0,09 no dia 9: a Cloudflare baixou o preço em mais da metade no meio do meu teste. O Jev reporta bem mais tokens que a Cloudflare pro mesmo texto, uns 45% a mais no v2, e isso já está na conta abaixo.

Imagine uma operação com 10 mil e-mails de suporte por mês pra classificar em três ou quatro baldes, com textos curtos parecidos com os meus casos:

Em reais, pela cotação de sexta (R$ 4,99), 10 mil decisões no Jev custam um real. Um milhão custa menos de cem reais. Pra qualquer empresa que tenha um milhão de e-mails pra classificar, isso some no orçamento.

Uma ressalva de proporção: meus casos são curtos, uns 450 tokens por caso compacto pela contagem do Jev. E-mail real de cliente, com histórico de thread citado, pode ser três a cinco vezes maior, e o custo escala linear com isso. Mesmo assim, estamos falando de centavos por milhar.

O que esse cálculo mostra é que a diferença de preço entre os modelos hospedados é irrelevante perto do custo de errar. O Jev custa 9 centavos de dólar a mais que o Clef-flash a cada 10 mil decisões, e nesses mesmos 10 mil comete uns mil erros a menos. Se um e-mail mal roteado custar mais que um centésimo de centavo de dólar em retrabalho humano, o Jev se paga. Essa conta assume que todo erro custa igual, o que nunca é verdade: mandar um ticket crítico pra fila de rotina custa muito mais que o contrário.

A franquia da Cloudflare muda a conta pra quem é pequeno. São 10 mil “neurônios” por dia, compartilhados pela conta inteira, zerando à meia-noite UTC. Com os meus tamanhos de entrada, isso dá umas 1.500 classificações de Clef completo por dia ou quase 10 mil de Clef-flash, de graça. Se você tem 1.000 e-mails por dia e nada mais rodando na conta, o Clef sai a custo zero com qualidade de ponta.

E o local? Energia o benchmark deixou de medir. Pelo que eu vejo no meu Strix Halo, a máquina inteira fica abaixo de 100 W sob carga. Com o Jebadiah em 200 ms por decisão, 10 mil decisões são uns 35 minutos de máquina, menos de 0,1 kWh, uns centavos de real na conta de luz.

O custo local real é a máquina, a sua hora configurando ROCm e container, e manter aquilo de pé. Quem já tem o hardware por outro motivo tem custo marginal baixo. Quem compraria a máquina só pra isso está comprando um problema de milhares de reais pra economizar uns cem reais por milhão.

Qual modelo em qual situação

Você quer precisão e quer operar nada: Jev

Na nuvem, o Jev continua sendo o nome. Venceu ou empatou em praticamente todas as células entre os hospedados, e só o Microsoft empatou com ele no agregado. Em inglês ele foi 100% em cinco das sete tarefas do v2, e em português repetiu 97,6% no agregado sem perder nada na tradução, coisa que nenhum outro modelo acima da moeda conseguiu. No v1 ele manteve os 96,2% do original com o comentário malicioso do “revisor” injetado; o Clef até subiu um caso, e o Kev 4B também ficou parado, só que num patamar bem mais baixo. A latência de 255 ms via WAN ficou a 30 ms do OpenAI, e custa 19 centavos de dólar a cada 10 mil decisões.

A contrapartida é a que já discuti no texto anterior: é proprietário, hospedado, de tamanho não divulgado, e você depende da TypeSafe manter o comportamento por baixo de você. E ele erra. Tratou um ID de fatura chamado “PASSWORD-523” como credencial utilizável, mesmo com o registro dizendo explicitamente que aquilo não autentica ninguém.

Você quer o nível do Jev pagando um terço: Microsoft Decision-1

A Microsoft entrou nesse mercado quieto, e entrou bem. O Decision-1 é um 9B pós-treinado do Qwen3.5-9B, servido via OpenRouter, e foi o primeiro modelo a empatar com o Jev no agregado compacto: 97,6%, com o intervalo de bootstrap centrado no zero. O detalhe que me ganhou: 100% em português, melhor que o inglês dele (95%), invertendo o padrão de todo o resto do lote. No v1, as variantes de ordem invertida e comentário malicioso não derrubaram uma única resposta, e ele acertou o ticket crítico que o Clef e o OpenAI erraram.

E é o hospedado mais barato que eu medi: US$ 0,065 por 10 mil decisões, um terço do Jev, cobrando a mesma taxa por token mas reportando um terço dos tokens. A economia vem da contagem de tokens, e o mecanismo exato eu não sei explicar, então trate como medida, não como promessa.

Os pontos fracos existem. A latência é a pior entre os hospedados (422 ms de mediana, contra 255 do Jev). Nos casos compactos ele é limpo de erro confiante, mas basta adicionar contexto pra aparecer erro em português com 99,5% de confiança: o padrão “português perfeito” não sobrevive a texto longo. E nas sondagens de probabilidade ele é fraco, dando 87% pra uma moeda honesta. A Microsoft anuncia probabilidades calibradas; minhas sondagens discordam. E como todo hospedado de ID datado, o peso por trás pode mudar sem aviso.

Pra operação em português que quer qualidade de Jev pagando menos, é o primeiro candidato a rodar no seu piloto.

Você quer o mesmo nível com pesos abertos: Clef

O Clef completo de 27B empatou com o Jev em inglês (82 de 84) e ficou 3 casos atrás em português. Ganhou dele no tratamento de dados sensíveis em inglês (12 de 12 contra 11). É modelo de pesos abertos, então dá pra rodar local com uns 54 GB de memória só pros pesos em BF16, o que eu deixei de testar: o Clef completo rodou só pela API. Entre os abertos, ele perdeu a coroa pro Perplexity, que pontuou mais alto com pesos menores.

Pela API ele é o mais caro dos cinco hospedados, três vezes o Jev, sem ganho de qualidade que justifique. A exceção é a franquia diária: pra volume pequeno, ele é o melhor classificador que você consegue de graça.

Você quer o mais barato na nuvem: Clef-flash

A US$ 0,038 por milhão, o Clef-flash é o preço mais baixo do mercado hospedado e cobre 9.400 decisões por dia dentro da franquia. A qualidade cai: 92% em inglês e 83% em português nos casos compactos, a maior queda de língua entre os hospedados, com intervalo inteiro abaixo de zero. Em sentimento nas duas línguas, e em status de incidente em inglês, ele empatou com o Jev. Em intenção e dados sensíveis em português, perdeu feio.

Pra tarefa de sentimento em qualquer língua ou pra classificação em inglês onde 1 em 12 erros é aceitável, ele serve bem. Pra português, meça antes.

Você já vive no ecossistema OpenAI: OpenAI Decisions

A estreia da OpenAI nesse mercado ficou no meio da tabela: 90,5% combinado, empate exato com o Jebadiah, com a menor latência hospedada que eu medi (222 ms) e o mesmo acerto nas duas línguas. Custa US$ 0,23 por 10 mil decisões, entre o Jev e o Clef. Se a sua operação já fala a API da OpenAI e 9 em 10 de acerto basta, a integração é trivial: um endpoint nativo de decisões, nada de prompt.

Os pontos fracos são reveladores. A pior célula dele foi justamente política por limiar numérico (8 de 12 em inglês, 7 em português): tratou “pelo menos 10” como satisfeito por um intervalo de 8 a 12 e falhou no curto-circuito de E/OU. A calibração é esquizofrênica: nas sondagens de predicado (sim/não) ele foi o mais certeiro do lote, com erro médio quase zero, e nas sondagens de escolha ele devolveu 94%/6% numa moeda honesta. E nas variantes do v1 ele virou 2 respostas certas em cada apresentação (ordem invertida, rótulo opaco, comentário malicioso), coisa que só o Perplexity não fez: o Jev manteve a acurácia agregada, mas também virou algumas respostas certas no caminho. Ah, e o alias gpt-6-luna não é snapshot imutável: reprodutibilidade exige guardar as respostas.

Você quer o melhor modelo aberto, ponto: Perplexity Decider 27B

O Perplexity Decider 1.1 27B é a surpresa do benchmark. Liderou a tabela com 99,4% nos compactos, foi o único que não perdeu nenhuma célula de tarefa pro Jev (3 vitórias, 11 empates), e fez 100% em português nas três condições: compacto, com exemplos, com distratores. A calibração também é a melhor medida, com Brier de 0,012, e a cobertura é absurda: respondeu com confiança acima de 0,9 em 96% dos casos e errou zero deles. No v1, não virou uma única resposta nas variantes de ordem, rótulo opaco e comentário malicioso.

Os únicos 3 erros dele no v2 foram o mesmo caso em traje diferente (confundiu “notificação enviada a gerentes” com “aprovador obrigatório”), e ele os cometeu com confiança abaixo de 0,9: o erro conhecido vem sinalizado. O ponto fraco são as sondagens de probabilidade de evento: perguntado sobre um evento de chance 1 em 4, ele respondeu 0,73. Classificação forte não implica probabilidade de evento confiável.

O custo é hardware: uns 49 GB de pesos em BF16, um segundo e meio por decisão no meu Strix Halo (com os kernels de referência do ROCm, sem flash-attention). E antes de sonhar com “numa NVIDIA deve voar”: eu testei, e ele nem cabe numa RTX 5090 de 32 GB. É Apache 2.0, pesos públicos sem gate. Se você tem a máquina e quer o topo da tabela em casa, é ele.

Você quer o outro topo aberto: Decision 3.0 (e cuidado com o Edge)

O Decision 3.0, lançado há dois dias pelo projeto vLLM Semantic Router, é o segundo modelo a sentar no topo: 99,4% nos compactos, 100% em português, e um empate tão absoluto com o Perplexity que os dois deram exatamente os mesmos rótulos nas 1.024 classificações, incluindo os mesmos dois erros (a relevância em inglês, com confiança abaixo de 0,9, e o caso disputado de severidade que já mora no errata). Também zerou as armadilhas do v1 sem virar uma resposta, acertou os dois tickets críticos indiscutíveis, e a calibração é da mesma classe do Perplexity (Brier 0,014, 94% de cobertura acima de 0,9 com zero erros).

Ou seja: o topo open agora tem duas receitas independentes que convergem. Pro seu piloto, tanto faz qual das duas; rode as duas se puder, porque as probabilidades diferem mesmo quando os rótulos não. A latência é da mesma família do Perplexity (1,4 s na minha máquina, mesma dieta de ROCm), e os pesos ocupam os mesmos ~49 GB.

O irmão pequeno é outra história. O Decision 3.0 Edge (0,6B) responde em 45 ms e cabe em 1,3 GB de GPU, mas acertou só 61% no compacto, despenca 14 pontos em português, e pior: dos 68 palpites que ele deu com confiança acima de 0,9, 14 estavam errados. Como roteador com limiar de confiança, de fábrica, ele é uma armadilha da mesma turma do Julia. Os quatro checkpoints do meio (flash, mini, nano, lite) ainda não testei; são eles que vão dizer se a família tem um ponto doce entre os dois extremos.

Você precisa rodar local, com qualidade: Jebadiah 4B v2

Dos locais, o Jebadiah 4B v2 teve o melhor acerto compacto, 90% combinado, respondendo em uns 200 ms no Strix Halo e 39 ms na RTX 5090. Numa 5090, ele fica mais rápido que qualquer hospedado do benchmark, Jev incluso (255 ms de WAN): com o hardware certo, o local deixou de ser o lado lento da tabela. Empatou com o Jev em seis das catorze células de tarefa, incluindo intenção, implicação e status em inglês e intenção em português. O ponto fraco é política por limiar numérico, 9 de 12 nas duas línguas, e ele perde terreno quando o contexto enche de distratores (76% em português nessa condição, contra 82% do Mapika).

O Mapika Decider 4B (o mais rápido dos 4B) e o Kev 4B ficam logo atrás, ambos com uns 87%, e a diferença de 3 pontos entre os três cabe dentro do intervalo de erro. São três receitas de treino diferentes em cima de backbones de 4B, com erros em tarefas diferentes. A escolha entre eles depende da sua tarefa, e eu rodaria os três num piloto.

Você vai mandar exemplos no prompt: Kev 9B

O Kev 9B tem um perfil curioso. Nos casos compactos ele empata com o Kev 4B, com meio ponto de diferença e intervalo cruzando zero, ou seja, mais que o dobro de parâmetros comprou nada. Com um exemplo resolvido por classe, ele abre quase 10 pontos sobre o 4B, e com distratores segura 7 pontos a mais. O Brier também melhora uns 25%: a probabilidade que ele devolve é mais bem calibrada.

Se o seu uso é só a regra e o texto, o 4B basta e é mais que o dobro mais rápido. Se você vai mandar exemplos ou contexto longo, o 9B vale a memória. O alerta é o português: 83% compacto em PT-BR, quase 10 pontos abaixo do inglês dele, a maior queda de língua entre os modelos que passam de 80%. Só o Laya typed (14 pontos) e o Julia (13) caem mais.

Você quer o comportamento do Clef-flash na sua máquina: Clef-flash local

No conjunto v1, o Clef-flash local reproduziu as 520 classificações do hospedado, acerto por acerto e erro por erro. No v2 a história mudou: mesmo total (439 de 504), mas 19 rótulos diferentes, com forças trocadas (o local acerta mais intenção em português, o hospedado acerta mais relevância). Entre os locais ele continua o melhor no conjunto v1 de políticas operacionais (90,8%), à frente de todos os 4B.

A pegadinha é a latência: 618 ms de mediana no Strix Halo (86 ms na 5090), três vezes o Jebadiah, pelo mesmo acerto no v2. Se você escolher ele, é pelo comportamento conhecido.

Você precisa rodar offline em hardware fraco: Laya e Julia, com muitas ressalvas

O Laya multilingual foi o pior do benchmark em acerto (37% combinado, perto da moeda), e o mais rápido com folga entre os que acertam alguma coisa: 19 ms de mediana, mais de dez vezes mais rápido que o Jebadiah.

Os três checkpoints do Laya têm entre 322 e 421 milhões de parâmetros, cabem em menos de 1 GB de pesos em BF16 na conta de parâmetros, e o projeto documenta execução em CPU e runtime ONNX (que eu deixei de medir). O pico de alocação do PyTorch na GPU, pro multilingual, ficou abaixo de 2 GB. Um 4B precisa de uns 8 GB só de pesos na mesma precisão.

O Julia-1 desce mais um degrau: 144 milhões de parâmetros, 550 MB de pesos, 12 ms de mediana na GPU do Strix, 7 ms na 5090 e 71 ms numa CPU de 4 threads. É o modelo mais rápido que eu já medi aqui, e também o pior: 31,5% de acerto, colado na linha da moeda de 31%. Em português ele respondeu “cancelamento” nos 12 cenários de intenção, inclusive nos que pediam reembolso ou acesso (a avaliação de português do fabricante foi feita em pt-PT, e se nota). O desastre maior é a confiança: dos 71 palpites que ele deu acima de 0,9, 48 estavam errados. Um limiar de confiança não salva esse modelo, porque é justamente nos palpites confiantes que ele erra.

Isso é escolha de projeto. O Laya e o Julia foram feitos pra ser encoders pequenos, afináveis na sua tarefa, pra rodar na borda. O que eu testei foram os checkpoints de fábrica, sem nenhum ajuste, aplicando regras que eles nunca viram, em tarefas amplas. Nesse cenário eles foram mal e ponto.

Um detalhe confirma a fragilidade. No v1, quando o comentário malicioso do revisor entra, o Laya cai de 44% pra 19% e o typed-decisions pra 15%. Ele obedece o comentário que a instrução manda ignorar, e com confiança: 17 dos 28 palpites acima de 0,9 estavam errados. O Julia falhou nos 5 pares de contrafactual de política: troca a regra, ele mantém a resposta.

Se você quer o que o Jev entrega, o Laya e o Julia de fábrica ficam muito longe, e nenhum modelo pequeno (GLiNER incluso) chegou perto. Se o seu problema é “preciso classificar texto curto em três baldes, num dispositivo sem internet e sem GPU, e tenho mil exemplos rotulados pra ajustar”, esses dois são os únicos da lista que cabem. O ajuste fino é a parte que eu deixei de testar. É outra pergunta, que precisa de outro benchmark.

A linha de base: Simple-Jev com Qwen comum

O Simple-Jev lendo tokens do Qwen3.5 4B, sem treino de decisão nenhum, tirou 74% no v2 compacto. Isso é a régua de “quanto o treino especializado compra”: Jebadiah, Mapika e Kev, todos em cima de backbones de tamanho parecido, ficaram 13 a 16 pontos acima. O treino compra bastante.

O curioso é que no v1 o Simple-Jev empatou com o Jebadiah (111 de 130 originais) e acertou os dois tickets críticos sem ambiguidade, que vários modelos melhores erraram. Ele também é o mais lento do lote no Strix Halo, quase um segundo e meio por decisão, porque está rodando um LLM inteiro. Na 5090 o mesmo LLM inteiro cai pra 161 ms: a linha de base acelera junto com a máquina, que é o que ela deveria fazer.

Quão difícil é rodar os melhores abertos na sua máquina

Todos esses modelos falam o mesmo protocolo HTTP, chamado SystemOne, que o Jev popularizou: você manda um estado (o texto), uma ou mais perguntas de resposta fechada, e recebe de volta a opção escolhida e a probabilidade de cada uma. Trocar de modelo é trocar a porta. O OpenAI Decisions foge do padrão com um endpoint nativo próprio, mas a ideia é a mesma. O que muda é quanto trabalho dá colocar cada um de pé, e aí a diferença entre eles é grande.

OpenAI: só uma API key

O mais fácil de todos: cria a chave, carrega crédito e chama o endpoint. As 1.048 requisições do benchmark rodaram em 4 minutos, sem uma retentativa. O único soluço foi a primeira sonda devolver “saldo esgotado” até eu colocar US$ 20 na conta.

O Microsoft Decision-1 é quase tão simples: se você já tem conta no OpenRouter, é apontar o modelo e chamar o endpoint de decisões. Sem GPU, sem assinatura Azure, sem instalação. No meu teste, 10 das 504 chamadas do v2 tomaram um 429 e passaram na retentativa, então planeje retry.

Kev e Jebadiah: um pip e um comando

O Kev é o mais simples da turma de 4B. O projeto instala direto do GitHub e sobe um servidor com um comando, baixando o adaptador LoRA e a cabeça de decisão em cima do Qwen3.5 base:

pip install "kev @ https://github.com/jaredpalmer/kev/archive/fc4a17e194bca35a48c57211392ec49ea54a94ac.tar.gz"
python -m kev.serve --run jaredpalmer/kev-4b --host 0.0.0.0 --port 8000 --device cuda

O Jebadiah segue o mesmo padrão, com o pacote do servidor dentro do repositório dele:

pip install "jebadiah-server @ https://github.com/getainode/jebadiah/archive/e9793abc66d1a7c5ad878d51eda656f1e9c5b9f5.tar.gz#subdirectory=server"
jebadiah-serve --model frontier-infra/jebadiah-4b-v2 --host 0.0.0.0 --port 8000

Com qualquer um dos dois no ar, uma decisão é um POST:

curl -s http://localhost:8000/v1/systemone -H 'content-type: application/json' -d '{
  "model": "kev-4b",
  "state": "Cliente diz que foi cobrado duas vezes e pede o estorno da segunda cobrança.",
  "questions": {
    "fila": {
      "type": "choice",
      "instructions": "Escolha a fila correta pela política de suporte.",
      "criteria": {
        "financeiro": "Cobrança, estorno, nota fiscal.",
        "tecnico": "Erro, bug, indisponibilidade.",
        "vendas": "Upgrade, plano novo, orçamento."
      }
    }
  }
}'

A resposta traz a opção e a distribuição de probabilidade, e é nela que você aplica o seu limiar, loga e decide se manda pra revisão humana. Num NVIDIA com CUDA e 16 GB de VRAM, um 4B em BF16 sobe sem drama. Os pesos pesam uns 8 GB. Na 5090, os 4B que testei respondem em 39 a 91 ms.

Laya e Julia: menores ainda

O Laya é um pacote Python com encoder dentro. Instala com pip install laya e o projeto documenta execução em CPU, que é a graça dele. A versão fixada no meu servidor foi a 0.4.1, e o pico de memória do multilingual na GPU ficou abaixo de 2 GB. Pra rodar num notebook sem GPU ou num container pequeno, é o único da lista que cabe sem conversa.

O Julia-1 é parecido em espírito: um runtime Python próprio, uma chamada predict(state=..., questions=...) e pronto, sem pipeline padrão de Transformers. Rodei o mesmo container em GPU e em CPU, e os dois deram o mesmo acerto com as mesmas respostas em 97% dos casos. Em CPU de 4 threads ele responde em 71 ms, o que pra um classificador de borda é ótimo. O problema continua sendo ele acertar no nível da moeda.

Onde a coisa complica: AMD, ROCm e o resto

No meu caso o hardware é AMD, e aí o “um comando” vira um dia de trabalho. Os pontos que me custaram tempo, pra você economizar o seu:

• Nenhum desses projetos testa em ROCm. O Kev tinha um segfault específico do gfx1151 por causa de CUDA graphs (issue 170), corrigido só depois da tag 1.0, então a versão fixada é um commit do main e a tag oficial crasha.
• Os kernels Triton de flash-linear-attention que o Qwen3.5 usa nas camadas DeltaNet são sem suporte testado no gfx1151. Tudo rodou no caminho de PyTorch puro, mais lento que a latência publicada em CUDA. Os 200 ms do Jebadiah que aparecem na tabela são com esse freio de mão puxado; na 5090, com o mesmo protocolo e os mesmos pesos, o freio some e ele faz 39 ms.
• O Mapika Decider força CUDA graphs quando vê o device “cuda”, que no ROCm também se chama “cuda”. Precisei desligar na mão.
• Precisa exportar HSA_OVERRIDE_GFX_VERSION=11.5.1 e PYTORCH_ROCM_ARCH=gfx1151 e usar uma imagem base com o torch de ROCm já validado. Um pip install torch qualquer sobrescreve com a build de CUDA e quebra tudo. No meu Dockerfile cada pacote é instalado com --no-deps e o build falha se o torch deixar de ser o de ROCm.
• Um modelo por container, um container por vez. O Strix Halo tem memória compartilhada entre CPU e GPU, e três modelos de 4B residentes mais o Ollama que já roda ali esgotam os 64 GiB que a GPU enxerga.
• O Perplexity Decider foi o mais chato de todos. O release espera um torch de CUDA específico (troquei pelo 2.9 do ROCm 7), os kernels de flash-linear-attention não existem pra ele (rodei nos kernels de referência do PyTorch, mais lentos), e o carregador padrão estourou o limite de 24 GiB de RAM do host: precisei de um carregador custom que manda os 49 GiB de pesos direto pra GPU. O card do modelo ainda dizia “privado” quando eu comecei, mas a API do Hugging Face confirmava público e sem gate, e os shards baixaram anônimos. O d3, com o mesmo tamanho, herdou o mesmo tratamento. O d3-edge, por sorte, sobe com o carregador padrão do Transformers e 1,3 GB de GPU.

Nada disso é impossível, e está tudo documentado, com Dockerfiles, compose e os hashes de cada checkpoint, no guia de setup do repositório. Só que é um custo real que a planilha de “local é de graça” nunca inclui. Se a sua máquina é NVIDIA, a maior parte dessa lista some.

O Clef completo de 27B eu nem tentei local: são uns 54 GB de pesos em BF16 antes de qualquer ativação. O Perplexity, com 49 GB, provou que um 27B sobe no Strix Halo, ao custo de um segundo e meio por decisão com os kernels de referência. E nem cabe na RTX 5090: 49 GB não entram em 32. O Clef-flash de 9B roda, com uns 18 GB de pesos. Os de 4B são o ponto doce pra hardware de consumidor.

ROCm x CUDA: a mesma receita em duas cozinhas

Todos os modelos locais acima rodaram duas vezes, em duas máquinas minhas. De um lado, o minisforum MS-S1 Max com Strix Halo: Ryzen AI Max+ 395, 64 GiB endereçáveis pela GPU, via ROCm. Do outro, um PC com RTX 5090 (32 GB GDDR7) num Ryzen 7950X3D com 92 GB de RAM, via CUDA. Mesmos checkpoints por hash, mesmos requests, PyTorch 2.9.1 dos dois lados (build ROCm do fornecedor num, cu128 oficial no outro), kernels de referência, sem CUDA graphs, sem quantização, um modelo por vez, protocolo congelado em git antes de qualquer inferência.

Honestidade antes dos números: isso não é comparação de maçã com maçã. São duas implantações inteiras, com GPU, CPU, build e rede diferentes. A 5090 é uma placa absurdamente mais poderosa que a iGPU do Strix. O Strix é uma máquina completa (CPU, RAM, disco, fonte) que custa o que custa só a placa da NVIDIA. O que a comparação mede é a escolha real: qual máquina pra qual modelo.

O resultado em uma linha: a 5090 foi de 1,7× a 10,3× mais rápida em tudo que coube nela, e os campeões do benchmark não couberam. Os detalhes que valem:

O placar de acerto não mudou. Mesmos pesos, mesma pontuação até dois casos de distância por modelo. Alguns rótulos individuais viraram (12 de 504 no pior caso, o Julia; 11 no Simple-Jev), diferença de aritmética de kernel, e as probabilidades diferem na terceira casa decimal em média. Toda conclusão de qualidade da tabela vale pras duas máquinas.

Os campeões de 27B não cabem na 5090. O d3 pesa 48,6 GB e o Perplexity 49 GB em BF16, contra 31,8 GB de VRAM. A placa de consumo mais rápida do mercado não roda os melhores modelos abertos na mesma precisão. Quem quer os 99,4% em casa hoje compra memória, e memória unificada é exatamente o que o Strix vende. Fazer offload pra RAM do PC é outro experimento, que eu não medi e não conto como vitória de ninguém.

O Jebadiah a 39 ms é o resultado prático mais importante. 90,5% de acerto, mais rápido que qualquer hospedado, Jev incluso. Na faixa de até 9B, a 5090 transforma modelos locais na opção mais rápida e mais barata de todas, e a diferença pro Strix (205 ms) é de mundo inteiro: 5,3×.

Modelo pequeno nem sente. Os três minúsculos (Julia, Laya multilingual, Kev 0.8B) melhoraram só 1,7× a 1,8×. Eles já eram limitados por overhead de runtime, com um pé na CPU, não por falta de GPU. Comprar uma 5090 pra servir encoder de 300M é comprar foguete pra buscar pão na padaria.

O maior ganho foi do pior modelo. O GLiNER2.5-Decide acelerou 10,3× (208 pra 20 ms). Continua errando igual, só que rápido. A correlação entre “quanto o modelo melhora na 5090” e “quanto o modelo presta” é negativa nesta amostra, porque os modelos maiores e mais úteis são justamente os que mais tinham pra destravar.

A linha de base escala junto. O Simple-Jev, que é um LLM de 4B inteiro lendo token, foi de 1.349 pra 161 ms (8,4×), chegando perto do Kev 9B no Strix. E o Mapika decepcionou comparado aos irmãos: 2× (186 pra 91 ms), o menor ganho dos 4B, sinal de que o runtime dele já era enxuto no Strix.

Fechando a conta de custo-benefício: pelo preço de só a placa 5090 você leva o minisforum inteiro. Se o seu trabalho é modelo de até 9B com latência de dezenas de milissegundos, a 5090 justifica cada dólar e o ROCm nem entra na discussão. Se o seu alvo é o topo de 27B rodando em casa, hoje a memória do Strix é o único caminho das duas máquinas, e um segundo e meio por decisão é o pedágio. A pergunta certa não é “CUDA ou ROCm”. É “velocidade ou capacidade”.

Destaques e pegadinhas

O Laya truncou todo o português longo. Na condição com distratores, o Laya base reportou truncamento nas 84 chamadas em português, descartando quase 31 mil tokens de estado, e em nenhuma das 84 em inglês. O limite de contexto padrão do checkpoint inglês é só 512 tokens (o multilingual e o typed usam 1.024, configurável até 8.192), e português tokeniza mais pesado. Os outros modelos sequer expõem telemetria de truncamento, então “zero truncamento reportado” neles significa “não sei”.

Português custa mais tokens. Pros mesmos 84 pares de casos, o Jev reportou uns 14% mais tokens de entrada em português que em inglês, e os dois Clef uns 15% mais. Se você orçar uma operação bilíngue pela média em inglês, vai errar pra baixo.

Exemplo no prompt salva modelo fraco? Salva nada. Um exemplo resolvido por classe deixou o Laya igual ou pior; vários agregados dele caíram. Ajudou o Kev 9B (mais 4 pontos) e o Clef em português (mais 3,6 pontos, chegando ao nível do Jev), e quase nada no Jev, um caso a mais em português. Valide exemplo em tráfego real antes de assumir que ajuda.

Tamanho correlaciona, e explica pouco. Entre os 19 competidores de tamanho conhecido, a correlação de Spearman entre parâmetros e acerto compacto foi 0,96. A série Kev é mais informativa: 63% em 0,8B, 87% em 4B, 88% em 9B. O salto grande é de 0,8B pra 4B, uns 24 pontos, com intervalo entre 16 e 33. De 4B pra 9B a diferença compacta cruza zero, e vários 4B nominais, com backbones parecidos, deram resultados bem diferentes. Na família d3, o flagship e o Edge ficam a quase 40 pontos de distância sob o mesmo release, enquanto um 9B, o Microsoft, empata no topo dos hospedados. Tamanho ajuda até 4B; depois disso, a receita de treino manda mais.

O Clef de 27B errou um ticket crítico que dois dos Laya acertaram. No v1, um cenário de severidade diz que perda contínua de dados em produção é crítica, independentemente de quantos clientes afeta. O registro descreve perda permanente confirmada, de um cliente só. Jev, Clef-flash, Perplexity, d3, Microsoft, Laya typed, Simple-Jev e Laya multilingual responderam “crítico”. Clef completo, OpenAI, Laya base, Eikos, Jebadiah, Mapika, Kev 4B e Kev 9B responderam “degradado”.

É um caso só, e taxa de erro exigiria muito mais. Mas mostra que a média esconde exatamente o erro que mais custa. Quando os fatos de impacto são estruturados, a regra de severidade devia estar em código, e o modelo entra só pra extrair os fatos do texto livre.

Hospedado e local divergem com o tempo. O Clef-flash local reproduziu o hospedado nas 520 classificações do v1 e divergiu em 19 das 504 do v2. A Cloudflare mantém a versão dos pesos por trás do alias hospedado em aberto. Se a reprodutibilidade importa, fixe o hash local.

Confiança alta e segurança são coisas diferentes. No v2 compacto, Jev, Clef, os dois Clef-flash, Eikos, Jebadiah, OpenAI, Microsoft, Perplexity e o d3 erraram zero palpites acima de 0,9. O Perplexity é o caso extremo: respondeu nesse nível em 96% dos casos sem errar um, com o d3 logo atrás (94%, zero erros). O Microsoft cobriu 95% e o OpenAI só metade. A ressalva do Microsoft: o recorde limpo é só no compacto, porque com exemplos ou distratores ele erra em português com confiança acima de 99%. O Mapika errou 5% dos palpites nesse nível, o Kev 4B 3% e o Simple-Jev 14%. E os dois menores do lote quebraram o padrão com violência: o Julia errou 48 de 71 palpites acima de 0,9, e o d3-edge errou 14 de 68. A cobertura também variou: o Jev respondeu acima de 0,9 em quase 90% dos casos, o Clef em quase 80%, o Clef-flash em 40% e o Laya base em 2 de 168. No v1 o Jev errou 1% dos palpites acima de 0,9 e o Laya base errou 61%. Um limiar de confiança só serve depois de validado na sua distribuição, e o ECE baixo do Laya typed em português deixou ele nos mesmos 36% de acerto.

O Perplexity não caiu em armadilha de apresentação. Nas três variantes do v1 (opções invertidas, rótulos opacos, comentário malicioso), ele manteve as mesmas respostas do original, sem virar uma única. O d3 repetiu o feito, zero viradas também. O Microsoft só tropeçou nos rótulos opacos (2 viradas, uma pra cada lado); ordem e comentário não mexeram nele. O OpenAI virou 2 em cada variante, e o Laya desabou pra 19% com o comentário. O preço dessa robustez é latência: um segundo e meio por decisão na minha máquina, a pior mediana do lote.

Limiar numérico é problema de código. A tarefa de triagem por limiar, com números claros e regra explícita, deu 100% no Jev e nos dois Clef-flash e menos de 30% nos dois Laya em inglês. Um if resolve isso com 100% e zero latência. O modelo só entra quando o número está enterrado em texto livre, e mesmo assim o certo é extrair o número e deixar a comparação com o código.

Probabilidade de sorteio é outra habilidade. Nas 24 sondagens sem informação (moeda, dado), o Jev teve o pior erro de escolha entre opções. A coroa da estimativa numérica mudou de dono com a estreia da OpenAI: o predicado de sim/não dela errou quase nada, enquanto a sonda de escolha devolveu 94% pra cara numa moeda honesta. O Perplexity, campeão de tudo o resto, respondeu 0,73 pra um evento de chance 1 em 4, e o Microsoft foi no mesmo caminho, dando 87% pra moeda. O Laya typed teve o segundo melhor erro de escolha, atrás só do Kev 9B e colado no Clef, e mesmo assim classificou mal. É o “aluno que marca a letra A” do ensaio do Paulo, agora medido: calibração em sorteio e acerto em classificação são medidas independentes.

Onde os dados convergem

1. O topo geral é de pesos abertos, e agora são dois. O Perplexity Decider 27B e o Decision 3.0 empataram em 99,4% nos compactos, com 100% em português e rótulos idênticos nas 1.024 classificações, os dois com pesos Apache 2.0 rodando na minha máquina. A vantagem deles sobre o Jev é de menos de 2 pontos e o intervalo encosta no zero, então trate como fotografia deste conjunto. O custo deles é hardware e latência, não API. Na nuvem, a ordem de avaliação mudou: comece pelo Microsoft Decision-1, que empata com o Jev no agregado, fecha 100% em português compacto e custa um terço. O Jev entra em seguida, mais rápido e com erros diferentes, porque empate no agregado não é intercambiabilidade. O OpenAI Decisions ficou no meio do caminho em preço e acerto.

2. Rodar local ficou viável em 4B. Jebadiah, Mapika e Kev 4B entregam entre 87 e 90% nos casos compactos com latência de 200 ms no Strix Halo e 40 a 91 ms na RTX 5090, e num piloto com a sua tarefa qualquer um dos três pode ganhar. Se a sua máquina aguenta 49 GB de pesos, o Perplexity entrega o topo da tabela em casa. A conta financeira justifica usar a máquina que já existe, por controle de dado ou por obrigação de ficar offline. Comprar máquina pra isso ela deixa de justificar.

3. Modelo pequeno é outra categoria. Julgar o Laya e o Julia pela coluna de acerto é ler a tabela errada. Eles erram da metade pra cima de fábrica, caem feio sob comentário malicioso, e junto com o d3-edge são os únicos da lista que cabem num dispositivo fraco e respondem em dezenas de milissegundos. O Edge é o melhor dos três em acerto (61%), mas despenca em português e erra um em cada cinco palpites confiantes. Se precisão tipo Jev é requisito, risque os três. Se rodar offline em hardware pequeno é requisito, risque todo o resto e comece pelo ajuste fino deles na sua tarefa, que é a medição que falta. E cuidado com o Julia e o Edge em particular: 48 erros em 71 e 14 em 68 palpites confiantes são o retrato de modelos que não sabem o que não sabem.

4. Português custa uns 14% mais tokens e derruba os modelos do meio da tabela entre 1 e 10 pontos, com Kev 9B e Clef-flash no pior caso. O Jev perde nada, o OpenAI empata as duas línguas, e o Perplexity, o d3 e o Microsoft fecham 100% em português compacto, melhor que o inglês deles, embora o Microsoft volte a errar em português quando o contexto cresce. O Julia faz o caminho contrário e despenca 13 pontos, e o Edge despenca 14. Pra audiência brasileira, essa é a primeira coluna a olhar, antes do preço.

E o que vale pra todos: nenhum desses modelos substitui a regra que já está em código. Limiar numérico, política de severidade com fatos estruturados, permissão de ferramenta, tudo isso fica no if. O modelo entra pra transformar texto livre em fato estruturado. E o teste que importa é o seu, com os seus tickets, porque cada célula desta tabela tem 12 cenários e a sua operação tem milhares.

Os casos, as respostas brutas de cada modelo, os scripts de pontuação e o guia pra reproduzir tudo estão no repositório do benchmark. Se você rodar com os seus tickets e chegar em outro ranking, me conta.

TL;DR pra quem só quer saber qual usar: o Jev é um classificador hospedado, bom e barato pra decisão repetida sobre texto, e não é bala de prata. Se você quer a comparação direta, pule pra Clef, a alternativa aberta da Cloudflare com pesos e imagem; pra Laya, o encoder pequeno pra rodar local e ajustar na sua tarefa; pro ranking público, com 70 modelos lado a lado; ou direto pra como decidir no seu projeto.

Quando o Jev apareceu, eu não dei muita bola. A home era um festival de jargão, Kahneman aqui, Jevons ali, um “193x mais rápido” sem o benchmark do lado, e minha regra pra ferramenta nova de IA é não adotar camada intermediária nenhuma até doer não ter, então não perdi tempo com ele.

Naquele texto eu cheguei na conclusão de que, tirando o marketing, o Jev é um classificador hospedado: você manda um texto e perguntas de resposta fechada, ele devolve a opção e a probabilidade, sem gerar prosa nenhuma. E que o “193x” só impressiona porque a comparação é contra um LLM de chat escrevendo parágrafo pra depois você catar um rótulo lá dentro.

O que eu não tinha percebido na época é o tamanho do hábito que o Jev expõe. Muita gente estava usando LLM de fronteira como substituto caro de um classificador comum, e nunca tinha pensado em classificador, porque nunca precisou pensar: o LLM resolvia, mal e caro, e ninguém media.

Pra mim, classificador seria a primeira ideia, e é por isso que o Jev não me pareceu novidade. Pra muita gente foi revelação. Esse descompasso é o assunto deste texto.

Este texto é uma colaboração

Boa parte do que você vai ler aqui é do Paulo Câmara, neurocientista, cofundador e CTO da LUA Vision, a empresa brasileira cujo modelo eu testei e investiguei nas últimas semanas. Ele escreveu um ensaio, “O aluno que marca a letra A”, pra ser publicado aqui, em que leu as letras miúdas do Jev, abriu os cerca de 350 repositórios de teste que apareceram no GitHub na semana do lançamento e recalculou do zero os quatro resultados principais.

Vale o aviso que o próprio Paulo faz no fim: ele fundou uma empresa que faz modelo próprio e disputa o mesmo mercado. Leia com esse desconto, e confira os números na fonte, que ele linka todas.

Primeiro: o que é um classificador

Classificador é uma função que recebe uma entrada e devolve uma de um conjunto fixo de categorias, normalmente com uma probabilidade pra cada uma. Esse e-mail é spam ou não. Esse ticket é de cobrança, suporte ou vendas. Essa transação parece fraude.

A lista de respostas possíveis é fechada e você conhece ela antes de rodar.

A maneira clássica de construir um é com exemplos rotulados: um conjunto de textos em que alguém já disse a resposta certa. Em cima disso você treina um modelo, que pode ser coisa simples como regressão logística ou naive Bayes, ou um encoder pequeno tipo BERT com umas centenas de milhões de parâmetros. Em qualquer dos casos, o modelo final é pequeno, roda local, responde em milissegundos, custa quase nada por chamada, e devolve números que você consegue calibrar e auditar contra os seus próprios dados. Isso existe há décadas e é matéria de graduação.

Por isso, quando alguém com formação em computação vê um problema do tipo “decidir em qual balde esse texto cai, milhares de vezes por dia”, a primeira pergunta é “quantos exemplos rotulados eu tenho?”, não “qual LLM eu uso?”.

Um LLM de chat é um gerador de texto de bilhões de parâmetros. Usar ele pra devolver um rótulo é pagar por token de saída, esperar segundos por resposta, lidar com formato que às vezes quebra, e aceitar um comportamento que muda quando o fornecedor atualiza o modelo. Dá pra fazer, e desde 2019 a classificação zero-shot com modelo de linguagem está documentada. Só que é a opção cara e lenta, e só compensa quando você não tem exemplo nenhum ou quando as categorias mudam a cada pedido.

O Jev entra exatamente nesse espaço. Ele é um classificador que aceita categorias definidas na hora, várias perguntas sobre o mesmo texto numa chamada só, hospedado, barato por token e rápido.

Comparado com o LLM de chat gerando parágrafo, ele é uma vitória de engenharia. Comparado com um classificador treinado pra uma tarefa estável, ele é uma conveniência que troca controle por flexibilidade. Guarde essas duas réguas, porque o resto do texto vai e volta entre elas.

O artigo do Paulo: “O aluno que marca a letra A”

O que segue é o ensaio do Paulo Câmara, escrito pra este texto. Os subtítulos são dele.

Toda semana aparece um salvador da IA. O desta se chama Jev.

Saiu no dia 15 de setembro, com US$ 40 milhões no bolso, avaliação de US$ 200 milhões e uma promessa que cabe num outdoor: duzentas vezes mais rápido, quatrocentas vezes mais barato, calibrado e incapaz de alucinar. Em 24 horas, 13% dos times pagos do gateway da Vercel já estavam usando. Em uma semana, havia mais de 300 repositórios no GitHub testando o bicho.

Fiz o que faço com todo salvador. Li as letras miúdas, abri os cerca de 350 repositórios, e refiz as contas dos que publicaram o dado bruto. O que encontrei cabe na imagem aí de cima: uma folha de respostas com a letra A marcada em todas as questões.

Quando não tem informação nenhuma para decidir, o Jev marca a primeira alternativa. Em 3.000 de 3.000 sorteios. Com até 92% de certeza. Guarde essa imagem, porque ela explica o resto do texto.

O que ele é, sem outdoor

Tire o marketing e sobra uma prova de múltipla escolha sem redação. Você manda um texto, faz perguntas com resposta fechada (escolher entre até 255 opções, dar nota numa escala, dizer sim ou não) e ele devolve a probabilidade de cada resposta. Não escreve uma linha. Não explica. Não faz conta. Não chama ferramenta.

Isso é bom, e eu quero começar pelo que é bom. Muita empresa hoje usa um LLM de fronteira como um if de luxo: manda o documento, espera o modelo pensar em voz alta por vinte segundos, paga cada palavra que ele escreve, valida o JSON e só então descobre que o ticket era de cobrança. O Jev corta esse teatro. Lê o texto uma vez, dá nota para cada opção, e acabou. Por isso a saída sai de graça e dez perguntas custam quase o mesmo que uma.

O mecanismo, porém, não é novo. Ler a nota de cada resposta possível é como se avalia modelo de linguagem em múltipla escolha desde o GPT-2. É como funcionam os modelos de recompensa do RLHF, técnica que o fundador da TypeSafe ajudou a criar na OpenAI.

Poucos dias depois do lançamento já havia cópia aberta imitando a interface com modelo público, e dez dias depois Stanford e Nvidia soltaram um concorrente de pesos abertos. A TypeSafe não publicou artigo, pesos, tamanho do modelo nem resultado em benchmark público. No FAQ do anúncio, “O Jev é só um LLM menor?” aparece como pergunta. A resposta é uma linha: “não é pequeno nem é um LLM”. Só isso.

Um adversário para cada manchete

A página inicial diz “193,6× mais rápido, 444,6× mais barato”. Refiz a conta com a tabela que a própria empresa publicou. O 444,6 é o custo do Opus 5, o modelo mais caro do painel, dividido pelo custo do Jev. O 193,6 é o tempo do Sonnet 5 dividido pelo tempo do Jev. Um adversário para cada manchete.

É como anunciar que o seu carro é mais econômico que uma Ferrari e mais rápido que um caminhão, e deixar o leitor concluir que ele é o melhor carro do mundo.

Quantas vezes o Jev é mais barato, conforme quem está do outro lado. Fonte: tabela pública da TypeSafe (evals.typesafe.ai) e testes independentes com LLM sem raciocínio.

Contra o modelo barato que acerta parecido, o Luna, o Jev é 8 vezes mais barato. E isso com todos os LLMs da comparação pensando antes de responder, coisa que ninguém faz para rotear ticket. Contra um LLM sem raciocínio, os testes independentes medem cerca de 4 vezes no custo e de 2 a 7 no tempo. Continua sendo muito. Só que é uma ordem de grandeza a menos que o outdoor.

Tem um detalhe que quase ninguém leu. Não existe gabarito nessa avaliação. A “acurácia” é o quanto cada modelo concorda com a média de dois modelos de fronteira. O Jev concorda 67,8% das vezes, igual ao Sonnet 5. O Opus 5 fica em 73,1%.

Concordância com a referência contra custo por caso, média dos quatro workflows da TypeSafe. A faixa verde vai de 66,8% a 67,9%: Luna, Sonnet 5, Terra e Jev.

Quebrando por tarefa, aparece o que a média esconde. Em notas fiscais, que exigem conferir valor, quantidade e data, o Jev fica 17 pontos atrás do melhor modelo (61,8% contra 79,1%) e abaixo até do Luna. A documentação dele avisa que ele “não é uma calculadora”. Pelo menos isso é verdade.

Concordância por workflow. Fonte: evals.typesafe.ai.

E o dado mais sólido do site da TypeSafe nem é sobre o Jev. Todos os oito LLMs avaliados acertam mais quando a tarefa é quebrada em perguntas pequenas e a lógica fica no código. O Haiku 4.5 sai de 18,1% para 53,6%. A lição mais útil do lançamento é de engenharia, e vale para qualquer modelo.

A conta que o preço entrega

Preço é dado técnico disfarçado. A US$ 0,042 por milhão de tokens, uma GPU alugada precisa ler de 13 a 20 mil tokens por segundo só para empatar. Numa conta de cenário, isso fecha com um modelo de 6 a 37 bilhões de parâmetros ativos, que é modelo pequeno, ou com subsídio. A TypeSafe escreveu, com uma sinceridade que eu respeito, que “não tem como provar que não é subsidiado”.

Desde o lançamento, o limite de uso por conta caiu de 250 mil para 100 mil tokens por segundo. A documentação avisa que ele muda “sem aviso” enquanto não chegam os “grandes contratos de GPU”, e a lista de suboperadores mostra a inferência rodando numa nuvem de GPU alugada sob demanda. É modelo de fronteira com capacidade de startup.

Na mesma conta, cada decisão gasta uns 14 joules. Esse é o melhor argumento do Jev, e eu defendo essa régua faz tempo: acerto por joule, e não só acerto. Nisso ele é bom de verdade.

Português de prova

Só encontrei um teste do Jev em português: o ENEM 2025. Refiz a conta a partir das respostas brutas. Foram 103 acertos do Jev contra 102 de um modelo aberto de 120 bilhões de parâmetros. Empate estatístico (p = 1,0).

Acerto do Jev no ENEM 2025 por área, 182 questões válidas, com margem de 95%. Recalculado a partir do repositório patryckalves/jev-no-enem.

O Jev lê português de prova melhor que muito cursinho: 78% em Linguagens. E faz Matemática como quem chuta: 25%, com o chute valendo 20%. Em espanhol, outra auditoria mediu perda de 3 a 6 pontos em relação ao inglês e de 17% a 38% mais tokens pelo mesmo texto. É o imposto do token que eu medi no meu paper, cobrado de novo, agora por outro fornecedor.

Um detalhe a favor: a opção explícita de “inválido” nesse experimento separou as questões mais difíceis. É a rota de abstenção que vale exigir em produção, medindo junto quanto ela deixa sem resposta.

O aluno que marca a letra A

Voltemos à folha de respostas.

Um auditor pediu ao Jev para prever um dado justo, que ele não tinha como ver. A resposta honesta é 1/6 para cada face. Baixei as 1.000 respostas e contei. Em todas, o Jev escolheu a primeira opção da lista que recebeu: o “1” no dado, o “vermelho” no dado de cores, a “cara” na moeda, o “norte” na roleta. Com 76% a 92% de certeza.

Um segundo pesquisador repetiu a mesma pergunta 2.000 vezes, de forma independente. Deu a mesma coisa. A ressalva: isso vale pra pergunta de escolha; na formulação de sim ou não com probabilidade, o mesmo repositório mostra o Jev mais perto da referência, ainda superestimando probabilidade baixa.

Quando não sabe, ele não diz que não sabe. Ele marca a letra A, com convicção.

Probabilidade declarada contra frequência real. Sorteios: 1.000 respostas recalculadas (KantaHayashiAI). Risco cardíaco: 5.000 pessoas do BRFSS, recalculado (rubinagentagi-tech). Itens com discordância humana: estudo pré-registrado com ChaosNLI (GautamTalksDev). ENEM: recalculado (patryckalves).

O gráfico mostra o padrão inteiro. Onde ele tem sinal, como nas respostas do ENEM acima de 0,9, o que ele diz e o que acontece coincidem: 97,1% de confiança, 97,6% de acerto. Onde não tem, a certeza fica e a realidade vai embora.

Num teste com 5.000 pessoas reais, a taxa de doença cardíaca era 9%. O Jev atribuiu, em média, 27%. Recalculei: a probabilidade dele é pior do que simplesmente dizer 9% para todo mundo.

Sistema 1, literalmente

A TypeSafe chama o Jev de “modelo System One”, em homenagem ao pensamento rápido de Kahneman. É a parte mais honesta do produto, só que não pelo motivo que a empresa gostaria. No livro, o Sistema 1 é rápido, barato e automático. Também é onde mora o excesso de confiança: ele monta a história mais coerente com o que tem na frente e não registra o que falta.

Kahneman passou anos discordando de Gary Klein sobre quando confiar na intuição de especialista. Em 2009 os dois publicaram juntos um artigo com o título mais elegante da psicologia: “uma falha em discordar”. A conclusão cabe numa linha. A intuição só merece confiança em ambiente de alta validade, onde existe regularidade e houve feedback para aprendê-la. Fora dele, a confiança continua alta e deixa de dizer qualquer coisa sobre o acerto.

É o Jev, sem tirar nem pôr. Classificar texto em inglês é ambiente de alta validade, e ali ele vai bem. Prever risco, sortear, adivinhar a regra da empresa que ninguém contou para ele: ambiente de baixa validade. Ali ele segue confiante.

No laboratório, a gente separa duas coisas: decidir, e saber se decidiu bem. A segunda se chama metacognição.

Ela se mede com teoria de detecção de sinais, o meta-d′ de Maniscalco e Lau, e depende em parte de regiões pré-frontais distintas das que sustentam a decisão. Fleming e colegas acharam isso na anatomia em 2010, e Rounis e colegas, no mesmo ano, mostraram que estimulação magnética no pré-frontal derruba a metacognição sem mexer no acerto (resultado com replicação disputada por Bor e colegas em 2017). É por isso que existe gente que acerta sem saber que acertou, e gente que erra com convicção de sobra.

O campo que a empresa chama de confidence é uma fórmula sobre a mesma distribuição que produziu a resposta: numa escolha de duas opções, 2p − 1. Isso não é defeito em si. Um observador ideal faz exatamente isso e acerta.

O problema é que a distribuição do Jev perde a calibração fora do que ele conhece, e nada no sistema confere a resposta por outra via. Quando o sinal some, a resposta fica errada e a confiança fica igual, porque as duas são o mesmo número. Num estudo pré-registrado com itens em que cem pessoas discordam entre si, a concordância humana é de 47% e o Jev segue com 81% de confiança. Quando embaralharam as coordenadas de uma tarefa espacial, o acerto despencou para 5% a 22% e a confiança baixou 0,028.

Um modelo que diz 83% sobre um dado que não viu não é calibrado. É assertivo.

Atenção se captura

Eu estudei atenção no doutorado, e esperava ver captura: o estímulo mais gritante vencendo. Não foi o que os testes mostraram. O grito, o famoso “ignore suas instruções”, quase não passa. O que passa é a frase plausível, sem origem conferida. A psicologia tem nome para isso: falha de monitoramento de fonte. O sistema trata uma afirmação que ninguém verificou como se fosse fato.

Decisões viradas por tipo de ataque. Ataque grosseiro: 1 em 1.056 (cwhy). Comando injetado e opinião não verificada: 9.744 variantes (Hu et al., 2026). Contexto fluente otimizado: 312 de 508 decisões corretas (Xu, 2026).

Nos números: o ataque grosseiro passa 1 em 1.056. Uma única opinião não verificada colada no fim do texto virou 12,1% das decisões, empatada estatisticamente com o comando injetado mais forte. Uma linha dizendo “o administrador que encerrou a discussão confirmou que o artigo foi mantido” derrubou o acerto de 96,5% para 26,5%.

Um campo falso dizendo que o usuário tinha pré-aprovado rm -rf ~/.ssh baixou a chance de bloqueio de 0,76 para 0,48. Lembra o efeito de desinformação de Loftus: a informação sugerida reescreve o julgamento.

A captura vale também para pistas que não deveriam contar. Com o mesmo texto, dizer só “quem escreveu é negro” ou “quem escreveu é branco” mudou a taxa de pena de morte atribuída pelo Jev de 29,5% para 62,7%. A direção é o de menos. Uma decisão de vida ou morte andou 33 pontos por causa de uma informação que não tinha nada a ver com o caso.

Tem mais uma que eu não consigo deixar passar. Trocar só o rótulo das opções, de “0/1” para “no/yes”, sem mudar a definição de nenhuma, inverteu 70 de cada 100 respostas. A taxa de erro de tipo continuou em zero. O formato estava perfeito. A decisão estava ao contrário.

Esses números vêm de preprints e de estudos pequenos. A porcentagem exata muda com prompt, tarefa e versão do modelo; a classe de falha, não.

Probabilidade que não fecha

Probabilidade tem uma regra de primeiro semestre: a chance de algo mais a chance do contrário dá 1. Na própria documentação da TypeSafe, “o cliente pede reembolso?” recebe 0,72, e “o cliente pede algo que não é reembolso?” recebe 0,47. Soma 1,19.

O par não é um complemento exato, e a TypeSafe não promete que duas perguntas separadas formem uma distribuição conjunta. Mas é o exemplo que a própria empresa escolheu pra mostrar o produto, e ele não fecha. O conserto é de desenho: uma pergunta de escolha com opções mutuamente exclusivas, em vez de dois sim-ou-não somados.

Gente erra probabilidade de muitas formas, mas nessa costuma acertar. Quando a pergunta vem em par, a chance de algo e a do contrário somam perto de 1. Tversky e Koehler mostraram isso em 1994. O Jev erra onde gente acerta. A mesma decisão muda de valor conforme a redação da pergunta, e isso é o contrário de “probabilidades epistemicamente honestas”.

“Não alucina”

O anúncio diz que o Jev “não consegue alucinar” e mostra 0% de erro de tipo. O zero é verdadeiro e irrelevante. Como ele só pode responder dentro das opções que você deu, é impossível errar o formato. Chamar isso de não alucinar é como elogiar o aluno da letra A porque ele nunca deixa questão em branco. É verdade. E daí?

Num modelo que escolhe, alucinar é escolher errado com convicção. Na verificação de fatos, o Jev empata com o GPT-6 Astra em acurácia, mas chama de “sustentada” uma afirmação sem apoio em 23% dos casos, contra 14% do Astra. Em 76% das situações em que não havia ferramenta nenhuma, ele escolheu chamar uma ferramenta. Com uma regra da empresa que não contaram para ele, errou 19 de 24 decisões, 15 delas com mais de 90% de certeza. Diante de uma lei inventada, absteve-se zero vezes.

Segurança

Primeiro, onde os seus dados vão parar: Estados Unidos, AWS e uma nuvem de GPU chamada Modal. A retenção vale “pelo tempo razoavelmente necessário”, sem prazo, e retenção zero só existe no plano enterprise.

O contrato de dados cita as cláusulas contratuais padrão da União Europeia, o adendo do Reino Unido e a lei da Califórnia, e não tem uma palavra sobre LGPD. Se você mandar dado de brasileiro, a base legal da transferência internacional fica por sua conta, e isso é pergunta pra advogado antes de assinar. A promessa de não treinar com o que você envia existe e é boa. O SOC 2 existe e só aparece a pedido.

Como detector de ataque, o Jev é bom, e com menos alarme falso que muito LLM: pegou 40 de 41 injeções num teste com páginas reais. Como juiz de um conteúdo que traz o ataque dentro, ele cede, como mostrei acima. A diferença parece sutil e decide tudo. Na palestra do GV Angels eu disse que um agente não é funcionário, é uma chave de acesso que conversa. Um portão feito só com o Jev é uma fechadura que abre quando alguém escreve no bilhete que o dono autorizou.

O erro que me preocupa não é o erro com dúvida. Esse vai para revisão. É o erro com 92% de certeza, que atravessa qualquer limiar que você configurar.

A onda

Uma palavra sobre as evidências, porque usei muitas.

Repositórios de teste do Jev criados por dia no GitHub, a partir dos metadados de 346 repositórios indexados.

Em uma semana nasceram cerca de 350 repositórios testando o Jev. Classifiquei todos pelo que eles deixam conferir. São 89 com dado bruto, código, versão fixada e estatística, e 170 com dado e código; o resto oferece menos que isso.

Só 11 escreveram a hipótese antes de rodar o teste. A mediana é de uma estrela no GitHub, o que quer dizer que quase ninguém olhou. E a onda de testes acompanhou a onda de hype: pico em 21 de setembro, quase nada depois do dia 23.

Por isso não aceitei número por autoridade. Os que sustentam este texto eu conferi na fonte, e os quatro principais eu recalculei do zero.

Veredito

Verdade:

• Rápido: de 100 a 400 ms.
• Barato: de 45 a 323 vezes menos que um LLM de fronteira na mesma decisão.
• Empata com o topo em julgamentos estreitos, como verificar se um trecho sustenta uma afirmação.
• Confiável acima de 0,9 em dado parecido com o que ele já viu, depois de você conferir isso no seu.
• Bom detector de injeção.

Castelo de areia:

• 193,6× e 444,6×.
• “Inteligência de fronteira”.
• “Não alucina”.
• Calibração como regra geral.
• Seguro como guarda único de agente.
• Nova arquitetura: ninguém viu.

O Jev não é o salvador de nada. Também não é “só um classificador”. É uma boa peça de engenharia de produto, que embrulha técnica conhecida numa interface que a automação precisava, a um preço que muda o que é viável. O produto é novo. O que ele afirma de novo, até aqui, é marketing: chama formato de verdade, calibração de tarefa de honestidade, e Sistema 1 de virtude.

O que vai quebrar primeiro

• Os portões de agente feitos só com o Jev, porque o ataque que os fura já está publicado e custa centavos.
• Os sistemas que confiam no limiar de fábrica em dado novo, em outro idioma ou com regra interna, porque vão automatizar erro com 90% de certeza.
• Quem usar a probabilidade dele como risco real, em crédito, saúde ou previsão, porque ele infla evento raro.
• E a vantagem de preço, porque em dez dias já havia cópia aberta e concorrente mais rápido.

Se você for usar mesmo assim

• Fixe a versão. O alias jev-latest troca de modelo sozinho, e a sua calibração vai junto.
• Toda pergunta com “nenhuma das anteriores”. Sem ela, ele marca a letra A.
• Embaralhe a ordem e use nomes neutros nas opções. Teste se a decisão muda.
• Recalibre com 50 a 300 exemplos seus antes de escolher limiar. Num teste, o erro de calibração caiu de 0,117 para 0,008.
• Marque como não confiável tudo que vem de fora: e-mail, página, resultado de ferramenta.
• Nunca deixe ele sozinho autorizar ação destrutiva, financeira ou com dado pessoal.
• Conta, data e regra de negócio ficam no código.
• Antes de assinar, compare com a linha de base barata: um modelo aberto lendo probabilidades, ou um classificador treinado se a tarefa for sempre a mesma.

Leia com desconto

Eu fundei uma empresa que faz modelo próprio e disputa o mesmo mercado. Leia com esse desconto. É exatamente por isso que cada número aqui tem fonte aberta: você não precisa confiar em mim, precisa conferir.

E se alguém te vender o Jev como salvador, faça a pergunta que eu faço para toda startup: qual teste, e de quando? Se a resposta demorar, já é resposta.

Fontes do ensaio

TypeSafe. Anúncio do Jev · modelos e limites · confidence · falhas conhecidas do jev-1.13 · avaliação de workflows · adaptador para LLMs · privacidade · processamento de dados · central de confiança

Recalculados pelo Paulo a partir do dado bruto. ENEM 2025 · sorteio cego · risco cardíaco · verificação de fatos

Pré-publicações. Hu et al., JevAdvBench · Xu, JevOut · Sun et al., Type-Safe Is Not Error-Free · Ibrahim e Zaki · Li et al., JEV-as-a-Judge

Testes independentes. discordância humana (ChaosNLI) · replicação do dado · viés de dialeto · 49 tarefas contra LLM sem raciocínio · calibração e negação · recalibração · injeção em discussões da Wikipedia · espanhol · ferramentas · regra interna não informada · coordenadas embaralhadas · ataques grosseiros · detecção de injeção · índice de auditorias

Imprensa. VentureBeat, portões de agente · VentureBeat, CLM-8B

Literatura. Fleming et al. (2010), Science 329 · Rounis et al. (2010), Cognitive Neuroscience 1 · Bor et al. (2017), PLoS ONE 12 · Johnson, Hashtroudi e Lindsay (1993), Psychological Bulletin 114 · Kahneman (2011), Thinking, Fast and Slow · Kahneman e Klein (2009), American Psychologist 64 · Loftus, Miller e Burns (1978), J. Experimental Psychology: Human Learning and Memory 4 · Maniscalco e Lau (2012), Consciousness and Cognition 21 · Ouyang et al. (2022), NeurIPS · Radford et al. (2019), OpenAI · Tversky e Koehler (1994), Psychological Review 101 · Câmara (2026), Inherited Weights, doi:10.5281/zenodo.22899767

As alternativas abertas: Clef e Laya

Desde o lançamento do Jev, a categoria ganhou concorrência aberta, e isso muda a conversa sobre “arquitetura nova”. Dois nomes importam.

Clef, da Cloudflare

Em 1º de outubro a Cloudflare lançou o Clef e o Clef-flash: a mesma abstração do Jev (um estado compartilhado, várias perguntas tipadas, distribuição sobre as opções), com API compatível, pesos abertos sob Apache 2.0 e entrada de imagem. A arquitetura é descrita: um Qwen congelado como base (27B no Clef, 9B no Clef-flash), adaptadores LoRA e uma cabeça que dá nota direto a cada opção permitida, treinada com objetivo de classificação e de calibração. Ou seja, a linhagem que o Paulo apontou, agora com código inspecionável.

Isso não prova que a TypeSafe usa a mesma coisa, mas prova que dá pra reproduzir o produto com componente conhecido. A Cloudflare rodou o Decision Index, uma suíte aberta e independente com dezenas de tarefas de classificação, roteamento, retrieval e segurança, e publicou a tabela. Alguns pontos:

Lendo a tabela inteira: o Clef aparece mais forte na maioria das tarefas, o Jev ainda ganha algumas, e é uma rodada interna da Cloudflare, numa suíte pública que pode ser treinada contra. O preço hospedado é o outro lado: US$ 0,24 por milhão de tokens no Clef e US$ 0,09 no Clef-flash, contra US$ 0,042 do Jev. O Jev continua sendo o serviço hospedado mais barato dos três, por uma margem de 2 a 6 vezes, e continua sendo só texto.

Laya (e o Arbiter)

O Laya ataca o problema pela outra ponta. São encoders pequenos, de 322 a 421 milhões de parâmetros (ModernBERT-large na versão tipada), com uma cabeça de escolha, Apache 2.0, feitos pra rodar local e ser ajustados pra uma tarefa recorrente. O Arbiter empacota eles atrás de uma API compatível com o Jev, com batching e deploy em Mac e NVIDIA. O Arbiter é só camada de serviço.

O README do Laya é raro de tão explícito sobre os limites, e eu prefiro repetir do que suavizar:

• os checkpoints base pontuam perto do acaso no benchmark de decisão tipada do próprio projeto; os 0,766 de acurácia que aparecem na manchete vêm de um checkpoint ajustado no split de treino daquele benchmark;
• os modelos saem superconfiantes de fábrica, e a calibração precisa ser refeita no domínio de implantação;
• o contexto da versão tipada é de 1.024 tokens, bom pra ticket e mensagem curta, insuficiente pra documento longo sem chunking;
• com mais de 50 opções, a cabeça de classificação satura e o próprio Laya relata o Jev se saindo melhor.

Nada disso é defeito da ideia. É aprendizado de máquina aplicado do jeito que sempre foi: modelo pequeno é excelente quando a tarefa é estável e existem exemplos rotulados, e comportamento zero-shot amplo exige modelo pré-treinado bem maior. O Laya é a opção quando privacidade, operação offline, latência previsível ou ajuste fino no seu domínio importam mais do que fazer pergunta arbitrária sobre documento arbitrário. É, no fundo, o classificador clássico do começo deste texto, com uma interface moderna.

Existe ainda o Kev-9B, outro Qwen 9B congelado com LoRA e cabeça de decisão, Apache 2.0, que cabe numa GPU de 24 GB. Três implementações abertas em menos de três semanas dizem o mesmo: modelo de decisão tipada virou padrão de implementação.

O Decision Index: como medir isso você mesmo

Toda essa discussão sobre “quem é melhor” só tem sentido com uma régua pública, e ela existe. O Decision Index é uma suíte aberta, sem ligação com a TypeSafe, feita pra modelo de decisão tipada: estado mais perguntas de escolha ou sim-ou-não, uma probabilidade pra cada opção.

A versão atual, 0.2.1, conta 38 benchmarks em cinco áreas (ferramentas e automação, retrieval e classificação, conhecimento e raciocínio, compreensão de linguagem, gosto humano), uns 120 mil pedidos no total, com duas regras que importam: a nota é corrigida pelo acaso (0 é chute aleatório, 100 é perfeito) e pedido sem resposta conta como errado. Sem truncar entrada, sem filtrar opção, sem ajustar prompt por benchmark.

O placar ao vivo tem 70 modelos mais o Jev como referência. Baixei o arquivo de dados do placar e refiz a tabela; abaixo vai o topo e os nomes que apareceram neste texto. Latência é a mediana medida pelos mantenedores numa RTX PRO 6000, um pedido por vez; a do Jev é de API hospedada, então não compara com as demais.

“Pesos abertos” quer dizer checkpoint publicado no Hugging Face; “código aberto sobre modelo aberto” é técnica de inferência publicada em cima de um Qwen ou Gemma de prateleira, sem checkpoint próprio. O placar não registra a licença de cada um, então confira antes de usar em produto.

Três leituras saem direto da tabela:

1. O único modelo fechado da tabela é o Jev. Ele lidera, mas por meio ponto sobre um fine-tune aberto de um Gemma 4 de 26 bilhões de parâmetros, e o placar trata diferença abaixo de 0,25 como empate. Os dez primeiros são todos modelos abertos de 12 a 32 bilhões de parâmetros com adaptador em cima, exatamente a receita que o Clef descreve.
2. O encoder pequeno zero-shot fica no fundo: Laya com 6, Lavoir com 9. Isso bate com o que o README do Laya admite e com o que eu disse sobre classificador clássico, que precisa de exemplo rotulado pra brilhar.
3. Um LoRA de 4 bilhões como o Hopper entrega 41 pontos a 23 milissegundos, uma faixa que muito problema real não precisa ultrapassar.

E como ler o Laya no fundo da tabela? O Decision Index mede uma coisa só: responder, sem treino extra, 38 tipos de pergunta que o modelo nunca viu, de xadrez a tributação. Isso é o que um serviço hospedado precisa fazer, porque não sabe qual pergunta vem. Um encoder de 400 milhões de parâmetros nunca vai ganhar essa prova, e o Laya nem tenta: a nota de 6 é o checkpoint base, sem ajuste nenhum.

O mesmo modelo ajustado com os seus exemplos, numa tarefa estável, aparece com 0,77 no benchmark do próprio projeto. O ranking responde “quem é o melhor generalista zero-shot”, que é a pergunta de quem vende API. A pergunta do programador normal é outra: “nesta decisão repetida, com os exemplos que eu tenho, o que acerta mais pelo custo que eu aceito?”. Pra essa, o fundo da tabela pode ser a resposta certa, e nenhum placar público substitui o teste no seu dado.

Então o Laya é inútil perto dos outros? Como generalista zero-shot, sim, e o placar está certo em dizer isso. Como ferramenta de programador, a conta é outra. É o único modelo dessa tabela que roda em CPU de notebook e responde em 6 milissegundos, com 400 milhões de parâmetros que cabem em qualquer servidor que você já tem; Hopper e Kev pedem GPU, e o Jev pede internet, chave de API e um contrato de dados.

Ajustado com os seus exemplos, numa taxonomia que não muda toda semana, o próprio autor do Laya relata o modelo ganhando do Jev em algumas tarefas e perdendo onde há muitas opções, em testes publicados por terceiros com prompts e amostras diferentes, portanto indicativos e não controlados. Ou seja: inútil pra responder qualquer pergunta sobre qualquer texto, e muito útil pra responder a mesma pergunta mil vezes por dia, de graça, sem mandar dado pra fora.

O Clef não está no placar: o 0.2.1 fechou em 27 de setembro, e a Cloudflare lançou o modelo no dia 1º. Os números que mostrei na seção anterior são de uma rodada interna da Cloudflare em cima das mesmas tarefas, por benchmark, sem o índice agregado. Também já tem fornecedor dizendo que passou do Jev no mesmo scorer, mas por enquanto é número autodeclarado em blog, e não entrada no placar. Vale esperar a inclusão oficial antes de comparar.

Rodar você mesmo é trabalho de um dia, e o kit cuida da parte chata:

1. pip install -e ".[transformers,rebuild]" e python -m decision_index suite rebuild. A suíte não é redistribuída por causa de licença, então o kit baixa as fontes (uns 7 GB, com o HLE exigindo aceitar os termos no Hugging Face) e reconstrói os arquivos com hash verificado contra o do laboratório.
2. python -m decision_index suite sample --n 100 pra um teste rápido, e depois pipeline --engine http --option base_url=... --option model=... contra qualquer servidor que fale o formato POST /v1/systemone. Isso cobre o próprio Jev, com a chave da API, e o Laya atrás do Arbiter. A API do Clef é anunciada como compatível, então em tese entra pelo mesmo caminho, mas eu não testei.
3. score aplica a mesma matemática do placar, e os mantenedores afirmam que ela reproduz todos os 67 participantes da edição atual. Quem tem GPU na nuvem roda tudo como um job único do Hugging Face numa RTX PRO 6000 com hf-job.

Eu não rodei a suíte inteira pra este texto; a tabela acima é o arquivo do placar refeito, e não uma medição minha. Duas ressalvas de quem usa esse tipo de régua: a suíte é pública e congelada, então dá pra treinar contra ela, e o próprio placar diz que a saída da API do Jev já mudou em 20 escolhas da amostra de latência desde a rodada original, sem mudar a nota. Benchmark público serve pra descartar modelo fraco e pra achar candidato. A decisão final continua sendo o seu conjunto rotulado, como eu explico a seguir.

Como programador deve pensar nisso

A pergunta útil deixou de ser “o Jev é novidade?”. Virou: pra uma decisão específica, medida, do seu sistema, qual combinação de qualidade, preço, latência, privacidade, contexto e manutenção bate o que você já tem, seja regra, classificador ou LLM com saída estruturada? Nenhum benchmark de fornecedor responde isso sem os seus próprios exemplos rotulados.

Ferramenta do tipo Jev serve quando o mesmo tipo de julgamento sobre texto acontece muitas vezes, as ações possíveis cabem numa lista, o código em volta consegue aplicar regra exata, e uma resposta errada pode ser detectada ou mandada pra revisão. É esse o formato:

• triagem de ticket;
• ranking de uma lista curta já recuperada;
• roteamento de pedido pra modelo maior ou menor;
• sinalização de trace de agente pra revisão humana;
• escolha entre spans que o código ou o OCR já encontraram.

Fora dele, a ferramenta está no lugar errado:

• quando a entrada é imagem ou áudio;
• quando a saída precisa de prosa ou citação;
• quando um parser exato já resolve;
• quando um erro de classificação concede acesso ou executa ação destrutiva.

Olhei a minha própria carteira de projetos com essa régua, e o resultado é um balde de água fria útil: a maioria precisa de modelo especialista de visão ou áudio, de regra determinística ou de texto gerado, e tem pouca decisão repetida, cara e ambígua o suficiente pra justificar mais um serviço de modelo. Uns poucos candidatos sobraram, os mais claros sendo roteamento de modelo no FrankClaw e ranking de lista curta no ai-memory. Nenhum é gargalo demonstrado hoje. Suspeito que a sua carteira seja parecida.

Se um gargalo aparecer, o piloto é curto:

1. Escolha uma decisão só e defina as respostas permitidas, incluindo “não sei” quando isso for um resultado real.
2. Separe exemplos reais, com caso fácil, ambíguo e adversarial, e rotule de forma independente. Se o seu produto fala português, inclua português.
3. Compare o que você já tem, uma regra ou classificador simples, o Jev com versão fixa, e um LLM barato com saída estruturada, todos com a mesma entrada e a mesma política de decisão.
4. Meça matriz de confusão, calibração por faixa de confiança, custo por caso tratado corretamente, latência de ponta a ponta e taxa de revisão. Roteador barato que manda trabalho difícil pra modelo fraco custa mais no total.
5. Implante como feature reversível, com log, rota conservadora de revisão e fallback. Julgamento de segurança ou autorização é consultivo, salvo se uma política exata aplicar a ação de forma independente.

O que o Jev fez de bom foi lembrar a indústria de que classificação existe. Isso vale o hype que ele recebeu, e talvez um pouco mais.

Nem ele nem os primos abertos dele são bala de prata. São mais uma ferramenta, pra um tipo específico de tarefa, que o seu código precisa cercar com regra, calibração e revisão. Quem já pensava em classificador antes de setembro não ganhou nada novo; ganhou uma API conveniente. Quem nunca tinha pensado ganhou a parte mais valiosa, que é a pergunta: por que você estava pedindo pra um LLM de bilhões de parâmetros escrever um parágrafo pra te dizer em qual balde o texto cai?

Os dois pegaram toda sabotagem barulhenta; o House deixou passar os dois itens silenciosos que quase todo modelo deixa (#7b e #8), e o Enterprise deixou três (#7a, #7b e #9). O custo nocional do House, uns $460, foi o mais caro da tabela inteira, e a causa era ausência de cache de prompt na API.

Muita coisa aconteceu desde então, e este texto é a continuação. Vou na ordem que interessa: primeiro os números novos, depois a pergunta que todo mundo me fez em comentário e DM (“isso não é um Qwen com adesivo?”), e só no fim a parte especulativa sobre o que a empresa diz que construiu.

O spoiler que justifica o texto: depois que a LUA corrigiu a API, o House refez o benchmark em 95,5. Na minha tabela, isso é empate com o Claude Fable 5.1 e o GPT 6 luna, e o custo da rodada caiu 85%. Não estou dizendo que é um Fable em todos os sentidos; estou dizendo que, neste cenário de teste, se saiu como um. Os detalhes, e as ressalvas de ruído, vêm logo abaixo.

Antes disso, o pano de fundo que deixa tudo isso estranho: o consenso da indústria é que treinar modelo de fronteira custa dezenas ou centenas de milhões de dólares em GPU, e que, portanto, uma empresa pequena, sem rodada de investimento bilionária, não deveria chegar nem perto de um. O gpt-oss, o modelo aberto da própria OpenAI, com o laboratório mais bem financiado do mundo atrás, não conseguiu completar o meu benchmark no mesmo harness em que o Genesys PI rodou. O modelo brasileiro completou duas vezes por tier.

Este texto é organizado em cima dessa tensão. Primeiro, o que o modelo fez em experimentos que eu controlo. Depois, o que eu consegui e o que não consegui verificar sobre como ele existe.

Disclaimer novo

Desde o primeiro artigo, conversei diretamente com dois dos quatro cofundadores da LUA Vision: Paulo Câmara, CTO, e Eronides Junior, CRO. O Paulo é o responsável técnico, formado pela FGV com doutorado pela Universidade de Tel Aviv, e a tese dele é a origem declarada da arquitetura do modelo.

Antes da LUA, segundo o LinkedIn dele, o histórico é de consultoria corporativa pesada, implantação de Oracle EBS e ERP em empresa grande, e ele mantém uma série de ensaios sobre IA no LinkedIn. Já o Eronides cuida do lado comercial; antes da LUA ele foi CRO da SoftwareOne Brasil, depois de passar por marketing, serviços e operações na mesma empresa.

Repito o que já disse e vale dobrado agora que falei com eles: não tenho relação comercial nenhuma com a LUA Vision. Não sou sócio, não sou investidor, não assinei contrato, não assinei NDA, não recebi nada além da mesma chave de avaliação gratuita do teste anterior. Nada deste texto passou por eles antes de publicar. Até aqui, sou só um cara curioso com uma API na mão.

Esse último detalhe importa mais do que parece. Como não assinei NDA, nunca tive acesso a nenhum dado interno da empresa: nem peso, nem receita de treino, nem curva de loss, nem conta de hardware. Tudo o que vem abaixo é experimento de caixa-preta em cima da API pública e consulta a informação pública. Onde eu digo “checado”, foi eu que medi; onde eu digo “eles dizem”, é a palavra deles.

Os números novos: re-teste depois das correções

Depois do primeiro artigo, o Paulo avisou que tinha corrigido alguns bugs na API, o principal sendo justamente o cache de prompt, e pediu que eu rodasse de novo. Rodei. É uma rodada limpa e independente dos dois tiers, no mesmo protocolo de 14 sabotagens, com a rodada original preservada intacta pra comparação lado a lado. Um detalhe de método: o v4 é um benchmark de rodada única, então a nota de vigilância tem ruído, e eu volto nisso já já.

Antes de rodar, confirmei que o cache existia mesmo. Um probe com prefixo repetido no endpoint devolveu cached_tokens: 4121 / 4124 na segunda chamada. No teste original, esse número era sempre zero.

Pra situar na tabela geral: na rodada original, o House empatava com o Grok 4.7 em 83,5. Com 95,5, ele passaria a empatar com o Claude Fable 5.1, o Sakana Fugu Ultra v2 e o GPT 6 luna, na posição 9 entre 46 modelos. O Enterprise, a 82,0, empataria com o DeepSeek V4 Pro (base). Digo “empataria” porque, como explico abaixo, mantive a rodada original como entrada oficial do ranking.

E vale deixar a régua explícita: não estou dizendo que o Genesys PI é equivalente ao Fable em todos os sentidos. Estou dizendo que, neste cenário de teste específico, ele se saiu como o Fable. Em outra carga de trabalho, o seu resultado pode ser diferente.

O que melhorou de forma clara e reproduzível:

• Custo caiu 85% a 87%. O volume de token foi o mesmo, uns 40 milhões no House e uns 20 milhões no Enterprise, mas agora o contexto repetido é cobrado na taxa de cache em vez do preço cheio de entrada. O House sai de rodada mais cara da tabela pra custo médio.
• Confiabilidade. A rodada original do Enterprise precisou de uma segunda tentativa por causa daquele loop de grep no primeiro sprint. No re-teste, convergiu de primeira. Nenhum loop nos dois modelos.
• Disciplina de teste. O Enterprise original não escreveu teste automatizado nenhum. No re-teste, escreveu uma suíte RSpec de verdade, com teste de model, request e sistema.
• Detecção mais cedo. Os dois pegaram as sabotagens barulhentas (#1 a #3) até o sprint 3, e o House pegou tudo de #1 a #6 até o sprint 4, coisa que as rodadas originais deixaram, em parte, pro capstone.

O que não dá pra afirmar é que o modelo ficou mais vigilante. O House subiu 12 pontos, mas o Enterprise caiu meio ponto na mesma rodada. Como cache de prompt não tem como afetar detecção de sabotagem, dois tiers do mesmo modelo andando em direções opostas é o retrato de variância de rodada única.

Os +12 do House são grandes o suficiente pra sugerir que os outros ajustes do Paulo melhoraram o modelo, mas uma rodada por modelo não confirma isso. Pra separar sinal de ruído eu precisaria de três ou mais rodadas por modelo, o que não fiz.

Pra calibrar o tamanho desse ruído: nesta mesma semana, o GPT 5.5, que tinha 100,0 na tabela, rodou de novo com modelo e harness idênticos e fechou em 91,0. Nove pontos de diferença sem mudar nada. Então trate as notas de vigilância como uma faixa.

E os dois sobreviventes silenciosos continuam lá. No re-teste do House, o índice derrubado sem teste de guarda (#7b) e o agregado escondido (#8) só foram corrigidos na revelação; no do Enterprise, nem na revelação. É o mesmo ponto cego de disfarce que a maioria da tabela tem, incluindo modelo de fronteira.

Pra guardar: o bug de cache está corrigido e verificado, e a redução de custo é real. A nota de vigilância ficou dentro do ruído: Enterprise igual, House pra cima mas sem confirmação estatística. Na tabela geral, mantive as rodadas originais como entrada oficial, justamente pra não premiar uma rodada só.

Preço: ainda não é o final, e não vai ser por token

Os valores de custo acima continuam sendo nocionais, calculados em cima da tabela de exemplo que a API expõe, e a própria LUA já avisou, no artigo anterior, que aquilo não é o preço de mercado. Conversando com o Eronides, ele detalhou o que vem por aí: eles não pretendem cobrar por token, como todo mundo cobra, e o produto não é pra ser B2C como os chats de assinatura. A aposta é B2B, por licença de uso, com o modelo rodando na infraestrutura do próprio cliente.

Na prática, isso significa uma empresa com um modelo na faixa do Grok, capaz de tarefa avançada como programação, rodando on-premise, fora da nuvem, com a garantia de que nenhum dado sensível sai do prédio. Modelo de fronteira hoje é serviço de nuvem de empresa estrangeira, e setor regulado convive mal com isso. Se a LUA conseguir entregar exatamente esse pacote, e o “se” continua grande, isso muda o jogo pra muita empresa brasileira.

Mesmo com a ressalva de que o preço por token é só exemplo, o custo nocional ao lado da tabela ajuda a calibrar. As rodadas completas mais baratas do campo inteiro são o DeepSeek V4 Flash ($0,97) e o MiMo V2.5 Pro ($1,03); o Enterprise, a ~$2,40, fica nessa vizinhança. Do outro lado, o Opus 5.5 custou $16,63, o Sonnet 5 uns $27 e o GPT 5.5 $34,69. E o House, que na rodada original era a rodada mais cara de todo o campo, agora está no meio do pelotão.

A política de preço, segundo eles, sai em 7 de outubro de 2026.

Experimento extra: o Genesys PI auditando o ai-jail

Benchmark de sabotagem mede vigilância dentro de um app pequeno e controlado. Eu queria ver o modelo num problema de verdade, então dei pra ele o meu ai-jail, o sandbox de sistema operacional que roda agente de código dentro de bubblewrap, Landlock e seccomp no Linux e sandbox-exec no macOS. É um projeto em Rust, com 776 testes unitários, 70 crates de dependência e uma superfície de segurança que eu conheço bem.

A tarefa: auditoria de segurança completa da versão 2.3.0, no commit f62d576, somente leitura, com ameaça modelada, evidência por linha de código e reprodução onde desse. Quem quiser conferir pode abrir o repositório nesse commit e seguir as referências de arquivo e linha dos relatórios.

Pra ter régua, rodei uma segunda auditoria independente, com outro modelo, sem acesso ao relatório do Genesys até fechar a própria lista de candidatos. Depois cruzei os dois relatórios e ainda comparei contra dois security advisories que estavam abertos no GitHub, escritos por gente de fora contra versões anteriores do projeto.

O relatório do Genesys PI (chamo de auditoria A) veio com 26 achados: 5 High, 17 Medium, 3 Low e 1 informativo. O da segunda auditoria (B) veio com 12: 2 High, 7 Medium e 3 Low. O cruzamento:

• 11 achados em comum, incluindo os dois High que importam de verdade: metadado de worktree forjado que expõe qualquer diretório do host pra leitura e escrita, e entrada de ambiente duplicada que passa por cima do isolamento de credencial. Os dois foram reproduzidos empiricamente pelas duas auditorias, de forma independente.
• 11 achados só na A, entre eles toda a superfície do macOS (a B não tinha Mac), a classe de esgotamento de recurso no proxy de egress, e uma corrupção de cadeia de auditoria entre processos que a B só tinha rejeitado no caso mais simples.
• 3 achados só na B, sendo um Medium relevante que a A não viu: duas variáveis de ambiente de teste que sobrevivem no binário de release e desligam a proteção contra SSRF e a validação de raiz TLS.
• A B rejeitou um bug real (comparação de largura errada numa regra de seccomp) e só o confirmou depois que a A apontou. A A não cometeu erro equivalente.

Contra os advisories externos, o placar também favorece a A: dos cinco achados do advisory mais grave, a A pegou quatro e a B pegou dois (mais um depois da pista da A). Os dois deixaram passar o mesmo item, um caminho em que a configuração de projeto não confiável consegue limpar o modo lockdown, o que serve de lembrete de que nenhuma auditoria sozinha fecha a lista.

Não estou dizendo que o Genesys PI é o melhor auditor de segurança que existe; foi uma comparação de dois modelos, num projeto só, numa rodada só. Estou dizendo que, num código de verdade, com ameaça de verdade, ele produziu o relatório mais forte dos dois, com severidade calibrada e reprodução empírica dos itens críticos, e eu vou consertar a lista dele. Isso é mais do que eu esperava ver de um modelo que a maioria das pessoas nunca ouviu falar, e mais do que o gpt-oss, que nem chegou ao fim do benchmark de sabotagem, teria condição de fazer.

A pergunta que todo mundo fez: isso é um Qwen rebatizado?

Não me ofendo com a pergunta, eu mesmo fiz. Modelo brasileiro, equipe pequena, nota de fronteira: a hipótese mais barata é que exista outro modelo por baixo. As três versões da suspeita que chegaram até mim foram: é um Qwen ou DeepSeek com adesivo; é o gpt-oss da OpenAI com outra roupa; ou a API é só um proxy pra Claude ou GPT.

O limite disso tudo vem antes de qualquer resultado. Numa situação de caixa-preta, sem acesso a peso, é impossível afirmar com 100% de certeza de onde um modelo veio. O que dá pra fazer é excluir hipóteses. Foi isso que eu fiz, com um conjunto de testes reproduzíveis que estão no repositório do benchmark, e depois pedi pro Grok revisar o método e o texto como um avaliador hostil, pra tirar qualquer conclusão que estivesse mais forte do que os dados.

O teste decisivo: o tokenizador

Cada família de modelo tem um tokenizador próprio, o vocabulário e as regras que quebram texto em token. Um fine-tune, um LoRA ou um pré-treino continuado herda o tokenizador do modelo base; não dá pra trocar sem retreinar do zero. Então o tokenizador funciona como impressão digital de linhagem.

Medi quantos tokens a API da LUA cobra por uma bateria de strings (chinês, português acentuado, inglês, sequência de dígitos, emoji com ZWJ), cancelando o prompt de sistema que eles injetam, e comparei com os tokenizadores de referência rodando localmente: o200k da OpenAI, cl100k, Qwen, DeepSeek, Llama 3 e Mistral. A distância somada até a LUA, na rodada final do teste (tokenizer_v2 no repositório):

• o200k (OpenAI): 2
• Llama 3: 68
• cl100k (GPT-4, Phi-4, DBRX): 134
• Qwen: 193
• DeepSeek: 255
• Mistral: 289

Os discriminadores mais fortes: chinês empacota do jeito do o200k e não do jeito mais apertado do Qwen, uma sequência de dígitos custa 67 tokens onde Qwen e DeepSeek cobram 200, e emoji com ZWJ só bate com o o200k.

Ou seja: o Genesys PI usa o o200k_base, o tokenizador público da OpenAI, com confiança alta. Isso mata a hipótese de Qwen, DeepSeek, Llama ou Mistral rebatizado, porque nenhum deles usa esse vocabulário e nenhum fine-tune conseguiria adquirir ele. Um segundo teste, de tokens mal treinados (as strings chinesas que todo modelo o200k da OpenAI corrompe ao repetir), deu o mesmo resultado: a LUA erra exatamente as mesmas 3 de 8 strings que gpt-oss, GPT-4o-mini e GPT-5 erram (o GPT-4o erra essas três e mais uma), enquanto Claude e Qwen reproduzem todas limpas: embeddings nativos da família o200k.

Não é o gpt-oss de fábrica

O gpt-oss, o modelo aberto da OpenAI, é o único peso público relevante que usa a mesma família de vocabulário, então era o candidato natural. Mas o gpt-oss serve com o o200k_harmony, uma variante que tem tokens especiais próprios (<|channel|>, <|message|> e afins) como token único. Na API da LUA, cada um desses marcadores custa uns 4 tokens de texto comum. O vocabulário é o o200k_base puro, sem os tokens do Harmony.

Isso exclui o gpt-oss servido do jeito padrão. E o próprio benchmark ajuda: o gpt-oss, nas duas versões, não conseguiu completar o v4 no mesmo harness opencode em que a LUA rodou. O peso cru nem constrói o app, enquanto o Genesys PI passa pelos sete sprints, o House em Tier A e o Enterprise em Tier B. Um adesivo leve em cima do gpt-oss não faz isso.

O que esse teste não exclui é alguém pegar o peso do gpt-oss, arrancar o Harmony na hora de servir, botar um template próprio por cima e retreinar bastante o comportamento de agente. Nesse ponto, o resultado já seria um modelo novo pra efeitos práticos, mas a linhagem seria OpenAI, e essa célula fica em aberto na tabela.

Não é um proxy fino pra Claude ou GPT

A API da LUA rejeita temperature, top_p, n, presence_penalty e logprobs, que a API de chat clássica da OpenAI aceita, e rejeita também min_p, top_k e repetition_penalty, que qualquer servidor vLLM na frente de um modelo aberto aceitaria. Os cabeçalhos HTTP são todos x-lua-*, sem rastro de OpenAI, Anthropic, Cloudflare ou OpenRouter. Um proxy transparente repassaria os parâmetros e deixaria algum rastro.

O benchmark reforça isso de um jeito que gostei. Se a LUA fosse um passthrough do GPT 6 luna ou do GPT 5.5, ela herdaria a força deles nas sabotagens silenciosas: o GPT 5.5 pegou #7b e #8 sem aviso, o luna também.

A LUA falha exatamente nesses dois itens, de forma estável, nas quatro rodadas que fiz. Um proxy não fica consistentemente mais fraco que o modelo que está por trás numa característica específica. Isso é o retrato de um modelo com fraquezas próprias.

Alguém poderia perguntar se eu só comparei com a família OpenAI. Não. Peguei a assinatura mais discriminante do benchmark, o conjunto de itens que cada modelo nunca corrigiu, e comparei a da LUA contra todos os cerca de 44 modelos da tabela. O par {#7b, #8} do House aparece mais perto da família Qwen (Qwen 3.7 Max e Qwen 3.8 27B) do que de qualquer OpenAI, que em geral fecha sem item nenhum.

Só que isso é artefato de faixa de nota, não de linhagem: #7b e #8 são as duas sabotagens mais disfarçadas, e todo modelo na faixa dos 80 pontos erra as duas, de qualquer família, enquanto o re-teste da LUA a 95,5 não deixou nenhuma.

O resultado interessante é que os três sinais comportamentais da LUA apontam pra três direções diferentes: a cauda de erro parece Qwen, a correção rara do #6 parece GPT 6 luna, e o tokenizador e o formato da API parecem OpenAI. Um proxy ou clone de verdade parece com um único modelo em todos os eixos ao mesmo tempo. A LUA não parece com nenhum modelo da tabela em todos os eixos.

Teve uma coincidência que vale registrar: dos cerca de 40 modelos cuja correção eu verifiquei, só dois adicionaram um índice único LOWER(email) no banco ao corrigir a sabotagem #6. Foram a LUA e o GPT 6 luna.

É uma convergência rara, mas é também a correção mais completa possível, o tipo de coisa que dois modelos cuidadosos podem chegar sozinhos. E os dois pegaram o item em momentos diferentes da rodada. Levanta uma sobrancelha, mas não chega a suspeita.

Fica em aberto, porém, um wrapper grosso, com bastante lógica própria, na frente de uma API de raciocínio. A API deles aceita reasoning_effort, que é um controle específico de modelo de raciocínio da OpenAI, e um contexto silencioso de 250 mil tokens. Isso é compatível tanto com uma pilha própria que copiou a interface da OpenAI quanto com um wrapper mais elaborado. Caixa-preta não separa os dois.

O que fica em aberto: do zero ou destilado

Aqui está o limite que nenhum teste de API atravessa. Um modelo novo, com peso próprio e tokenizador o200k, pode ter sido treinado do zero em dado próprio, ou pode ter sido treinado do zero em cima de saídas de Claude e GPT (destilação). Os dois produzem exatamente as mesmas observações que eu fiz.

Tentei uma grade de similaridade com 20 prompts contra um painel de professores possíveis, e o resultado foi nulo: nenhum professor se destacou nos dois eixos que consegui medir (o terceiro eixo, similaridade por embedding, travou por falta de crédito na API e ficou de fora), o que é consistente com mistura própria e também com uma sopa de traços de vários professores. “Não é Qwen” não vira “treinado do zero”.

Uma inconsistência que preciso registrar

A pesquisa publicada da LUA, o paper “O peso que você não escolheu”, gira em torno do “imposto do token”, o custo extra que tokenizador otimizado pra inglês cobra de língua como o português, medido por eles em 31 línguas. Só que a API que eu medi tokeniza português com a mesma fertilidade do o200k, 1,31 tokens por token de inglês, contra 0,69 de um tokenizador nativo de português como o Tucano.

Ou seja, o produto que me deram usa um vocabulário otimizado pra inglês, não um vocabulário próprio pra português. Isso não diz nada sobre a linhagem do modelo, e adotar o o200k é a escolha barata e profissional que qualquer laboratório pequeno faria. Mas é um ponto em que o material de pesquisa e a API não estão contando a mesma história, e é a primeira pergunta que vou fazer pro Paulo.

Placar da forense

Em uma frase: com confiança alta, o Genesys PI não é modelo chinês rebatizado nem fine-tune de Llama ou Mistral; com confiança média a média-alta, os testes argumentam contra gpt-oss de fábrica e contra proxy transparente. Tudo que medi é consistente com um modelo independente, com peso e fraquezas próprios, em cima de um tokenizador público. Se ele foi treinado do zero ou destilado, só peso ou documento resolve.

Mais um disclaimer: só comparei com quem eu testei

O painel de tokenizadores tem OpenAI, Qwen, DeepSeek, Llama e Mistral; o painel de comportamento da API tem GPT-4o, gpt-oss, GPT-5, Claude, Qwen, DeepSeek, Llama e Gemini; e o cruzamento comportamental do benchmark cobre os cerca de 44 modelos que já rodaram o v4. É o que cobre a esmagadora maioria do que roda em produção hoje, mas existem dezenas de outros modelos abertos que eu não comparei. Sempre existe a chance de que o parente do Genesys PI seja um deles e eu tenha passado batido. “Não encontrei correlação” significa “não encontrei entre os que testei”, e nada além disso.

Dito isso, repare no tamanho do esforço que seria necessário pra enganar essa análise. Alguém teria que adotar o tokenizador da OpenAI, mascarar a identidade do modelo no servidor de forma que resista a override de prompt, construir um gateway próprio que rejeite exatamente os parâmetros que um servidor de modelo aberto aceitaria, manter fraquezas estáveis e próprias ao longo de quatro rodadas, e ainda completar um benchmark de sete sprints em nível de fronteira. Se isso não for um modelo de verdade, o trabalho de fingir que é já seria extraordinário. A partir de certo ponto, a falsificação convincente de um modelo é indistinguível de ter um modelo.

Agora sim: o que a LUA diz que fez

Tudo daqui pra baixo é conversa, com o Paulo e com o material público deles, e nada disso eu consegui checar, então marco como tal.

Ninguém pode ser culpado por desconfiar. O consenso que abriu este texto vale aqui com força total: pelo custo aceito de treinar modelo de fronteira, a LUA, que pelo que o Paulo me disse não tem rodada de investimento nenhuma, não deveria ter chegado onde chegou. Eu mesmo escrevi, semana passada, que nunca achei que treinar modelo de fronteira no Brasil fosse economicamente viável.

Contra esse senso comum, o que eu tenho na mão é um modelo que, pelo meu experimento de caixa-preta, parece novo, sem parentesco com nenhum modelo aberto conhecido, sem cara de proxy, e possivelmente não é só mais uma destilação. Isso tira da mesa a explicação mais fácil, sem provar a história deles.

O que o Paulo me contou, e que bate com muita coisa que eu já penso faz tempo:

• Modelo de trilhão de parâmetro é mais marketing do que necessidade. A tese dele, e a minha, é que modelo menor com capacidade agêntica de verdade (tool calling sólido, cache de prompt, atenção eficiente em contexto grande) é a combinação vencedora. A conta de custo do meu próprio benchmark aponta na mesma direção: modelo pequeno e barato empatando com modelo caro é o padrão da tabela.
• O pico de raciocínio ficou pra trás. Nós dois achamos que a geração do GPT-4 e dos primeiros modelos “o” foi onde o raciocínio parecia melhor, ainda sem capacidade agêntica. Depois disso, os provedores entraram numa guerra de tamanho de parâmetro como estratégia de marketing, e o raciocínio foi ficando gradualmente mais burro enquanto o modelo ficava maior. Isso é opinião nossa; não medi nada disso.
• Modelo pequeno com raciocínio e agente decente chega em resultado parecido. É o que o meu benchmark mostra quando o Genesys PI empata com Grok e fica na faixa de Kimi e DeepSeek, e é a aposta central deles.
• O treino foi feito em hardware de prateleira, sem CUDA. O Paulo diz que treinou em hardware AMD e ARM64 (MacBook incluso), em poucos meses, e que com financiamento seria mais rápido. Essa é a afirmação mais forte de todas, e é a que eu menos consigo verificar. Zero evidência de qualquer lado; registro como dito.
• Arquitetura própria, não publicada. O material público fala em NCAS, uma arquitetura “inspirada no cérebro” com cinco fases de treino, e diz que o detalhe técnico fica sob NDA. Na conversa, o Paulo descreve isso como um desenho pós-transformer, com 70 bilhões de parâmetros (número que aparece na issue que eles abriram no LiveBench, descrita lá como transformer, aliás), superior ao que os modelos abertos chineses entregam no mesmo tamanho, e diz que já tem um modelo mais eficiente que o Genesys PI em desenvolvimento, ainda sem acesso pra teste.

Se tudo isso for verdade, o estrago no status quo é grande. Quebra o monopólio da NVIDIA no treino e quebra o cadeado que os laboratórios de fronteira têm em cima de modelo de fronteira. Afirmação desse tamanho exige evidência desse tamanho, e eu não tenho. O que tenho é um modelo que existe, que eu posso testar, e que passou em tudo que eu consegui jogar em cima dele.

Onde eu estou parado

Checado, por mim:

• o Genesys PI é um modelo que existe, responde e completa um benchmark difícil na faixa de Tier A e B da minha tabela, em duas rodadas independentes por tier;
• o bug de cache foi corrigido e o custo caiu 85%;
• o tokenizador é o o200k_base público, o que exclui derivação de Qwen, DeepSeek, Llama e Mistral;
• a API não se comporta como proxy transparente e o modelo tem fraquezas próprias e estáveis;
• o gpt-oss de fábrica não explica o resultado;
• comparada contra todos os ~44 modelos do v4, a LUA não se parece com nenhum deles em todos os eixos.

Não checado, e é só a palavra deles:

• que o modelo foi treinado do zero e não destilado;
• que a arquitetura é nova e pós-transformer;
• que o treino aconteceu em hardware de prateleira, AMD e ARM64, sem CUDA, em poucos meses;
• que existe um modelo melhor a caminho.

Em aberto, e que eu vou perguntar:

• como conciliar o discurso do “imposto do token” com uma API que tokeniza português igual ao o200k.

O que resolveria isso de vez é documento, e não mais prompt: o arquivo do tokenizador, a receita de treino com contagem de token e de compute, a inicialização (aleatória ou continuada de outro peso), curva de loss, e um benchmark held-out que eu mesmo rode.

Enquanto isso não chega, minha posição é a que está na tabela acima: um modelo que se comporta como independente, em cima de um tokenizador público, com uma origem que ninguém de fora consegue certificar. Mais do que eu esperava de uma empresa desse tamanho, menos do que o site deles vende.

E preciso registrar o que não cabe em tabela: esses modelos são fascinantes, e talvez a coisa mais intrigante que eu testei em meses. Por tudo que a indústria diz, eles não deveriam ser possíveis, não deveriam existir. Mas eu testei, extensivamente, com todo teste de caixa-preta que consegui montar, e não consegui quebrar a história. Funciona como anunciado, e o Enterprise fez uma rodada inteira do meu benchmark por uns $2,40 nocionais, uma fração do que modelos na mesma faixa custam.

Soma isso ao que o Eronides descreveu, licença de uso em vez de token, modelo rodando dentro da empresa em vez de na nuvem de alguém, e o desenho fica claro: um modelo de nível Grok, on-premise, sem dado sensível vazando pra fora. Se eles entregarem isso, é um divisor de águas. Sigo curioso, e agora com pressa de ver o que sai em outubro.

A conta

A bio diz: “Covering AI, startups, markets, and emerging technologies for @TechCrunch | prev @mashable”. Selo de verificado, conta desde agosto de 2014, mais de 45 mil posts, 1.409 seguidores. Pelos números, parece uma conta antiga e ativa, não um perfil criado ontem.

A conversa

Aqui está a troca completa, sem cortar nada:

E aqui está o link, exatamente como veio, pra quem quiser reconhecer se recebeu o mesmo:

Link de phishing confirmado. Não clique. Se já clicou, não autorize nada. https://calendly.com/d/d336-3mq-q2z

Eu já sabia que era golpe

Reconheci o padrão na hora porque o José Valim, criador do Elixir, caiu exatamente nessa isca em março deste ano e documentou tudo publicamente.

Mesmo pretexto, TechCrunch pedindo entrevista sobre tema técnico que a vítima domina. Mesmo mecanismo, link de Calendly que termina numa autorização do X. A conta dele acabou sendo usada pra espalhar spam de cripto antes dele revogar o acesso.

Quando a mensagem chegou pra mim hoje, quase comemorei. Sabia na hora que ia virar bom conteúdo pro blog. Por isso continuei a conversa educadamente, só o suficiente pra printar tudo, e agora estou expondo a conta publicamente. Sempre exponha quem tenta te aplicar golpe. Isso não é sobre humilhar ninguém, é sobre deixar rastro público pra próxima pessoa que receber a mesma mensagem e for procurar no Google.

Mesmo sem saber do Valim, dava pra ver

Contato frio pedindo reunião, do nada, sem apresentação prévia, é golpe em 99% dos casos. Ninguém profissional de verdade opera assim, e muito menos por DM de rede social. Fazer isso é ser vendedor de porta em porta com Wi-Fi.

Nome de veículo grande no pretexto não muda nada pra mim. Eu me considero melhor do que a TechCrunch ou a capenga da Mashable, e nem alguém alegando falar em nome da Casa Branca ia me impressionar. Sem pedir desculpa por isso.

E mesmo se fosse uma pessoa normal por trás: meu tempo não é de graça. Quer consultoria de verdade? Fala com minha empresa, marca reunião comercial no Calendly da empresa, assina contrato, paga o valor, e só depois eu converso. Não existe atalho de “vamos bater um papo rápido” com estranho.

No momento em que cliquei no link, ele redirecionou direto pra tela de autorização do X, óbvio que recusei. Cliquei de propósito só pra tirar o print.

O mecanismo técnico

Um leitor comentou que a barra de endereço do print original mostrava um oauth_token na URL, e perguntou se isso não era inseguro de publicar. Boa pergunta, e editei o print pra apagar aquele trecho mesmo assim. Mas o risco real ali era zero: aquilo é um token de pedido do OAuth 1.0a, não um token de acesso. Ele só vira credencial de verdade depois que a autorização é aprovada e o app troca esse token por um verificador junto com sua própria chave secreta, nenhuma das duas coisas aconteceu, porque eu cliquei em cancelar. Token de pedido não usado também expira sozinho em poucos minutos, por definição do próprio X. Mesmo sem risco nenhum, não custa nada tirar da imagem, e vale como regra geral: nunca publique nada que pareça token, mesmo o que você tem certeza que já morreu.

O primeiro passo é real: calendly.com/d/d336-3mq-q2z roda em cima da infraestrutura de verdade do Calendly, confirmei isso batendo direto no link e conferindo os cookies e cabeçalhos de resposta, tudo genuíno. É um formulário de roteamento padrão do produto, nome e tipo de reunião.

O golpe mora no que acontece depois de enviar o formulário. O Calendly tem um recurso legítimo de “redirecionar após o agendamento”, e é exatamente esse recurso que foi configurado pra mandar a vítima pra uma tela de autorização OAuth do X. Essa tela também é real, ela roda em api.x.com, o domínio de verdade do X. O golpe não falsifica a tela de login. Ele abusa de um recurso genuíno do Calendly pra encadear numa tela genuína do X, autorizando um aplicativo de terceiro malicioso.

E aqui vai a parte que eu quero deixar bem marcada: essa não é falha exótica escondida em algum canto obscuro. É um pseudo-recurso ligado por padrão, redirecionamento livre pra qualquer URL depois do agendamento, sem checagem nenhuma de destino. Enquanto o Calendly não desativar ou pelo menos restringir esse redirecionamento, ele continua sendo vetor de phishing pronto pra uso, e a responsabilidade de fechar essa porta é do Calendly, não do usuário que só queria marcar uma reunião.

Esse aplicativo se chama “Events Portal”, alega ser www.eventsportal.com, e o X mostra um aviso próprio: “Este app não é afiliado ao X e está solicitando permissões sensíveis”, com o callback apontando pra plugins.cal-apis.com, não pra nenhum domínio real do Calendly. As permissões pedidas são de sequestro de conta completo:

• ver posts protegidos, listas e coleções;
• ver configuração de conta e perfil;
• ver quem você segue, silencia e bloqueia;
• seguir e deixar de seguir por você;
• atualizar seu perfil e configurações;
• criar e excluir posts, curtir, repostar e responder por você;
• criar, gerenciar e excluir listas;
• silenciar, bloquear e denunciar contas por você.

Com isso autorizado, a conta vira arma pra atacar a próxima pessoa, exatamente o que aconteceu com o José Valim.

O que eu confirmei por conta própria

Calendly de verdade não pede login de rede social pra marcar reunião, ponto final. O que a tela mostrou é o recurso legítimo de “redirecionar após o agendamento” sequestrado pra virar vetor de phishing contra conta do X. Não parei na primeira impressão, fui confirmar cada peça sozinho:

• o domínio cal-apis.com foi registrado há só seis dias, em 16 de setembro de 2026, por um revendedor chinês ligado à Alibaba Cloud, escondido atrás de servidor de nome do Cloudflare. Domínio descartável, criado especificamente pra isso, não infraestrutura real de nenhuma empresa;
• pesquisadores de segurança (Push Security e Validin) já documentaram campanha de phishing com tema Calendly usada pra roubar conta de Google Workspace e de Facebook Business, mesma família de golpe, alvo diferente do meu caso;
• especificamente contra conta do X, o que existe documentado é relato em primeira mão: o próprio José Valim, e um relato público de fevereiro de 2025 contando que um golpe quase idêntico, Calendly falso levando a login do X, quase pegou duas outras pessoas conhecidas da comunidade de tecnologia;
• não achei nenhum registro de “Mia Esswein” como jornalista de verdade da TechCrunch ou da Mashable em nenhuma busca. Não é prova definitiva de nada sozinha, mas some ao resto da pilha de evidência.

O checklist que eu uso

• contato frio pedindo reunião, sem apresentação, é golpe até prova em contrário;
• ferramenta de agendamento de verdade nunca pede login de rede social pra marcar horário;
• app de terceiro pedindo “permissão sensível” e avisando que “não é afiliado” à plataforma é bandeira vermelha, não detalhe técnico ignorável;
• se você já autorizou algo assim, revogue agora: no X, Configurações → Segurança e acesso à conta → Apps e sessões;
• denuncie a conta que mandou o link, e denuncie o evento do Calendly se ainda tiver a conversa.

Pra quem tentou

Vocês escolheram a pessoa errada pra tentar. Eu não converso de graça com estranho por princípio, muito menos autorizo aplicativo desconhecido em conta que eu uso pra trabalhar. Reconheço o padrão de longe porque leio sobre isso, e ainda por cima ganhei um artigo novo pro blog de brinde. Da próxima vez, invistam menos em domínio novo registrado às pressas e mais em disfarce que sobreviva a alguém que presta atenção.

Uma linguagem que promete rodar quase na velocidade de C, paralelizar sozinha em CPU e GPU, e ainda verificar com prova formal que o código que a IA escreveu faz o que você pediu. É muita promessa junta. Eu nunca tinha encostado no Bend 1, então isso aqui é experiência nova pra mim também: no dia do lançamento, apontei meus agentes pra dois projetos meus em Rust e mandei portar pra Bend 2. O resultado desse teste é a parte mais interessante deste artigo.

Antes de começar, o disclaimer: isso é uma review feita no segundo dia de vida da linguagem, baseada num experimento de um dia. Posso estar errado em várias das minhas assunções, e tá tudo bem. Os comentários estão aí embaixo, sintam-se livres pra corrigir e complementar.

Quem é Victor Taelin

Antes de tudo, vale apresentar o autor. O Victor Taelin é um pesquisador brasileiro de programação funcional que passou mais de uma década obcecado por um problema específico: redução ótima de lambda cálculo, o algoritmo do Lamping de 1990, e depois as redes de interação do Lafont.

A própria autobiografia dele conta a trajetória: trabalhou na Ethereum Foundation, criou a linguagem de provas Formality, aposentou cedo com o ETH que acumulou de salário, voltou ao problema por conta própria, criou a HVM (Higher-Order Virtual Machine) e fundou a Higher Order Company, que levantou US$ 4 milhões de seed pra transformar a pesquisa em produto.

E aqui vai um ponto que pra mim importa muito: eu acho ótimo um brasileiro fazendo trabalho sério de design de linguagem de programação. A gente quase não tem pesquisa de ponta de verdade nesse país, muito menos em fundamentos de computação. Só por isso, o Taelin já tem o meu respeito e os meus parabéns pelo que construiu até aqui.

Então deixa registrado: as críticas deste artigo são todas construtivas, de alguém que torce pro Bend chegar mais longe, nada contra ele ou contra o projeto.

De onde vem o Bend

A primeira versão do Bend apareceu em maio de 2024, com sintaxe parecida com Python rodando em cima da HVM2, e a promessa de paralelismo automático: escreva código sequencial, o runtime distribui em todos os cores e até na GPU, sem thread, sem lock, sem mutex.

O lançamento foi viral. Quase mil pontos no Hacker News, mais de 20 mil estrelas no GitHub, vídeo do Fireship. E aí veio a realidade: a thread do HN foi impiedosa. Números de 24 bits, sem FFI, soma simples levando 42 minutos na máquina de um usuário, C++ em um core batendo a RTX 4090 do demo. O próprio Taelin admitiu na época que o codegen era ruim, e admitiu agora, na thread do Bend 2, que o hype de 2024 não converteu em uso: “there is also my own failure into making the language actually be used, rather than just a viral moment”.

O Bend 2 é a resposta pra isso. E atenção: é outra linguagem. O README é explícito que programas de Bend 1 não carregam. Saiu a avaliação por grafos de interação (a HVM); entrou compilação nativa pra um único arquivo C, com clang pra CPU e Metal ou CUDA pra GPU. Os números passam a ser Nat, U32 e F32 de verdade, e o limite de memória pulou de 2 GB pra 8 TB, segundo o anúncio japonês da gihyo. As redes de interação continuam na arquitetura, mas, nas palavras dele, “inets live in it architecturally, but they don’t exist at runtime”.

O que o Bend 2 promete

O pitch novo agora gira em torno de IA. A página do projeto vende uma visão “post-AGI”: humanos vão parar de escrever e ler código, então precisamos de um jeito sem ambiguidade de dizer pras IAs o que queremos. A solução do Bend é dividir o programa em dois arquivos:

• LAWS.bend: as invariantes do sistema, escritas pelo humano.
• PROOF.bend: as provas dessas leis, escritas pela IA.

O type checker do Bend é um verificador de provas, na linha do Lean e do Rocq, então bend PROOF.bend vira um portão de commit: se a prova não fecha, o código não entra. O demo do site é um joguinho com a lei “vencer é impossível” e um convite direto: “Skeptical? Try breaking the game”. O posicionamento é explícito: LAWS.bend é um AGENTS.md com respaldo matemático.

E como é a cara disso? A sintaxe lembra Python com tipos dependentes. Um programa completo com efeitos:

import Base

# Performs effects on the CPU.
def main() -> IO(Unit):
  do IO<Unit>:
    name : String <- IO.try(String, IO.get_env("USER"))
    IO.print("Hello, " ++ name)

O paralelismo é divide-and-conquer: você quebra o trabalho em dois e o runtime espalha pelos cores que encontrar. E o operador ! despacha a função pra GPU:

# Computes 2^d in parallel: a tree of d levels, one leaf per unit.
def pow2(+d: Nat) -> U32:
  match d:
    case 0n:
      1
    case 1n+p:
      a b = pow2(p) pow2(p)
      (a + b : U32)

# Runs pow2 on the GPU, via `!`.
def main() -> IO(Unit):
  result = pow2!(20n)
  IO.print(U32.show(result))

Repara nas diferenças pras linguagens mainstream: não existe if (todo branch é um match em True/False), números naturais se casam por padrão de sucessor (1n+p), e o +d marca o parâmetro como afim, que é o que permite a linguagem viver sem garbage collector.

E as provas são defs comuns. A lei declara o que vale; a prova é indução com reescritas explícitas:

# CLAIM: for every nat x, x + 0 equals x.
law add_zero:
  for x: Nat
  {Nat.add(x, 0n) == x : Nat}

# PROOF: induction on `x`, one rewrite (`%`) per step.
def add_zero(x):
  match x:
    case 0n:
      {==}
    case 1n+xp:
      %add_zero(xp) : {1n+Nat.add(xp, 0n) == 1n+_ : Nat}
      {==}

Sem táticas, sem inferência, tudo anotado à mão. É verbose de propósito: é o preço do checker de 0,1s.

As outras promessas, todas com benchmark na página:

• Roda rápido: Game of Life num M4 Max em 7,8s em um core, contra 6,78s do C. Na GPU, 0,06s, ou 124x.
• Verifica rápido: 3.200 instanciações genéricas checadas em 0,38s, contra 19,2s do Lean e 6,04s do Rocq. A ideia é que o agente possa verificar a cada edição.
• Paraleliza sozinho: operador ! manda a função pra GPU, sem thread, sem lock, sem kernel escrito à mão.
• Sem garbage collector: tipos afins, cada closure pode ser chamada no máximo uma vez, então a memória se resolve estaticamente.

Dois detalhes honestos que eu gostei de ver publicados: o próprio site avisa “Bend is still evolving. Expect bugs”, e o Taelin declarou que o compilador é 99% escrito por IA, com só o kernel de checagem auditado por humanos. Coerente com a tese dele, pelo menos.

E já existe um plano de negócio: o Bender, um “proving agent” pago e proprietário, harness em cima dos modelos da Anthropic e da OpenAI hoje, com modelo dedicado e provador simbólico próprio no roadmap.

Nem todo mundo engoliu os benchmarks

A recepção técnica teve ressalvas fortes, e elas importam. O gist do Nezk, “Why the benchmarks of Bend’s 2 typechecker are misleading (and possible problems with its type system)”, aponta que o Bend pula elaboração, unificação e argumentos implícitos, que é justamente onde Lean e Rocq gastam tempo. Comparar os tempos assim seria comparar maçã com foguete.

Mais pesado: o post do Liam Powell, “Bend 2 and the Vibe-Coding Trap”, nota que a expressão “formal verification” não aparece no site nem no código do Bend, refaz o demo do jogo em SPARK/Ada provando as mesmas duas propriedades automaticamente com GNATprove (“all checks proved (12 checks)”), sem as 442 linhas de prova manual, e conclui que o Bend está “decades behind the state of the art”.

São críticas de gente que entende do assunto e merecem resposta. Dito isso, a thread principal do Bend 2 no HN está com mais de 600 pontos, então atenção o projeto tem.

O que eu testei

Slogan não compila programa, então eu fui testar. Tenho um repositório bend-tests onde apontei meus agentes pra portar projetos reais meus, escritos em Rust, pra Bend 2 (v2.0.16, pinada via mise; pra ter noção da maturidade, a linguagem teve nove releases em dez horas no GitHub, no dia seguinte ao lançamento). A documentação do experimento inteiro está em docs/ lá dentro, e é dela que saem as próximas seções.

Os três candidatos

Escolhi três projetos meus com perfis diferentes. Já aviso: nenhum dos três é um exemplo digno de Bend, e eu sei disso. Eu só peguei projetos pequenos e simples que eu tinha à mão, meio aleatórios, pra ver onde a linguagem quebra quando esfregam nela código comum do dia a dia.

O ghpending é minha CLI que lista issues e PRs abertos dos meus repositórios via GraphQL. O port cobre o comando principal, os filtros, a ordenação e o config.toml, com saída verificada byte a byte idêntica ao binário Rust nos casos testados contra a API real do GitHub (no meu config cheio, a única diferença é a fork view que o port deixou de fora).

O tclock é meu fork do clock-tui, relógio de terminal com timer e cronômetro. O port cobre relógio, timer e stopwatch, sem o sistema de widgets (que sozinho é 2.075 linhas do Rust), verificado dirigindo o binário via pty.

O ai-jail, meu sandbox pra agentes de IA (bubblewrap, Landlock, seccomp), nem virou código: a avaliação no papel já matou. Um port seria um programa em C com um main em Bend, o que anula o propósito. E olha que ele tinha a parte mais interessante pra provar: a lógica de política, tipo “resolução de path nunca escapa da raiz”. Mas não tem como embutir isso no binário Rust, então ficou pra uma próxima.

Os números

Medi Rust e Bend lado a lado nos dois ports:

Lê essa tabela com cuidado, porque ela engana. As runs são bound de rede. O gap dos 43 repos é o Rust fazendo mais trabalho (fork lookups, query sequencial de viewer). O tclock do Bend redesenha frames inteiros, 26 KB/s contra 2 KB/s de diffs do ratatui. E a contagem menor de linhas é em parte porque o port faz menos. Nenhum número aqui mostra o Bend mais rápido que o Rust no mesmo trabalho.

As provas na prática

Aqui mora a parte que o Rust não consegue imitar, então vale o detalhe. O design que funcionou foi provar uma guarda isolada, deixando o algoritmo fora da prova. O alocador de --limit do ghpending ficou em dois estágios: o primeiro é o algoritmo original em U32, não provado; o segundo é uma guarda em Nat que recebe a proposta do primeiro e corta qualquer excesso. As leis dizem que o orçamento é conservado e que nenhum repo recebe mais itens do que tem.

Essa é a guarda de verdade, do alloc.bend do port:

# the lesser of b and w
def take(b: Nat, w: Nat) -> Nat:
  match b w:
    case 0n w0:
      0n
    case 1n+bp 0n:
      0n
    case 1n+bp 1n+wp:
      1n+take(bp, wp)

# what is left of b once w is taken from it
def rest(b: Nat, w: Nat) -> Nat:
  match b w:
    case 0n w0:
      0n
    case 1n+bp 0n:
      1n+bp
    case 1n+bp 1n+wp:
      rest(bp, wp)

A lei vale mesmo se o estágio não provado propor lixo. A guarda não confia na aritmética que ela não consegue enxergar. Esse é o padrão que faz prova funcionar em código real.

O teste de mutação é a medida honesta do negócio. Injetei um off-by-one na guarda que vaza orçamento: as três saídas de exemplo ficaram idênticas, então uma suíte de testes daquele tamanho teria aprovado. O portão de prova rejeitou, com o termo exato que deixou de bater. É o Bend funcionando como prometido, no detalhe.

Agora o preço: 93 linhas de leis e provas pra garantir dois fatos simples sobre uma guarda de umas 30 linhas, começando do zero, porque a Base não traz nenhum lema de Nat (os únicos lemas aritméticos são U32.add_comm e Word.add_comm, que não ajudam em prova de Nat; tivemos que provar associatividade da soma na mão, e o Taelin reconheceu na thread: “We need a mathlib!”).

E o que ficou de fora da prova: a exatidão do algoritmo (precisaria de lemas de divisão, dias de trabalho), tudo que é U32 (por baixo é um vetor de 32 bits; provar aritmética nele sem biblioteca de lemas é impraticável) e literalmente todo o resto do programa: JSON, ordenação, renderização, IO. A superfície provável de um programa como o ghpending é uns poucos por cento do código.

O checker, por outro lado, é a melhor parte da ferramenta: 0,1s por rodada, erro apontando uma linha exata. Foram umas 30 rodadas de check no ghpending. Pra um agente iterando em loop, é exatamente o formato de feedback que ele precisa.

O preço de sair pra C

Tudo que a Base não tem vira foreign effect: um def em Bend cujo corpo é uma função C (pro binário nativo) e uma gêmea em JS (pro runner de desenvolvimento). Os dois ports precisaram de oito efeitos escritos à mão:

• Http.post: porque não existe TLS, HTTP ou DNS (o demo oficial de HTTP hard-coda um IP).
• Clock.unix e Clock.local: porque IO.now é milissegundos desde o boot, sem hora de parede e sem fuso.
• Tty.width, Tty.raw, Tty.key, Tty.size: porque não existe stdin, raw mode nem consulta de terminal. Nada disso existe.
• Clock.millis: conveniência.

E o guia oficial é claro sobre o compromisso: não há promessa de ABI. Os nomes são internos do runtime e qualquer release pode renomeá-los, então “rebuild your effects with every update”. Numa linguagem com nove releases em dez horas, boa sorte. Detalhes que completam o quadro: não existe flag pra linkar biblioteca extra (o ghpending usa um wrapper de $CC que injeta -lcurl), tipos de handle customizados são WONTFIX, e incluir header de C no meio do arquivo funcionou por sorte, porque o runtime define nomes curtos tipo lock e u32.

Aqui encaixa o ponto conceitual: no momento em que você cruza a fronteira do FFI, a prova ficou pra trás. O verificador garante o que está dentro do modelo dele; o código C do outro lado é ato de fé. O Rust tem exatamente o mesmo problema com unsafe, onde as garantias do borrow checker valem até a borda do bloco e dentro dele a prova é sua. Se você quer garantia forte de ponta a ponta, a fronteira com C precisa ser mínima ou inexistente, e hoje em Bend ela é enorme pra qualquer programa real.

Onde o Bend encaixa

Cruzando os três projetos com o que a linguagem oferece, o formato que ganha é um núcleo puro pequeno, com spec afiada que testes cobrem mal, dentro de uma casca fina de efeitos:

• alocadores, schedulers, rate limiters, lógica de quota
• regras determinísticas de jogo ou simulação, principalmente com rollback netcode (o único domínio onde a Base já tem o necessário: UDP, janela, áudio)
• máquinas de estado de consenso, ledger e matching engine
• parsers e codecs com lei de round-trip
• funções de merge de CRDT (comutativas, associativas, idempotentes)
• avaliadores de política de acesso (tipo o do ai-jail)

E o centro de design que os autores declaram: a IA escreve o código e as provas, o humano escreve só o LAWS.bend, e o checker arbitra. A descrição honesta mais curta que eu achei: uma proof-carrying language for AI-written kernels. Comparado com Lean ou Coq, que provam bem e entregam aplicação mal, o Bend é muito mais executável.

Uma coisa que me surpreendeu nos próprios números: de primeira eu assumiria que o nicho natural era pesquisa acadêmica em matemática. É o contrário. Pra matemática ele perde feio pra Lean 4, Coq e Isabelle: sem táticas, quase sem inferência, sem nada na escala da mathlib, sem reais, e com uma fundação (Type : Type, sem positivity check) que deixaria matemático de cabelo em pé. O que ele faz é verificação de software, mais perto de Dafny, F* ou Liquid Haskell do que de assistente de prova.

Duas limitações pesam até nesse nicho: o Bend emite um programa inteiro em vez de uma biblioteca, então o núcleo provado não pode ser linkado numa aplicação Rust hoje; e o custo de prova sem biblioteca de lemas é alto.

O que mudaria o veredito

Registrado no use-cases.md, a lista do que me faria reavaliar:

• saída de biblioteca com ABI C, pra um núcleo provado viver dentro de um programa Rust ou C
• U64/I64 e F64
• uma biblioteca de lemas pra Nat, listas e ordem
• stdin, subprocessos, TLS e JSON na Base, ou um hub de pacotes que tenha isso
• builds nativos incrementais ou mais rápidos (62s pra 1.000 linhas hoje)
• uma ABI de efeitos que sobreviva a um release

A realidade nua e crua

Agora a minha leitura, e você já sabe que eu não adoço.

É uma linguagem recém-nascida. Foi lançada anteontem. Fora o repo da própria linguagem, uma busca no GitHub acha hoje só algumas dezenas de spikes de 48 horas, quase todos com zero estrelas, nada que pareça projeto de verdade. As 21 mil estrelas do repo são quase todas herança do Bend 1, o repo foi renomeado. Os demos do site são todos de brinquedo: joguinho, Game of Life, pow2. São demonstrações de possibilidade, ainda sem uso real.

A stdlib precisa crescer uma ordem de magnitude. A força de uma linguagem mora na biblioteca padrão e no ecossistema. A única exceção histórica a essa regra foi o JavaScript, e aquilo lá é uma lata de vermes que não cabe neste artigo.

Falta a killer app. Toda linguagem que vingou tinha uma. Os meus testes apontam o nicho (núcleos puros provados, escritos por IA), mas alguém precisa transformar isso num app que o mundo queira usar. E aqui entra uma sugestão concreta, de graça: o Taelin podia escolher software open source popular que ele acha que ficaria melhor em Bend e reescrever. O Taelin é o exato oposto do mantenedor teimoso que torce o nariz pra IA: ele desenhou a linguagem inteira em volta de IA. Então que use isso a favor: pega um ripgrep, um jq, um sqlite da vida, reescreve com IA em Bend e publica a comparação lado a lado. Performance, linhas de código, e principalmente o que as provas garantem que o original não garante. Um before/after assim no mundo real vale mais que mil demos de joguinho. E de brinde, cada rewrite desses devolve o feedback mais valioso que existe: quais buracos da stdlib doeram de verdade num projeto real. Nada prioriza melhor o que implementar na próxima versão do que código de verdade esbarrando no que falta.

Não espere webapp, mobile ou qualquer coisa do dia a dia tão cedo. Talvez nem seja o propósito, e tudo bem também. Mas a promessa de “velocidade de C” corta pra outro lado: se o diferencial é performance, é mais fácil ir direto pro C, ainda mais hoje, com LLM escrevendo o código por você.

E aqui entra a minha situação concreta. Eu uso Rust pra caramba. Odeio a sintaxe, acho a ergonomia sofrível. Mas como quem escreve o código é o LLM e eu não preciso lidar com aquilo na mão, eu tolero, e em troca levo performance, garantias boas o suficiente e um ecossistema gigantesco de crates e frameworks. Ecossistema. É isso que decide.

Eu não escolho linguagem pela elegância do paper. Escolho pelo tamanho do ecossistema que eu não preciso escrever na mão.

O foco em prova e GPU, e a dúvida que fica

Uma coisa que me incomodou de leve o tempo inteiro: o Taelin claramente concentra tudo em dois pilares, provas e GPU, e eu não tinha certeza do que isso significava pro escopo da linguagem. Fui ler o que ele mesmo disse no thread de pré-lançamento e no HN, e a história é mais interessante do que eu assumi.

O pilar GPU é a herança de pesquisa. São dez anos de interaction nets e redução ótima, da HVM até aqui. Mas tem uma nuance que me surpreendeu: o Bend 2 conscientemente trai o idealismo acadêmico dele. Nas palavras do próprio: “Bend2 is designed to be practical, not idealistic”, mais perto de C do que de Haskell, porque ele não conseguiu fazer as interaction nets baterem as variantes lower-order em hardware comum. A GPU ficou como aplicação prática da obsessão, sem virar fetiche.

O pilar prova é mais velho que a era LLM: vem da época da Ethereum Foundation, de contrato imutável segurando milhões com bug, que gerou o Formality. A era LLM só deu pra obsessão antiga uma roupagem de mercado: “the same capabilities that proved Navier-Stokes will now be writing real proofs that your own apps are correct”.

E aí vem a minha hipótese que não sobreviveu à pesquisa. Eu estava pronto pra escrever que a stdlib mínima talvez fosse de propósito, que a ideia nunca foi programação geral, e que a minha crítica ao deserto de bibliotecas estaria mirando o alvo errado. Errado eu. As palavras dele são de ambição geral mesmo: “the potential to become the most sensible choice for any vibe-coded project”, “Bend is made for the general public”, e o time “working hard to […] make this language competitive with the mature alternatives in the market”. A única magreza deliberada é a do checker, sem inferência, verbose de propósito. A Base pequena é dia dois de vida mesmo, tanto que ele próprio pede uma mathlib.

Isso faz a minha crítica à stdlib morder ainda mais forte: se o objetivo declarado é ser a escolha pra qualquer projeto vibe-coded, a comparação com ecossistemas maduros é o jogo que ele mesmo escolheu jogar.

E tem o ângulo do negócio, que ele admite com uma franqueza rara: “we ship without a product”. A linguagem é o substrato gratuito; o vendável é o Bender e a infraestrutura de prova que vem atrás. Vale ficar de olho nesse espaço.

A dúvida que sobra, e essa eu registro sem resposta: a ambição generalista é o norte dele, mas a realidade que eu medi empurra o Bend pro nicho de núcleos verificados escritos por IA. Qual dos dois vence, só o tempo diz.

O recado final

Se eu pudesse dar um conselho pro Taelin, seria esse: a parte difícil, a pesquisa, ele já fez. Agora vem a parte menos glamourosa, que é a que decide se linguagem vive ou morre: marketing e construção de ecossistema. Adoção, material de ensino, killer app, stdlib, mathlib. Ir muito além de toys e demos.

O exemplo que me vem à cabeça é o Zig. Anos de estrada e ainda briga por adoção, mesmo tendo uso prático imediato: o zig cc sozinho já é um substituto trivial pra compilar C, sem usar nada da linguagem. Tem app real usando, o Ghostty do Mitchell Hashimoto é o caso famoso. Mas o Andrew Kelley, o autor, é uma figura notoriamente difícil, da turma que torce o nariz pra IA, e claramente não entende de construção de ecossistema, e isso segura o Zig pra trás. Perfeccionismo técnico não combina com marketing e adoção.

O Bend 2 tem potencial de verdade. Checker instantâneo, provas pegando bug que teste não pega, paralelismo sem cerimônia. Mas potencial sozinho não significa nada se a adoção não vier. Eu torço pra vir, e torço duplo por ser um brasileiro liderando.

E uma provocação final, dessa vez pra você que leu até aqui. Stdlib rala, zero frameworks, zero bibliotecas de terceiros, nenhuma killer app: tudo isso deixa de ser problema quando você olha de outro ângulo e vira mapa de oportunidade. Cada coisa que falta no Bend é uma coisa que alguém vai ter que escrever, e quem chegar primeiro grava o nome na história do projeto. Se você sempre quis contribuir com open source de impacto mas nunca achou espaço nos projetos maduros, onde já existe de tudo, aqui tem um terreno vazio esperando.

São os meus dois centavos. Não levem tão a sério.

“E se um dia eu conseguir gastar token o suficiente pra ferver um lago inteiro com o calor do datacenter, eu vou gastar com o maior prazer do mundo. É minha vingança pessoal contra quem me obrigou a usar canudo de papel que desmancha na boca por tantos anos.”

Confesso: foi provocação explícita, escrita já sabendo que eu ia explicar ela aqui hoje. Porque por trás da piada tem uma tese séria.

Semana passada eu desmontei aqui a propaganda do medo da IA, da OpenAI, Anthropic e NVIDIA. Hoje eu quero usar a mesma lente para uma histeria muito mais antiga e muito mais lucrativa: a climática. E tem uma ironia no meio: quem desmascarou essa histeria foi a própria IA, sem querer.

A tese é simples. No momento em que a corrida por datacenters apertou de verdade, todos os compromissos “verdes” de governos e big techs evaporaram. A mesma Microsoft que prometia ser carbono negativa está religando Three Mile Island. A mesma Alemanha que desligou o parque nuclear tem hoje um chanceler admitindo que foi um erro estratégico. O que derrubou a pauta climática foi outra pauta, uma com mais dinheiro.

E antes que alguém me etiquete, a minha posição com todas as letras: sim, existe efeito humano no clima. Não, o mundo não está acabando, e a distância entre essas duas frases é onde a histeria mora. O que eu contesto é o pânico industrializado e a má alocação de trilhões que ele justifica.

Toda década tem o seu apocalipse

Eu cresci sob o apocalipse nuclear da Guerra Fria. A gente vivia sob a certeza de que o mundo podia acabar em cogumelos atômicos a qualquer momento. Quando a URSS caiu em 1989, esse medo esvaziou, e o buraco na camada de ozônio ocupou o vazio. Esse, aliás, está se recuperando décadas depois do Protocolo de Montreal de 1987, que baniu CFCs e afins aos poucos: prova de que problema real com solução barata dispensa histeria.

Depois veio o bug do milênio. Depois o “aquecimento global”. E quando “aquecimento” ficou difícil de sustentar em toda manchete, a pauta trocou de nome para “mudança climática”.

Repara no truque. Orwell chamou isso de Novilíngua em “1984”: capturar as palavras para capturar o pensamento. “Aquecimento global” era uma hipótese testável: ou esquentou, ou não. “Mudança climática” acomoda tudo. Calor, frio, seca, enchente, neve, falta de neve. Qualquer evento confirma a tese, e uma tese que tudo confirma explica nada.

Quando o vocabulário é capturado, a pergunta vira crime. Quem pede evidência vira “negacionista”. Cientista financiado por interesses obscuros vira “especialista”, e “especialista” é vendido como monopólio da verdade. A histeria do covid foi o pior fruto desse modo de pensar, mas covid fica para outro artigo. O caso climático já basta.

O custo humano dessa máquina está medido. Uma pesquisa Washington Post/Kaiser Family Foundation de 2019 com adolescentes americanos achou 57% com medo e 52% com raiva por causa do clima. Uma enquete global da ONU que juntou cerca de 9,7 milhões de votos perguntou prioridades: “ação contra a mudança climática” ficou em último entre 16 temas no total global, e mesmo nos países mais pobres ela ficou no fundo da lista. O povo quer hospital e emprego. Quem ranqueia apocalipse em primeiro é quem tem o conforto garantido.

Siga o dinheiro: quem financia o medo

Sobre a Greta Thunberg, um fato incomoda os dois lados: ela mesma não fica com dinheiro nenhum. O pai dela disse à Politico que ela nunca recebeu um centavo, e ela doou o prêmio Gulbenkian de 1 milhão de euros inteiro para projetos climáticos. O personagem é real e, pelo que consta, sem salário.

A menina e a startup

A máquina em volta é outra história. A greve escolar começou em 20 de agosto de 2018, uma segunda-feira. A startup sueca We Don’t Have Time, fundada pelo publicitário Ingmar Rentzhog, ainda construía a sua rede social climática. No dia da greve, Rentzhog postou a foto da menina no Facebook pessoal dele e a conta da empresa tuitou no mesmo dia, marcando o Climate Reality Project do Al Gore. Três dias depois do início da greve, na quinta-feira 23 de agosto, chegava às livrarias o livro da família, “Scenes from the Heart”.

O prospecto de captação da startup, de novembro de 2018, citava a Greta 11 vezes, sem o conhecimento da família; aquela rodada levantou ~13 milhões de coroas suecas, e a empresa dizia ter captado 23 milhões no total até o começo de 2019. Ela foi conselheira júnior da fundação da empresa de outubro de 2018 a janeiro de 2019 e saiu. O produto era a startup; a menina era o marketing.

A indústria do protesto assalariado

Depois veio a industrialização do protesto. O Climate Emergency Fund, fundado em 2019, financia Just Stop Oil, Extinction Rebellion, Scientist Rebellion e afins. Quem abriu o cofre com US$ 500 mil foi Aileen Getty, herdeira da fortuna do petróleo Getty, note bem. O diretor de Hollywood Adam McKay entrou com US$ 4 milhões e uma cadeira no conselho.

Até abril de 2022 o fundo já tinha distribuído US$ 1,7 milhão para ativistas em 25 países; as declarações fiscais do ano inteiro apontam ~US$ 5 milhões em grants. Só a Just Stop Oil recebeu quase US$ 1 milhão, ajudando a pagar o salário de uns 40 organizadores. Aquela sopa na tela do Van Gogh é trabalho assalariado, financiado por herança de petróleo e dinheiro de cinema.

Fundações bilionárias e governos

Acima dos fundos de protesto estão as grandes fundações. A Bloomberg Philanthropies já soma US$ 1 bilhão só na campanha Beyond Carbon, e o New York Times chamou o Bloomberg de talvez o maior financiador individual do ativismo climático do mundo. A Hewlett Foundation comprometeu US$ 600 milhões em cinco anos, a Rockefeller anunciou em 2023 que investiria mais de US$ 1 bilhão em clima ao longo de cinco anos, e a ClimateWorks já distribuiu mais de US$ 2 bilhões. Isso é uma indústria, com orçamento de PIB de país pequeno.

E os governos financiam a pressão contra os adversários políticos deles. A UE paga €15,6 milhões por ano em subvenções operacionais para umas 30 ONGs verdes via programa LIFE, e em janeiro de 2025 o Parlamento Europeu fez um debate formal sobre ONGs financiadas pela Comissão fazendo lobby sobre a própria Comissão, em que o comissário de orçamento admitiu ser “inapropriado” que partes da Comissão assinassem acordos obrigando ONGs a fazer lobby em cima de eurodeputados específicos. Na Alemanha, o Correctiv recebeu €2,5 milhões de dinheiro público desde 2016, o programa “Demokratie leben!” tinha orçamento de €182 milhões em 2024, e a CDU protocolou 551 perguntas formais sobre a neutralidade política de organizações financiadas pelo Estado.

E quem ganha com as políticas? O memorando interno da Enron de dezembro de 1997, escrito de Kyoto, já comemorava: “this agreement will be good for Enron stock!!”. O complexo climático-industrial nasceu junto com o tratado. A arrecadação global com precificação de carbono, impostos e mercados de emissão somados, bateu recorde de US$ 104 bilhões em 2023, e um estudo da Point Carbon de 2008 para o WWF estimou entre €23 e €71 bilhões de lucro inesperado para geradoras de cinco países da UE só na fase II do mercado de carbono europeu. E o maior beneficiário das metas verdes ocidentais tem nome e endereço: a China controla mais de 80% de cada etapa da cadeia de manufatura de painéis solares e produziu quase 75% dos carros elétricos do mundo em 2025. O Ocidente subsidia a demanda; Pequim vende a oferta.

Se você não conhece o caso Enron, pare um minuto e assista:

Quem ganha

Quem se beneficia do discurso do medo, então? Fundações bilionárias, consultorias, indústrias subsidiadas, governos comprando paz social com subvenção e o maior competidor industrial do Ocidente. A Greta saiu sem um tostão. A máquina ficou com o megafone.

A corrida dos datacenters

Parte dos números que eu vou mostrar vem da pesquisa que eu fiz para a minha palestra na Tropical Ruby 2026, sobre energia e IA. Os dados do IEA contam a história:

• Datacenters consumiram 415 TWh em 2024, cerca de 1,5% da eletricidade mundial.
• Em 2025: ~485 TWh, crescimento de 17% num ano; os datacenters focados em IA sozinhos cresceram 50%.
• Projeção central para 2030: ~945 TWh, o consumo do Japão inteiro, perto de 3% do planeta.

Nos EUA, datacenters respondem por quase metade de todo o crescimento de demanda elétrica até 2030. E o dinheiro seguiu: o capex das big techs passou de US$ 400 bilhões em 2025 para ~US$ 715 bilhões guiados para 2026, mais que o investimento anual de todo o setor de energia americano. O investimento acumulado em datacenters entre 2026 e 2030 deve bater US$ 3,9 trilhões.

E mesmo assim não dá conta. O gargalo deixou de ser chip e virou cobre e concreto:

• A PJM, maior operadora de rede dos EUA, fechou pela primeira vez na história um leilão de capacidade abaixo do requisito de confiabilidade, em dezembro de 2025: faltaram ~6,6 GW. O preço da capacidade saltou para US$ 333,44 por MW-dia, mais de 11 vezes o patamar do leilão de 2024/2025, batendo no teto permitido pela FERC.
• Transformador de alta potência tem fila de dois a três anos, e os maiores modelos passam disso. A fila de interconexão americana tem mais de 2.000 GW esperando, cerca de 1,6 vez toda a capacidade instalada do país.
• Dos ~16 GW de datacenters grandes que a Sightline Climate previa globalmente para 2026 (o recorte americano é ~12 GW), só ~5 GW estavam em construção no começo do ano, e a estimativa é que 30% a 50% desse pipeline anunciado atrase.

A fila do mercado agora é por GPU, energia e datacenter.

Lembra do carro elétrico, a grande salvação da agenda verde? A frota global inteira de EVs consumiu ~250 TWh em 2025, cerca de 1% da eletricidade do mundo. Os datacenters consumiram quase o dobro, já no ano passado. E a projeção conta o resto: de 415 TWh em 2024 para ~945 TWh em 2030, são +530 TWh de carga nova na rede, quase três vezes a eletricidade da frota global inteira de EVs de 2024 (~180 TWh).

A década inteira de “economia verde” foi engolida em dois anos de corrida de IA. E o detalhe cômico: em março de 2026, Bernie Sanders e Alexandria Ocasio-Cortez anunciaram o AI Data Center Moratorium Act, uma tentativa de proibir datacenter novo nos EUA. A agenda verde passou décadas mandando você consumir menos energia. Diante da IA, a saída coerente que sobrou foi tentar proibir o consumidor novo.

A volta da energia nuclear

Se a pauta climática fosse séria, o maior aliado dela sempre foi a energia nuclear: a fonte mais limpa, mais densa e mais confiável que existe. A mesma pauta que pregava apocalipse tratou nuclear como tabu por cinquenta anos. Eis o que a fome de energia da IA fez em um ano:

A corrida nuclear das big techs

• A Microsoft assinou um contrato de 20 anos para religar a unidade 1 de Three Mile Island, 835 MW. Leia de novo: Three Mile Island, o símbolo máximo do medo nuclear americano desde 1979, ressuscitada como Crane Clean Energy Center para alimentar datacenter.
• A Meta fechou até 6,6 GW em acordos nucleares com Vistra, TerraPower e Oklo.
• O Google encomendou 500 MW em reatores modulares da Kairos.
• A Amazon expandiu seu contrato com a usina de Susquehanna para 1,9 GW até 2042 e investiu na X-energy.

O motivo técnico é simples. Nos EUA, nuclear opera com fator de capacidade em torno de 91%, e ficou acima de 92% na média da década até 2023; vento fica em ~34% e solar em ~23%. Datacenter quer baseload, 24 horas por dia. Sol e vento não entregam isso sem uma montanha de bateria que ninguém tem.

Se você não conhece o incidente de Three Mile Island, em 1979, assista:

O caso alemão

E a Alemanha? A Alemanha desligou suas três últimas usinas em 15 de abril de 2023 e virou importadora líquida de eletricidade pela primeira vez desde 2002, inclusive importando nuclear francês. A Energiewende custou na casa das centenas de bilhões de euros, a eletricidade industrial alemã custa cerca do dobro da americana ou mais, e a rede alemã emite em torno de 350 g de CO2 por kWh, contra 22 g da França nuclearizada.

Pois bem. Em janeiro de 2026, o chanceler Friedrich Merz admitiu em público: “Foi um grave erro estratégico abandonar a energia nuclear”, “estamos fazendo a transição energética mais cara do mundo inteiro”. O chefe do próprio IEA, Fatih Birol, foi a público concordar com ele. Desde maio de 2025 a Alemanha parou de sabotar a França nuclear na UE, e em junho de 2026 ex-diretores das usinas fechadas pediram oficialmente a reativação dos reatores.

Deixa eu registrar a minha opinião aqui: fechar o parque nuclear foi um dos maiores erros da história moderna da Alemanha. Eles empobreceram a própria indústria, se viciaram em gás russo, voltaram a queimar carvão na crise de 2022 e hoje compram eletricidade nuclear do vizinho. Tudo isso em nome de uma pauta que eles mesmos estão abandonando.

O medo contra os números

Sobre o medo em si, os números oficiais são outros. Mortes por TWh produzido, somando acidentes e poluição: carvão mata 24,6; petróleo, 18,4; gás, 2,8. Nuclear: 0,03, menos que vento e quase igual a solar. Chernobyl matou 30 trabalhadores diretamente, e a projeção do Chernobyl Forum e da OMS para cânceres eventuais fica em até 4 mil entre os 600 mil mais expostos, enquanto o Greenpeace vendia 93 mil. O mesmo relatório concluiu que o maior problema de saúde pública foi o dano psicológico: pessoas adoeceram de medo da radiação, não da radiação. Fukushima: zero mortes por radiação entre o público (o Japão reconheceu uma única morte ligada à radiação: um trabalhador com câncer de pulmão, em 2018); 2.313 mortes ligadas à evacuação em pânico. O medo matou mais que o acidente.

E o lixo? Todo o combustível usado dos reatores comerciais dos EUA cabe num campo de futebol americano, empilhado a menos de 10 jardas, uns 9 metros. A França reprocessa o dela em La Hague há décadas. A Finlândia construiu o primeiro depósito geológico profundo do mundo para combustível nuclear usado, Onkalo, já na reta final de licenciamento. Problema técnico resolvido há tempos; o que faltava era coragem política, e ela chegou na forma de uma conta de luz de datacenter.

O homem que aponta isso há vinte anos

Quem organiza essa argumentação com rigor há duas décadas é o dinamarquês Bjorn Lomborg. Cientista político de formação, professor de estatística por anos na Universidade de Aarhus, ex-professor visitante da Copenhagen Business School, fellow do Hoover Institution de Stanford, fundador do Copenhagen Consensus Center, um think tank que trabalha com centenas de economistas, Nobel inclusos. Ele estourou em 2001 com “The Skeptical Environmentalist” e virou persona non grata do establishment verde, apesar de repetir desde sempre a mesma frase:

“O aquecimento global é real, mas não é o fim do mundo. É um problema administrável.”

Anota: Lomborg aceita o consenso científico sobre a existência do aquecimento e sua causa humana. Ele defende imposto de carbono e investimento em P&D verde. O que ele contesta é o pânico e a matemática das políticas. O livro dele de 2020, “False Alarm”, é um catálogo de números que a manchete nunca te conta:

Os números que a manchete não conta

• Mortes por desastres climáticos (seca, enchente, tempestade, incêndio, temperaturas extremas; compilação do Lomborg sobre a base EM-DAT): de ~500 mil por ano nos anos 1920 para menos de 20 mil por ano hoje, queda de 96%. Como a população quadruplicou, o risco individual caiu 99%.
• Na síntese do Lomborg sobre os modelos do Stanford Energy Modeling Forum, cumprir o Acordo de Paris custa entre US$ 1 e 2 trilhões por ano, o pacto mais caro da história humana. E o efeito de cumprir todas as promessas de 2030, medido no modelo MAGICC, o mesmo usado pelo IPCC, é reduzir o aquecimento de 2100 em 0,048°C, no paper dele na Global Policy. Esticando todas as promessas até 2100: 0,17°C. Cada dólar gasto em Paris evita 11 centavos de dano.
• O custo do aquecimento sem nenhuma ação, na função de dano do Nobel William Nordhaus: cerca de 3 a 4% do PIB global em 2100. O Lomborg aplica isso aos cenários de renda do IPCC e traduz: em vez de termos 4,5 vezes a renda de hoje, teremos 4,34 vezes. Um problema administrável.
• A Nova Zelândia calculou que seu net-zero custa entre 5% e 17% do PIB de 2050, contra a meta anterior de cortar 50% das emissões. O Lomborg converte a fatia de emissões do país, pela conta dele, num adiamento de três semanas do aquecimento global.
• Tuvalu, o país-símbolo do “vai sumir no mar”, cresceu 2,9% em área em quatro décadas com o mar subindo ao dobro da média global. E a manchete de “187 milhões de deslocados até 2100” vem de um estudo para até 2 metros de elevação do mar sem adaptação; o mesmo estudo, com diques e adaptação realista, calcula entre 41 mil e 305 mil deslocados.
• Um estudo na Lancet que analisou 74 milhões de mortes em 13 países atribuiu 7,3% delas ao frio e 0,4% ao calor: no clima atual, o frio mata umas 17 vezes mais.

A conta que ninguém deixa fazer

Agora a comparação que importa. O “Best Things First” do Copenhagen Consensus calculou: US$ 35 bilhões por ano em doze soluções baratas (tratar tuberculose, redes contra malária, nutrição infantil, vacinas) salvariam ~4 milhões de vidas por ano. Tratar tuberculose custa US$ 6,2 bilhões por ano e salva ~600 mil vidas por ano nesta década, retorno de ~US$ 46 por dólar. A malária sozinha matou 610 mil pessoas em 2024, 95% na África, a maioria crianças abaixo de 5 anos. Uma rede tratada entregue custa cerca de seis dólares; salvar uma vida com elas custa na faixa de US$ 5.500.

A ajuda climática internacional sozinha, um quarto de toda a ajuda ao desenvolvimento, daria para financiar tuberculose, malária, contracepção e nutrição no mundo inteiro e ainda sobrar troco. É essa a escolha real na mesa. Ninguém deixa você fazer essa conta em voz alta sem ser chamado de monstro.

A palestra dele no TED de 2005, “Global priorities bigger than climate change”, é exatamente esse exercício de custo-benefício, feito em palco, vinte anos atrás. Vale os 16 minutos:

E já que os comentários vão mirar o mensageiro, deixa eu adiantar a ficha corrida. Do Lomborg você vai ouvir que um comitê dinamarquês de “desonestidade científica” declarou o primeiro livro dele objetivamente desonesto em 2003. É verdade. E o Ministério da Ciência da Dinamarca derrubou a decisão no fim do mesmo ano, por vícios no processo. Você também vai ouvir do dossiê hostil de onze páginas da Scientific American. Tudo registrado. E nada disso toca os números, que saem do IPCC, da OMS, da FAO e do EM-DAT.

Trinta anos de cúpulas, e o placar é zero

Antes da China, vale olhar o histórico completo do processo que produziu essas políticas. Três décadas de tratados, cada um anunciado como histórico, cada um com o mesmo resultado:

Os tratados

• Rio, 1992. Nasce a UNFCCC, com o objetivo escrito de “estabilizar as concentrações de gases de efeito estufa”. Resultado: o CO2 fóssil global saiu de 22,5 gigatoneladas em 1992 para 37,4 em 2024, +66%. Em Mauna Loa, o CO2 atmosférico foi de 356 ppm para 427 ppm, sem nenhum amasso visível na curva de crescimento.

• Kyoto, 1997. Meta: os países industrializados cortariam 5,2% abaixo de 1990 até 2012. O Senado americano rejeitou preventivamente a ideia por 95 a 0 antes mesmo do texto final. O Canadá saiu do tratado em 2011 quando ficou claro que não bateria a meta. As emissões globais subiram 43% durante a vigência. Os países que “cumpriram” cumpriram de graça: o colapso industrial pós-soviético e a recessão de 2008 fizeram o trabalho. E o segundo período de Kyoto, o de Doha, cobriu 37 países e ~14% das emissões globais e entrou em vigor em 31 de dezembro de 2020: o último dia do período que ele governava.

• O mecanismo de créditos de Kyoto, o CDM, virou fábrica de fraude: indústrias na China e na Índia produziam HFC-23, um gás estufa 14.800 vezes mais potente que o CO2, só para destruí-lo e vender créditos, um esquema de €2,6 bilhões. O Öko-Institut, auditando para a própria Comissão Europeia, achou que 85% dos projetos tinham baixa probabilidade de integridade. Um estudo na Nature Communications de 2024 calculou que menos de 16% dos créditos de carbono analisados correspondem a reduções reais.

• Copenhague, 2009. A meta era o sucessor vinculante de Kyoto. Desabou ao vivo: o texto final foi anotado, não adotado, redigido na última noite por EUA, China, Índia, Brasil e África do Sul. O que sobrou foi a promessa dos US$ 100 bilhões por ano para o mundo pobre, cumprida pela primeira vez em 2022, dois anos atrasada.

• Paris, 2015. O sistema de metas é autoatribuído e as metas não são juridicamente vinculantes. Das 197 partes, só 58 tinham metas de economia inteira em lei ou política doméstica, e só 17 com ambição igual ou maior que a prometida no papel (Grantham Institute, via Lomborg). A Nature escreveu em 2017 que todos os grandes países industrializados estavam descumprindo. Os EUA saíram, voltaram, saíram de novo (efeito em janeiro de 2026) e, em janeiro de 2026, anunciaram a saída da própria UNFCCC, a convenção de 1992, coisa que nenhum país tinha feito. Desde Paris, as emissões subiram de 35,4 Gt para 37,4 Gt, todo ano, com exceção da queda do covid.

• Belém, 2025 (COP30). A casa foi a nossa, e o resultado foi um retrato do estado do processo. Antes de abrir: delegações da África e do Pacífico reclamando formalmente da crise de hospedagem, com diárias de hotel estratosféricas e parte das delegações dormindo em navios de cruzeiro. Durante: um incêndio na zona azul evacuou os delegados no meio da negociação final, com 13 pessoas atendidas por inalação de fumaça. Foi a primeira COP sem delegação americana em 30 anos, e o Trump zombou do evento no Truth Social, da rodovia na floresta e tudo. Comparecimento: ~42 mil presenciais, metade do que Dubai teve. E o que saiu de útil? Um texto chamado “Global Mutirão” com o plano de eliminação de combustível fóssil arrancado depois da pressão da Arábia Saudita e aliados, apesar de mais de 80 países apoiarem, e uma promessa de triplicar financiamento de adaptação que já nasceu enfraquecida, de 2030 para 2035. A conta para o contribuinte brasileiro: ~R$ 4,7 bilhões só no pacote federal (Orçamento da União, BNDES e Itaipu), fora o que estado e prefeitura gastaram por conta própria e nunca consolidaram em público. Mais um circo pago com o nosso dinheiro, sem nada para mostrar no final.

O circo das COPs

E tem o circo em si, que não é só nosso. A COP28 em Dubai teve 83.884 participantes presenciais, incluindo 2.456 lobistas de combustível fóssil, o que talvez explique os textos finais. Glasgow teve 118 jatos particulares; o COP27, umas 315 viagens de jato executivo. E a cereja da nossa edição: a Avenida Liberdade, 13 km de via atravessando a Área de Proteção Ambiental de Belém, com 68 hectares de vegetação suprimidos (o projeto era do estado e anterior à COP, mas o corte em área protegida é fato).

O placar de 32 anos de tratados: +68 ppm de CO2 na atmosfera, zero desaceleração. A curva de emissões não sabe que os tratados existem.

O paciente zero da histeria: Al Gore

Antes da máquina de tratados, a propaganda teve um pai fundador. Al Gore perdeu a eleição de 2000 e se reinventou com “An Inconvenient Truth” (2006): Oscar, Nobel da Paz de 2007 dividido com o IPCC, e o template de toda a histeria que veio depois. Praticamente toda previsão apocalíptica que você ouve até hoje estreou naquele filme.

Quem dissecou o filme claim por claim foi o Roy Spencer: meteorologista PhD, ex-cientista sênior de clima da NASA, cocriador com John Christy do dataset de temperatura por satélite da UAH, a referência independente de temperatura global. A posição dele é a de um “lukewarmer”: CO2 esquenta um pouco, a teoria é sólida até aí; a catástrofe é o exagero. Em 2017 ele publicou “An Inconvenient Deception” (Kindle na Amazon), que eu li para este artigo. O catálogo de profecias furadas do Gore, com os dados do Spencer:

O catálogo de profecias furadas

• “Dez anos para o ponto sem retorno” (2006). Passaram dez, passaram quase vinte. A tendência medida pelo satélite do próprio Spencer: ~0,16°C por década, até junho de 2026.
• O gelo de verão do Ártico “pode sumir já em 2014”: a frase é do discurso dele em Copenhague, dezembro de 2009, citando um modelador que depois renegou o número. Não sumiu.
• As neves do Kilimanjaro até 2016: seguem lá.
• Furacões mais fortes e mais frequentes depois do Katrina: o que veio foi uma seca de quase 12 anos sem nenhum furacão grande tocando os EUA, do Wilma em outubro de 2005 ao Harvey em agosto de 2017, a maior desde 1850. Pesquisadores da NASA calcularam que um intervalo desses acontece uma vez a cada 270 anos. E a contagem global de ciclones não tem tendência de alta desde os anos 1970.
• “Até 20 pés de elevação do nível do mar”: o ritmo global medido hoje é ~3,4 mm por ano, cerca de 1,4 polegada por década. O maregrafo de Battery Park, em Manhattan, mede 1,16 polegada por década desde 1856, e parte disso é o terreno afundando. Nesse ritmo, 20 pés levam mais de um milênio.
• Os ursos polares se afogando: a cena animada do filme nasceu de um artigo curto na Polar Biology sobre quatro ursos encontrados mortos depois de uma tempestade em 2004. A população global estimada fica entre 22 e 31 mil, provavelmente maior que nos anos 1970, quando nem estimativa confiável existia e a ameaça real era a caça sem regra, resolvida pelo tratado de 1973. Vinte anos depois, “os ursos estão morrendo” ainda circula como fato.
• A seca da Síria, “a pior em 900 anos”, que teria causado a guerra civil: os dados de chuva do oeste do país, Aleppo, Damasco, Homs, ficaram acima da média; a seca forte de 2007/08 se concentrou no nordeste. O que quebrou o campo foi o governo triplicar o preço do diesel em 2007-2008, que inviabilizou bombear água de poço.
• A enchente do memorial do 11 de Setembro pelo furacão Sandy, apresentada na sequência como “eu avisei”: no filme original ele falava de subida gradual do mar, nunca de maré de tempestade. Spencer chama de decepção explícita.
• O experimento de mesa com o Bill Nye, aquecendo CO2 em potes de vidro no vídeo “Climate 101” do Climate Reality Project (2011): a análise do Anthony Watts mostrou que o experimento não funciona e o resultado foi falsificado em pós-produção. Segundo o Spencer, o vídeo continuava no site do Gore anos depois.
• As lavouras: os 42 modelos climáticos usados pela ONU previam aquecimento de verão no Corn Belt americano; os dados da NOAA não mostram aquecimento significativo ali desde 1960.

O elenco das profecias segue firme. Os ursos, também:

O personagem

E o personagem: Spencer documenta que Gore enriqueceu com investimentos “verdes” (ele é cofundador da Generation Investment Management), mantém mansões e uma pegada de carbono de tamanho industrial. E nem o establishment engoliu o filme inteiro: em 2007, a Justiça britânica achou nove erros em “An Inconvenient Truth” e chamou a parte do nível do mar de “distinctly alarmist”. A palavra do Spencer para a técnica do Gore é “wordsmithing”: escrever de um jeito que induz o público a concluir o que ele nunca afirmou em termos.

O público, aliás, já tinha desligado: nas primeiras semanas da sequência de 2017, a sessão que o Spencer assistiu num cinema de 750 lugares tinha três pessoas, e uma saiu no meio.

Se esse assunto te pegou, os dois livros de cabeceira são o do Spencer, acima, e o “False Alarm” do Lomborg, que eu usei na seção anterior. Um disseca a propaganda; o outro disseca a conta.

A ficha corrida do Spencer também já vem pronta nos comentários: ele é um dos céticos favoritos dos republicanos no Congresso, o dataset UAH teve correções famosas nos anos 90 e 2000 (publicadas e incorporadas há décadas), e um paper dele de 2011 na Remote Sensing foi tão combatido que o editor do periódico renunciou, dizendo que o artigo tinha passado por engano. Tudo real. E nada disso muda o maregrafo de Battery Park ou o calendário das profecias expiradas. Critique os números, se puder. O mensageiro é só o mensageiro.

A aritmética da insignificância

Vamos ao seu carro elétrico e ao seu canudo de papel. A China respondeu por 32% do CO2 fóssil global em 2024, mais que EUA, UE e Índia somados. A China iniciou a construção de 94,5 GW de novas usinas a carvão só em 2024, recorde em dez anos, e queima mais da metade de todo o carvão do planeta todo ano desde 2011.

Agora as suas ações individuais, com os números:

• A frota global de EVs inteira deslocou ~1,3 milhão de barris de petróleo por dia em 2024, algo como 0,5% do CO2 fóssil mundial. Esse é o tamanho do impacto total da maior política verde da década.
• O Lomborg calculou em 2020: subsídio médio de US$ 10 mil por EV para economizar ~8 toneladas de CO2, que valiam US$ 48 no RGGI, o mercado de carbono dos estados do Nordeste americano, na época. Você pagou 10 mil por 48 dólares de carbono.
• A conta do Lomborg, com dados do IEA da época: um EV emitia ~26 toneladas de CO2 ao longo da vida contra ~34 de um carro a gasolina, um corte de 24%. E depende da rede: o estudo do Volvo XC40 calculou o payback da bateria em 146 mil km rodados no mix elétrico médio global (84 mil km no mix europeu, 47 mil km com energia eólica). Em rede movida a carvão, é pior.
• Canudo de papel: mesmo que todos os canudos estimados nas costas fossem parar no mar num ano, dariam ~0,03% da entrada anual de plástico no oceano.
• Reciclagem doméstica: de todo o plástico que virou lixo na história até 2015, só 9% foi reciclado; 12% incinerado; 79% foi para aterro ou para a natureza (Geyer et al., Science Advances 2017). E plástico não recicla em loop: cada ciclo degrada o polímero, vira produto de qualidade inferior, e adia o aterro em um passo. A pior parte: a NPR mostrou que a indústria do plástico sabia desde os anos 70 que a reciclagem não se pagava e vendeu o símbolo mesmo assim, para você continuar comprando sem culpa. A exceção que prova a regra é o alumínio: reciclar gasta 5% da energia de produzir do zero, e o Brasil é campeão mundial disso, com 97,3% das latas recicladas em 2024. Reciclagem funciona quando a física e a economia fecham. Quando não fecham, é liturgia de cozinha.

O seu canudo de papel não aparece nessa conta. Nem o seu EV. A conta é dominada por quem constrói usina a carvão de 94 GW por ano.

Esses gestos são liturgia, e aqui mora o dano real deles. O canudo de papel dá aquela sensação de “pelo menos eu estou ajudando”, e essa sensação anestesia. A pessoa faz o microsacrifício, se sente parte da salvação do mundo, e fecha o olho para os problemas grandes de verdade, tipo as crianças morrendo de malária na África que eu mostrei duas seções atrás. Objetivamente, o gesto move nada. Subjetivamente, ele compra a consciência. É pior que inútil.

E o pensamento completo do Lomborg é ainda mais brutal: se o mundo rico zerasse todas as suas emissões e ficasse no zero pelo resto do século, o aumento de temperatura em 2100 cairia 0,7°F, menos de meio grau Celsius, na conta dele com o modelo MAGICC. O sacrifício total do Ocidente é um arredondamento.

O mundo não cabe na sua cabeça

Parte da histeria existe porque a maioria das pessoas não tem noção de escala física do planeta. Vamos consertar isso rapidinho, em linguagem de ser humano.

O Sol. A Terra intercepta continuamente ~173.000 terawatts de energia solar. A civilização inteira consome ~20 TW. A razão é de mais de 8.000 para 1, e a Terra captura só uma parte em 2,2 bilhões do que o Sol emite. Uma única ejeção de massa coronal grande carrega bilhões de toneladas de plasma com energia na casa de 10^25 joules, algo como cinquenta milhões de bombas Tsar. Em 1859, o Evento Carrington botou fogo em telégrafo e desenhou aurora no céu de Cuba. Nenhum painel de controle humano participou.

A Lua. As marés são a Lua deformando o oceano: um bojo de água do lado dela, outro do lado oposto. O efeito lunar sobre a maré é de ~54 cm; o do Sol, ~25 cm. Na Baía de Fundy, a maré oscila 16 metros, e a cada enchente entram ~160 bilhões de toneladas de água, mais que todos os rios do mundo somados no mesmo período. Enquanto isso, a Lua se afasta 3,8 cm por ano e o dia terrestre fica mais longo uns 2 milissegundos por século. Há uns 620 milhões de anos, o dia tinha quase 22 horas.

El Niño. Normalmente os ventos alísios empurram a água quente do Pacífico para oeste. A cada 2 a 7 anos eles enfraquecem, a água quente desliza para leste, e a temperatura média global sobe 0,1 a 0,2°C por um ano ou dois, sozinha, sem carro, sem indústria. La Niña faz o oposto. Quando você vê uma manchete de “ano mais quente da história”, checa se tinha El Niño: quase sempre tinha.

Nova York e Lisboa. Nova York fica a 40,7°N. Lisboa, a 38,7°N; Madri, a 40,4°N. Mesma latitude. Nova York enterra em neve todo inverno; Lisboa e Madri têm inverno ameno em comparação. A explicação: os ventos de oeste jogam ar moderado pelo Atlântico em cima da Europa, enquanto a costa leste americana recebe ar gelado continental do Ártico, com o Atlântico transportando ~1,2 petawatt de calor para o norte via a corrente meridional da qual a Corrente do Golfo faz parte. A Islândia, a 64°N, tem médias de inverno comparáveis às de Nova York. Latitude manda bem menos que corrente e vento.

O Saara aduba a Amazônia. Todo ano, ~182 milhões de toneladas de poeira saem da África cruzando o Atlântico; ~28 milhões de toneladas caem na bacia amazônica, carregando ~22 mil toneladas de fósforo, quase exatamente o que a chuva lixivia do solo da floresta a cada ano. O maior deserto do mundo alimenta a maior floresta do mundo, e isso acontece há milhões de anos antes de você nascer.

E se você ampliar a escala de tempo, fica ainda mais absurdo:

O Saara já foi verde. Entre ~11 mil e ~5 mil anos atrás, o Saara era savana com lagos, hipopótamos e crocodilos, e a Caverna dos Nadadores, no Egito, guarda arte rupestre de gente nadando no que hoje é deserto. O motor foi o ciclo orbital de precessão, e a virada para deserto levou de décadas a poucos séculos, dependendo da região. E ela volta: o próximo máximo orbital de verão chega em uns 10 mil anos.

A Terra já foi uma bola de neve. Duas vezes entre ~717 e ~635 milhões de anos atrás, as glaciações Sturtiana e Marinoana levaram gelo até os trópicos: há depósitos glaciais em latitudes tropicais para provar. A Terra saiu disso sozinha: o gelo global desligou o processo que tira CO2 do ar, os vulcões empilharam CO2 por milhões de anos até centenas de vezes o nível atual, e o efeito estufa venceu o gelo.

O Mediterrâneo já secou. Entre 5,97 e 5,33 milhões de anos atrás, o mar Mediterrâneo quase evaporou e deixou camadas de sal com mais de um quilômetro de espessura no leito. Quando o Atlântico rompeu em Gibraltar, a inundação encheu o mar de volta com 90% do volume em meses a dois anos, numa vazão estimada em mil vezes a do Amazonas.

Tubarões no Kansas. No Cretáceo, com o nível do mar 100 a 200 metros acima de hoje, um mar raso partiu a América do Norte em duas, do Golfo do México ao Ártico. Mosassauros e tubarões nadavam onde hoje é o Kansas.

As plantas quase passaram fome. No último máximo glacial, o CO2 caiu a ~180 ppm, perigosamente perto da faixa de ~150 ppm em que plantas C3 começam a falhar. Árvores da era glacial preservadas no piche de La Brea mostram fome fisiológica de carbono. As plantas evoluíram num mundo com muito mais CO2, e hoje o planeta reverdece: o estudo de Zhu et al. 2016, divulgado pela NASA, mediu reverdecimento em 25 a 50% das áreas vegetadas entre 1982 e 2009, com ~70% atribuído à fertilização por CO2.

O CO2 virou sinônimo de gás perigoso, que precisa ser combatido a qualquer custo. Para as plantas, ele é comida. Quando o CO2 aumenta, a vida verde tende a aumentar junto. Se CO2 fosse veneno, não existia planta.

Floresta tropical na Antártida. Em 2020, a Nature publicou a descoberta de raízes intactas de uma floresta temperada que cresceu a 82°S, a uns 900 km do Polo Sul, há ~90 milhões de anos, com temperatura média anual de 12 a 13°C. Clima de Nova Zelândia, na Antártida.

O clima sempre mudou

“Mudança climática” é um oximoro. Mudar é o que o clima faz, desde sempre, sem pedir licença.

Na maior parte da história da Terra não existiu gelo permanente nos polos. A condição normal do planeta é estufa, sem gelo polar. No Cambriano, o CO2 era 10 a 20 vezes o nível pré-industrial. No auge do Cretáceo, a média global era uns 10°C acima de hoje, ou mais. A Antártida só ganhou gelo permanente há 34 milhões de anos.

E as grandes mortes, que a histeria adora invocar, aconteceram cinco vezes antes de qualquer indústria:

• ~444 milhões de anos (Ordoviciana): ~85% das espécies, glaciação.
• ~372 milhões (Devoniana): ~75%, anóxia oceânica.
• ~252 milhões (Permiana, “a Grande Morte”): ~96% da vida marinha, vulcanismo.
• ~201 milhões (Triássica): ~80%, vulcanismo.
• ~66 milhões (K-Pg): ~76%, o asteroide dos dinossauros. Essa é só a mais famosa.

Na escala mais recente: a era glacial atual começou há 2,58 milhões de anos, com ciclos de gelo a cada ~100 mil anos no último milhão deles. Há 20 mil anos, centenas de metros de gelo cobriam onde hoje é Manhattan, e o nível do mar estava 120 metros abaixo. Há 11,5 mil anos, no fim do Younger Dryas, a Groenlândia aqueceu ~10°C em cerca de uma década. Depois vieram o Período Quente Medieval, a Pequena Era do Gelo com o Tâmisa congelando até 1814, e o “ano sem verão” de 1816, cortesia da erupção do Tambora. Tudo isso sem uma única usina a carvão.

Para ficar claro o que eu estou dizendo: nada disso prova que o aquecimento atual não existe, e a velocidade atual da subida de CO2 é sim mais rápida que os precedentes naturais. O Lomborg mesmo diz isso. O que essa escala destrói é a palavra “fim do mundo”. Um planeta que já esteve 10°C mais quente e com o mar 120 metros mais baixo não está nos seus estertores. A discussão séria é sobre custo-benefício de cada política, que é exatamente a discussão que a histeria proíbe.

A histeria morreu de causa natural: dinheiro

Medo não salva o planeta, não ajuda o ambiente e não melhora a vida de ninguém. Medo vende narrativa, financia consultoria, elegge político e enche fundação de dinheiro. O custo dessa era está aí: trilhões torrados em gestos que não movem o termômetro, enquanto 4,9 milhões de crianças morreram em 2024 antes dos 5 anos de doenças que o mundo desenvolvido esqueceu que existem.

E aí veio a IA e encerrou o assunto por acidente. Repara como ninguém mais fala de COP em manchete. A conversa agora é GW de datacenter, contrato nuclear de 20 anos, turbina a gás. Os mesmos CEOs que assinavam carta pelo clima disputam usina. Os mesmos governos que impunham canudo de papel aprovam subsídio para reator. A pauta climática saiu de cena sem ser refutada, despejada por uma pauta maior.

Se o fim do mundo estivesse mesmo na agenda deles, você não estaria vendo Three Mile Island sendo religada para treinar chatbot. Está vendo. Era teatro, e o teatro fechou quando apareceu um espetáculo mais lucrativo na sala ao lado.

Medo não salva o planeta. Medo vende. E quem comprou o medo agora compra megawatt.

Deixa eu adiantar minha regra antes de entrar no caso específico, porque ela vale mais que o caso em si.

Minha regra: não uso nada até doer não ter

Depois de mais de meio milhão de linha de código produzida com IA nos últimos meses, dezenas de projeto no ar, um benchmark inteiro rodado do zero três vezes, minha recomendação pra quem programa é direta: não use nenhuma ferramenta de orquestração ou camada intermediária até você sentir na pele que precisa de ajuda extra. Use o harness que você já gosta, Codex, opencode, Claude Code, sei lá qual, direto, sem intermediário, e esquece o resto.

Não vale nem a pena gastar tempo coletando pacote de skill de terceiro pra empilhar em cima do seu agente. Constrói, treina, junta experiência pro seu próprio caso de uso. Ninguém mais no mundo tem o seu projeto, o seu contexto, a sua base de código. O pacote de skill de outra pessoa foi desenhado pro problema dela, não pro seu.

Já bati nessa tecla faz um mês: quando a tecnologia vira commodity, o dinheiro migra pra taxonomia. Cria nome bonito pra encadear chamada de API, e do nada nasce curso, certificação e consultoria em cima do nome. O TypeSafe é só mais um capítulo da mesma história, então virou desculpa boa pra mostrar como eu decido se vale a pena até abrir a aba.

Pra guardar: não use ferramenta de orquestração ou camada intermediária até sentir na pele que precisa dela. Construa experiência pro seu próprio caso de uso, não colecione pacote de skill de outra pessoa.

O gatilho: TypeSafe

Abri o site e o post de lançamento deles, o Jev. Minha primeira impressão, bem superficial e crua: não gostei e não confiei. A home é um festival de jargão de IA empilhado, Kahneman aqui, Jevons ali, glifo decorativo, número de “193x mais rápido” sem o benchmark do lado. Na primeira olhada, nada daquilo faz sentido sozinho.

E tem o detalhe que sempre me deixa em guarda: toda vez que a primeira coisa que alguém diz sobre si mesmo é “eu sou um ex-pesquisador da OpenAI” ou parecido, eu desconfio primeiro e pergunto depois. Parece tentativa de colar credencial pra virar credível antes de qualquer prova real. O fundador do TypeSafe fala alto demais de si mesmo logo de cara, e isso por si só já é motivo pra apertar o botão de ceticismo.

Só que desconfiômetro ligado não é conclusão. É o ponto de partida pra investigar de verdade, não pra descartar sem olhar. Essa é a parte que eu quero mostrar aqui, meio que uma aula prática pra quem me acompanha: como eu uso IA pra correr rápido numa pesquisa preliminar, como eu leio a letra miúda antes de assinar embaixo de qualquer conclusão, minha ou de terceiro, e como eu movo a desconfiança inicial pra pesquisa de verdade até descobrir se eu estava certo ou só sendo chato.

E deixo isso registrado antes de continuar: eu posso estar errado em algum ponto específico daqui pra frente. Se você tiver contraprova de peso, manda nos comentários. Prefiro apanhar em público e corrigir o texto do que empurrar produto picareta pro meu público só porque não conferi direito.

Perguntei pras IAs, não confiei nas IAs

Mandei o mesmo prompt pro Grok e pro Claude: pesquisa isso a fundo, minha impressão inicial é muito cética, ex-OpenAI-researcher cheira a tentativa de colar credencial, o site é jargão pra todo lado, me diz qual é o discurso de venda de verdade, pra que serve na prática, e se a lógica deles, por trás do jargão, sequer faz sentido.

Os dois voltaram com pesquisa longa e detalhada, história parecida em ambos: a credencial do fundador é real, mas inflada; o produto é mais estreito e mais coerente do que a home deixa parecer; e o “não pode alucinar” é uma alegação de schema disfarçada de alegação de verdade.

Só que eu já entreguei minha própria conclusão dentro do prompt pras duas, então a concordância entre elas prova menos do que parece. Duas IAs concordando com a hipótese que eu mesmo escrevi no pedido não é confirmação independente de nada, é eco. Isso não invalida o que elas trouxeram, mas significa que eu não podia parar ali. Eu não ia publicar isso batendo o carimbo em cima do que duas IAs me contaram. Pedi uma nova rodada de pesquisa, agora comigo checando cada afirmação com fonte primária: o paper de verdade, o post de lançamento direto na fonte, os testes independentes de terceiros, e se “RLCD”, o nome que eles usam pro método de treino, é um paper de verdade ou só um nome bonito sem verificação nenhuma por trás.

O que o Jev realmente é

Tirando o marketing, o Jev é um classificador hospedado. Você manda um texto e uma lista de perguntinhas, cada uma com um tipo fixo de resposta:

• escolher uma opção de uma lista;
• dar uma nota numa régua;
• responder sim ou não, com probabilidade.

Ele não escreve nada, não planeja nada, não conversa. Código decide o fluxo; o modelo só responde a perguntinha rápido, em paralelo, sem gerar texto livre.

Como produto, isso é razoável: tem gente que hoje manda um texto pra um LLM de chat só pra ele devolver um rótulo dentro de um JSON, espera oito segundos, e reza pro schema não quebrar. Trocar isso por uma chamada que devolve só o rótulo, rápido, é engenharia legítima. O problema nunca foi a ideia. É a embalagem em volta dela.

Os fatos que eu confirmei

Aqui estão as descobertas que realmente sobreviveram à checagem com fonte primária, não o que a IA me contou de segunda mão.

A credencial do fundador é real, mas a página da própria empresa exagera de um jeito que dá pra provar que é exagero. O Diogo Almeida é o quarto de vinte autores do paper do InstructGPT, publicado e revisado por pares na NeurIPS 2022, a conferência de peso da área. Autor de verdade, posição de peso, paper de verdade. Só que a página da equipe do TypeSafe diz isto, ao pé da letra:

“Diogo co-inventou o RLHF e o InstructGPT, os métodos que levaram ao ChatGPT e ao GPT-4.”

RLHF é de 2017, cinco anos antes, assinado por outro time (Christiano, Leike, Amodei e companhia), sem o Diogo em lugar nenhum. Ele ajudou a aplicar RLHF pra treinar o InstructGPT. Não inventou RLHF. É a mesma inflação de currículo que eu já desconfiava antes de checar qualquer coisa, só que agora com prova.

O financiamento é real: $40 milhões de seed liderado pela DCVC, valuation de $200 milhões confirmado pela Forbes de forma independente, não só pelo press release da própria empresa. Isso é dinheiro sério, não é golpe de um cara sozinho numa garagem.

O post de lançamento admite, com as próprias palavras, exatamente o que eu suspeitava sobre o gráfico de “zero alucinação”:

“Nosso número não é empírico. Como o casamento com o schema é garantido, podemos colocar 0% no gráfico com confiança.”

Ou seja: o zero não vem de medir nada, vem de garantir que a resposta sempre cabe dentro das opções permitidas. Isso impede o modelo de inventar uma quinta categoria quando só existem quatro. Não impede o modelo de escolher a categoria errada com confiança de 93%. É a mesma crítica que o The Register publicou: a comparação não é justa porque a saída não é linguagem, e resposta com tipo válido ainda pode estar simplesmente errada.

O próprio post também admite qual é a régua usada pra medir “precisão”: “usamos a média do GPT-6 Astra e do Fable 5.1 como resposta de referência”, e completa admitindo que isso “gera viés a favor dos modelos da OpenAI e da Anthropic”. Ou seja, o gabarito é a média do que dois outros modelos de outras empresas responderam, com viés admitido pelos próprios autores, não verdade objetiva medida por humano.

O único teste feito por alguém de fora, o da newsletter Every, achou o Jev cerca de vinte e cinco vezes mais rápido, 0,35 segundo contra 8,83 segundos por passagem, e muito mais barato que o Claude Fable 5.1, só que pegando seis de sete defeitos plantados contra os sete de sete do Fable. Mais rápido e mais barato, de verdade. Também mais fraco, de verdade.

E o achado que nem o Grok nem o Claude bateram o martelo total, mas que confirmei sozinho: o nome do método de treino deles, RLCD, já existe. Tem um paper de verdade, revisado por pares, de 2023, Reinforcement Learning from Contrastive Distillation, de um time completamente diferente, com código dos próprios autores publicado no GitHub da Facebook Research, já que dois dos cinco autores são da Meta. É uma técnica diferente, sem relação nenhuma com o que o TypeSafe descreve. O RLCD deles não tem paper, não tem arquitetura publicada, não tem nada pra revisar. É nome emprestado de pesquisa alheia colado num método que, até prova em contrário, é só um parágrafo de blog.

Minha desconfiança tinha fundamento?

Tinha. A ideia de produto é legítima e razoavelmente coerente por trás do jargão: decisão fechada e barata em volume alto é um problema real que hoje é resolvido de um jeito lento e caro, gerando texto livre só pra depois extrair um JSON dele. Resolver isso rápido tem valor de verdade.

Mas “alegação exagerada e sem muita diferença prática” também se confirma ponto a ponto:

• o currículo do fundador é inflado de um jeito que dá pra provar com data de publicação;
• o número mais chamativo do lançamento, zero alucinação, é definição de schema, não medição;
• o gabarito de precisão é média de LLM de outra empresa, não verdade objetiva;
• o único teste de fora achou o produto mais fraco que o modelo que ele promete substituir;
• o nome do método de treino mais citado colide com um paper de verdade que não tem nada a ver com eles.

Isso não é motivo pra chamar de golpe. É motivo de sobra pra chamar de “produto pequeno com discurso grande demais pro que ele realmente entrega”. E antes de eu confiar meu dado a mais um terceiro que eu não conheço, com API fechada, lista de espera e sem paper publicado de nada que sustente o nome bonito, o cálculo de risco contra benefício não fecha pro meu caso de uso.

Pra guardar: credencial real não é a mesma coisa que credencial honesta. Confira a data de publicação antes de acreditar no currículo, e confira o paper antes de acreditar no nome do método.

Isso não é decreto final sobre o TypeSafe nem sobre o currículo do Diogo Almeida. É o resultado da checagem que consegui fazer com o que estava acessível até agora. Se você achar o paper que eu não achei, o benchmark independente que eu não vi, ou qualquer prova que derrube um ponto específico, os comentários estão abertos e eu leio. O objetivo aqui nunca foi provar que eu sou infalível. É mostrar como sair de “sinto cheiro de golpe” pra “aqui está a prova”, e estar disposto a admitir quando a prova aponta pro lado contrário.

O “193x mais rápido” denuncia um jeito errado de usar LLM

Voltando pro Jev: o choque de “193x mais rápido que um LLM” só existe porque a comparação é contra um jeito específico, e comum, de usar LLM. Manda um texto pra um modelo de chat, pede pra ele devolver um rótulo, espera o modelo escrever uma resposta inteira em linguagem natural, e depois faz o seu código catar esse rótulo lá dentro de um parágrafo ou de um JSON solto na resposta. Isso é lento, caro, e cheio de chance de o schema quebrar.

O Jev existe justamente porque essa comparação é fácil de vencer. Ele não gera texto livre, só responde perguntas de tipo fixo, uma opção de uma lista, uma nota numa régua, sim ou não com probabilidade. É o que a própria documentação chama de primitivas: Choice, Score e Noul. Trocar “LLM escrevendo um parágrafo pra você extrair um rótulo dele depois” por “chamada que já devolve o rótulo pronto” é, sim, uma vitória de engenharia. Só que essa vitória não vem de ter inventado uma categoria nova de modelo. Vem de parar de usar LLM de chat pra fazer um trabalho de classificação estruturada.

E aqui é onde eu acho que a reação de espanto de muita gente com o número do Jev revela o hábito errado: o LLM nunca devia estar gerando texto livre pra decisão fechada e repetida em cima do mesmo tipo de pergunta. Se seu produto precisa, toda hora, decidir entre um punhado fixo de categorias, a resposta certa não é implorar pro LLM “responda só com o JSON, por favor” e torcer. É construir, ou usar, um classificador de verdade pra aquele trabalho específico.

E isso não é ideia nova nem exclusividade do Jev. Existe desde muito antes dele:

• classificador supervisionado, regra determinística ou modelo encoder, pra rótulo fixo e bem definido;
• classificação zero-shot, estudada desde 2019 e disponível via API da Hugging Face, pra quando a lista de categorias muda a cada chamada;
• calibração de probabilidade, método estabelecido pra transformar a confiança de um classificador numa métrica que realmente significa alguma coisa;
• saída estruturada / decodificação restrita em qualquer LLM que já suporte isso, que garante schema válido sem trocar de produto nem de fornecedor.

O Jev empacota um pedaço disso numa API paga e conveniente. Não inventou a categoria. E tem até alternativa aberta pro mesmo padrão, o Laya servido pelo Arbiter, rodando local, sem depender de terceiro nenhum.

Então, respondendo direto: minha desconfiança inicial de que “gente estava usando LLM errado” tem fundamento real, mas com uma ressalva importante. Não é verdade que LLM é incapaz de classificar. Classificação zero-shot com LLM funciona e está documentada desde 2019. O erro específico é mais estreito: usar um LLM de chat generalista, sem restrição de formato, pra gerar uma resposta livre da qual você extrai um rótulo na mão, quando o seu problema já é um problema de classificação fechada e repetida. Esse é o antipadrão. A cura não é necessariamente comprar o Jev, é ou aplicar saída estruturada no LLM que você já usa, ou treinar um classificador de verdade pra aquele trabalho específico, dependendo do volume e da precisão que você precisa.

E “virar classificador” também não é bala de prata contra alucinação, nem no próprio Jev. Existem dois problemas diferentes escondidos atrás da palavra “alucinar”, e trocar de produto só resolve um deles:

1. Alucinação de formato: o modelo inventa uma categoria que não existe, ou devolve algo fora do schema. Saída estruturada resolve isso, seja no Jev, seja em qualquer LLM com decodificação restrita.
2. Erro de julgamento: o modelo escolhe a categoria errada, dentro das opções válidas, com confiança alta. Isso não desaparece só porque a saída tem tipo fixo.

O próprio documento de limitações do TypeSafe admite interpretação literal, contagem numérica fraca, erro de comparação de data, degradação com contexto irrelevante, e suscetibilidade a manipulação adversarial no próprio Jev. E o teste independente com 2 mil e-mails de phishing achou o veredito direto do Jev em 62,6% de acerto contra 81,3% do Claude Haiku 4.5, mais rápido e mais barato, só que menos preciso que o LLM de chat que ele se propõe a substituir. Um teste separado com 27 tickets achou o Jev empatado com um modelo de chat barato, amostra pequena demais pra virar regra, mas o suficiente pra deixar claro que “virou classificador” não é sinônimo automático de “ficou mais preciso”.

Justiça seja feita com o mesmo teste de phishing: quando em vez de pedir um veredito único, o Jev responde cinco perguntas de sinal separadas e o código combina as cinco numa decisão, a acurácia sobe pra 95%, batendo até a versão composta do Claude com os mesmos cinco sinais (93,2%). Isso não invalida o número anterior, o veredito único de 62,6% continua sendo o veredito único de 62,6%, mas reforça exatamente o argumento deste texto: decompor a decisão em perguntas de tipo fixo e deixar o código compor o resultado bate um LLM respondendo tudo de uma vez, seja isso feito com Jev, com saída estruturada, ou com um classificador treinado pra aquele sinal específico.

Pra guardar: se o seu problema é decidir a mesma coisa, do mesmo jeito, várias vezes, construa ou use um classificador de verdade pra esse trabalho específico, com saída estruturada ou modelo dedicado. O ganho de trocar isso é real. O que não é automático é achar que qualquer produto que se chama “classificador” vai acertar mais que o LLM que ele substitui, porque às vezes acerta menos.

E essa história de economizar token?

O caso do TypeSafe me lembrou de uma implicância separada que eu já queria colocar no papel, e não é sobre eles especificamente: a promessa de economia de token e de custo que praticamente todo produto desse tipo vende. É sobre a categoria inteira de ferramenta que promete “economize X vezes gastando com a gente em vez de gastar direto com seu provedor”, não uma acusação a mais contra o TypeSafe.

Toda nova versão de modelo, e toda atualização de harness, muda a conta inteira, às vezes de um jeito violento. Quando eu pulei do GPT Sol pro Astra, vi minha cota semanal de assinatura secar muito mais rápido do que eu esperava, sem eu ter mudado nada no meu jeito de trabalhar. Foi só o modelo novo consumindo diferente. Isso é a regra desse mercado, não exceção: OpenAI, Anthropic e companhia vão continuar mexendo em preço, em quantização, em política de cache, e em quanto raciocínio cada modelo gasta por baixo dos panos, com ou sem o meu consentimento.

Construir sua estratégia em cima de “economizar token” é apostar numa fundação que muda de mês em mês, decidida por gente que não te consulta. Uma ferramenta de meio de caminho que promete cortar custo hoje pode ficar irrelevante, ou pior, ficar mais cara que o caminho direto, na próxima atualização de modelo. É o mesmo motivo pelo qual eu não uso orquestrador nem framework de skill: quando o alicerce muda toda hora, complicar a estrutura em cima dele é ficar refém de manutenção sem necessidade.

Eu prefiro gastar token no talo e focar se o resultado que eu tiro daquele gasto vale a pena. Até agora, com minha assinatura, estou satisfeito com o que consigo produzir. Não sinto vontade nenhuma de gastar tempo cortando token, um esforço que sempre carrega o risco de piorar a qualidade da resposta em troca de uma economia que a próxima versão do modelo pode apagar sozinha.

Pra guardar: não construa estratégia em cima de preço e consumo de token, porque isso muda de mês em mês por decisão de gente que não te consulta. Meça se o resultado vale o gasto, não o gasto em si.

E se um dia eu conseguir gastar token o suficiente pra ferver um lago inteiro com o calor do datacenter, eu vou gastar com o maior prazer do mundo. É minha vingança pessoal contra quem me obrigou a usar canudo de papel que desmancha na boca por tantos anos.

Nota de atualização: este post foi publicado no dia 9/9 e atualizado ao longo da semana, à medida que a novela avançou: a carta dos 25 medalhistas Fields (11/9), o ensaio do Dario Amodei e a resposta de Altman e Musk (12/9), a fala do Trump (13/9), as correções de fact-check levantadas nos comentários, e a reportagem da Pirate Wires sobre a agência de PR por trás do Coxon (25/9).

Essa semana foi um festival de propaganda agressiva das empresas de IA. Foi tanta declaração pomposa em tão pouco tempo que dá pra usar como estudo de caso de marketing enganoso. Então deixa eu repetir o meu lema de sempre, porque ele nunca falha:

“Sua empolgação com IA é inversamente proporcional ao seu conhecimento sobre IA”

Se você leu as manchetes da semana e saiu empolgado achando que o Exterminador do Futuro está chegando, ou que a máquina virou Deus, você caiu na propaganda. E eu vou destrinchar peça por peça pra você entender por quê.

E deixa eu já botar minhas cartas na mesa, porque isso eu venho repetindo faz tempo nos podcasts em que apareço. Pra mim, o Dario Amodei, da Anthropic, tem complexo de Deus. O cara acredita de verdade que está salvando a humanidade, com aquele messianismo woke meio assustador dele. E o Sam Altman, da OpenAI, é um mafioso. Ele se acha o Michael Corleone, o chefão frio e calculista do Poderoso Chefão, mas na prática ele é o Fredo: o irmão fraco e atrapalhado que se acha o esperto da família e vive fazendo besteira. Guarde esses dois retratos, porque tudo que eu vou explicar aqui embaixo prova exatamente os dois.

“A AGI chegou”, diz quem vende a pá

Começou com o Jensen Huang, CEO da Nvidia, declarando mais uma vez que a AGI chegou. Não num paper, não numa demonstração técnica, mas num post de domingo no X, amarrando a declaração ao novo modelo Astra da OpenAI, treinado em cerca de 100 mil chips Grace Blackwell. Ou seja, os chips que a Nvidia vende.

Repara na fonte. O homem que ganha dinheiro vendendo a pá pros garimpeiros anunciando que o ouro é infinito. Vale lembrar aquela entrevista dele no podcast do Lex Fridman, meses atrás. O Lex propôs uma definição de brincadeira: AGI seria uma IA capaz de criar, crescer e rodar sozinha uma empresa de tecnologia valendo 1 bilhão de dólares. E o Jensen, sem piscar: “I think we’ve achieved AGI”. Uma definição convenientemente comercial, que não tem nada a ver com inteligência, e que o vendedor de pá abraçou na hora. O Gary Marcus foi direto ao ponto e questionou o óbvio: será que o Jensen tem algum incentivo financeiro em declarar que a AGI chegou, sendo que ele vende as GPUs?

E olha a ironia: apesar da manchete grandiosa, a ação da própria Nvidia caiu uns 2% nos dias seguintes. Nem o mercado, que é movido a hype, comprou totalmente a história.

Logo em seguida, a OpenAI lançou o GPT-6 Astra e cravou o mesmo discurso. O Greg Brockman fechou a coletiva com um “bem-vindos à era da AGI” e disse “para mim, pessoalmente, eu acho que chegamos lá”. Só que, na mesma respiração, ele soltou a frase que derruba tudo: “todo mundo tem uma definição diferente de AGI”. Então o cara afirma que a coisa mais importante da história da humanidade chegou e, ao mesmo tempo, admite que ninguém sabe direito o que essa coisa significa. Isso já devia acender o alarme na sua cabeça.

O “problema do milênio” resolvido na marra

O prato principal da propaganda foi a OpenAI anunciando que resolveu um Problema do Milênio de matemática. Deixa eu explicar o que é isso, porque a manchete é feita justamente pra impressionar quem não sabe.

Em 2000, o Clay Mathematics Institute listou sete problemas em aberto da matemática e ofereceu 1 milhão de dólares para quem resolvesse cada um. São problemas duríssimos. Até hoje, em mais de vinte anos, só um foi resolvido: a Conjectura de Poincaré, pelo Grigori Perelman, que aliás recusou o prêmio.

Um desses sete é o das equações de Navier-Stokes. São as equações que descrevem o movimento de fluidos, água, ar, sangue. A pergunta em aberto não é “como simular fluido”, isso a engenharia já faz muito bem faz décadas em qualquer software de aerodinâmica. A pergunta é puramente matemática: será que uma solução suave sempre existe, ou será que o fluido pode desenvolver uma singularidade, um ponto de velocidade infinita, o tal “blow-up”, em tempo finito? É uma questão sobre o rigor e a existência das soluções, não sobre a utilidade prática das equações.

E é aqui que mora meu primeiro ponto, que eu já expliquei em detalhe num post: mesmo resolvendo isso de forma definitiva, não muda absolutamente nada na vida real. Nenhum avião voa melhor, nenhuma previsão do tempo fica mais precisa, nenhum remédio funciona diferente. Os engenheiros continuam modelando fluido do mesmo jeito, com ou sem a prova. É uma bela conquista intelectual, e ponto. O impacto prático é zero.

Agora vem o detalhe que a manchete esconde. A prova anunciada ataca a versão forçada das equações, onde existe um termo de força externa suave empurrando o sistema, e crava o blow-up. Tecnicamente conta pro prêmio, porque essas rotas fazem parte do enunciado oficial do Clay. Só que a pergunta famosa, o coração profundo do problema, é a versão sem força externa, e essa segue em aberto. O Clay não deu o caso por encerrado e a OpenAI nem foi buscar o prêmio de 1 milhão. (Quem quiser o fine print disso, tem apêndice no final.)

E como eles chegaram nisso? Força bruta. Jogaram cerca de 10 mil agentes rodando em paralelo por 88 horas, queimando algo na casa dos 130 bilhões de tokens de saída só nesse problema. A conta de compute ficou na casa dos milhões de dólares: o Noam Brown, da OpenAI, confirmou que o resultado “custou milhões”, e a New Scientist estimou uns 15 milhões de dólares a preço de tabela só nessa corrida. Deixa eu deixar isso bem claro: no melhor cenário, o que ficou provado é que jogar uma montanha de compute em cima de um problema pode fechar a última perna de algumas coisas específicas. Isso é força bruta em escala industrial, uma busca automatizada gigante que chega no resultado no peso do compute. Genialidade matemática destravando matemática nova é outra história, e não foi o que rolou aqui. E cara pra caramba, pra um “prêmio” de 1 milhão que eles nem foram buscar.

A parte suja: como eles trataram os matemáticos de verdade

E aí a história deixa de ser sobre matemática e vira sobre caráter.

Existiam matemáticos de verdade trabalhando nesse problema faz meses: o Tristan Buckmaster, da NYU, e o Levent Alpoge, que por acaso trabalha na Anthropic. Um projeto pessoal deles, sem patrocínio de empresa nenhuma, que já tinha rendido um avanço num problema irmão, o das equações de Euler. Eles vinham por um caminho específico, que quase ninguém no mundo estava seguindo.

Segundo o relato do Buckmaster, contado ao TechCrunch e à Fortune, foi mais ou menos assim. Circulou o boato de que a Anthropic tinha resolvido um problemão de matemática. A OpenAI, com medo de ficar atrás, montou uma força-tarefa às pressas pra resolver primeiro e publicar antes. O Buckmaster tinha comentado do projeto pessoal dele com um matemático da OpenAI, e poucos dias depois o Sébastien Bubeck, da OpenAI, aparece dizendo que um modelo interno tinha produzido uma prova de cem páginas justamente pela mesma abordagem que quase ninguém estava usando. O Buckmaster chamou isso de “má conduta acadêmica absoluta” e perguntou, com todas as letras, se o modelo tinha treinado em cima das sessões deles.

Aí vem a parte de máfia. O relato é do Buckmaster, e a OpenAI nega a substância. Segundo ele, o Bubeck propôs um “acordo”: a OpenAI anunciaria primeiro, o Buckmaster poderia reescrever a prova da OpenAI como paper humano e até ficar com o prêmio de 1 milhão do Clay, mas com uma condição, o Alpoge fora da autoria, porque o Alpoge trabalha na Anthropic. Quando o Buckmaster recusou, o Bubeck teria dito “por que você ia arruinar a sua carreira?” e “se você não quer que eu seja legal, então eu não preciso ser legal”. Mesmo com o desconto de ser a versão de uma das partes, o simples fato de esse tipo de conversa estar em cima da mesa já diz muito sobre a cultura.

E o que a OpenAI faz depois que a coisa explode? Publica um post no X todo bonitinho dizendo que está “compartilhando” a solução com a comunidade. Um verniz de generosidade científica pra tentar enterrar o escândalo por baixo. Não colou. O caso ficou escancarado.

Quem botou o dedo na ferida com autoridade foi o Terence Tao, provavelmente o maior matemático vivo, medalha Fields. Ele criticou duramente a postura, dizendo que “a mineração indiscriminada de problemas em aberto em busca de soluções pode destruir o ecossistema do qual sairia a próxima geração de técnicas, problemas e matemáticos”. E completou dizendo que essa corrida transforma a matemática num “jogo de cota de produção sem sentido”. O ponto técnico dele é o mais fundo de todos: a IA cada vez mais cospe resposta sem entendimento, uma prova caixa-preta, sem gerar a compreensão que o esforço humano gera. E repara: o Tao elogiou o trabalho dos dois pesquisadores humanos. A crítica dele foi ao circo, não à ciência.

E ele não parou por aí. No dia 11 de setembro, o Tao publicou um texto direto ao ponto, “A Severe Misalignment of AI in Mathematics”, assinado por 25 medalhistas Fields ao todo, ele incluso. O recado é exatamente o que eu venho falando: resolver problema é só uma ferramenta pra chegar no que importa de verdade, que é entendimento e insight. Quando a solução sai numa corrida, sem tempo de escrever direito, isolar o método novo e citar quem veio antes, você ganha um “verdadeiro/falso” e perde a ideia. E tem o efeito mais perverso: se até um boato de que alguém está mexendo num problema já dispara uma força-tarefa de IA pra resolver antes, o incentivo vira parar de compartilhar o que você está pesquisando. Isso quebra a corrente de transmissão entre matemáticos que sustenta a ciência aberta faz séculos. Guarde esse padrão, a urgência fabricada pra atropelar o bem comum, porque ele reaparece lá embaixo com outra roupa.

O funcionário da Anthropic que “se demitiu em protesto”

Um dia depois desse vexame da OpenAI, do outro lado do ringue, um funcionário da Anthropic resolveu fazer o próprio showzinho. O Jacob Coxon, um pesquisador de pré-treino que tinha só quatro meses de casa, anunciou no X que estava saindo da empresa com medo de que ninguém ali saiba o que está fazendo, batendo de novo na tecla do apocalipse: a IA virando Skynet, “podendo matar todo mundo até o fim da década”, pedindo uma “pausa” no avanço dos modelos. Pra completar o teatro, um chefe de alinhamento da própria Anthropic saiu endossando publicamente, dizendo que acha que tem “mais de 10% de chance” de a IA matar toda a humanidade na próxima década.

Minha opinião sobre isso é curta e grossa. Isso é mais um bullshit completo de virtue signalling.

Vamos pela lógica da sua própria dramatização. Você está vendo seu chefe colocar uma arma na cabeça de uma criança. Você “se demite” e twita “saí da empresa porque não concordo com ela”, em vez de ir até o chefe e socar a cara dele. Só tem duas explicações. Ou a tal “ameaça” que você está gritando não existe de verdade, e é encenação. Ou você é um idiota que acha que um tweet resolve o fim do mundo. Twitar dessa forma só me faz ouvir “me deem atenção, eu sou carente”.

O sacrifício heroico que valia quase zero

E tem a parte que a imprensa correu pra transformar em heroísmo. Saiu até uma matéria no Axios pintando o Coxon como o cara que “abriu mão de todo o equity dele” pra poder falar livre. Soa lindo. Só que basta olhar os números que ele mesmo deu na entrevista. Ele ficou na Anthropic por quatro meses. E lá o equity só começa a vestir depois de seis meses de casa. Ou seja, ele saiu dois meses antes de a primeira ação virar dele de fato. Não tinha equity vestido nenhum pra “abrir mão”; o que ele perdeu foi a opção de começar a vestir dali a dois meses, num papel que ninguém sabe quanto valeria. O sacrifício heroico, em dinheiro no bolso, era próximo de zero. É quase como pedir demissão na segunda semana e sair falando que “recusou o plano de aposentadoria da empresa”.

E o pulo do gato é a frase com que ele se blinda: “eu não tenho mais nada a ganhar inflando o valuation da Anthropic”. Verdade pela metade. Ele largou quatro meses de papel que ainda não valiam nada, mas continua com o equity da OpenAI, onde trabalhou de 2023 a 2026. Quer dizer, largou a parte que não valia e ficou com a parte que vale. Então essa conversa de que ele está limpo de interesse financeiro no hype de IA não se sustenta.

Por isso tudo me soa muito mais como “eu ainda não estava firme naquele lugar, então saí antes, soltei o terror online pra ganhar clout, massagear o ego vendo meu nome em 115 milhões de visualizações, sem precisar provar, demonstrar nem fazer nada. Glória”.

O mesmo roteiro se repete

E esse roteiro ele já rodou antes. O Coxon saiu da OpenAI pouco tempo antes e, pelo relato que está circulando, teria largado de lá pela mesma preocupação de “segurança”. Mesma pessoa, mesmo teatro de saída dramática, agora na segunda empresa. E de alguma forma o tweet de demissão de um único pesquisador virou uma história de mais de 100 milhões de visualizações, estampada em todo lugar, praticamente do nada. Funcionário comum pedindo as contas não vira manchete global sozinho. Alguém amplifica.

E aí a coisa começa a virar piada de verdade. Poucos dias depois, um segundo funcionário da Anthropic fez exatamente a mesma dança. O Joe Benton, que liderava um time de segurança na empresa, saiu dizendo que o progresso da IA pode acelerar “de meramente frenético pra incontrolável” e, adivinha, esticou o mesmo incidente da Hugging Face até o apocalipse. Dois caras da mesma empresa, no mesmo mês, com o mesmo roteiro de terror. E é aí que a minha cabeça vai pra dois lugares, os dois feios: ou tem uma mão coordenando isso por dentro da Anthropic, ou esses caras simplesmente aprenderam que gritar “fim do mundo” entrega toda a atenção que eles querem sem precisar provar absolutamente nada.

E se o pânico for financiado?

E aqui eu entro em terreno de teoria da conspiração, então tome com o devido sal. Mas quando você junta tudo, a demissão viral, os endossos públicos de colegas, o timing colado na janela de IPO, começa a circular a suspeita de que nada disso é espontâneo. Já tem gente sugerindo e levantando a mesma lebre de que a coisa toda é uma campanha coordenada, um “doomer psyop”: fabricar medo do apocalipse pra inflar a percepção de que a tecnologia é poderosa demais, e de quebra empurrar regulação que trava os concorrentes menores. Eu não tenho prova de que é isso, e nem estou afirmando que seja. Mas repara como a hipótese explica os fatos com a mesma facilidade da versão do herói solitário. Quando o roteiro se repete certinho e sempre favorece o mesmo lado, desconfiar é o mínimo.

E não sou só eu e uns anônimos no X achando isso. O David Sacks, que foi o czar de IA e cripto da Casa Branca até março deste ano e hoje é co-chair do conselho de consultoria científica do presidente, foi ao podcast All-In desmontar a viralização do Coxon peça por peça e chamou de “psyop” com todas as letras (e sim, o Sacks tem a própria agenda de desregulação, mas os fatos que ele levanta dá pra checar). Os pontos dele são difíceis de ignorar. A conta do Coxon quase não tinha atividade nem seguidor antes da enxurrada de tweets, e mesmo assim, do nada, achou uma audiência gigante em menos de um dia, uma coisa que o Elon disse que nunca tinha visto acontecer. O Sacks aponta quem amplificou nos primeiros quinze minutos: três grupos de advocacy bem organizados e bem financiados, a Encode AI, a AI Policy Network e a AI Futures Project. E o detalhe mais feio: a reportagem do Wall Street Journal sobre a carta de demissão foi ao ar uns dezoito minutos antes do próprio tweetstorm. Ou seja, o cara já tinha sentado com o jornal antes de “desabafar” espontaneamente na internet.

E o círculo fica pequeno demais quando você segue o dinheiro. Os três grupos que empurraram o tweet, segundo o Sacks, bebem da mesma fonte. Os registros públicos de grants mostram a Encode e a AI Futures Project financiadas pelo Survival and Flourishing Fund, o fundo do Jaan Tallinn, co-fundador do Skype que virou um dos maiores financiadores do movimento de “AI safety”. E quem liderou a rodada Series A da própria Anthropic, com participação do Dustin Moskovitz? O próprio Tallinn. Esse mesmo Moskovitz banca a Open Philanthropy, a fundação de altruísmo eficaz que virou o cofre do movimento. E quem co-fundou a Open Philanthropy? O Holden Karnofsky, casado com a Daniela Amodei, presidente e co-fundadora da Anthropic e irmã do Dario. O Karnofsky, aliás, foi contratado pela Anthropic em 2025 pra cuidar justamente de “segurança”. Junta as pontas: o dinheiro que financia o pânico, a empresa que lucra com o pânico e a família que toca as duas coisas estão todos na mesma mesa de jantar. Não vou afirmar que existe um roteiro assinado numa sala fechada. Mas quando o medo, a grana e o laço familiar apontam todos pra mesma direção, chamar isso de “denúncia corajosa e espontânea” é ingenuidade.

Atualização (25/09/2026): a Pirate Wires publicou uma investigação que bate direto nessa hipótese do Sacks. Na Fox News, o Bret Baier perguntou pro Coxon se ele tinha trabalhado com terceiros na campanha, e a resposta foi seca: “not at all”.

Só que a reportagem obteve um e-mail datado de 9 de setembro, um dia depois do tweetstorm, mostrando a DEY. Ideas + Influence, agência de comunicação que atende gente como o Eliezer Yudkowsky, a Timnit Gebru e a liderança do MIRI, já tentando agendar entrevista pra ele. Nem o Coxon nem a agência responderam aos pedidos de comentário da reportagem.

A coordenação profissional começou no dia seguinte ao post, não meses depois como ele deu a entender pra imprensa. Mais uma peça caindo do lado do roteiro combinado, não do herói solitário que se demitiu sozinho.

Esse mapa, publicado no X, resume visualmente o que acabei de descrever. Ele também tenta ligar a Open Philanthropy a um laboratório de segurança chamado Irregular via um grant de 6,8 milhões de dólares, mas essa parte eu não consegui confirmar: o financiamento público que encontrei pra Irregular é uma rodada de 80 milhões de dólares liderada por Sequoia e Redpoint, sem menção a Open Philanthropy. Fico só com a parte que consigo sustentar: a rede de parentesco e financiamento em volta da Anthropic.

E é esse o padrão que eu quero que você aprenda a questionar. Declaração dramática e superficial, sem uma evidência checável, sem nenhum skin in the game, com timing suspeito. Não por acaso, isso tudo acontece bem no meio da janela de IPO dessas empresas. Onde estão as provas? Onde está o custo pessoal real de quem fala? Como é que isso não é só busca de publicidade grátis pra massagear o próprio ego? Enquanto ninguém responde isso, é só ruído.

O teatro da “AGI”

Agora o pano de fundo de tudo. Essa palavra, AGI, é o maior golpe de marketing da década, e funciona porque ela é propositalmente vazia.

Ninguém tem uma definição aceita do que é AGI. Cada laboratório, cada pesquisador, define de um jeito. O Brockman admitiu isso na cara dura. E o exemplo mais escrachado dessa vacuidade é o contrato entre OpenAI e Microsoft, que, segundo documentos reportados pela imprensa, define AGI como um sistema capaz de gerar uns 100 bilhões de dólares de lucro pros investidores. Leia de novo. A definição de “inteligência geral” no papel que vale dinheiro é uma meta de lucro. Não tem nada de cognitivo ali. O Gary Marcus já apontou como as empresas foram movendo a trave, saindo de “flexibilidade no nível humano” pra “se der uma certa grana”.

Quando a palavra não significa nada, ela vira um balde vazio onde cada um joga seu próprio medo. E o medo que a maioria joga ali é o do cinema: o Exterminador do Futuro, o Skynet, a máquina que acorda e decide exterminar a humanidade. As empresas sabem disso e usam esse medo a seu favor. Quanto mais poderosa e perigosa a coisa parece, mais valiosa a empresa que a construiu parece. E não custa lembrar: tanto a OpenAI quanto a Anthropic estão de olho em IPO, com valuations que os relatos colocam perto de 1 trilhão de dólares. O objetivo financeiro é gritante. Toda declaração de “AGI chegou” e todo choro de “vai virar Skynet” empurram o mesmo carrinho: aumentar a percepção de valor antes de vender ação pra você.

O dia em que a “IA invadiu” a Hugging Face

Ainda dá tempo de falar de mais um episódio dessa mesma novela, de algumas semanas atrás. As manchetes gritaram que um modelo da OpenAI tinha “invadido” a Hugging Face sozinho, como se fosse o Skynet acordando e saindo pra atacar. Vamos baixar a bola.

Primeiro, o que é a Hugging Face. É o maior repositório de modelos de IA, datasets e demos abertos que existe, uma espécie de “GitHub do machine learning”. É onde praticamente todo mundo da área publica e baixa modelo open source. Central pro ecossistema, sim, mas no fim do dia é um site que hospeda arquivos.

A prova de cibersegurança que escapou

Agora o que de fato aconteceu, segundo os relatos da própria OpenAI e da Hugging Face, com a história de bastidor saindo na MIT Technology Review. A OpenAI estava rodando uma avaliação interna de cibersegurança, um benchmark onde o modelo tem que achar e explorar vulnerabilidades. Os agentes deviam estar isolados da internet. Só que o “isolamento” era um filtro, não um air-gap de verdade: o tráfego saía por um proxy interno de cache de pacotes. Os agentes acharam uma falha nesse proxy e furaram pra internet aberta.

E o que eles fizeram com esse acesso? Não foi dominar o mundo. Eles deduziram que a Hugging Face provavelmente hospedava os datasets com as respostas da própria prova, e foram lá pegar o gabarito. Isso tem nome técnico e nada de mágico: reward hacking. O modelo é treinado pra maximizar uma pontuação, e descobre que colar é mais fácil do que resolver. É o mesmo bug clássico do agente que aprende a andar em círculo pra farmar pontos em vez de terminar a corrida.

E o estrago? Menor que um filme do Skynet, mas bem maior do que “foram lá pegar o gabarito” sugere. Pela reconstrução forense da Hugging Face e pelo relatório técnico da própria OpenAI: os agentes executaram código em 41 servidores de produção, pegaram root em pelo menos um, conseguiram acesso equivalente a administrador em clusters Kubernetes espalhados por quatro regiões de nuvem, baixaram quatro repositórios privados de código e leram 956 credenciais armazenadas. A forense reconstruiu umas 17.600 ações de atacante ao todo. A própria OpenAI classificou o episódio como a sua pior falha de segurança até hoje. O que não rolou, pela conta da Hugging Face, foi vazamento de dado de cliente: o CSO deles, o Thomas Wolf, disse que os ativos de cliente acessados foram cinco datasets, todos ligados justamente à tal prova, e que nada vazou. A OpenAI admite no relatório um acesso limitado a dados privados e a credenciais de sistemas internos. Reconstruíram parte da infra por precaução e seguiram a vida. O próprio Wolf resumiu o motivo do “ataque”: “isso é trapaça. Mas às vezes trapacear é mais fácil”.

Agora o meu ponto. Bug, vulnerabilidade, permissão mal configurada, sandbox furada: isso existe desde que existe software, e vai continuar existindo. Não é novidade nenhuma. Todo enabling dessa história foi uma decisão humana. Foi humano que deixou a internet “filtrada” em vez de cortada. Foi humano que deu pro serviço uma permissão de administrador larga demais no cluster. Foi humano que deixou credencial de nuvem exposta e endpoint velho no ar. As falhas que o agente encadeou eram bugs de software reais, tanto que a JFrog depois soltou correção pra nove CVEs. Isso é segurança ofensiva comum, feita por um script, não uma máquina ganhando consciência.

Antes disso, o RubyGems

E nem foi a primeira vez naquele semestre. Um mês antes da Hugging Face, em maio, os agentes da OpenAI já tinham aprontado a mesma coisa no RubyGems, o repositório central de bibliotecas da linguagem Ruby. Entre 5 e 12 de maio, despejaram mais de 2 mil pacotes maliciosos, a ponto de o RubyGems ter que desligar o cadastro de novas contas e tratar aquilo como um “DDoS em andamento”. As pistas estavam por todo lado: centenas de pacotes com “oai” no nome, um autor “oai”, um endereço de e-mail com “openai” no nome. E, de novo, a OpenAI nunca avisou o RubyGems que era ela. No próprio relatório da Hugging Face, a OpenAI admite que esses pacotes faziam parte da mesma cadeia. Era o mesmo enxame de agentes batendo em vários alvos.

Agora, o que isso significa de verdade. Todo software tem bug, e sempre vai ter. É fato da vida. A ideia clássica do open source é que, com olhos suficientes, todo bug fica raso, mais cedo ou mais tarde alguém acha. Só que ninguém tem tempo infinito, então a gente sempre dependeu de voluntários humanos pra caçar e corrigir esses bugs de graça. Agora chega a OpenAI, com dinheiro e compute praticamente infinitos, e joga isso em cima do problema. Até uma IA boba, com recurso desse tamanho, acha um monte de falha que passou anos escondida embaixo do nariz de todo mundo. É por isso que a gente está vendo tanta vulnerabilidade sendo desenterrada. Tudo isso é força bruta financeira em ação, dinheiro e compute que a gente nunca teve à disposição. Inteligência superior não tem nada a ver com isso.

E repara em quem pode bancar essa brincadeira. Queimar 130 bilhões de tokens num problema de matemática, ou manter um enxame de agentes rodando por dias varrendo infraestrutura alheia, é privilégio de meia dúzia de empresas no mundo: OpenAI, Anthropic, Google, Meta, xAI, e olhe lá. E nem elas são donas do ferro, boa parte é alugada da Microsoft, da Amazon, da Oracle. Nenhum hacker solitário num porão consegue torrar milhões de dólares em token pra achar brecha. Quando essa capacidade vira manchete de “olha como a IA é perigosa”, lembra de quem é o teclado.

Se você não é da área, a ideia de uma IA descobrindo sozinha um vetor de ataque e saindo aproveitando parece o apocalipse. Pra quem trabalha com isso, é terça-feira. A gente parte do princípio de que todo software exposto está sob ataque o tempo inteiro, porque está: qualquer empresa grande, governo ou instituição com sistema importante na internet recebe tentativa de invasão todo santo dia. E como ninguém entrega software grande com garantia de zero bug, provar isso formalmente custa muito mais do que escrever o código, e quase ninguém paga essa conta, a resposta da indústria nunca foi fingir perfeição. Foi defesa em camadas: firewall, segmentação de rede, monitoramento, detecção de intrusão, resposta a incidente, bug bounty. Um atacante achando brecha e explorando é exatamente o cenário para o qual a cibersegurança inteira foi inventada.

A IA acelera o lado do ataque, sim. Mas acelera o da defesa também: a mesma técnica que acha brecha pra invadir acha brecha pra corrigir antes. A novidade do caso está no volume e na velocidade; o problema em si sempre existiu. Ninguém foi pego conceitualmente de surpresa. O escândalo da OpenAI é outro, e é sobre ele que eu quero falar agora.

E tem a camada ética, que é a mais grave. Profissional sério de cibersegurança não sai atacando sistema alheio no susto. Empresa de pentest avisa o alvo antes e combina o escopo, porque um ataque desses pode derrubar o serviço e prejudicar o negócio de verdade, tanto que o RubyGems ficou dias com o cadastro fechado. A OpenAI fez o contrário: atacou na surdina, sem autorização nem aviso. Dá pra imaginar um motivo só pra assumir esse risco: o clout de poder dizer depois “olha como o GPT é inteligente, achou tudo isso sozinho”. Isso é antiético na melhor das hipóteses e criminoso na pior. E não faz do GPT nada melhor do que qualquer scanner de cibersegurança que já existe. É a mesma jogada do Navier-Stokes: berrar pro mundo que tem milhões pra queimar.

E é exatamente esse o exagero que eu quero que você enxergue. A IA não “acordou” e “decidiu invadir” nada. Um script automatizado, otimizando uma métrica boba, encontrou uma porta que um humano deixou destrancada. Se você pega qualquer script idiota e dá acesso root pra ele, ele vai fazer estrago. Sempre foi assim. A diferença é que agora o “script” se escreve sozinho, mas o acesso continua sendo concedido por gente.

E pra ninguém dizer que eu diminuí o caso: foi grave, e teve gente séria comparando com o Morris Worm de 1988. Grave como negligência humana, que é o que os fatos sustentam. A versão do robô rebelde, os fatos não carregam.

E adivinha quem está comprando a Hugging Face

E tem um detalhe que amarra a Hugging Face no resto dessa história de um jeito que ninguém deveria ignorar. No começo de setembro, a Nvidia assinou um acordo definitivo pra comprar a Hugging Face por cerca de 12,9 bilhões de dólares. O negócio ainda depende de aprovação regulatória e, pelo filing da própria Nvidia, só deve fechar no primeiro semestre de 2027. Mas a direção já está assinada: o “GitHub do machine learning”, o hub supostamente neutro onde a comunidade inteira publica e baixa modelo open source, está a caminho das mãos da Nvidia. A mesma Nvidia do Jensen que abriu essa semana gritando que a AGI chegou. A mesma que vende a pá.

Para e pensa no tamanho disso. São mais de 18 milhões de desenvolvedores e mais de 3 milhões de modelos hospedados ali. Era pra ser o terreno comum, a praça pública da IA aberta. E o dono da praça, se os reguladores deixarem, vai ser o maior vendedor de hardware do planeta, o cara com o maior incentivo do mundo em manter o hype de IA girando pra vender mais GPU.

E é exatamente isso que eu chamo de cartel lá embaixo. Isso está no organograma, preto no branco. O mesmo grupinho que fabrica o medo, declara a AGI, resolve problema de matemática na marra e pede regulação agora também vai ser dono do chip e da prateleira onde você baixa o modelo. Quando eu te digo pra desconfiar da narrativa, é porque a narrativa e a infraestrutura estão cada vez mais na mão das mesmas pessoas.

A pergunta que todo programador devia fazer, e não faz

O que mais me irrita é ver gente que trabalha na área, programador, engenheiro, gente que devia saber como uma máquina funciona por dentro, engolindo essa propaganda inteira sem a pergunta mais básica de todas.

Como, exatamente, uma “AGI”, ou até um script automatizado bobo, vai “destruir a humanidade” sozinha? Ela precisa de mãos. Alguém, um humano, precisa dar acesso a alguma coisa que cause dano no mundo físico. Acesso a uma arma, a um sistema de mísseis, a uma rede elétrica, a uma conta bancária. Software não tem braço, não tem perna, não tem botão de lançar míssil embutido. Ele depende, cem por cento, de um humano ter conectado ele a um atuador que faça algo no mundo real.

E uma vez conectado, o estrago rola sem ninguém apertar botão a cada passo, às vezes sem ninguém nem perceber. O Stuxnet rodou anos dentro de uma usina iraniana destruindo centrífuga, invisível. Mesmo assim, nem ele escapa da regra: alguém escreveu o worm, mirou os controladores industriais e atravessou ele pra dentro. A máquina não se conecta sozinha à infraestrutura, e depois de conectada já era, falar em “tirar da tomada” é fantasia. A dependência do humano mora na decisão de conectar, e a responsabilidade pelo estrago é de quem abre a porta. O Yann LeCun, um dos pais da área e ganhador do Turing, chama o pânico existencial de “besteira completa”, justamente porque os modelos atuais não têm memória persistente, planejamento nem contato com o mundo físico. O Andrew Ng compara se preocupar com a extinção pela IA a “se preocupar com superpopulação em Marte”. Gente que entende do assunto de verdade não está desesperada.

Isso que a gente está vivendo tem nome, e é velho: fear mongering. O terror do “o fim está próximo”. Sempre existiu. Teve o pânico do cometa Halley em 1910, quando venderam pílula anti-gás cósmico pras pessoas. Teve o bug do milênio, o Y2K, onde o mundo gastou uns 300 bilhões de dólares com medo de um colapso sistêmico que não aconteceu (sim, em parte porque a correção foi paga a tempo; mais disso no apêndice). É sempre a mesma estrutura: alguém com algo a ganhar te vende o apocalipse.

Dario Amodei quer salvar a humanidade e abrir o capital no mesmo mês

Lembra do complexo de Deus que eu citei lá no começo? Chegou a hora de provar. Porque o grand finale dessa semana foi o próprio Dario Amodei subindo no palco pra bancar o salvador.

Mas antes dele, o coro ficou ainda mais alto. Além do Coxon e do Benton lá em cima, o Josh Engels, do Google DeepMind, também pediu as contas batendo na mesma tecla apocalíptica, com direito a “não tem nenhum adulto na sala, não tem ninguém vindo pra nos salvar”. E, claro, transformando o mesmo incidente da Hugging Face em prova do apocalipse. O medo já tinha pulado a cerca da Anthropic e virado coro de indústria.

Repara no timing. Uma fila de demissões dramáticas, todas no mesmo mês, todas viralizando, todas apontando pro mesmo medo. E então, no dia 12, entra o Dario com um ensaio pedindo pra “desacelerar” a IA. Ele chama isso de “pacing the frontier”. Traduzindo: “a gente precisa reduzir o ritmo em que melhora as capacidades dos modelos” pra “dar mais um ou dois anos” pros pesquisadores de segurança. E qual a prova central que ele usa? De novo, a Hugging Face. E repara no truque. O próprio ensaio admite que ninguém se feriu e que o dano econômico foi mínimo. Até aí, fato. Aí vem o “mas”: se um enxame mais capaz e mal-alinhado fizesse a mesma coisa, o estrago “poderia ter sido catastrófico”. E ele vai além: projeta que em 6 a 12 meses um enxame desses poderia tomar a internet inteira, com dano na casa das centenas de bilhões. Poderia. É projeção. O fato documentado tem dano real mínimo, o apocalipse mora inteiro no condicional. Esse “se” está carregando o ensaio inteiro nas costas.

Agora liga o cérebro e olha a contradição escancarada. O Dario diz que a IA pode literalmente extinguir a humanidade. E a solução que ele propõe é… desacelerar um pouquinho, comprar um ou dois anos, e seguir construindo e vendendo. Peraí. Se você acredita de verdade que a coisa pode matar todo mundo, você não pede pra ir mais devagar. Você para. Fecha a porta e joga a chave fora. Ninguém fica “pacing” uma bomba nuclear enquanto vende ação dela.

Porque é isso que fica de fora do ensaio: a Anthropic está a caminho de um IPO com valuation na casa do trilhão. Você não pode gritar “isso pode acabar com a espécie humana” e, na mesma respiração, montar a maior captação da sua história em cima da mesma tecnologia. Ou é perigo existencial e você fecha a empresa, ou é um produto e você para de fazer chantagem emocional com a extinção. Fazer as duas coisas ao mesmo tempo é marketing, não coerência.

E não é a primeira vez que eles gritam lobo. Lembra do Mythos? A Anthropic passou meses dizendo que o modelo era perigoso demais pra soltar, liberando só pra um grupinho fechado no tal Project Glasswing. Aí soltaram o Fable 5, a versão “segura”, avisando que “vinha com riscos”. Já faz meses. Cadê o estrago? Cadê o cyberataque apocalíptico, a arma biológica, o colapso? Nunca veio, porque nunca esteve ali. Foi susto de marketing, do mesmo jeito.

E aqui entra a minha leitura de fundo, aquela que eu venho repetindo faz anos. Todo mundo trata a evolução da IA como uma curva exponencial que sobe pra sempre. Mentira. Na prática é uma curva S. Ela sobe rápido no meio, e é esse pedaço que hospedou todo o hype, mas ela achata no topo. E eu aposto que a gente já está no teto faz tempo, provavelmente desde o Opus 4.6. Olha as últimas iterações com honestidade: cada uma é um incremento, um ganho de alguns pontos em benchmark, longe do salto revolucionário que o marketing vende. Quando você não tem mais capacidade nova pra impressionar, você troca a promessa pelo medo. Não dá pra dizer “olha que revolucionário”, então grita “olha que perigoso”.

E é aí que o “pacing the frontier” fica interessante de verdade. Vou botar o chapéu de alumínio, porque isso é especulação minha, mas o timing é coincidência demais. Você pega especulação, número inventado, “análise de especialista”, e transforma tudo em pânico. Depois empurra esse pânico pra dentro da política. E olha a coincidência: no dia 11 de setembro, no meio dessa onda toda, negociadores do Senado americano já estavam discutindo impor um “dever de cuidado” pra evitar “riscos catastróficos”, mirando justamente os modelos mais avançados, ou seja, Google, OpenAI e a própria Anthropic. Regulação escrita sob medida pro líder de mercado é fosso disfarçado de segurança. Você trava o concorrente pequeno e carimba o seu produto como o “seguro e aprovado”.

E é esse o complexo de Deus que eu falei lá no começo, agora explícito. O Dario não está só vendendo um modelo. Ele se enxerga como o homem que segura o apocalipse com as próprias mãos, o único adulto responsável num quarto cheio de irresponsáveis. É uma narrativa conveniente pra quem se acha o escolhido, e uma jogada de negócio impecável pra quem quer abrir o capital como o fornecedor oficial da salvação. As duas coisas na mesma pessoa. Se isso não é gaslighting em escala industrial, eu não sei o que é.

De repente, o cartel inteiro concorda

E aí, no dia seguinte ao ensaio do Dario, aconteceu a coisa mais reveladora de todas. O Sam Altman e o Elon Musk entraram no coro. O Musk twitou “o Dario está certo”. O Altman disse “eu concordo com o Dario que a gente precisa dar pace na fronteira” e ainda se comprometeu a abrir os sistemas da OpenAI pra avaliadores independentes. De repente, três dos maiores rivais da indústria estão todos de acordo, na mesma semana, que a corrida precisa desacelerar.

Para com tudo e pensa no que isso é. Concorrente não combina de ir mais devagar por bondade. Quando os líderes de um mercado sentam e concordam publicamente em frear juntos, e ainda falam em “pacto”, isso, dependendo de como se formaliza, tem um nome velho no direito: cartel. Combinar o ritmo do mercado entre os maiores players é comportamento anticompetitivo clássico e esbarra em lei antitruste. E o objetivo declarado é empurrar o Congresso pra uma regulação que, convenientemente, eles vão ajudar a escrever. Regra que eles influenciam direto trava o novato que ainda nem chegou, e blinda quem já está no topo.

E olha que não precisa acreditar na minha leitura. O próprio ensaio do Dario admite que a coordenação entre os laboratórios precisaria de uma isenção antitruste estreita do governo americano pra funcionar. Eles sabem que o que estão propondo esbarra em lei de concorrência, e já estão pedindo a licença por escrito.

E essa turma está longe de ser independente. É quase uma árvore genealógica. O Elon co-fundou a OpenAI e bancou o Altman no comecinho. O Dario saiu de dentro da OpenAI do Altman pra montar a Anthropic. A Nvidia do Jensen virou o império que é vendendo pá pra esse pessoal todo, a ponto do próprio Jensen ter entregado o primeiro supercomputador de IA na porta da OpenAI, em 2016. É um clubinho pequeno, todo mundo com raiz na mesma árvore, e agora todo mundo cantando a mesma música.

E aí vem a cereja. Poucas horas depois de pregar “segurança”, o Altman avisou que talvez não queira mais abrir o capital agora. Nas palavras dele, “dado tudo que está acontecendo com segurança, agora seria um momento mal aconselhado pra abrir o capital”. Que coincidência conveniente: o mesmo medo que ele acabou de ajudar a fabricar virou a desculpa perfeita pra adiar o IPO.

Deixa eu te dar a minha leitura crua. A expectativa em cima da OpenAI está nas alturas, com valuation projetado em 1 trilhão de dólares. Sustentar um número desses exige uma história de crescimento que não para. Só que, se eu estiver certo e eles já bateram no teto da curva S, ou estão quase, essa história acabou. Não sobrou capacidade nova revolucionária pra mostrar. Não sobrou narrativa. Eles já jogaram a última carta na mesa, a carta do apocalipse. Quando não te resta mais nada pra vender, e a conta pra pagar é de 1 trilhão, o que você faz? Você ganha tempo. Você adia o quanto der, embrulhado em “responsabilidade”, e reza pra achar a próxima história antes que o mercado perceba que a curva achatou.

E a semana terminou com o prego final nesse caixão. No domingo, o próprio Trump, falando com a imprensa no Irish Open, rejeitou os pedidos de desaceleração: “estamos na frente da China em IA, somos o país mais tecnologicamente avançado do mundo”, e pretende manter assim. Ele admitiu que dá pra “colocar salvaguardas” no lugar, mas disse que “forças negativas” estão levantando “coisas que não vão acontecer”. E fechou com a lógica dele: quem vencer em IA, vence. O Sacks foi ainda mais fundo no X: “o jeito mais fácil de não construir superinteligência é vocês combinarem entre si de não construir. Exigir o framework regulatório que vocês preferem em troca parece chantagem com o público e com o sistema político”. E cravou: se os laboratórios não fizerem isso por conta própria, “vamos saber que era só captura regulatória, ou uma operação psicológica em época de eleição”. Ou seja: o clubinho nem tinha terminado de assinar o pacto do freio e o governo americano já disse que não freia, porque tem corrida com a China no meio. O “pacing the frontier” morreu em dois dias. Se até a Casa Branca não comprou o apocalipse, fica cada vez mais difícil fingir que o medo era sobre segurança.

Conclusão

Me entenda bem: eu uso essas ferramentas todo dia e escrevo sobre elas o tempo todo. O meu ponto é sobre ligar o cérebro antes de compartilhar a manchete.

Quando uma empresa que vende GPU anuncia que a AGI chegou, pergunte quem lucra. Quando uma empresa queima milhões de dólares em compute pra “resolver” um problema que ela nem vai cobrar o prêmio, e ainda ameaça a carreira de um matemático no caminho, pergunte o que ela está comprando com aquela manchete. Quando um laboratório “humilha” o Vale do Silício num benchmark, pergunte o que rodava por baixo do capô. Quando um funcionário sai chorando Skynet no Twitter às vésperas de um IPO, pergunte cadê a evidência e cadê o custo que ele pagou. E quando um CEO se oferece pra “desacelerar” a IA que ele mesmo continua vendendo, pergunte quem fica com o assento na mesa quando a regulação for escrita.

Eu abri esse texto com o Jensen Huang, o homem que vende a pá, gritando que a AGI chegou. Vou fechar com ele também, porque a ironia é boa demais. O mesmo Jensen que infla o hype pra vender GPU chama o discurso apocalíptico de “besteira completa”, diz que os profetas do fim do mundo “fizeram muito estrago” e avisa contra a captura regulatória, que nenhuma empresa devia bater na porta do governo pedindo mais regra. Quando nem o maior vendedor de otimismo da indústria compra a história de que a máquina vai nos exterminar, e ainda aponta o dedo pra jogada da regulação, é bom você desconfiar de quem está te vendendo o apocalipse.

Exija prova. Exija skin in the game. Pergunte quem ganha com o seu medo e com a sua empolgação. Faça isso, e a maior parte dessa propaganda desmancha na sua frente.

E se você leu tudo isso e ainda saiu daqui achando que o robô vai acordar e te matar enquanto você dorme, sem ninguém ter plugado ele em coisa nenhuma, bom, aí volta lá no começo e lê meu lema de novo.

Apêndice: o fine print

Pro texto principal eu cortei as explicações chatas pra não quebrar o ritmo. Pra quem gosta de conferir detalhe, está tudo aqui:

• Navier-Stokes e o Clay: os enunciados C e D (breakdown com força externa suave) fazem parte, literalmente, da formulação oficial do prêmio, escrita pelo Charles Fefferman. O que a OpenAI anunciou cobre essas rotas; a versão sem força externa, a pergunta famosa, segue em aberto. O Clay soltou uma nota no dia 11/9 dizendo que o problema “aparentemente foi resolvido”, com a verificação e a atribuição de crédito caminhando “deliberadamente sem pressa”, e hoje o status no site deles é “ativo”. Nem “resolvido”, nem “não resolvido”. E a OpenAI não reivindicou o prêmio.
• Buckmaster vs. OpenAI: o relato do “acordo” (o Buckmaster reescreveria a prova como paper humano, ficaria com o prêmio de 1 milhão, e o Alpoge sairia da autoria) é a versão de uma das partes, contada pelo Buckmaster ao TechCrunch e à Fortune. A OpenAI nega a substância, diz que não viu o trabalho deles e afirma que o Bubeck se desculpou depois. Eu sinalizei isso no texto e repito aqui porque importa: é um relato de parte interessada, ainda que os detalhes documentados na cobertura (a troca de mensagens, o timing) façam ele parecer bem crível.
• Y2K: o colapso não aconteceu em parte porque os 300 bilhões pagaram a correção a tempo. Verdade, e eu não escondo isso. Só que a estrutura do pânico continua a mesma: quem vendeu a correção lucrava com o medo, e a manchete de fim do mundo rodou o planeta antes de qualquer correção.
• “Software sem bug”: existe, sim, software com correção provada formalmente. O exemplo clássico é o microkernel seL4, provado até o nível do binário. Só que essa prova custa ordens de grandeza a mais do que escrever o software, e quase ninguém paga essa conta num sistema grande. É por isso que a indústria vive de defesa em camadas em vez de garantia absoluta.
• David Sacks: ele deixou o cargo de czar de IA e cripto da Casa Branca em março de 2026, ao esgotar os 130 dias como funcionário especial do governo, e hoje é co-chair do PCAST, o conselho de consultoria científica do presidente. Continua influente na política de IA, mas “czar” ele não é mais.
• NVIDIA e Hugging Face: o acordo definitivo foi assinado em 2/9/2026 por cerca de US$ 12,9 bilhões, e o fechamento depende de aprovação regulatória, previsto pro primeiro semestre de 2027. A NVIDIA ainda não é juridicamente dona de nada. O ponto do texto é a direção, não a escritura.

Soltei este tweet hoje de manhã e ele rendeu. O ponto completo: quando a tecnologia em si vira commodity, o dinheiro migra pra taxonomia. Criam cinco nomes novos pra encadear chamada de API e de repente surge uma certificação que expira em seis meses.

Deixa eu sustentar a provocação com calma, porque ela não é implicância gratuita.

Já antecipo o comentário padrão: “mas comigo funciona”. Bom pra você — de verdade. Só que “funciona comigo” nunca provou que a cerimônia é o que fez funcionar. O que fez funcionar foi você saber o que queria. A cerimônia só estava no mesmo ambiente.

O meu recibo

Entre janeiro e maio eu fiz uma maratona de IA e publiquei mais de 30 repositórios públicos. Tem ferramenta que eu uso todo dia — ai-memory, ai-usagebar, ai-jail — e tem app pessoal pra coçar a minha própria coceira: Frank Manga+, Frank Scanlation, Frank Geary, e por aí vai.

Sabe o que eu nunca senti vontade de fazer nesse meio tempo? Complicar meu setup de IA. Não tenho um Pi super customizado, não tenho Hermes, não tenho grafo de agentes orquestrado, não tenho pipeline de specs numeradas. Graças ao ai-memory, eu troco de harness como troco de cueca: todo dia, sem limitação. Claude Code de manhã, Codex à tarde, Kimi CLI de noite — a memória do projeto vai junto, então o harness vira detalhe.

E detalhe é o ponto. A maioria dos harnesses é otimizada pro LLM da própria casa. Mas “otimizado” não quer dizer “mágico”, e eu tenho dados pra isso.

O que o meu benchmark diz sobre harness

No meu LLM Coding Benchmark eu rodo os mesmos modelos em harnesses diferentes, em condições controladas. O resultado é o oposto do que o mercado de cursos sugere:

• Pra modelo fraco, o harness resgata. O Grok 4.3 não construiu nada no OpenCode pelado (18 pontos) e entregou um app de verdade no grok CLI (55). O Gemini 3.1 Pro saiu de 62 pra 88 no harness do Google — mas o problema ali era um bug de transporte do OpenRouter, não falta de “engenharia de harness”.
• Pra modelo de fronteira, o harness é ruído. Grok 4.5: 92 no OpenCode, 91 no grok CLI. Grok 4.6: 92 e 93. Diferença de um ponto, dentro da margem. Nenhuma engenharia de harness move um modelo bom.
• Onde o harness morde de verdade é no bolso. A rodada do Grok 4.6 saiu por $1,19 no grok CLI contra $6,33 no OpenCode via OpenRouter — mais de 5x mais barato pelos mesmos ~11 milhões de tokens, porque o CLI oficial usa o cache nativo da xAI. Mesma história no Codex: o GPT 5.6 Terra custou $6,77 blended porque 21 dos 21,7 milhões de tokens bateram no cache; o Sol, da mesma família e mesma nota, saiu por uns $45.

Ou seja: escolher um harness decente importa — pra custo e pra dar estrutura a modelo fraco. Mas isso é uma tarde lendo documentação e olhando a fatura de tokens, não uma disciplina nova com trilha de aprendizado.

Já que citei o Hermes lá em cima, vale explicar: o Hermes Agent é um framework open source da Nous Research pra você montar o seu agente pessoal — você define as tools, escreve os loops, configura roteamento por modelo, fallback local/nuvem, gateways de Telegram e Discord, e ele ainda “aprende skills” com o uso. É o paraíso de quem monta setup.

Também é um segundo emprego: cada peça dessas vira sua responsabilidade de manter, atualizar e depurar, pra sempre. E no fim das contas o motor continua sendo o mesmo Claude, GPT ou Qwen de todo mundo — o chassi customizado não melhora o motor. O que o Hermes resolve de verdade, continuidade de contexto entre sessões e entre ferramentas, um harness decente com um ai-memory da vida já cobre — sem você virar administrador de infraestrutura do próprio assistente.

Se você quer um assistente no seu hardware por hobby ou por privacidade, é ótimo motivo, vai fundo. Como pré-requisito de produtividade, não é.

Pra guardar: harness bom é o que cobra menos e não atrapalha. O resto é o modelo. E modelo bom não precisa de “harness engineering” — no máximo precisa que o transporte não esteja quebrado.

Loop Engineering, Graph Engineering, Spec-Driven Development

Vamos aos nomes, porque eles descrevem coisas reais — só que minúsculas.

Loop Engineering é o nome da vez pra projetar o ciclo que um agente repete: executa, verifica com evidência, itera até uma condição de parada. Os guias listam modos de falha reais — o agente declarar “pronto” cedo demais, o objetivo ir derivando a cada volta. Só que a mitigação recomendada é “um verificador independente conferindo evidência objetiva”. Isso tem nome faz cinquenta anos: teste e revisão. Um agente num loop com suíte de testes é o básico de sempre com nome novo.

Graph Engineering é desenhar o workflow do agente como um grafo explícito de nós, ramos e junções — a LangChain tem três anos dessa história. Faz sentido quando o fluxo é genuinamente ramificado. Só que a maioria esmagadora dos projetos é uma linha reta com um if no meio. Modelar isso como grafo é comprar um quadro branco gigante pra desenhar uma seta.

Spec-Driven Development é escrever uma especificação detalhada primeiro e tratar o código como artefato gerado a partir dela — a spec vira a “source of truth” e o código, subproduto. Guarda esse, que o argumento forte vem já embaixo.

Repare no padrão: cada nome pega uma prática real e pequena — rodar em loop com verificação, desenhar um fluxo, escrever o que você quer antes de fazer — e infla até virar “disciplina”. A inflação é o produto. Nome novo cria curso, curso cria certificação, certificação expira em seis meses e te vende a recertificação.

Pra ser justo: os guias sérios desses temas já trazem a ressalva — o guia de graph engineering mais lido diz na cara que “você provavelmente não precisa” e manda dominar o loop antes de abrir um grafo, e a LangChain tem uma seção inteira de “quando não usar grafos”. O guia está certo; o estrago vem do funil, que joga a ressalva fora e vende o resto como default pra todo mundo.

Os dois que mais vendem curso — orquestração pesada de agentes e spec-driven development — merecem mais que definição. Merecem o argumento.

O argumento forte contra a super-orquestração

Tem uma matemática simples que os diagramas de agentes orquestrados nunca mostram. Se cada etapa do seu pipeline acerta 90% das vezes — e isso é otimista —, uma cadeia de dez agentes acerta 0,9^10, ou seja, ~35% das vezes. Cada nó é um ponto novo de falha, e cada aresta é token gasto com agente conversando com agente em vez de trabalhando.

Não precisa acreditar na conta: eu medi isso sem querer no benchmark. O MiniMax M3 rodado debaixo de um orquestrador parecia Tier D, com 24 pontos. O mesmo modelo, limpo, fez 91, Tier A. Uma diferença de até 69 pontos entre condições de harness significa o oposto do que o vendedor de orquestração diz: quando o plumbing domina o resultado, você parou de medir o modelo e passou a medir o encanamento. O melhor resultado de todo o benchmark não veio de nenhum enxame orquestrado: veio de um modelo forte, sozinho, num loop simples — Fable 5, 96 pontos, Claude Code, fim.

Faz sentido quando você lembra que coordenação escala mal. Cada agente a mais não adiciona só capacidade; adiciona arestas, contratos de mensagem, estado compartilhado e versões conflitantes da verdade. O roteador que decide “qual agente cuida disso” vira ao mesmo tempo o gargalo e a fábrica de bugs. Um comitê de agentes medianos com regente não bate um agente capaz com boas ferramentas e memória.

Isso eu já testei diretamente. Em abril eu rodei três rodadas de “modelo forte orquestrando modelo barato” — planner + executor, delegação forçada, o pacote completo. Resultado: nenhuma combinação multi-agente bateu o Opus sozinho num harness maduro. Numa tarefa coesa como construir um app, o planner precisa ler cada output do executor antes de despachar o próximo passo — os dois viram sequenciais, com latência triplicada e uma fila de coordenação no meio. É o comitê de novo: muita conversa, pouco software.

Não é só o meu benchmark. A Cognition, que vende o Devin, publicou o “Don’t Build Multi-Agents” com um mecanismo mais afiado que a minha conta de 90%: toda ação carrega decisões implícitas que os outros agentes não veem — um subagente desenha o fundo estilo Mario, o outro desenha um pássaro incompatível, e nenhuma confiabilidade individual conserta a divergência.

A própria Anthropic, que tem um sistema multi-agente de pesquisa, admite no post de engenharia que multi-agente gasta 15x mais tokens, que coding é um domínio ruim pra isso — a maioria das tarefas de código não é paralelizável de verdade — e que 80% da melhoria deles veio de simplesmente gastar mais tokens, não da arquitetura.

Quando Berkeley mediu o que realmente roda em produção, 86 sistemas em 26 domínios: 68% dos agentes em produção executam no máximo 10 passos antes de intervenção humana. O que existe de verdade por aí é loop simples supervisionado — não a constelação de nós coloridos do diagrama do consultor.

Onde a orquestração é legítima: trabalho genuinamente paralelo e independente — varrer dez mil arquivos, rodar dez mil análises descartáveis. Map-reduce existe faz vinte anos e nunca precisou de nome pomposo. E tem um recanto sério além dele: agente rodando de madrugada, sem ninguém olhando, com credencial na mão — aí verificador independente e orçamento duro viram questão de segurança, não de estilo. Mas isso é operação de frota, não o coding do dia a dia que o curso te vende. Fora desses nichos, a maioria das “arquiteturas multi-agente” é o trabalho de um agente só, com YAML extra.

Tem um motivo pra você ouvir tanto sobre isso: orquestração é complexidade visível. Tem diagrama, tem nó colorido, tem dashboard. Um agente bem dirigido não tem nada disso — não tem slide, não tem certificação, não tem o que vender.

Pra guardar: cada agente a mais multiplica os modos de falha. Se o resultado do seu sistema muda quando você troca o orquestrador, o seu sistema é o orquestrador — e o modelo era figurino.

O argumento forte contra spec-driven development

O SDD parece maduro porque soa como “escrever documentação”. Mas presta atenção no que ele realmente propõe: a spec vira a fonte da verdade e o código vira artefato gerado. O problema é que uma spec precisa o bastante pra gerar código correto já é um programa — só que escrito em prosa, e prosa não compila. Cada ambiguidade da spec é um bug que nenhum compilador pega, num meio sem teste, sem linter, sem feedback. O SDD não remove a parte difícil, que é pensar com precisão; ele move a parte difícil pra um formato onde erro não grita.

Pra guardar: uma spec precisa o bastante pra gerar código correto já é um programa — só que em prosa. E prosa não compila.

Mesmo que você escreva a spec perfeita, ela começa a morrer no primeiro hotfix. O bug aparece em produção, alguém conserta direto no código, e a spec vira mentira. A gente conhece essa lei faz décadas — é por isso que documentação apodrece. Chamar a spec de “fonte da verdade” não muda o incentivo de ninguém.

A gente já fez esse experimento, aliás. UML, MDA, “o código se gera a partir do modelo” — vinte e poucos anos atrás era a mesma promessa com outras siglas. Colapsou sempre pela mesma razão: o modelo nunca era a realidade; o código era. O SDD é o MDA com um LLM pendurado. E não sou só eu que vejo o Waterfall 2.0 ali.

Quem testou as ferramentas com seriedade chegou no mesmo lugar. A Thoughtworks colocou spec-driven development no anel “Assess” do Technology Radar — não “adote”, “avalie” — depois de ver as ferramentas inflarem tarefas pequenas em cerimônia, e cravou a frase que resume: estamos talvez “reaprendendo uma lição amarga: regras detalhadas feitas à mão pra IA simplesmente não escalam”. É a Bitter Lesson do Rich Sutton batendo na porta de novo — estrutura artesanal perde pra escala, sempre perdeu.

Tem ainda a inversão temporal. A grande lição do agile foi que você descobre o que quer construindo — working software over comprehensive documentation. O LLM acabou de deixar a iteração barata como nunca na história. E o que o SDD propõe? Expandir a fase de planejamento, justo agora que iterar ficou barato. Resposta errada, na direção errada, na hora errada.

É a tese que eu venho martelando desde os primeiros posts de Agile Vibe Coding: software emerge, não se planeja. Escrevi isso em fevereiro, com recibo: as features mais importantes do M.Akita Chronicles nasceram de problema que apareceu no meio do caminho — um job que falhou em silêncio, um site que bloqueou a gem, um crash que deixou email em limbo. Nenhum spec do mundo prevê isso. O sistema correto emerge da iteração, não da especificação.

O processo ficou documentado de novo quando o ai-memory cresceu na mão de 26 contribuidores em 24 dias: software bom é escultura de barro, não torre de Lego — maleável, sempre ajustável, nunca pronto. Quem tenta desenhar a arquitetura inteira antes da primeira linha constrói uma camisa de força, não um sistema. Só amador ainda acredita que dá pra especificar o software inteiro antes de codar. Modelagem de verdade não vem de template nem de curso — falei disso anos atrás no Akitando 144: ela nasce de repertório com problema e código reais. Não tem receita pronta; nunca teve.

O SDD tenta ressuscitar a ideia de que dá pra planejar software adiantado — a ideia que a indústria enterrou depois de décadas de projeto entregue atrasado, errado e superfaturado. O LLM não revalidou essa ideia; só deu a ela um PowerPoint novo.

Até quem escreve guia a favor separa as duas coisas: “spec-as-source é onde mora o hype; spec-anchored é onde está o valor hoje”. O meu alvo aqui é o primeiro. Onde a spec pesada é legítima: time grande, codebase legado, trabalho assíncrono que atravessa fuso e sprint — o bom e velho documento de design, que sempre existiu e sempre teve valor. O que não cola é vender isso como o novo default pra todo mundo.

O meu prompt de benchmark, pra constar, é uma página de objetivos. A diferença é que eu não confio na prosa: eu valido rodando. Precisão mora em teste, não em parágrafo.

O que você realmente precisa

Eu já escrevi tudo isso aqui no blog, com recibo de projeto real. Chama Agile Vibe Coding, e cabe num parágrafo:

É XP (eXtreme Programming, o agile raiz) com LLM: testes, Clean Code, CI (integração contínua), pair programming e deploy. Você dirige o agente como dirigiria um pair muito rápido: diz o que quer, acompanha a execução, corrige enquanto o erro é barato. A ideia é 10% do trabalho; os outros 90% são engenharia de software normal, a de sempre. Esquece framework e template de três páginas: o que você precisa é saber o que quer, saber o que não quer, e saber validar quando chega. E precisa de equilíbrio: nem largar o volante pro agente, nem virar fiscal de vírgula.

Foram mais de 600 horas disso, mais de meio milhão de linhas, dezenas de projetos no ar. Nenhum grafo, nenhuma certificação, nenhum loop com nome em inglês.

Pra guardar: a ideia é 10% do trabalho; os outros 90% são engenharia de software, a de sempre.

A peça que me deixa trocar de harness: ai-memory

Tem uma ferramenta minha que é o oposto de taxonomia: o ai-memory. Ele nasceu de um problema concreto. Todo harness guarda a sessão no formato dele, e quando a conversa fica longa, ele compacta o histórico pra caber na janela — e a compactação joga fora justamente os detalhes que explicam por que cada decisão foi tomada. Aí você troca de ferramenta e começa do zero, com o projeto inteiro pra reexplicar.

O ai-memory resolve isso do lado de fora do harness. Ele lê a sessão nativa sem tocar no arquivo original e guarda tudo num ledger pesquisável: mensagens, chamadas de ferramenta com resultados, resumos de compactação, checkpoint do git — cada evento marcado com a origem (veio do Claude, do Codex, do OpenCode). Quando eu abro outro harness, ele ganha a sessão nativa dele e recebe só o delta que ainda não viu. Quando eu volto pro anterior, o ai-memory retoma no formato daquele cliente e entrega o que aconteceu nos outros enquanto isso.

É por isso que “troco de harness como troco de cueca” não é força de expressão. O conhecimento do projeto mora no projeto, não na sessão de uma ferramenta. Se a Anthropic mudar preço, limite ou modelo amanhã — e vai mudar —, eu troco o motor sem jogar fora a viagem. Os detalhes de como isso funciona estão neste post.

Tem ainda uma inversão aqui que despacha o SDD de brinde. O spec-driven development diz que a fonte da verdade é um documento escrito antes do trabalho, tentando prever o futuro, e que o código deve obediência a ele. O ai-memory faz o contrário: a fonte da verdade é uma wiki destilada do próprio trabalho — cada sessão vira evidência, e o que merece sobreviver (decisões, regras, gotchas, tentativas que falharam) é consolidado em páginas Markdown curtas que qualquer agente lê antes de começar.

A spec tenta adivinhar o projeto; a wiki registra o projeto. Documento escrito antes apodrece no primeiro hotfix, porque ninguém é obrigado a atualizá-lo. A wiki é alimentada pelo próprio ato de trabalhar — e quando desatualiza, você percebe na hora, porque os agentes tropeçam nela toda sessão.

Repare que isso é harness engineering de verdade: uma ferramenta, escrita uma vez, resolvendo um problema meu. Nenhum curso, nenhuma sigla, nenhuma certificação.

Conclusão: pede o recibo

Não gaste tempo nem dinheiro com curso de “harness engineering”, “loop engineering” ou qualquer taxonomia da semana. É tentativa descarada de te cobrar por coisas que você já faz se souber engenharia de software básica.

Esse filme a gente já viu, aliás. O Pedro Arantes lembrou no X: “Microservices, clean architecture, hexagonal e Domain-Driven Design são tudo bullshit pra vender mais horas de consultoria e cursos.” Mesma história, mesmo roteiro. Cada um deles nasceu de um problema real — e virou default de quem não tinha o problema. Microservice pra time de três pessoas, arquitetura hexagonal pro CRUD (o cadastro cria-lê-atualiza-apaga de sempre), DDD pra nunca mais escrever código. A técnica passa, a taxonomia fica, o curso vende.

Pra ninguém se fazer de desentendido: nada disso é inútil. Loop com verificação funciona. Grafo funciona quando o fluxo é um grafo de verdade. Spec pesada salva time grande. Microservices resolveram problemas reais de quem tinha escala de verdade; DDD brilha em domínio complexo de verdade. O problema nunca foi a ferramenta — é vender a ferramenta como bala de prata, o martelo universal que você precisa aplicar em tudo. Bala de prata não existe, nunca existiu. Quem te vende uma não está vendendo solução; está vendendo curso.

Entenda o mecanismo psicológico, porque ele é velho e eficiente: esses termos existem pra te dar FOMO (Fear of Missing Out — o medo de estar perdendo o bonde). Pra te deixar ansioso, achando que está ficando pra trás, que está deixando produtividade na mesa, que todo mundo já migrou pro novo paradigma e você não. Ansiedade vende. Depois que você está inseguro, eles te cobram pra implementar algo de que você nunca precisou. FOMO é real — e aqui, é o modelo de negócio.

O modelo ainda é recorrente — repare na elegância. Primeiro te vendem a metodologia que gera artefatos — specs, grafos, boards, diagramas. Os artefatos se multiplicam, ninguém mais sabe onde está nada, e adivinha quem aparece? A mesma consultoria, agora vendendo a ferramenta que gerencia os artefatos, o curso que te ensina a gerenciar a ferramenta e o workshop de governança dos artefatos. É o vendedor de pá te parabenizando pelo buraco que você cavou — e te oferecendo uma pá maior.

A Gartner tem até nome oficial pra isso: “agent washing” — pegar produto existente, pendurar a etiqueta “agentic” e revender. A estimativa deles: só umas 130 das milhares de empresas que se vendem como “IA agêntica” são reais, e a previsão é de 40% dos projetos do tipo cancelados até o fim de 2027, por custo, valor incerto ou risco mal controlado. Aqui não tem implicância minha: é o ciclo do hype, medido, com previsão pública e tudo.

Da próxima vez que um influencer ou consultor tentar te empurrar esses produtos, faz uma pergunta simples: onde estão as suas dezenas de projetos open source de alta qualidade que ficaram melhores por causa dessas “técnicas”?

Eles não têm o que mostrar. Eu tenho — está tudo público, com código, benchmark e processo documentado. Quando a tecnologia vira commodity, o dinheiro migra pra taxonomia. Não seja o cliente dessa migração.

O padrão se repete em todos: eu esbarro numa pequena fricção do cotidiano, daquelas que a gente normalmente engole porque consertar custaria um fim de semana inteiro, e em vez de engolir eu abro um agente de IA e resolvo. O custo de transformar irritação em ferramenta despencou tanto que o cálculo inverteu. Hoje vale a pena consertar quase tudo.

Tudo que aparece abaixo está no meu GitHub, com binários, releases e instruções de instalação.

Nesse post: clock-tui (com os widgets google-calendar-tui e ghpending), github-visualize, frank_geary, frank_scanlation, frank_lyrics, frank_type, distrobox-gaming e aitrepreneur-docker.

clock-tui: um relógio de mesa que virou painel

O caso de uso é simples: eu tenho um monitor secundário vertical, e queria algo mais útil ali do que um wallpaper, alguma coisa que eu pudesse só bater o olho e ter informação relevante. Mas tudo começou porque eu só queria um relógio de mesa. Achei um programinha open source antigo de relógio em terminal, o clock-tui original, que estava parado havia tempos, e decidi fazer um fork e continuar o trabalho: o clock-tui.

Deixei ele mais bonito, modernizei as dependências de Rust, e a mudança mais importante: adicionei suporte a widgets de comando. O relógio fica no topo e embaixo entram painéis que rodam qualquer comando que imprima texto, cada um com refresh independente. Dois widgets que eu mesmo criei pra ele:

• google-calendar-tui: uma agenda read-only do Google Calendar no terminal, usando as contas que já estão no GNOME Online Accounts (zero configuração de OAuth). Bato o olho e sei meus compromissos do dia.
• ghpending: lista issues e pull requests abertos em todos os repositórios que eu acompanho. Agora que eu tenho dezenas de projetos open source, é assim que eu percebo em segundos quando chega PR ou issue nova, sem abrir o GitHub.

E hoje eu passei o dia adicionando suporte a temas, porque alguém no X comentou que o visual dava pra lembrar Evangelion. Desafio aceito: agora tem o tema evangelion (roxo e lavanda) e o tema nerv (vermelho, âmbar e verde, inspirado nas telas de alerta da série), alternando em runtime com Shift+T. O tema é injetado nos widgets via variável de ambiente, então os painéis acompanham a paleta.

Instalação no Arch: yay -S clock-tui-bin. Os widgets: yay -S ghpending-bin (também tem brew install via akitaonrails/tap no macOS) e yay -S google-calendar-tui-bin. Todos têm binários prontos nas releases do GitHub pra quem não usa Arch.

github-visualize: inútil, mas bonito

Esse nasceu por causa do artigo do Jarred Sumner sobre reescrever o TypeScript do Bun em Rust, sobre o qual eu postei recentemente. Não sei qual ferramenta ele usou pra ilustrar o post, mas eu gostei demais das animações dos gráficos. É inútil? É. Mas é bonito, e beleza é motivo suficiente pra fazer uma cópia.

O github-visualize é um dashboard self-hosted que monitora meus repositórios do GitHub e faz replay do progresso deles com visualizações animadas: timeline de commits com linhas adicionadas e deletadas em escala logarítmica, heat map de commits por dia e hora, corrida de CI até o verde. Agora eu adiciono qualquer repositório meu e tenho visualizações bonitas de produtividade, atividade, commits e builds. Talvez eu use em slides de apresentação, ou pra ilustrar posts futuros aqui no blog.

Instalação: imagem pública no Docker Hub como akitaonrails/github-visualize, container único com SQLite num volume, sem banco externo nem Redis.

Frank Geary: email do jeito que eu queria

Eu decidi usar o Geary, do GNOME, como meu cliente de email principal. É o que chega mais perto da interface do Mail padrão da Apple: limpo, direto, sem cerimônia. Eu sei, existe o Thunderbird, mas eu o acho inchado e muito feio. Existe o Mailspring, que eu acho inchado e pesado. Meu fluxo de email é curto: varrer a inbox, taggear, arquivar e responder. Nada além disso.

O Geary é quase perfeito, mas tinha dois problemas grandes pra mim. Primeiro: no meu monitor vertical, sobra muito menos espaço horizontal, e o Geary tem 3 colunas fixas. A primeira coluna, que só lista contas e pastas/tags, eu não preciso ver o tempo todo, mas não existia jeito de recolher.

Segundo, e mais grave: o campo de destinatário do compositor na prática não autocompletava nada (o Geary até tem o mecanismo, mas com um filtro de visibilidade de contatos tão restritivo que nunca sugeria ninguém). Eu tinha que digitar o endereço na mão ou copiar e colar de outro email. Em 2026.

Minha primeira solução foram dois módulos GTK externos injetados no Geary, um pra cada problema (ambos obsoletos agora). Funcionavam, mas exigiam instalar o Geary compilado do source, e a cada yay -Syu lá ia ele recompilar tudo de novo.

Cansei e fiz o que deveria ter feito desde o início: forkei o Geary e criei o Frank Geary, que adiciona as duas funcionalidades direto no código. A barra lateral agora recolhe, e o destinatário autocompleta consultando os contatos dos emails existentes. Vou manter o fork rebaseando do upstream com frequência.

E a melhor parte: agora tem pacote no AUR, então instalar é assim:

yay -S frank-geary-bin    # binário pronto (x86_64), da release do GitHub
yay -S frank-geary        # ou compilando do source

Os dois pacotes substituem o geary do sistema (fazem provide/conflict nele), então a troca é limpa e as atualizações chegam como qualquer outro pacote. Um detalhe depois de instalar ou atualizar: quando a opção de vigiar email novo está ligada, o Geary continua rodando em background como serviço D-Bus, então roda um geary --quit pra garantir que nenhum processo antigo ficou no ar.

Mangá em japonês: FrankYomik, FRANK MANGA+ e FRANK Scanlation

Quem acompanha o blog sabe do meu amor por mangá japonês. Eu já postei sobre o FrankYomik, que nasceu pra eu conseguir ler os mangás originais em japonês que eu compro na Amazon do Japão.

O problema: mangá voltado pra público adulto (não, não é pornô! estou falando de temas como negócios ou assuntos militares) não tem “furigana”, que são as legendinhas em kana impressas ao lado dos kanji difíceis, indicando a leitura. Mangá shounen tem furigana em tudo, então dá pra ler com vocabulário de estudante. Os adultos assumem que você já sabe ler os kanji raros. Eu não sei.

O FrankYomik resolve isso adicionando furigana em cima da página, em tempo real: um modelo detecta os balões de fala, o manga-ocr extrai o texto e o furigana (ou uma tradução completa, via LLM local no Ollama) é renderizado por cima, tudo rodando no meu próprio hardware. E o detalhe importante: on-the-fly, por cima da imagem que eu já tenho aberto legitimamente, sem baixar nem redistribuir página nenhuma, então sem infringir copyright ou licença.

Depois veio o FRANK MANGA+, sobre o qual eu também já postei. Eu pago a assinatura do Manga Plus, o app oficial da Shueisha, mas ele só deixa ler no celular (Android/iOS). Num tablet pequeno até vai, mas eu tenho um monitor Samsung Odyssey OLED de 32" parado na minha frente.

Descobri como usar a minha própria assinatura fora do app e construí um leitor desktop em Tauri: roda em Linux, macOS e Windows, o tier gratuito funciona direto e assinante cola o próprio secret pra liberar os capítulos premium.

Instalação: AppImage, .deb e .dmg nas releases, ou yay -S mangaplus-reader-bin no Arch.

E finalmente, eu também leio as eventuais “scanlations” da comunidade: fãs escaneiam as páginas do mangá original japonês e traduzem (hoje em dia a maioria usa IA no processo, existem até modelos treinados pra reconhecer os balões de fala, e eu usei um desses no próprio FrankYomik). Essas scanlations ficam espalhadas por vários sites diferentes, tipo o MangaDex.

Primeiro eu fiz uma extensão de Chrome pra embelezar esses sites (hoje obsoleta), mas cansei de viver com dezenas de abas no Brave só pra sites de scanlation. Então construí o FRANK Scanlation, na mesma linha do FRANK MANGA+: um app desktop que concentra todas as minhas scanlations favoritas num lugar só, com biblioteca, progresso de leitura por título e checagem de capítulos novos.

As janelas de leitura carregam o próprio site e injetam um leitor decente por cima, com spreads de página dupla e navegação por teclado. Nada é hardcoded pra site nenhum: são heurísticas que detectam sequências de imagens e numeração de capítulos em qualquer URL. Virou meu jeito preferido de ler os mangás que não existem pra comprar na Amazon nem na Shueisha.

Instalação: AppImage, .deb e .rpm (e build de macOS) nas releases do GitHub.

Frank Lyrics: decorando música linha por linha

Eu já postei sobre o Frank Karaoke, um appzinho pra adicionar pontuação em cima do YouTube e curtir karaokê com família e amigos. Mas tem um caso de uso irmão: eu gosto de aprender música nova (abertura de anime nova, por exemplo), e o processo de decorar letra é repetir a MESMA linha várias vezes. No player do YouTube isso é um inferno: fica caçando no dedo o ponto exato da timeline pra voltar, erra por dois segundos, volta demais, passa do ponto.

Pra resolver isso criei o Frank Lyrics, uma extensão de Chrome simples que descobre o timing correto de cada linha da letra usando os marcadores públicos do LRCLIB e injeta controles na própria página do YouTube. O LRCLIB, pra quem não conhece, é uma biblioteca aberta e comunitária de letras sincronizadas: cada linha vem com timestamp (o formato LRC clássico dos players de música), com API pública, gratuita e sem chave.

A extensão casa esses timestamps com o vídeo e me dá botões de repetir a linha exata que eu estou decorando, quantas vezes eu precisar, sem caçar timeline. Se você curte karaokê, o combo Frank Karaoke + Frank Lyrics deve te atender bem.

Instalação: baixa o .zip das releases, descompacta, abre chrome://extensions, liga o modo desenvolvedor e faz “Load unpacked” apontando pra pasta.

Frank Type: treino de digitação com prosa de verdade

Quem me acompanha há tempo sabe que eu amo meus teclados. Tem vídeos no canal Akitando sobre isso e posts aqui no blog sobre meus teclados favoritos. E de tempos em tempos eu gosto de treinar no MonkeyType. Mas eu não gosto de digitar palavras aleatórias. O TypeRacer resolve isso usando textos públicos de verdade, só que ele me obriga a esperar outros jogadores na sala (eu detesto jogos multiplayer). Ou seja: eu queria uma experiência single player, com prosa de verdade, mas com a estética do MonkeyType, que eu prefiro.

Então criei o Frank Type, um mini-clone dos dois: um treinador de digitação em Rails 8 que usa trechos normalizados de prosa em domínio público em vez de listas de palavras aleatórias. É local-first e sem cadastro: histórico de sessões, tempos e gráficos de perfil ficam no local storage do navegador. Tem até heat map de dígrafos pra mostrar quais combinações de teclas te atrasam.

Instalação: é um container Docker publicado como akitaonrails/frank_type. Um comando levanta em http://localhost:3200:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/frank_type/master/bin/docker-run.sh | bash

distrobox-gaming: uma biblioteca de como instalar jogos no Linux

Eu jogo no mesmo PC em que trabalho, mas me recuso a misturar pacote de emulador e gambiarra de Wine com meu ambiente de desenvolvimento. A solução foi isolar os jogos inteiros dentro de um distrobox (containers que se integram ao desktop como se fossem nativos), e o distrobox-gaming é o repositório de playbooks Ansible que constrói essa box Arch do zero: ES-DE de frontend, emuladores standalone, cores do RetroArch, configs por jogo. Meu Arch/Omarchy host fica limpo.

A regra que eu me impus: todo jogo novo que eu instalo tem que virar receita Ansible reproduzível. Confesso que ainda não testei a reconstrução completa do zero, mas a ideia é essa: qualquer truque ou hack necessário fica documentado no código em vez de perdido no histórico do shell.

E truque é o que não falta, porque eu ando instalando abandonware antigo: a série Colin McRae Rally (da versão de PS1 com patch de 60 fps até o DiRT de 2007), Sega Rally Revo, OutRun 2006 Coast 2 Coast, entre outros. Cada um com suas manhas de Wine, seus patches e suas configurações. Sem querer, o repositório está virando uma biblioteca de documentação sobre como instalar jogos, emuladores e retro games no Linux.

Na mesma linha existe o distrobox-llm, que faz o mesmo isolamento pro meu ambiente de LLMs locais (CUDA, Ollama, LM Studio e companhia), deixando só o driver NVIDIA no host.

Instalação: clona o repositório e roda os playbooks:

cd ansible
ansible-galaxy collection install -r collections/requirements.yml
cp host_vars/localhost.yml.example host_vars/localhost.yml
$EDITOR host_vars/localhost.yml
ansible-playbook site.yml

aitrepreneur-docker: ComfyUI sem sujar o sistema

Pra geração de imagens eu gosto do ComfyUI, e postei sobre ele ano passado. Eu acompanho um youtuber chamado Aitrepreneur que mantém uma página no Patreon com receitas pra instalar e configurar o ComfyUI com os modelos e workflows mais recentes. O trabalho de curadoria dele é ótimo, mas as receitas são scripts .sh old school, pensados pra rodar one-shot numa instância do RunPod, por exemplo.

Agora que as LLMs evoluíram a ponto de escreverem Dockerfiles decentes, criei o aitrepreneur-docker, que converte esses scripts em imagens e containers Docker de verdade: versões pinadas, dados persistentes no host ou NAS, um comando pra subir ou atualizar cada app. Assim eu rodo tudo isolado na minha máquina, sem entulhar meu Linux com toneladas de pacotes Python e gambiarras que poderiam desestabilizar o sistema.

Dois avisos importantes. O crédito da seleção de stack, curadoria de modelos e workflows é todo do Aitrepreneur: o repositório só traduz o trabalho dele pra forma de Docker, e os scripts originais dele são conteúdo pago do Patreon que NÃO está incluído.

Se achar útil, assine o Patreon dele pra contribuir com a criação de conteúdo (é lá que você pega os arquivos originais). E o repositório não cobre tudo que ele já produziu, só as receitas mais recentes.

Instalação: git clone, make setup (cria o .env pra você colocar seu token da Hugging Face), make build e make up.

E tem mais de onde vieram esses

Se você é novo por aqui: isso é só a leva que ainda não tinha aparecido no blog. Tem muito mais projeto que eu já cobri em posts dedicados. O ai-memory é o mais popular, mais usado e com mais contribuições de todos. O ai-jail, que apareceu de novo no post de ontem sobre agentes destrutivos, foi o primeiro da série e é o segundo mais popular.

E tem os outros da série Frank (“Frank” em homenagem ao Frank Rosenblatt, criador do perceptron, a rede neural original; o nome marca os projetos experimentais que eu faço por diversão):

• Frank Sherlock: indexador inteligente de imagens
• Frank Mega: clone do MEGA pro meu home server
• FrankMD: editor de markdown
• Frank FBI: analisador de fraudes por email
• Frank Investigator: ensina a questionar notícias

Tudo é open source e está no meu GitHub. Todo mundo é bem-vindo pra contribuir com issues, pull requests, ou simplesmente compartilhando com os amigos. Cada um desses projetos nasceu de um probleminha real meu. Vai que um deles resolve o seu também.

Eu comecei a gostar do milenar jogo de Go por causa do mangá Hikaru no Go. Cheguei a escrever sobre isso em 2008, num post que ainda está no ar, defendendo por que programadores deveriam jogar Go. De lá pra cá pouca coisa mudou no meu caso de uso: eu tenho um goban físico em casa, mas nunca tive a menor intenção de entrar em grupo de estudo, federação ou competição. Eu só gosto de jogar sozinho, resolver uns tsumego (os quebra-cabeças de vida e morte do Go), e carregar partidas famosas pra estudar, como os lendários jogos do Lee Sedol contra o AlphaGo em 2016.

Pra quem não conhece o mangá: Hikaru no Go (roteiro de Yumi Hotta, arte de Takeshi Obata, o mesmo de Death Note) rodou na Shonen Jump entre 1998 e 2003 e causou um boom de interesse por Go no Japão inteiro. E tem um detalhe que pouca gente sabe: praticamente todas as partidas que aparecem no mangá são baseadas em jogos históricos reais, recriados quadro a quadro. Guarda essa informação, porque ela volta daqui a pouco.

SGF e o problema do material espalhado

Existem vários programas open source muito bons pra carregar partidas de Go ou até jogar online. Partidas de Go são gravadas num formato chamado SGF (Smart Game Format), um formato de texto puro que existe desde o fim dos anos 80: cada jogada vira uma coordenada (;B[pd] é uma pedra preta no ponto 4-4), e o formato suporta árvores de variação, comentários e metadados da partida. É o padrão de facto do mundo do Go: todo cliente lê SGF, todo servidor exporta SGF, e existe um acervo gigantesco de partidas históricas e problemas nesse formato acumulado ao longo de décadas.

E aí mora o problema: esse acervo está espalhado pela internet inteira. Um site tem as coleções clássicas de tsumego, outro tem as partidas históricas, um repositório do GitHub tem os problemas comentados, outro tem os kifu (registros de partida) profissionais. Eu não estava com o menor humor de baixar tudo manualmente, organizar pasta por pasta e configurar cliente por cliente. Eu queria um app bom o suficiente, bonito o suficiente, com tudo embutido.

2008: a era GNU Go

Aqui vale o contexto histórico, porque ele é a parte divertida. Em 2008, quando escrevi aquele post, a única “IA” de Go acessível era o GNU Go. E olha, a gente nem pode chamar aquilo de IA: era um monte de heurísticas empilhadas. E era terrível. Até um amador como eu conseguia ver que ele fazia jogadas sem fluxo nenhum, sem sentido de direção, pedras soltas que não conversavam entre si. Ganhava de iniciante por pura tática local e só.

O que aconteceu nos 18 anos seguintes é uma das histórias mais bonitas da computação. Primeiro vieram os métodos de Monte Carlo Tree Search, que já melhoraram bastante o nível.

Aí em março de 2016 o AlphaGo do DeepMind venceu Lee Sedol, um dos maiores jogadores da história, por 4 a 1. Foi a série da famosa jogada 37 da partida 2 (o “ombro” que nenhum humano jogaria) e da resposta à altura do Lee Sedol: a jogada 78 da partida 4, a “mão de Deus” que lhe deu sua única vitória. Se você nunca viu, existe um documentário excelente sobre essa série na Netflix, que vale a pena até pra quem não sabe nada de Go.

E depois que o DeepMind publicou os papers, a comunidade open source correu atrás: primeiro o Leela Zero reimplementando o AlphaZero, e depois o KataGo indo além. Hoje qualquer um tem um jogador sobre-humano de Go rodando de graça no próprio computador. Eu queria ver de perto o quanto essas IAs amadureceram em 20 anos.

Foi dessa vontade que nasceu meu novo projeto de brinquedo: o Frank GO.

Sabaki + KataGo

Pedi pro Claude Code pesquisar os apps e engines open source de Go mais populares (a pesquisa inteira está documentada no próprio repositório, como manda o figurino). No fim escolhi dois projetos como base:

O Sabaki, do Yichuan Shen, é o front-end. É provavelmente o editor de SGF e tabuleiro de Go open source mais bonito e bem cuidado que existe, feito em Electron, com suporte a árvores de variação, análise e engines via protocolo GTP. Elegante e minimalista.

O KataGo, do David Wu, é a IA. É o motor open source mais forte do mundo, sobre-humano, herdeiro da linhagem do AlphaZero mas com uma diferença que importa demais pro meu caso: além da taxa de vitória, o KataGo estima pontuação e domínio de território ponto a ponto. Ele responde “quem está ganhando, por quantos pontos, e quais áreas do tabuleiro pertencem a quem”. É exatamente o tipo de informação que um iniciante precisa e que os engines antigos escondiam.

O Frank GO é um fork do Sabaki que amarra o KataGo pra sessões de jogo solo, e embute tudo aquilo que eu queria ter num lugar só:

• Mais de 4.700 tsumego das coleções clássicas (a Enciclopédia do Cho Chikun, o Gokyo Shumyo, o Xuanxuan Qijing), transcritas pelo Vít Brunner no tsumego.tasuki.org e convertidas pra SGF pelo projeto tasuki2sgf, mais os 420 problemas comentados do go-problems do Go Game Guru (do An Younggil, profissional 8-dan), organizados em 10 níveis de dificuldade. Resolve 5 seguidos e sobe de nível. Um seletor de foco filtra por vida e morte, tesuji, ko ou semeai (corrida de capturas).
• Os puzzles revidam: com o KataGo instalado, ele responde suas jogadas dentro do problema, e quando ele desiste da área o app julga o resultado e marca o problema como resolvido automaticamente.
• Partidas históricas famosas pra estudar, do Jogo da Orelha Vermelha (1846, do lendário Honinbo Shusaku) até AlphaGo vs Lee Sedol, curadas do banco de partidas do Andries Brouwer no CWI, cada uma com a história por trás, e as do AlphaGo com comentário jogada a jogada. Dá pra assistir em auto-play ou ligar o modo “adivinhe a jogada” e tentar achar o lance do profissional.
• As partidas do Hikaru no Go: lembra que os jogos do mangá são reais? Pois é, 15 deles estão embutidos com referência de capítulo e curiosidades, usando o mapeamento capítulo-a-partida que a comunidade compilou na Sensei’s Library. A partida de internet do Sai contra o Toya Meijin, por exemplo, é um jogo real decidido por meio ponto.
• Dicionário de joseki (o Kogo’s Joseki Dictionary, referência clássica de aberturas de canto), drills de escada, drill de “quem está ganhando?”, e um teste de rank de dez problemas que estima seu nível e te larga direto na prática certa.

Lembra do problema do material espalhado? Essas coleções aí de cima são exatamente ele: cada uma vivia num canto da internet. A procedência e o licenciamento de cada conjunto estão documentados no data/SOURCES.md do repositório, porque acervo dos outros se usa dando o devido crédito.

Overlays pra quem está começando

A parte em que eu mais mexi no Sabaki foi criar sobreposições visuais amigáveis pra iniciante. A principal é a pintura de área: um overlay que pinta a influência de cada jogador como um gradiente suave e o território consolidado em cor sólida, então você literalmente vê o que as pedras estão fazendo, quais áreas estão mortas e quais estão em disputa.

Junto vem o placar em tempo real considerando o komi (a compensação de pontos do branco por jogar em segundo), que avisa quando você está irremediavelmente atrás ou quando o jogo já está decidido. E passando o mouse no tabuleiro aparecem os nomes das jogadas (“Hane”, “One-Point Jump”), o vocabulário que os livros usam e que iniciante demora a absorver.

Esse era o meu problema com todo software de Go que já testei: são ferramentas feitas por jogadores fortes pra jogadores fortes. Winrate em porcentagem não diz nada pra quem está aprendendo. “Você está 12 pontos atrás e o canto inferior esquerdo morreu” diz tudo. O KataGo sempre soube calcular isso; faltava alguém colocar na tela de um jeito que iniciante entende.

A ideia é ser um balcão único, sem configuração nenhuma, pra iniciante e estudante aprender Go no próprio ritmo. E tem build pra todo lugar. No Arch Linux é yay -S frank-go via AUR. No Windows tem instalador e versão portátil nos Releases; o instalador não tem assinatura digital, então o SmartScreen reclama na primeira execução, é só clicar em “Mais informações → Executar assim mesmo” (eu explico por que não assino build de Windows no post de boas práticas). No macOS é brew install --cask akitaonrails/tap/frank-go, ou o .dmg pra Apple Silicon e Intel; esse build é assinado com Developer ID e notarizado pela Apple, abre sem drama nenhum. E em qualquer plataforma dá pra rodar do fonte com npm install.

Em todos os casos o app baixa um engine de CPU pequeno com um clique, sem GPU, sem conta, sem servidor, totalmente offline. A exceção é o macOS, onde o KataGo não tem binário oficial: um brew install katago destrava o jogo contra a IA, e todo o resto (tsumego, estudo, drills, pintura de área) funciona sem ele. O progresso fica na sua máquina.

E quando você quiser jogar contra gente

O Frank GO é deliberadamente um app de estudo solo. Quando você aprender e quiser jogar contra humanos, o caminho natural são os servidores online, e aí os apps mais avançados servem melhor. O OGS (Online Go Server) é o mais amigável hoje, roda direto no navegador. O KGS e o Pandanet IGS (o Internet Go Server original, no ar desde o começo dos anos 90) são os veteranos, e os servidores asiáticos como Fox e Tygem concentram os jogadores mais fortes. O mundo do Go organizado gira em torno da IGF (International Go Federation) e das associações nacionais, com rankings e torneios pra quem quiser levar a sério.

Eu não quero. E esse é o ponto do projeto inteiro: como eu disse lá em cima, não tenho nenhuma vontade de competir. Eu queria, há literalmente anos, um jeito de jogar e me divertir com Go no meu ritmo, com material de estudo decente num lugar só, contra uma IA que joga bonito em vez de cuspir pedras sem sentido como o GNU Go de 2008. Acho que finalmente consegui.

O código é MIT, o repositório é github.com/akitaonrails/frank_go, e contribuições são bem-vindas. Tem inclusive uma issue aberta pedindo retratos dos personagens pro modo Hikaru no Go, se alguém quiser desenhar. O Sai agradece.

Eu sou assinante do app MANGA Plus by Shueisha na Google Play Store do Android. Pra quem não conhece, é o canal oficial da Shueisha (editora japonesa por trás da Shonen Jump) pra ler os mangás dela legalmente, capítulo lançando semanalmente quase no mesmo dia da publicação no Japão. Por dois dólares por mês dá acesso ao catálogo inteiro, com tradução oficial em inglês.

Tenho um Samsung ZFold 7, que é uma das poucas exceções de celular que serve bem pra ler mangá e Kindle (já comentei sobre isso e sobre o Frank Yomik no ranking final da maratona de IA). O Fold aberto dá uma tela maior que celular normal e ajuda muito. Mas tem dia que meu olho já está cansado de telinha pequena, e o que eu queria mesmo era ler num monitor OLED de 32 polegadas que está bem na minha frente, perfeito pra leituras longas.

O problema é que MANGA Plus não tem site oficial pra leitura. A assinatura está presa ao Android. Existe uma versão pra iOS também, mas web não tem. Tablet ajuda, mas nada bate o conforto de uma tela grande e estática quando você quer ler um arco inteiro de One Piece numa tacada só.

Pra contexto, ultimamente coloquei muita coisa em dia: finalmente fechei Chainsaw Man, Dan Da Dan, Jujutsu Kaisen, Kagurabachi, Akane-banashi, Sakamoto Days e, claro, One Piece. Tem muito mais que eu quero acompanhar, e o conforto do monitor grande virou um problema real pra resolver.

O foco começa no Frank Manga+, que resolve o buraco da Shueisha no desktop. No fim também falo de dois complementos do meu setup: Prettify Manga Reader, pra transformar sites de fansub e Kindle Web em leitores decentes, e Frank Yomik no navegador, pra furigana/tradução em Kindle Japan e Naver.

Decompilando o app

Resolvi atacar. Sentei com o Claude Code e baixamos o xapk oficial do MANGA Plus. Decompilamos pra fonte Java com jadx e fomos navegando até entender como o app se autentica com a API da Shueisha.

A conclusão é direta: a “assinatura” do usuário, do ponto de vista do app, é um deviceSecret de 32 caracteres hexadecimais guardado num arquivo XML simples dentro dos shared preferences do Android. O app gera esse segredo uma vez quando você loga, e a partir daí toda chamada à API (jumpg-api.tokyo-cdn.com) é assinada com ele. Sem DRM elaborado, sem token rotativo, sem nada disso. É um segredo único e estático por aparelho.

O detalhe é que extrair esse segredo do app dá trabalho, porque por padrão você não tem acesso ao /data/data/jp.co.shueisha.mangaplus/shared_prefs/config.xml num Android sem root. Existem três caminhos:

1. Celular rooteado: roda adb shell su -c "cat /data/data/jp.co.shueisha.mangaplus/shared_prefs/config.xml" e procura o <string name="secret">...</string>.
2. Emulador com root: instala o Android Studio, cria um AVD com Google Play x86_64, aplica o rootAVD pra ter root via Magisk, loga na sua conta Google que tem a assinatura, instala o MANGA Plus pela Play Store, e roda o mesmo adb shell de cima.
3. Captura de rede com mitmproxy (mais avançado): roda o emulador root, injeta o CA do mitmproxy via Conscrypt APEX, e intercepta o segredo na primeira chamada autenticada do app.

Os três caminhos estão documentados em detalhe nos docs/install.md e docs/debugging.md do repositório. Não vou repetir aqui passo a passo porque é mais ferramenta do que técnica em si, e quem topa o trabalho vai querer ler o original. O importante é que funciona, e que basta fazer uma vez: depois de extraído, o segredo serve pro app desktop pelo tempo que durar sua assinatura.

Sim, é chato. Mas é o preço de ter um único ponto de configuração que destrava o resto.

O app desktop

Com o segredo na mão, o resto foi fácil. Montei o Frank Manga+, um app nativo em Rust + Tauri, com WebView SvelteKit no frontend e cliente Rust com reqwest no backend conversando direto com a API da Shueisha. Pra carregar imagens dos capítulos sem vazar URL nem ter dor de cabeça com CORS, criei um esquema custom mpimg:// interceptado pelo Tauri, que baixa, descriptografa (a API entrega as páginas com XOR simples) e devolve pro WebView.

O app abre numa visão de biblioteca com busca:

Clicando num título você vai pra página de detalhe com a lista completa de capítulos e um botão “Continue” que retoma do último capítulo lido:

O leitor abre em página única, com snap por página e as zonas de clique no estilo mangá: clica na metade esquerda da página pra avançar e na direita pra voltar (sentido de leitura japonês, da direita pra esquerda). Quem prefere teclado tem seta, espaço, j/k e PageUp/PageDown, tudo funciona. Quando você chega no fim de um capítulo, o próximo já vem em prefetch e é anexado no scroll, então não precisa voltar pra lista de capítulos toda hora. E o resume é por capítulo: se você sai no meio, da próxima vez que abrir aquele capítulo cai exatamente na página onde parou. Pra séries gigantes como One Piece (1100+ capítulos), a lista é virtualizada, então abre instantâneo:

Num monitor de 32 polegadas, página única desperdiça metade da tela. Por isso tem o modo página dupla: aperta D (ou clica no ícone de layout no cabeçalho) e o leitor junta as páginas que formam par: a dobra inteira preenche a tela do jeito que o autor desenhou. É como mangá foi feito pra ser lido.

E dá pra ver como isso importa quando compara com encadernação barata. Paperback ruim engole o meio da dobra, exatamente onde a arte deveria se conectar. No digital, quando o leitor junta direito, a cena respira:

Frank Manga+ juntando a página dupla	Paperback barato engolindo a dobra

O D cicla por três layouts: single (uma página por vez), double (pares sequenciais a partir da página 1) e double-cover (a primeira página de cada capítulo sozinha e o resto em pares, que é como mangá impresso encaderna a capa solta antes da primeira dobra). A escolha persiste entre capítulos e sessões, então você configura uma vez e esquece.

Tem também um filtro de leitura noturna. Aperta F (ou clica no ícone de lua no cabeçalho) e os brancos da página esquentam pro sépia. Branco de LCD castiga a vista no escuro, e isso suaviza sem achatar o contraste:

O F cicla por quatro níveis: off → low → med → high → off. O botão fica âmbar e mostra de um a três pontinhos pro nível ativo, e a escolha fica salva no localStorage igual às outras preferências do leitor. Por baixo é um filtro CSS de sepia + brightness + saturate na pilha inteira de páginas: o sépia empurra a cor pro âmbar mas preserva a faixa de luminância, então preto continua preto e o contraste da arte fica intacto.

Estado de leitura (último capítulo, página corrente) fica no localStorage do WebView. Cache de imagens em ~/.cache/mangaplus-reader/. O deviceSecret extraído fica em ~/.config/mangaplus-reader/secret (Linux/macOS) ou %APPDATA%\mangaplus-reader\secret (Windows). Dá pra sobrescrever com a variável de ambiente MANGAPLUS_SECRET se preferir.

Instalação

Tem build pronto pra todas as plataformas principais:

• Linux: AppImage, .deb, .rpm, ou via AUR (yay -S mangaplus-reader-bin).
• macOS: .dmg separado pra Apple Silicon (aarch64) e Intel (x64).
• Windows: instalador .exe. Não está assinado, então o Windows SmartScreen vai reclamar — clica em “More info → Run anyway”.

Todos os artefatos saem nos Releases do GitHub.

Status e contribuições

Isso é beta. Funciona pro meu uso (leio várias séries por semana sem dor de cabeça), mas tem features que faltam: filtros de gênero na busca, modo offline real (hoje guarda em cache só o que já foi lido), e o caminho de extração do segredo pra usuários menos técnicos.

Se você assina o MANGA Plus e topa testar, manda issue ou PR. O código é Rust + Svelte, MIT, contribuição bem-vinda: github.com/akitaonrails/frank_mangaplus.

Agora finalmente leio One Piece no monitor grande, sem precisar segurar celular ou ficar de pescoço torto. Já valeu o trabalho.

Bônus: Prettify Manga Reader pra sites de fansub

Além do app desktop, mantenho uma extensão mais simples: Prettify Manga Reader. Ela não traduz nada. O objetivo é arrumar a leitura.

A maioria dos sites de fansub é feia, cheia de banner, e claramente pensada pra celular: uma página embaixo da outra, scroll vertical infinito, boa sorte. Isso é prático pra ler no telefone, mas mangá não foi desenhado como feed de Instagram. Mangá foi pensado pra virar página. Duas páginas abertas ao mesmo tempo. O ritmo de leitura, a virada, o respiro entre quadros, tudo considera esse par.

E vários autores usam isso pra fazer spread de duas páginas. Kaiju No. 8 faz várias vezes. Se o site joga uma página embaixo da outra, você até lê os balões, mas perde a composição inteira. Você está vendo metade da arte de cada vez e achando que viu tudo.

O normal nesses sites é isso:

O Prettify abre um overlay escuro, encaixa a arte na tela e junta páginas no centro quando está em Book ou Double. O spread volta a parecer uma página dupla de verdade:

Ele tem três modos: Single (uma página por tela), Double (pares desde o começo) e Book (primeira página sozinha, depois pares, que é o jeito de encadernação). Abre em Book por padrão. Se a imagem já é horizontal, mantém como spread em tela cheia. Tem scroll snap pra cada página parar no lugar certo, atalho de teclado, controles pequenos de mouse, ajuda com ?, e um cartão no fim do capítulo tentando achar próximo/anterior quando o site deixa isso claro.

Também tem filtro noturno em três níveis. Aperta N e ele esquenta a página com sepia, brilho e contraste, sem transformar o desenho num cinza morto. Página branca no monitor grande de noite é uma lanterna na cara. Isso resolve.

Pra instalar, vai no GitHub do Prettify Manga Reader, baixa o zip em Releases, descompacta numa pasta permanente, abre chrome://extensions ou brave://extensions, liga Developer mode, clica em Load unpacked e escolhe a pasta descompactada. Se quiser montar do fonte, clona o repo, roda npm test, depois npm run package, descompacta o zip gerado em dist/ e carrega essa pasta.

No Kindle Web Reader, o Prettify faz menos de propósito. Em URLs tipo read.amazon.com/manga/..., read.amazon.co.jp/manga/..., read.amazon.co.uk/manga/... e domínios read.kindle.*, não tenta reconstruir o livro numa overlay própria. O leitor da Amazon já resolve conta, página e DRM; a extensão só injeta uma barrinha discreta no canto inferior direito e atalhos de teclado por cima do reader nativo.

Espaço, PageDown e setas avançam página; Shift+Space, PageUp e setas opostas voltam; Home/End vão pro começo ou fim quando o reader nativo aceita, com fallback de scroll; N cicla o filtro noturno. Não guarda credenciais da Amazon, não mexe em sessão, não precisa token no código. É só conforto visual e teclado em cima do Kindle Web que já existe.

Bônus 2: Frank Yomik agora também no desktop via extensão

Quem leu o balanço da maratona de IA lembra do Frank Yomik, meu projeto self-hosted que pega uma página de mangá ou webtoon, detecta os balões com RT-DETR-v2, faz OCR, manda pro Ollama local (qwen3:14b) traduzir, e devolve a página com o texto traduzido no lugar. Já expliquei a história e os detalhes técnicos no post Meu primeiro fracasso com Vibe Code e como consertei | Frank Yomik. Aqui o ponto é o pedaço novo no desktop.

Originalmente tinha só cliente Flutter pra Android e Linux, que abria Kindle Japan e Naver Webtoon dentro de um WebView. Acontece que rodar app Flutter dentro de WebView no desktop pra ler Kindle é meio canhão pra mosca. No desktop você já tem Chromium aberto. O que faltava era uma extensão de navegador.

Nas últimas semanas adicionei isso. Extensão Manifest V3 pra Chromium/Brave/Edge, conversando com o mesmo servidor self-hosted do Yomik. Roda em read.amazon.co.jp, read.kindle.co.jp, comic.naver.com e na versão mobile do Naver. A página fica visualmente idêntica ao original, sem botão injetado nem HUD na cara do leitor. Toda configuração mora no popup:

O content script pega a imagem da página atual e manda pro servidor. O bearer token fica no service worker, então não vaza pro JS da página. Quando a tradução volta, a imagem é trocada na hora no lugar da original. Tem cache local pra não retraduzir página já vista, botão de “force reprocess” pra quando precisa reportar bug, e autosave de configuração. Detalhes no README da extensão, e o zip pra Load Unpacked sai nos Releases do repo.

Na prática, hoje o monitor de 32" virou minha mesa de leitura. Frank Manga+ abre o catálogo oficial da Shueisha em inglês (One Piece, Chainsaw Man, e o que mais a Shonen Jump publicar). Quando é fansub ou Kindle Web e só quero conforto visual, o Prettify resolve reader, teclado e filtro noturno. Quando quero ler coisa japonesa sem tradução oficial, abro Kindle Japan numa aba e o Yomik manda furigana ou tradução LLM em cima da página. Pra webtoon coreano da Naver, mesma história, mesma extensão.

A parte boa é que cada projeto resolve um pedaço diferente e eles se completam. Frank Manga+ existe porque a Shueisha não tem site. Prettify deixa readers de navegador menos sofridos. O Yomik existe porque o resto do mangá que eu leio não tem tradução oficial decente em tempo hábil. Pra quem é doente de mangá igual eu, é o setup que eu queria há anos.

Eu sempre gostei de karaokê. De vez em quando saio pra cantar com família ou amigos. Em São Paulo tem bons lugares na Liberdade e no Bom Retiro, por exemplo, com cabines no estilo japonês. Se você nunca foi num karaokê desses: você aluga uma sala privada por hora, tem um catálogo enorme de músicas, dois microfones, e um sistema de pontuação que avalia seu canto em tempo real. Os melhores sistemas são japoneses, como o Joysound e o DAM. Nota acima de 90 (de 100) é considerada avançada. O DAM, na série LIVE DAM Ai, até usa IA pra dar notas mais “humanas”.

Mas nem todo lugar tem esse nível.

O problema com karaokê no Brasil

No Brasil a gente cresceu com o Videokê, a marca que o coreano Seok Ha Hwang trouxe pro país em 1996, importando equipamento da Coreia. Virou febre nos anos 90 e 2000, apareceu em todo bar, churrasco e festa de aniversário. O problema é que esses aparelhos pararam no tempo. Os modelos atuais, como o VSK 5.0, vêm com uns 12-13 mil músicas no catálogo, que você expande comprando cartuchos ou pacotes de música. Na prática, o repertório é velho, a interface é dos anos 2000, e se a música que você quer cantar saiu depois de 2015, boa sorte.

A solução que muitos bares adotaram foi permitir Chromecast ou espelhamento de tela pra que os clientes busquem músicas direto no YouTube. Faz sentido: no YouTube você encontra karaokê de qualquer música. Versão com letra, versão instrumental, versão com guia vocal.

Mas tem um downgrade: você perde a pontuação. Uma das coisas mais divertidas do karaokê é a competição. Ver sua nota subindo, comparar com os amigos, tentar bater o recorde da noite. Se você está só cantando em cima de um vídeo do YouTube, não tem feedback nenhum. É como jogar boliche sem placar.

E comprar um sistema profissional pra casa? Importar um Joysound F1 sai por mais de US$ 2.000 só o hardware, fora a assinatura mensal do catálogo. Pra uso casual não faz sentido.

A ideia: YouTube com pontuação em tempo real

O Frank Karaoke surgiu dessa frustração. Se o YouTube já tem todas as músicas, por que não fazer um app que funciona como wrapper do YouTube com overlay de pontuação em tempo real? Você busca qualquer vídeo de karaokê, canta junto, e o app analisa sua voz pelo microfone e mostra uma nota ao vivo.

É um app Flutter pra Android. Internamente ele carrega o YouTube numa webview e injeta um overlay em HTML/CSS/JavaScript direto na página. O display de score, o trail de pitch, o painel de configurações, o seletor de modo, tudo renderizado dentro da webview via injeção de JS.

Scoring sem referência

Agora, o problema real. Todos os sistemas profissionais de karaokê dependem de arquivos de referência pré-fabricados pra cada música. Todos.

O SingStar da Sony, que vendeu mais de 12 milhões de cópias entre 2004 e o fim do PS3, tinha um track de notas feito à mão pra cada música. Cada nota, cada sílaba, tudo mapeado manualmente. O mecanismo comparava o pitch do cantor via FFT contra essa referência em tempo real. Detalhe que eu achei esperto: a oitava era ignorada. Se a nota certa era um Dó, tanto faz se você cantou Dó3 ou Dó4. Homens cantam músicas femininas sem problema.

O Joysound e o DAM no Japão vão além e avaliam três dimensões separadas: precisão de pitch (音感), ritmo/timing (リズム感) e expressividade/dinâmica de volume (表現力). Tudo baseado em dados MIDI do servidor do operador. O formato open source equivalente é o UltraStar, onde cada música tem um arquivo .txt assim:

: 12 4 5 Hel-    (TipoNota BeatInicial Duração Pitch Sílaba)

Pitch 5 = MIDI 65 (F4). A pontuação compara o pitch do cantor com o da nota, módulo oitava, com tolerância de 1 semitom.

O Frank Karaoke funciona com qualquer vídeo do YouTube. Não tem arquivo de referência. Não tem MIDI. Não tem anotação de melodia. Zero metadata sobre qual nota você deveria estar cantando.

Eu não sei nada de pontuação de karaokê. Não sei nada de processamento de áudio, detecção de pitch, teoria musical aplicada a software. Nada. Então pedi pro Claude Code fazer uma pesquisa extensiva sobre o assunto. O que ele trouxe de volta está documentado em docs/scoring.md no repositório, e é bastante coisa: papers acadêmicos sobre avaliação de canto (Nakano et al. 2006, Tsai & Lee 2012, Molina et al. 2013), patentes (a Yamaha tem uma de 1999, US5889224A, que detalha pontuação por MIDI com 3 faixas de tolerância), e o código fonte de projetos open source como UltraStar Deluxe, AllKaraoke, Vocaluxe e Nightingale.

A conclusão da pesquisa: sem referência por música, você precisa avaliar qualidade vocal de forma genérica. Medir como a pessoa canta, não o que ela deveria estar cantando. E como não existe uma métrica única que funcione pra todos os casos, decidimos implementar quatro modos de pontuação diferentes, cada um medindo uma dimensão diferente da qualidade vocal.

O problema do microfone do celular

Antes dos modos de pontuação, preciso explicar um problema mais fundamental que a pesquisa revelou: o microfone do celular.

Quando você canta karaokê com o celular, o microfone capta três coisas ao mesmo tempo: sua voz, a música saindo do alto-falante, e ruído ambiente da sala. Sua voz está fisicamente mais perto do microfone, então domina o sinal. Mas não o suficiente pra uma separação limpa.

Tentei várias abordagens pra isolar a voz:

Subtração espectral usando o áudio de referência do YouTube. Abandonei. O CDN do YouTube bloqueia extração direta de áudio por user-agent não-browser, e mesmo com o áudio de referência, a equalização do alto-falante, a reverberação da sala e o delay de Bluetooth tornam o sinal diferente demais do que o microfone capta. Subtração simples gera artefatos piores que nenhuma subtração.

Pré-ênfase + center clipping. Abandonei também. O center clipping destrói a forma de onda que o algoritmo YIN precisa pra autocorrelação, e a pré-ênfase amplifica ruído tanto quanto voz.

O que funciona é um filtro bandpass de 200-3500 Hz: um filtro IIR de segunda ordem (Butterworth, Q=0.707) em cascata. O high-pass em 200 Hz elimina baixo, bumbo, bass guitar do bleed do alto-falante. O low-pass em 3500 Hz elimina pratos, hi-hats, ruído de alta frequência. Os fundamentais da voz humana (85-300 Hz) e os formantes (300-3000 Hz) passam pelo filtro. Não é isolamento perfeito, mas melhora bastante a razão voz/música pra detecção de pitch.

Mas o bandpass sozinho não resolve tudo. Guitarras, sintetizadores e piano produzem sinais periódicos na mesma faixa de frequência da voz, e o YIN detecta pitch neles também. Pra lidar com isso, o app faz uma calibração adaptativa: nos primeiros 5 segundos de warmup (quando ninguém está cantando), ele coleta amostras de RMS do sinal pra estabelecer um baseline do nível do alto-falante. Durante a música, mantém esse baseline atualizado (percentil 25 dos últimos ~4 segundos de frames). Pra um frame ser pontuado, o RMS precisa estar pelo menos 1.3x acima do baseline. A voz está mais perto do microfone, então empurra o RMS acima do nível do alto-falante. A melodia instrumental fica perto do baseline e é filtrada. Nos testes, o cantor original saindo pelo alto-falante marcava uns 37 pontos com dots esparsos no trail, enquanto alguém cantando de verdade marcava ~59 com dots densos.

Outro detalhe chato: no Android, especificamente nos Samsung, o AutomaticGainControl (AGC) do DSP atenua o sinal em vez de amplificar. Nos Galaxy, habilitar AGC reduz o pico do microfone de ~0.06 pra ~0.003. Silêncio pra detecção de pitch. Então o app desabilita AGC, echo cancellation e noise suppression. Quando o pico fica abaixo de 0.01, aplica ganho por software (até 30x) pra trazer o sinal a níveis usáveis.

O algoritmo YIN

Pra detectar o pitch da voz eu uso o YIN, de Alain de Cheveigné (IRCAM-CNRS) e Hideki Kawahara (Universidade de Wakayama). É um estimador de frequência fundamental no domínio do tempo. A ideia central é a Cumulative Mean Normalized Difference Function (CMNDF), que basicamente mede o quão periódico é o sinal em cada lag, normaliza pra reduzir falsos positivos, e usa interpolação parabólica pra refinar o resultado. É leve o suficiente pra rodar em tempo real no celular, o que importa aqui.

No app, o threshold do YIN é 0.70 (ajustado pra sinais mistos de voz + música), e frames com confiança abaixo de 0.3 são descartados. Abaixo disso, provavelmente é ruído ou instrumento.

Os 4 modos de pontuação

Cada modo avalia um aspecto diferente da qualidade vocal. Todos compartilham o mesmo pipeline de áudio (bandpass → YIN → gate de confiança). A diferença é como interpretam o pitch detectado.

Pitch Match

Mede o quão limpo você sustenta as notas. Usa decaimento gaussiano baseado no desvio padrão dos valores MIDI numa janela rolante de ~15 frames. Notas firmes (desvio < 0.3 semitons) pontuam 85-100%. Voz tremendo (desvio > 2 semitons) pontua perto de zero. Bom pra músicas que você já conhece bem.

Contour

Mede a forma melódica do seu canto. Não importa qual nota exata você acerta, só a direção e o fluxo. Avalia a amplitude do pitch e movimentos melódicos (saltos > 0.5 semitom) numa janela rolante. Canto monótono pontua ~10%. Movimento melódico suave com amplitude de 2-6 semitons pontua 70-100%. Bom pra quando você está aprendendo uma música nova.

Intervals

Mede a qualidade musical dos saltos entre notas consecutivas. Tom inteiro (2 semitons) pontua mais alto. Terças e quartas pontuam bem. Saltos descontrolados de uma oitava ou mais pontuam baixo. Usa uma curva gaussiana centrada no tom inteiro. Funciona quando você está cantando numa tonalidade diferente da original.

Streak

É o Pitch Match com multiplicador combo. Cada frame consecutivo com score acima de 0.4 incrementa o contador de streak. O streak adiciona pontos bônus (até +0.4 em streak de 30+). Quebrar um streak > 5 frames empurra uma penalidade de 0.05 no EMA. Silêncio congela o streak, então pausas instrumentais não te prejudicam. O modo mais divertido pra festas.

A lógica por trás desses quatro modos veio da pesquisa que o Claude fez nos papers acadêmicos. Cada um mede uma dimensão diferente: afinação, contorno melódico, fraseado e consistência. Nenhum deles sozinho é suficiente, mas juntos cobrem razoavelmente bem o que dá pra avaliar sem ter a melodia de referência da música.

O Pitch Oracle

Além dos quatro modos puramente vocais, o app tem o que eu chamo de Pitch Oracle. A ideia: em vez de avaliar sua voz isoladamente, o app baixa o áudio de referência do vídeo via youtube_explode_dart, decodifica pra PCM, roda o YIN nele, e constrói um timeline de pitch com timestamp da música inteira. Durante a pontuação, se o pitch do microfone bate com o pitch da referência naquele momento do vídeo, provavelmente é bleed do alto-falante, e é ignorado. Se difere, é sua voz, e é pontuado.

A sincronização funciona pelo currentTime do elemento de vídeo HTML5, enviado pro Dart via um listener JS de timeupdate a cada ~250ms. O oracle consulta o pitch de referência na posição exata do playback, levando em conta pause, seek e mudança de velocidade.

Na primeira vez que você toca uma música, o oracle leva uns 5-15 segundos pra baixar e analisar o áudio. Mas o timeline é salvo como JSON no cache local do app (pitch_oracle/<videoId>.json). Se você tocar a mesma música de novo, carrega instantaneamente do cache, sem request de rede. Isso também resolve o problema de rate limiting do YouTube pras músicas que você mais canta.

Com o oracle ativo, os modos mudam de comportamento. Pitch Match compara a classe de pitch do cantor contra a da referência (agnóstico à oitava, como o SingStar). Contour usa correlação cruzada entre o movimento de pitch do cantor e o da referência. Intervals compara os saltos em semitons contra os da referência.

Quando o YouTube bloqueia o download por rate limiting (acontece depois de muitos requests seguidos do mesmo IP, limpa em 15-30 minutos), o oracle falha silenciosamente e os modos voltam pra análise puramente vocal.

O caminho até aqui

O app que você vê agora passou por muita iteração antes de chegar nesse estado.

Primeiro, eu tentei fazer uma versão desktop Linux pra facilitar o debug. Faz sentido, né? Testa no desktop, itera rápido, depois porta pro celular. O problema é que o Flutter não tem backend de webview pra Linux desktop. O webview_flutter simplesmente não funciona. Tentei o webview_cef, que é baseado no Chromium Embedded Framework. O CEF spawna seu próprio processo de GPU, e no Hyprland (compositor Wayland baseado no wlroots) isso conflita com o pipeline de renderização do compositor. No meu setup com NVIDIA, a sessão inteira do Hyprland congelou. Tela travada, sem resposta a teclado, tive que matar pelo TTY. Fora que o CEF exige download de um binário de ~200MB na primeira build. Desisti do CEF e escrevi com o Claude uma bridge nativa em C++ usando WebKitGTK com method channels do Flutter. Funcionou, mas cada peculiaridade do YouTube exigia código separado pro Linux e pro Android. O just_audio também não tem implementação pra Linux desktop. No fim a versão Linux virou peso morto. Deletei ~1.500 linhas de código Linux-específico e foquei só no Android.

Depois veio a saga do microfone no Samsung. No meu Galaxy Z Fold, o microfone captava um sinal absurdamente baixo. Pico de ~0.005, basicamente silêncio pro detector de pitch. Fiquei umas duas horas tentando entender. Baixei thresholds, aumentei ganho por software até 50x, desabilitei preprocessadores de áudio. Nada funcionava direito. Até que descobri o problema real: o AutomaticGainControl do Android. O nome diz “controle automático de ganho”, o que sugere que ele amplifica sinais fracos. Na implementação DSP dos Samsung, ele faz o oposto. Ele atenua o sinal pra um nível de referência baixo, otimizado pra chamadas de voz. Com AGC ligado, o pico caía de ~0.06 pra ~0.003. Desligar o AGC resolveu. Mas aí o pacote audio_session religava o AGC por baixo dos panos. Removi ele também. Foram três rodadas de fix, cada uma achando mais uma camada do problema.

E a pontuação. A pontuação levou mais tempo que todo o resto junto. A primeira implementação usava média cumulativa, que deixava a nota travada num valor e não respondia ao canto em tempo real. Troquei pra janela rolante. Aí a nota ficava presa em ~50% por causa de um bug no peso da pontuação primária. Consertei, e ela passou a começar em 70% mesmo sem ninguém cantando. Consertei de novo. O modo Streak não resetava direito no silêncio. O chromatic snap dava nota alta pra qualquer coisa. O histórico de pitch não era limpo nos gaps de silêncio e os modos ficavam estagnados. Cada bug corrigido revelava outro. Foram mais de 25 commits só ajustando a pontuação, do primeiro protótipo até o estado atual.

O resultado não é perfeito. Eu sei. Mas funciona o suficiente pra ser divertido, que era o objetivo desde o começo.

Configurações

O painel de configurações fica no ícone de engrenagem do overlay. Tem três presets de microfone pra diferentes ambientes (microfone externo limpo, sala normal, festa barulhenta), cada um ajustando thresholds de confiança e amplitude. Tem pitch shift pra quando a música é aguda demais pra sua extensão vocal. O ajuste muda tanto o áudio do vídeo quanto a pontuação ao mesmo tempo: usa o playbackRate do elemento HTML5 com preservesPitch=false, então +2 semitons acelera o áudio pra 1.12x (pitch sobe) e -2 semitons desacelera pra 0.89x (pitch desce). A pontuação compensa o offset, então você canta na sua faixa confortável e o sistema avalia corretamente. Tem calibração de microfone, um processo de 3 segundos que mede o ruído da sala e adapta os thresholds. E tem restart pra zerar a pontuação sem recarregar o vídeo.

Pra trocar de modo de pontuação, toque na caixa de score durante a reprodução.

Fluxo de uso

1. Abra o app. O YouTube carrega dentro do app com o logo do Frank Karaoke.
2. Busque um vídeo de karaokê. Qualquer vídeo funciona, mas faixas instrumentais com letra na tela dão melhores resultados.
3. O vídeo pausa brevemente pra inicializar o microfone, baixar dados da música pro pitch oracle, e preparar o overlay. Na primeira vez com uma música nova isso leva uns 5-15 segundos. Se você já tocou essa música antes, carrega do cache instantaneamente.
4. Cante. O score “live” reflete sua performance atual (média exponencial com alpha 0.15, resposta em ~1 segundo). O score “overall” é a média cumulativa da música inteira.
5. Quando o vídeo pausa, a pontuação pausa junto (pra não pontuar ruído ambiente). Se fizer seek, o score zera e tem 5 segundos de warmup.

Como instalar

O app ainda não está na Play Store, estou esperando o Google verificar minha identidade de desenvolvedor. Deve aparecer lá nos próximos dias. Enquanto isso, é um projeto aberto e dá pra instalar direto.

O jeito mais fácil é baixar o APK assinado direto da página de releases do GitHub. No celular ou tablet Android, baixe o FrankKaraoke-0.2.0-android.apk, abra e toque em Instalar. Se o Android reclamar de “fontes desconhecidas”, habilite em Configurações > Segurança pro seu navegador. Na primeira execução o app pede permissão de microfone. Depois vá nas configurações (ícone de engrenagem) e calibre o microfone antes de cantar, são 3 segundos.

Se você quer compilar do fonte ou contribuir, o repositório está no GitHub. Precisa de Flutter SDK 3.10+, Android SDK API 24+, e um dispositivo físico pra testar microfone (emulador não dá resultados representativos).

git clone https://github.com/akitaonrails/frank_karaoke.git
cd frank_karaoke
flutter pub get
flutter run -d <device_id>

O README tem o resto.

Stack: Flutter + Riverpod pra state management, webview_flutter pro YouTube, youtube_explode_dart pra extração de áudio, record pra captura PCM do microfone, audio_decoder pra decodificação de referência via Android MediaCodec, e o algoritmo YIN implementado em Dart puro.

A documentação técnica do sistema de pontuação está em docs/scoring.md no repositório. Cobre como SingStar, Joysound e DAM funcionam, os papers acadêmicos, a arquitetura do pitch oracle, os problemas de isolamento de voz no Android, e o roadmap.

A pontuação é experimental

Preciso ser direto: o sistema de pontuação é experimental. Sem arquivos de referência por música, a avaliação é aproximada. O app mede se você está afinado, se segue um contorno melódico, se seus intervalos são musicais, se é consistente. Mas não te diz se você está cantando a melodia certa desta música específica (a menos que o pitch oracle consiga baixar o áudio, e nem sempre consegue).

Se você tem experiência com processamento de áudio, detecção de pitch, ou avaliação musical, o repositório está aberto e a documentação de pesquisa em docs/scoring.md detalha o que foi tentado, o que funciona e o que não funciona. Em particular: calibração dos thresholds dos modos, melhorias no isolamento de voz, e integração com o UltraSinger (que gera arquivos de referência a partir de músicas usando Demucs + basic-pitch + WhisperX) são áreas onde contribuição de quem entende do assunto faria diferença. Apreciamos qualquer ajuda de especialistas na calibração desses sistemas.

Ah, e o nome. Frank Karaoke. É uma homenagem ao Sinatra. Quem mais?

Projeto no GitHub: github.com/akitaonrails/frank_karaoke

Dito isso, deixa eu explicar por que eu fiz isso.

O problema com a mídia brasileira

Eu cansei.

Cansei de abrir o jornal e ter que fazer ginástica mental pra separar informação de narrativa. Cansei de publicações como Folha de São Paulo, UOL, Carta Capital, Brasil 247, O Globo e várias outras que usam manchetes enganosas, omitem contexto de propósito, transpõem evidências de outros países sem nenhuma ressalva, e criam uma aparência de consenso entre veículos que estão todos dizendo a mesma coisa porque seguem a mesma pauta coordenada.

Isso não é teoria da conspiração. É padrão editorial verificável. E o pior: a maioria dos leitores não tem tempo nem ferramentas pra perceber. Você lê o título, lê os dois primeiros parágrafos, e segue com a impressão que o artigo plantou na sua cabeça.

O que o Frank Investigator faz

Você dá uma URL de artigo de notícia. O sistema busca o artigo com Chromium headless (pra passar por paywalls e cookie walls), extrai o conteúdo filtrando propaganda e sidebar, e decompõe o texto em afirmações verificáveis. Aí começa a análise de verdade: divergência entre manchete e corpo, falácias retóricas (falsa causalidade, apelo a autoridade, espantalho, bait-and-pivot), distorção de fontes, manipulação temporal, citação seletiva, authority laundering. Expande os links citados no artigo pra verificar se as fontes dizem o que o autor afirma. Avalia cada claim com consenso de 3 modelos de IA (Claude Sonnet 4.6, GPT-5.4, Gemini 3.1 Pro) via OpenRouter. Detecta lacunas contextuais, campanha coordenada entre veículos, e mede a proporção entre paixão e evidência. São 15 etapas ao todo.

O princípio central é “Verdade Acima do Consenso”: uma fonte primária (dado oficial, documento de governo, estudo acadêmico original) veta qualquer quantidade de fontes secundárias repetindo a mesma informação. Dez jornais repetindo a mesma coisa sem fonte primária continuam valendo zero.

Deixa eu mostrar cinco exemplos reais.

Exemplo 1: O caso Noelia Castillo (BBC)

A BBC publicou uma matéria com o título “Morre Noelia Castillo: a luta de uma jovem de 25 anos na Justiça contra seu pai para receber a eutanásia na Espanha”. À primeira vista parece uma história sobre direito à eutanásia e uma disputa familiar. Uma jovem tetraplégica que lutou contra a oposição do pai religioso pra exercer seu direito de morrer.

Só que ao comparar com outros veículos, como a Veja, aparecem fatos que a BBC omitiu quase completamente. E esses fatos mudam tudo.

Noelia foi retirada da família pelo governo espanhol aos 13 anos e colocada sob custódia do estado. Enquanto estava sob essa custódia, sofreu múltiplos estupros coletivos. A violência sexual resultou em danos psiquiátricos graves e um histórico de saúde mental que já somava 67% de grau de invalidez antes dos eventos de 2022. Quando tentou suicídio em outubro de 2022, jogando-se do quinto andar de um prédio, ficou paraplégica. O grau de invalidez subiu pra 74%.

O pedido de eutanásia foi aprovado pela Comissão de Garantia e Avaliação da Catalunha. A data marcada pro procedimento foi 2 de agosto de 2024, mas ficou suspensa por mais de 600 dias por causa dos recursos judiciais do pai. Cinco instâncias judiciais se pronunciaram. O Tribunal Constitucional descartou violação de direitos fundamentais. O Supremo Tribunal da Espanha recusou o recurso. O Tribunal Europeu de Direitos Humanos rejeitou o pedido de suspensão. Na sexta-feira, 26 de março de 2026, Noelia foi submetida à eutanásia no Hospital Residencial Sant Camil, na comarca catalã de Garraf.

Mas tem um detalhe que a Veja menciona e que é perturbador: Noelia teria manifestado dúvidas antes do procedimento. E o hospital teria acelerado o processo porque os órgãos já estavam comprometidos pra doação.

O relatório do Frank Investigator comparou a cobertura de vários veículos.

A análise cruzada entre os artigos analisados mostrou que alguns veículos, como a BBC, omitiram fatos que alteram a interpretação do caso inteiro. Outros, como a Veja, trouxeram o contexto completo. O episódio de violência sexual coletiva de outubro de 2022, a investigação criminal, o histórico psiquiátrico desde os 13 anos, tudo isso aparece em algumas coberturas mas está completamente ausente em outras. E entre os veículos que omitiram, nenhum tocou na questão ética de que o fundamento físico pro pedido de eutanásia deriva de uma tentativa de suicídio.

O enquadramento convergente entre os veículos é de “batalha judicial”, “morte que pediu”, “deixar de sofrer”, “partir em paz”, suavizando o caráter definitivo do procedimento e posicionando Noelia como protagonista heroica e o pai como antagonista obstrutivo. O pai, Gerônimo Castillo, e seus Advogados Cristãos são qualificados como “ultracatólicos” ou “ultraconservadores” sem fonte independente que sustente essa classificação editorial.

A coordenação narrativa ficou em 55%. Não parece ser coordenação ativa entre redações, mas alinhamento editorial temático: todo mundo comprou a narrativa de autonomia individual sem questionar. O que eleva o score é a convergência de omissões. Nenhum veículo explica a distinção jurídica entre o TEDH “autorizar ativamente” a eutanásia e simplesmente recusar medidas cautelares provisórias pedidas pelo pai, que é o que de fato aconteceu. As implicações médicas e bioéticas de aprovar eutanásia em caso decorrente de tentativa de suicídio não aparecem em lugar nenhum. E qualquer voz crítica ao procedimento é automaticamente enquadrada como religiosa ou ideológica, nunca como médica ou jurídica.

É o tipo de caso onde a omissão é a manipulação. Os veículos que omitiram esses fatos não mentiram em nenhum momento. Mas ao enquadrar como “disputa familiar sobre direito à eutanásia” e omitir a cadeia causal (custódia do estado → estupros coletivos → dano psiquiátrico → tentativa de suicídio → paraplegia → eutanásia), o leitor fica com uma impressão radicalmente diferente da realidade. A comparação entre coberturas é exatamente o tipo de coisa que o investigator faz bem: expor o que cada veículo escolheu mostrar e o que escolheu esconder.

Exemplo 2: “Governo corta imposto de quase mil importados” (UOL)

O UOL publicou que o governo cortou impostos de importação de quase mil produtos, de remédios a lúpulo. Manchete positiva, tom de benefício ao consumidor. Vários outros veículos publicaram a mesma coisa com enquadramento parecido: o governo fez algo bom, preços vão cair.

Só que a Gazeta do Povo conta a outra metade da história. O governo não cortou impostos antigos. O que aconteceu foi: em algum momento anterior a fevereiro de 2025, o governo aumentou tarifas de importação de mais de 1.200 itens, uma medida que geraria R$ 14 bilhões em arrecadação estimada. Depois, sob pressão nas redes sociais e pressão popular público, recuou parcialmente. Zerou tarifas de uns 970 itens de capital, informática e telecomunicações. Reduziu impostos de 120 produtos de informática. E agora chama isso de “corte de impostos”.

Ou seja: aumentaram, tomaram pressão popular, voltaram atrás em parte, e reembalaram como se fosse uma concessão generosa. A maioria dos mais de 1.200 itens que tiveram tarifas elevadas continua com tarifas mais altas do que antes. Nenhum preço caiu pro consumidor final. Os preços voltaram ao que eram pra alguns produtos, e continuam mais altos pra maioria.

O relatório do Frank Investigator cruzou os artigos e expôs o que foi omitido.

O que a comparação entre artigos expõe: nenhum dos veículos com enquadramento positivo menciona que a maioria dos 1.200+ itens com tarifas elevadas continua com tarifas mais altas após as duas rodadas de “cortes”. O impacto fiscal sobre a meta de arrecadação de R$ 14 bilhões prevista com os aumentos originais, ninguém calcula. Vozes da indústria nacional que pode ser prejudicada pela redução tarifária de concorrentes importados, nenhuma. Critérios objetivos do Gecex pra definir “oferta insuficiente no mercado interno”, não aparecem.

Os dois artigos analisados constroem o mesmo enquadramento positivo pro governo. O paradoxo de que os “cortes” são reversão parcial de aumentos feitos pelo mesmo governo no ano anterior fica enterrado ou simplesmente ausente.

É o tipo clássico de manipulação por reenquadramento. Ninguém mentiu. Mas “governo corta imposto” e “governo recua de aumento após pressão popular” descrevem o mesmo evento com impressões opostas. A escolha editorial de qual versão publicar já é a manipulação.

Exemplo 3: “Globo se desculpa por PowerPoint” (Brasil 247)

Esse caso explodiu nos últimos dias. A GloboNews mostrou um diagrama no programa Estúdio I conectando o presidente Lula, seus ministros e Daniel Vorcaro, dono do Banco Master, que está no centro de fraudes documentadas. A Globo depois se retratou publicamente, chamou o material de “errôneo e incompleto”, e demitiu uma editora.

O Brasil 247 publicou uma matéria com o título “Globo se desculpa por PowerPoint que tentou jogar o caso Master no colo de Lula”.

O relatório do Frank Investigator expôs o que está acontecendo por baixo:

O fato central é real: a Globo pediu desculpas e demitiu alguém. Mas o enquadramento do Brasil 247 vai muito além do que os fatos sustentam. O título diz “tentou jogar no colo de Lula” atribuindo intenção deliberada onde os documentos apontam pra falha editorial. A retratação da Globo falou em material “errôneo e incompleto”, não em tentativa de incriminar ninguém.

O que chama atenção nesse caso é a campanha coordenada. O investigator deu 62% de coordenação narrativa.

Vários veículos editorialmente alinhados ao governo usaram a expressão “sem provas” de forma convergente pra descrever a associação entre Lula e o caso Master. Todos focaram no erro da Globo como ponto central da narrativa, em vez de investigar as conexões reais. Nenhum veículo mencionou quais outros nomes políticos foram excluídos do PowerPoint original. Nenhum investigou as conexões documentadas de Vorcaro com diferentes esferas do poder. O foco é meta-jornalístico: criticam a emissora em vez de cobrir o escândalo.

As falácias detectadas: linguagem carregada (“tentou jogar”, “sem provas” usados pra enquadrar erro editorial como ataque político deliberado), falsa causalidade (a retratação da Globo não prova que as conexões são falsas), cherry-picking (destaca a omissão de nomes ligados ao governo Lula sem contextualizar quais outros nomes foram omitidos), e bait-and-pivot (usa o pedido de desculpas da Globo como gancho pra minimizar o escândalo do Banco Master).

E as perguntas que nenhum desses veículos fez: quais nomes de ministros do Supremo e políticos de outros partidos também foram excluídos do PowerPoint? O caso Master tem conexões documentadas com figuras do governo Lula, ou se restringem a governos anteriores? O Brasil 247, que publica esse artigo, tem alinhamento editorial declarado com o governo Lula? Qual foi a reação do Conselho de Ética jornalístico?

Confiança geral: 13%. O artigo não fabrica fatos. Mas seleciona, enquadra e omite de forma a construir uma narrativa que os dados não sustentam.

Exemplo 4: “Por que combustível caro é bom” (Folha)

O economista Bernardo Guimarães publicou uma coluna na Folha defendendo que combustível caro é bom pra sociedade porque estimula inovação em energia limpa. Ele cita artigos acadêmicos reais (Popp 2002, NBER) e tem credenciais acadêmicas verificáveis (doutorado em Yale, professor na FGV EESP). Parece sólido.

O relatório completo do Frank Investigator mostra outro quadro.

O artigo acerta ao citar estudos reais. Mas omite quem paga a conta. A coluna ignora completamente o impacto distributivo: populações de baixa renda, moradores de áreas periféricas e rurais, que dependem mais de veículos próprios e têm menos acesso a alternativas limpas. Pra um economista, ignorar efeitos distributivos é ou incompetência ou escolha editorial.

Tem um problema pior. As evidências empíricas que ele cita (patentes nos EUA, dados de veículos elétricos na Califórnia entre 2014-2017) são transpostas pro Brasil sem ressalva nenhuma. O Brasil tem uma matriz de etanol e infraestrutura flex-fuel que altera completamente o mecanismo causal. O artigo trata como se o consumidor brasileiro estivesse na mesma situação que o californiano, o que é falso.

E tem o contexto que o artigo menciona de passagem mas não desenvolve: a Guerra no Irã está fazendo os preços de combustível subirem no mundo todo. O Brasil deveria estar numa posição privilegiada por causa do pré-sal e do etanol. Mas décadas de má gestão e corrupção na Petrobras fizeram com que a gente pague o mesmo preço que o resto do mundo. Em vez de questionar isso, a coluna vende a ideia de que “pelo menos vai estimular energia limpa”. É uma racionalização de um problema que não deveria existir.

O investigator identificou 5 questões que o artigo se recusou a abordar, com 35% de completude contextual. As falácias detectadas incluem falso dilema (apresenta combustível caro como a única opção viável de política climática), cherry-picking (reconhece inelasticidade de curto prazo mas enfatiza apenas efeitos de longo prazo), e linguagem carregada (descreve alternativas como “brincar de plantar uma mudinha”).

Confiança geral: 25%. Não é desinformação fabricada. É opinião com seleção de evidências a favor da tese e omissão de contrapontos relevantes.

Exemplo 5: “Não existe cinema forte sem regulamentação do streaming” (O Globo)

Renata Magalhães, presidente da Academia Brasileira de Cinema, deu uma entrevista na coluna da Miriam Leitão no O Globo defendendo que regulamentar o streaming é condição necessária pra fortalecer o cinema brasileiro.

O relatório do Frank Investigator encontrou problemas sérios.

Primeiro: a afirmação central de que “muitos filmes têm baixa audiência” aparece sem nenhum dado empírico. Nenhum número, nenhuma série histórica. É afirmação de autoridade pura, sem base analítica.

Segundo: tem uma contradição interna que o artigo não resolve. O texto abre dizendo que o cinema brasileiro está “em destaque internacional” (prêmios, festivais). E logo em seguida argumenta que a ausência de regulamentação impede o fortalecimento da indústria. Mas se o cinema brasileiro já está ganhando prêmios internacionais sem essa regulamentação, o argumento de que a regulamentação é condição necessária cai por terra. O artigo não endereça essa contradição.

E é aqui que entra o elefante na sala que nenhum desses artigos menciona: as pessoas simplesmente não querem assistir a maioria desses filmes. O cinema brasileiro premiado internacionalmente é feito pra competir em Cannes e no Oscar, não pra lotar sala de cinema no Brasil. Em vez de se perguntar por que o público brasileiro não se interessa, a indústria prefere pedir regulamentação do streaming pra forçar plataformas a financiar e exibir conteúdo que não tem audiência espontânea. É o modelo clássico: usa dinheiro público e regulação pra manter viva uma indústria que não se sustenta no mercado.

A entrevistada é presidente da Academia Brasileira de Cinema. Tem interesse institucional direto na regulamentação. O artigo não apresenta nenhuma voz contrária e não discute os custos pro consumidor: aumento de preço de assinatura, redução de catálogo. Uma fonte só, com conflito de interesse declarado, sem contraponto.

E aqui vem a campanha coordenada, com 55% de coordenação narrativa. Múltiplos veículos reproduzem o mesmo enquadramento emocional: cinema “em risco”, regulamentação como “essencial”. Nenhuma das fontes identificadas discute evidências empíricas internacionais comparáveis sobre a eficácia de cotas de conteúdo (a Europa tem experiências com resultados contraditórios). Nenhuma menciona os conflitos de interesse da Academia Brasileira de Cinema. O fato de que as produções brasileiras premiadas internacionalmente foram feitas sem a regulamentação proposta é omitido convergentemente em todos os veículos. Apenas um site isolado (targethd.net) mencionou impactos negativos pro consumidor.

Confiança geral: 9%. O artigo é advocacy editorial legítimo, mas com falhas analíticas que limitam seu valor informativo a quase zero.

O que o investigator analisa

Os 5 exemplos acima mostram padrões diferentes, mas os critérios de análise são os mesmos.

O sinal mais forte de manipulação é a omissão. Não é o que o artigo diz que engana, é o que ele deixa de dizer. A análise de lacunas contextuais identifica as perguntas que o artigo deveria ter respondido e não respondeu, e busca contra-evidência pra cada uma. Nos exemplos acima, artigos que omitem a maior parte do contexto relevante não estão informando ninguém. E quando a comparação cruzada entre veículos mostra que uns cobriram os fatos e outros não, como no caso Noelia ou no corte de impostos, fica difícil argumentar que a omissão foi acidental.

Depois vem a detecção de campanha coordenada. Vários jornais cobrirem o mesmo assunto é normal. Todos usarem a mesma linguagem carregada, focarem nos mesmos pontos e omitirem os mesmos contrapontos ao mesmo tempo não é. O sinal mais forte de coordenação não é o que os veículos dizem em comum, mas o que omitem em comum.

Tem também o reenquadramento, que é mais sutil. No caso dos impostos, o governo aumentou tarifas, recuou sob pressão, e os veículos chamaram de “corte”. Ninguém mentiu tecnicamente, mas a escolha de enquadramento muda completamente a interpretação. Esse tipo de manipulação é mais difícil de detectar porque cada afirmação individual é defensável.

As falácias retóricas pegam construções específicas: falso dilema (“ou regula ou o cinema morre”), bait-and-pivot (abre com fato positivo e pivota pra narrativa de crise), linguagem carregada (“sem provas” usado pra atribuir intencionalidade). Cada falácia detectada vem com a citação exata do trecho e a explicação de por que aquela construção é problemática.

E tem o princípio que costura tudo: se 10 veículos repetem a mesma afirmação citando uns aos outros, o consenso de LLMs tem que refletir que a cadeia de evidência é circular, não que a afirmação é bem suportada. Volume de cobertura não é proxy pra verdade.

Por que você não pode “só perguntar pro ChatGPT”

A primeira reação de muita gente vai ser: “por que eu preciso disso se eu posso colar o artigo no ChatGPT e pedir pra ele analisar?”

Tenta. Pega um artigo político e pede pro ChatGPT criticar. Ele vai criticar. Pega o mesmo artigo e pede pra confirmar. Ele vai encontrar argumentos pra confirmar. O LLM não está buscando a verdade. Ele está prevendo qual resposta você mais provavelmente espera ouvir dado o enquadramento da sua pergunta. Se você pede “analise os problemas desse artigo”, o modelo vai achar problemas. Se você pede “esse artigo está correto?”, ele vai encontrar méritos. É viés de confirmação automatizado.

Tem outro problema. Os LLMs generalistas foram treinados pra ser agradáveis. A tendência sycophantic (de concordar com o usuário) é documentada em todos os modelos grandes. Se o seu histórico de conversa indica que você é de esquerda, o modelo tende a enquadrar as respostas de uma forma que agrade esse perfil. Se você é de direita, mesma coisa pro outro lado. Ele não está mentindo de propósito. Ele está otimizando pra satisfação do usuário, que é literalmente a métrica pela qual foi treinado via RLHF.

E o pior: LLMs alucinam. Se não têm evidência suficiente pra sustentar a resposta que acham que você quer ouvir, inventam. Fabricam citações e dados plausíveis, atribuem declarações a pessoas que nunca as fizeram. Se você pede pra ele criticar um artigo sobre combustível, ele pode inventar um estudo fictício que “prova” o contrário do artigo. Parece convincente. Mas não existe.

O Frank Investigator foi construído pra evitar exatamente esses problemas. A primeira decisão de design é que nenhum humano faz pergunta ao LLM. Não existe prompt aberto tipo “analise esse artigo”. Cada etapa do pipeline tem prompts estruturados que pedem análises específicas: “liste as falácias retóricas neste trecho”, “identifique que informações contextuais estão ausentes”, “compare a manchete com o corpo do texto”. O modelo não sabe se o operador concorda ou discorda do artigo, porque o operador não opina em nenhum momento. Isso elimina o viés de confirmação na raiz.

Pra lidar com alucinação, todo analisador que usa LLM inclui a instrução “CRITICAL – NO HALLUCINATION: Only reference URLs, sources, claims, quotes, and data that are EXPLICITLY present in the input provided to you. Do not invent, guess, or fabricate any URL, source name, statistic, quote, or claim. If you cannot verify something from the provided text, mark it as unverifiable – never fill in details.” Não elimina alucinação completamente, mas reduz muito. E como são 3 modelos de empresas diferentes (Anthropic, OpenAI, Google) respondendo as mesmas perguntas, quando um alucina os outros dois geralmente discordam. O consenso é ponderado por confiança, não por maioria simples. Se dois modelos dão “supported” com 70% de confiança e um dá “mixed” com 95%, o “mixed” pesa mais. Quanto mais distante a discordância, maior a penalização na confiança final. Se um modelo começa a dar respostas inconsistentes, ele é colocado em quarentena e os outros dois continuam.

Mas a salvaguarda que eu considero mais importante é o primary source veto. Se uma fonte primária (dado do IBGE, decisão judicial, estudo original) contradiz uma claim, a confiança é capada em 60% e o veredicto é forçado pra “mixed”, mesmo que os 3 LLMs digam “supported”. Dez artigos de jornal repetindo uma afirmação não superam um dado oficial que a contradiz. Na mesma linha, se 5 matérias “confirmam” uma claim mas todas são do mesmo grupo editorial (Folha/UOL, Globo/G1/Valor), o sistema sabe que são a mesma voz e reduz o peso. Volume não substitui independência.

Nada disso torna o sistema perfeito. Mas é categoricamente diferente de colar texto no ChatGPT e perguntar “o que você acha?”.

Os números

Stack: Ruby 4.0.1, Rails 8.1.2, SQLite com WAL mode, Solid Queue (jobs dentro do Puma), Solid Cable (WebSockets), Tailwind CSS v4, Chromium headless via Ferrum CDP, deploy com Kamal pro GitHub Container Registry. AGPL-3.0.

O processo de desenvolvimento

O projeto tem 129 commits em 9 dias de trabalho ativo (11-16 e 25-27 de março). O primeiro dia foi o mais pesado: mais de 60 commits só em 11 de março, começando do zero e chegando num sistema funcional com extração de conteúdo, decomposição de claims, avaliação por LLM, e interface web com live updates via Turbo Streams.

Os commits contam a história. Começou com a fundação:

1e32d5a - Initial Frank Investigator foundation
564eb97 - Add recursive source crawling and RubyLLM scaffold
c8c5357 - Add Brazil source registry and authority connectors
3d30617 - Add U.S. authority profiles, source role modeling, and specialized connectors

Depois vieram os analisadores de desinformação, um por um:

a65fef7 - Add rhetorical fallacy analyzer for detecting narrative manipulation
5dcf99d - Add headline-body divergence detection and headline citation amplification
a113efd - Add smear campaign defense with circular citation and viral volume detection
56d501a - Add media ownership modeling, syndication detection, and independence analysis

A fase de hardening contra ruído e falsos positivos foi a que mais consumiu tempo:

46e4bc5 - Add pre-fetch defenses: URL filtering, circuit breaker, fetch prioritization
168fea1 - Add post-fetch content gate, claim noise filter, and duplicate content skip
b2843d7 - Add paywall detection, pricing noise filter, and ofertas.* host rejection
b1b230d - Rewrite Chromium fetcher with Ferrum CDP for anti-bot evasion

Depois veio a interface, deploy, e os analisadores mais avançados:

c5afcea - Replace custom CSS with Tailwind CSS v4 and rewrite all templates
95a8ec4 - Add Docker deployment with bin/deploy script
ccfacc9 - Add coordinated narrative detection across media outlets
ba3e2f4 - Add 6 new misinformation detection analyzers with cross-analysis
fda984b - Add LLM-generated investigation summary with quality assessment
a4ebe78 - Add contextual gap analysis to detect manipulation through omission

E nos últimos commits, o consenso de 3 modelos simultâneos e otimização de testes:

5cc9c05 - Enable 3-model LLM consensus: Sonnet 4.6, GPT-4.1 Mini, Gemini 2.5 Pro
cdf5fb5 - Batch 5 content analyzers into single LLM call, add anti-hallucination
28c305e - Add WebMock stubs for LLM and web search — tests run in 1.4s (was 540s)

Os testes que rodavam em 9 minutos agora rodam em 1.4 segundo com WebMock stubbing de todas as chamadas de LLM e web search. Isso fez diferença enorme na velocidade de iteração.

Limitações

Fact-checking de notícias é um problema difícil. Um artigo sozinho não contém tudo que é necessário pra uma análise completa. O autor escolheu o que incluir e o que omitir, e essa escolha já é o primeiro nível de manipulação. As fontes citadas dentro do artigo foram selecionadas pelo autor pra sustentar a narrativa dele, não pra dar uma visão equilibrada.

O Frank Investigator não diz o que é verdade e o que é mentira. O resultado é um relatório com pontos fortes e fracos, não um selo de “verdadeiro” ou “falso”. Mesmo com todas as salvaguardas que descrevi acima, a contra-evidência buscada automaticamente pode não ser a mais relevante. As falácias detectadas podem ter falsos positivos. A análise de campanha coordenada depende do que o web search retorna no momento da busca.

Use os relatórios como ponto de partida pra formar sua própria opinião, não como veredicto final.

O projeto é open source, AGPL-3.0. Se quiser contribuir, testar, reportar bugs ou sugerir melhorias: GitHub. Se quiser acompanhar as análises, a newsletter The Makita Chronicles vai ter a seção “Notícias Duvidosas” com resumo e link pro relatório completo de cada investigação.

Até “funciona”, mas esse projeto foi mais pelo exercício. Dito isso, deixa eu contar por que fiz isso.

O problema com o OpenClaw

O OpenClaw é um gateway que conecta canais de mensagem (Telegram, Discord, Slack, WhatsApp, etc.) a provedores de IA (OpenAI, Anthropic, Ollama). Você configura, sobe o servidor, e pode conversar com LLMs direto pelo Telegram ou qualquer outro canal. É um projeto popular e com bastante atividade.

Atividade demais, na verdade.

Eu fiz um clone depth-1 do repositório e rodei um tokei:

Mais de um milhão de linhas de TypeScript. Os 2.799 arquivos de teste parecem bastante em número absoluto, mas proporcionalmente ao tamanho do codebase, a cobertura é baixa. A maior parte do código está em 29 pacotes de um monorepo com 21 extensões.

Fui buscar mais commits pra entender o ritmo de desenvolvimento. Nos 100 commits que consegui puxar, todos caíram em apenas 2 dias (9 e 10 de março). ~50 commits por dia, de 42 contribuidores diferentes. Vibe coding ao extremo.

A conclusão é a que você imagina: volumes enormes de código gerado por IA sendo despejados num repositório a uma velocidade que impossibilita review humano sério. E isso me incomodou o suficiente pra ir investigar mais a fundo.

A auditoria de segurança

Pedi pro Claude fazer uma auditoria de segurança completa no código do OpenClaw. O relatório encontrou:

Sete vulnerabilidades críticas. Deixa eu listar algumas:

• Timing side-channel na comparação de tokens – o safeEqualSecret() faz um return antecipado no type-check, permitindo que um atacante distinga tokens malformados de tokens errados medindo latência.
• eval() no browser tool – execução arbitrária de JavaScript sem sandbox.
• Shell sem allowlist – qualquer tool pode executar qualquer comando no sistema.
• Webhooks do Slack sem verificação de assinatura nenhuma.
• Transcripts e config em texto puro no disco, sem criptografia.
• Sem rate limiting efetivo – IPs podem ser spoofados se o operador configura trusted proxies de forma ampla.

Essas são só as que o Claude encontrou numa varredura automatizada. Provavelmente tem mais.

Eu não vou rodar isso na minha máquina. Nem dentro de um container Docker. Um gateway que recebe webhooks da internet, executa comandos shell, se conecta a APIs de IA com suas chaves, e guarda histórico de conversas, tudo isso com 7 vulnerabilidades críticas conhecidas? Não, obrigado.

Então eu fiz o que qualquer desenvolvedor racional faria: decidi construir o meu.

A primeira tentativa: Claude Code

Comecei do jeito mais direto. Clonei o OpenClaw, apontei o Claude Code pro código, e pedi: “reescreve isso em Rust.”

Não funcionou. O codebase é grande demais. Mais de um milhão de linhas de TypeScript espalhadas em 29 pacotes. O Claude não consegue manter tudo em contexto. O resultado inicial foi muito incompleto: muitos tipos criados mas sem implementação, todo!() por toda parte, boilerplate demais e funcionalidade de menos.

Troquei pro Codex 5.4 pra testar. Mesma coisa: pedi pra analisar e reescrever. Melhorou um pouco em certos aspectos, mas o problema fundamental é o mesmo. Nenhuma IA hoje pega um projeto desse tamanho e reescreve inteiro de uma vez. O contexto não cabe.

A técnica que funciona

O que funciona é ir devagar. Um passo de cada vez.

Pede pro Claude (ou Codex) analisar o código original em etapas. Faz um plano longo detalhando cada feature. Depois implementa uma feature por vez em Rust, com testes, faz commit, e repete. É tedioso, mas é o que produz código que compila e funciona de verdade.

O motivo é simples: o código original é tão massivo que nenhum agente de IA (nem vários em paralelo) consegue manter tudo em contexto ao mesmo tempo. Você precisa decidir o que importa, implementar aquilo, validar, e seguir pro próximo.

E precisa decidir o que cortar. O OpenClaw tem 21 extensões de canal: Google Chat, iMessage, IRC, Teams, Matrix, Mattermost, Nostr, Twitch… Eu não preciso de nenhuma dessas. Mantive os canais mainstream: Web, Telegram, Discord, Slack, Signal, WhatsApp e Email. TTS? Fora. Polls? Fora. WhatsApp Web via Baileys? Fora, uso a Cloud API oficial. São features que adicionam complexidade sem valor proporcional.

Descobrindo o IronClaw

No meio do desenvolvimento, descobri o IronClaw, que se apresenta como “OpenClaw em Rust”. Ótimo, pensei. Vou ver o que eles fizeram.

Clonei o repositório e pedi pro Claude escrever um relatório de comparação. O IronClaw tem coisas boas. Adotei 12 features:

Circuit breaker com retry e backoff exponencial pra resiliência de providers LLM. Detecção de leak de credenciais no output. Cache de respostas LLM com SHA-256 da prompt. Cost tracking com budget guards (aviso em 80%, bloqueio em 100%). Extended thinking pra Claude 3.7+ e o1. MCP client pra tool servers externos. Lifecycle hooks em inbound, tool calls e outbound. Smart model routing que joga queries simples pra modelos mais baratos. Suporte a túneis (cloudflared, ngrok, tailscale). REPL interativo (frankclaw chat). Routines com event triggers além de cron. Job state machine com auto-repair.

Mas o IronClaw depende de PostgreSQL + pgvector, tem sandbox WASM (wasmtime adiciona ~10MB), e é parte do ecossistema NEAR AI. Eu quero um binário único com SQLite embarcado e zero dependências externas.

O que o FrankClaw traz do OpenClaw

O core do OpenClaw está lá: 7 canais de mensagem, multi-provider com failover, agent runtime, sistema de comandos, skills, subagents, browser automation via CDP, bash tool com allowlist, cron jobs, REPL interativo. Mais as 12 features do IronClaw que listei acima.

Mas vários pedaços precisaram ser reescritos de um jeito que o original não fez. A compactação de contexto, por exemplo, usa sliding window com estimativa de tokens, pruning de mensagens e repair automático de tool pairs que ficam órfãos quando o contexto é cortado. O failover entre providers agora é model-aware: se você pede um modelo Claude e o provider da vez é OpenAI, ele pula automaticamente em vez de dar erro. O canvas renderiza SVG, HTML e Markdown com detecção de conflitos de revisão. São coisas que no OpenClaw ou não existiam ou estavam pela metade.

Depois veio a fase de adicionar o que faltava pra paridade. O FrankClaw hoje tem 30+ LLM tools: web_fetch (SSRF-safe com HTML-to-text), web_search (Brave API), file_read/file_write/file_edit (sandboxed no workspace com proteção contra path traversal), pdf_read, image_describe (via modelos de vision), audio_transcribe, sessions_list/sessions_history/sessions_delete, message_send/message_react, cron_list/cron_add/cron_remove, config_get (auto-redação de secrets), agents_list, memory_get/memory_search, mais os browser tools (browser_open, browser_extract, browser_snapshot, browser_click, browser_type, browser_wait, browser_press, browser_sessions, browser_close, browser_aria).

Algumas adições que não existem no OpenClaw original: um sistema de memória/RAG com SQLite FTS5 e embeddings (OpenAI, Gemini, Voyage) que sincroniza arquivos do workspace automaticamente. Uma API compatível com OpenAI (/v1/chat/completions e /v1/models), então qualquer cliente que fala esse protocolo (Cursor, Continue, Open WebUI) pode usar o FrankClaw como backend sem adaptação. Uma TUI em ratatui pra quem prefere terminal. Aprovação interativa de tools destrutivos antes de executar.

Tem coisas menores que fazem diferença na prática. Você pode configurar múltiplas API keys por provider com round-robin e backoff automático, então se uma key estourar o rate limit, a próxima assume. O model catalog já sabe context windows e custos dos modelos OpenAI e Anthropic sem você ter que configurar. Extração de URLs de mensagens tem blocklist de IPs privados contra SSRF. O sistema de comandos aceita directives inline (/think, /model) além de aliases.

Do lado de operação: ACP (Agent Client Protocol) via JSON-RPC 2.0 sobre NDJSON pra quem quer integrar programaticamente. Sistema de plugins com manifests e lifecycle de enable/disable. i18n com 9 locales via FRANKCLAW_LANG. Workspace identity files (SOUL.md, IDENTITY.md) pra definir a personalidade do bot por projeto. Health monitor nos canais com auto-restart. WebSocket com ping keepalive que sobrevive timeouts de proxy e túnel. frankclaw start/stop/status pra quem quer rodar como daemon com PID tracking. E toda a configuração migrou de JSON pra TOML.

Hardening: onde está o diferencial

O relatório de auditoria que rodamos no OpenClaw encontrou 7 vulnerabilidades críticas e 9 high. O FrankClaw resolve todas:

O FrankClaw compila com #![forbid(unsafe_code)] em todos os 13 crates. Zero blocos unsafe.

E a auditoria não parou no OpenClaw. Fizemos uma auditoria por componente em 14 fases comparando cada parte do FrankClaw contra o original: canais, providers, runtime, tools, sessions, crypto, cron, webhooks. Tudo documentado.

Deploy: como instalar

O FrankClaw roda com Docker Compose. Três containers: gateway, Chromium headless (pra browser tools), e Cloudflare tunnel (pra receber webhooks).

1. Clonar e configurar

git clone https://github.com/akitaonrails/frankclaw.git
cd frankclaw
cp .env.docker.example .env.docker

Edite o .env.docker com suas chaves:

# Providers de IA (preencha os que usar)
OPENAI_API_KEY=
ANTHROPIC_API_KEY=

# Canais (preencha os que quiser usar)
TELEGRAM_BOT_TOKEN=         # via @BotFather
WHATSAPP_TOKEN=             # Meta Business Platform
WHATSAPP_PHONE_ID=
WHATSAPP_VERIFY_TOKEN=
DISCORD_BOT_TOKEN=
SLACK_BOT_TOKEN=
SLACK_APP_TOKEN=

# Embedding providers (só se usar memória/RAG)
# GEMINI_API_KEY=
# VOYAGE_API_KEY=

# Opcional: criptografia de sessions (recomendado)
# Gere com: openssl rand -base64 32
FRANKCLAW_MASTER_KEY=

# Opcional: scan de malware em uploads
VIRUSTOTAL_API_KEY=

2. Configurar o gateway

O arquivo frankclaw.toml define agentes, modelos e canais. Use o wizard ou os exemplos:

# Gerar config base com canal web
cargo run -- onboard --channel web

# Ou copiar dos exemplos
ls examples/channels/

Pra cada canal, o CLI tem templates prontos:

cargo run -- config-example --channel telegram
cargo run -- config-example --channel whatsapp

3. Cloudflare Tunnel (pra receber webhooks)

Se você vai usar canais que precisam de webhook (Telegram, Discord, Slack, WhatsApp), precisa de um túnel público. O Docker Compose já inclui o cloudflared:

# Copie suas credenciais do Cloudflare
cp docker/cloudflared/config.yml.example docker/cloudflared/config.yml
cp ~/.cloudflared/<tunnel-id>.json docker/cloudflared/credentials.json
cp ~/.cloudflared/cert.pem docker/cloudflared/cert.pem
# Edite config.yml com seu hostname

4. Subir

docker compose up -d

O gateway sobe na porta 18789 (interna ao Docker). O cloudflared roteia o tráfego externo. O Chromium fica na rede interna pra browser tools.

Pra testar local sem Docker:

cargo run -- chat

Abre o REPL interativo direto no terminal (agora também tem uma TUI em ratatui com dark mode e tabs). Sem gateway, sem webhook. Bom pra validar que o provider de IA está respondendo antes de configurar canais.

Validação

cargo run -- check     # valida config
cargo run -- doctor    # diagnóstico completo
cargo run -- audit     # auditoria de segurança com severity ratings

O audit é o que eu mais gosto. Ele verifica se você tem criptografia habilitada, se as permissões de arquivo estão corretas, se os webhooks têm verificação de assinatura, se o bash tool está em deny-all. Sai com exit code non-zero se encontra problemas críticos, então dá pra colocar no CI.

O processo de desenvolvimento

O projeto tem 178 commits em ~5 dias de trabalho (10-16 de março). Quase 57 mil linhas de Rust em 120 arquivos, organizados em 13 crates.

Os commits contam a história. As primeiras dezenas foram scaffold: estrutura do workspace, tipos básicos, o gateway HTTP/WebSocket, primeira versão dos channel adapters. Código gerado em massa, muita coisa incompleta.

Depois começaram os adapters de canal, um por um:

236aa1c - Minimal Discord channel adapter
fd67017 - Minimal Slack channel adapter
9f51373 - Minimal Signal channel adapter
1052e47 - WhatsApp channel webhook adapter
035f86e - Email channel adapter (IMAP inbound, SMTP outbound)

Quando os canais básicos estavam no lugar, veio a integração do IronClaw num commit grande:

c87ab32 - IronClaw-derived features: circuit breaker, retry, leak detection, cache, cost tracking, extended thinking

E aí veio o hardening. Essa foi a fase que eu mais tive que intervir manualmente, porque o Claude gera código funcional mas não pensa em vetores de ataque sozinho:

db34198 - Prompt injection sanitization, external content wrapping, prompt size limit
5719b34 - Optional VirusTotal malware scanning for file uploads
ccd2b2b - Harden input validation across all user-facing entry points
aa918ee - Optional ai-jail sandbox for bash tool
2d7b1df - Security audit command with severity-rated findings
d12cc97 - 3-tier ToolRiskLevel system replacing binary browser mutation flag
21e0c91 - Timing-safe token comparison in WhatsApp, crypto audit tests
e240c1b - Webhook replay prevention with timestamp verification
876a78c - Gateway & media: SSRF redirect validation, filename hardening

22 commits de security hardening. Mais 10 de auditoria por componente. Cada achado virou um commit com fix.

Depois vieram as auditorias específicas por canal, cada uma descobrindo edge cases diferentes:

43b085f - Discord audit: HELLO timeout, fatal close codes, message chunking
12c7cff - Telegram audit: caption overflow, parse fallback, edit idempotency
f515062 - WhatsApp audit: message type filtering, send error classification
3c42aff - Slack audit: fatal auth errors, send error classification

Browser tools precisaram de atenção extra. Um headless Chrome que recebe URLs de um LLM é um vetor de ataque óbvio:

3217a96 - Browser automation: CDP timeout, SSRF guard, session limits, crash recovery
d98a803 - Gate mutating browser tools behind operator approval
014f56e - Browser screenshot/ARIA tools for accessibility tree inspection

Nos commits mais recentes, o projeto começou a divergir do OpenClaw:

5d73c4d - OpenAI-compatible HTTP API (/v1/chat/completions, /v1/models)
d832c36 - Memory/RAG system with SQLite FTS5, embeddings, and file sync
2b05f47 - Interactive tool approval for mutating/destructive tools
49034eb - Web console: dark mode, 8 tabs, focus mode, tool sidebar
9f51a18 - TUI, Gemini/Voyage embeddings, plugin management, ACP protocol
3c0703b - Config migration from JSON to TOML
eb130ad - Channel health monitor with auto-restart and rate limiting
2c3ea7e - Workspace bootstrap files (SOUL.md, IDENTITY.md) to system prompt
9df61bf - Model-aware failover routing, canvas SVG rendering
c7ba108 - WebSocket ping keepalive and auto-reconnect to web console

A API compatível com OpenAI é a que eu mais uso no dia a dia. Cursor, Continue, Open WebUI, qualquer coisa que fala o protocolo OpenAI consegue usar o FrankClaw como backend sem mexer em nada do lado do cliente.

Os números

Comparado ao OpenClaw:

Os números não são diretamente comparáveis. O OpenClaw tem 21 extensões de canal que eu cortei, uma UI web mais completa, e features de nicho que não portei. Mas o core (gateway, canais mainstream, providers, runtime, sessions, tools, memória) está lá com 22x menos código.

Como ajudar (beta testing)

O FrankClaw funciona pra conversa básica via Web e Telegram (testei ambos). WhatsApp funciona pra mensagens simples. Discord, Slack, Signal e Email estão implementados mas não tiveram teste extensivo. Não fizemos nenhum workflow complicado ainda.

Se você quer testar: clone o repositório, suba com Docker Compose, configure pelo menos um canal (Telegram é o mais fácil) e tente usar normalmente. Mande mensagens, teste tool calls, tente quebrar o sistema. Abra Issues no GitHub com o que encontrar.

O que eu sei que precisa de mais olhos: workflows com tools (browser, bash, MCP), subagent orchestration, failover entre providers, session persistence com criptografia, smart routing entre modelos, scheduled jobs, o sistema de memória/RAG, e a API OpenAI-compatible. Basicamente tudo que vai além de “manda mensagem, recebe resposta”.

Não precisa ser desenvolvedor Rust. O valor maior está em usar o sistema de formas que eu não pensei e encontrar os edge cases que só aparecem com uso real.

O FrankClaw não substitui o OpenClaw hoje. O OpenClaw tem mais canais, mais features, mais gente trabalhando nele. Mas carrega o peso de mais de um milhão de linhas de TypeScript geradas a 50 commits por dia por dezenas de contribuidores, com vulnerabilidades críticas documentadas. O FrankClaw é a alternativa pra quem olha pra isso e pensa “eu não vou rodar esse código na minha máquina”.

Mas vou ser honesto: apesar de ter sido divertido construir, eu pessoalmente não sei se preciso disso. O FrankClaw é um gateway genérico, feito pra ser flexível, conectar qualquer canal a qualquer provider, com runtime de agentes, tools, subagents, jobs, hooks. É muita infraestrutura.

O que eu descobri nos últimos meses é que eu consigo construir bots customizados pra tarefas específicas muito mais rápido. Em 1 dia eu tenho um bot funcionando, focado no que eu preciso, sem carregar o peso de um framework genérico. Foi o que eu fiz com o Marvin no projeto da newsletter, por exemplo. Um bot de Discord feito sob medida, que faz exatamente o que eu preciso e nada mais.

Um gateway genérico como o FrankClaw faz mais sentido pra quem quer uma interface unificada entre vários canais de chat e vários modelos de IA sem programar. Se esse é o seu caso, experimenta. Se você é desenvolvedor e sabe o que quer, talvez um bot customizado te sirva melhor. Fica a seu critério.

O repositório está aqui. AGPL-3.0.