Faltava uma categoria que eu nunca tinha testado direito: os modelos open source grandes. Os que cabem na minha RTX 5090 de 32 GB ou no meu Strix Halo com 61 GB utilizáveis pela GPU são fracos demais pra isso. Servem pra tarefa simples de agente, e nenhum modelo pequeno aguenta tarefa real de programação, muito menos um projeto complexo de software.

O Qwen 3.8 27B levou 706 minutos pra fechar o v4 no Strix e fez 80; o GLM-4.7-Flash local fez 24. Então nem tente.

Mas e se a gente forçar? O que modelos de tamanho médio, de 100 a 400 bilhões de parâmetros, conseguem fazer rodando numa única B300 alugada? Eu podia alugar quatro delas e rodar os modelos gigantes de 750 bilhões ou um trilhão, e não tenho certeza de que o custo-benefício vale. Os dados abaixo respondem.

TL;DR: 14 modelos abertos, uma B300 de 288 GB na Runpod a uns 9 dólares por hora, mesmo protocolo v4 de sabotagem. Nenhum deles serve rápido do jeito que vem: o GLM 5.3 Flash decodificava a 10 tokens por segundo com a configuração padrão e a 141 depois de ajustado, 14 vezes mais só de flag. Dois modelos abertos, GLM 5.3 Flash e Qwen3.8 Flash-Next, fizeram 92,5, nível Claude Sonnet 5, e o Swift 1.5 27B fez 88, nível Opus 4.6. Nenhum chegou nos 100 da fronteira. O flagship de 397 bilhões fez 68,5 e deixou passar uma backdoor de admin, o DeepSeek V4 Flash fez 86 na nuvem e 44,5 servido por mim, e o Nemotron trapaceou num teste de regressão. A API em nuvem do mesmo modelo custa um dólar por rodada; o pod custa 218 dólares por dia. Pule pra B300 e Runpod, pro ajuste de servidor, pro ranking, pros casos interessantes, pra comparação com a fronteira, pra conta ou pra conclusão.

O que é uma B300, e o que é a Runpod

A B300 é a GPU de datacenter da geração Blackwell Ultra da NVIDIA, anunciada em março de 2025. Cada placa tem 288 GB de memória HBM3e, nove vezes a minha 5090, e uns 15 petaflops de computação densa em NVFP4, o formato de 4 bits que a Blackwell faz em hardware. É a placa que vai dentro do rack GB300 NVL72, 72 delas interligadas, que as empresas de IA compram aos milhares.

Sozinha, uma B300 custa mais que um apartamento. O que a torna acessível é alugar por hora.

A Runpod é um provedor de GPU em nuvem que aluga placas em “pods”, containers Linux com uma ou mais GPUs, cobrados por segundo. Você escolhe a placa, um template de imagem, sobe por SSH, e paga enquanto o pod está ligado, inclusive ocioso. A B300 custava uns 9 dólares por hora na nuvem segura deles na semana do teste; uma H100 sai por 3 a 4. O disco do container é efêmero: terminou o pod, os 250 GB de pesos que você baixou somem, e você baixa de novo.

O pod que eu usei: uma B300 com 275 GiB segundo o nvidia-smi (os mesmos 288 GB nominais, em unidades binárias), 344 vCPUs, 4 TB de RAM no host, 700 GB de disco. O servidor de inferência foi o vLLM; o harness foi o mesmo OpenCode de todos os outros modelos do ranking, conectado por túnel SSH ao pod. O modelo roda lá; o código, os testes e os resultados ficam na minha máquina.

Caber na memória é a primeira peneira. Na B300 cabem os modelos de 100 a 400 bilhões de parâmetros quantizados em NVFP4, mais os de 27 a 35 bilhões em BF16. Ficam de fora o GLM 5.3 flagship de 753 bilhões, o DeepSeek V4.1 Flash de 750, o DeepSeek V4 Pro de 1,6 trilhão e o Kimi K3 de 2,8 trilhões. Pra esses, seriam quatro B300 ou mais, uns 36 dólares por hora.

A metodologia

O protocolo é o v4 de sempre: o modelo constrói um app Rails em sete sprints acumulados, e entre os sprints um revisor independente, isolado do modelo, injeta 14 sabotagens, de CVE real a regressão silenciosa de lógica e de teste, no código que o próprio modelo escreveu. A nota de 0 a 100 mede vigilância: quanto o modelo pega e conserta sem ser avisado (peso cheio), quanto conserta depois de um “faça uma auditoria de segurança” explícito no último sprint (40% do peso), e o que fica sem resolver (zero). Os tiers são A a partir de 83, B de 73 a 82, C de 51 a 72, D até 50.

Duas diferenças nesta rodada. A primeira é o revisor: os cinco modelos que terminaram antes do bloqueio foram revisados de ponta a ponta pelo Codex, como nas rodadas anteriores.

No meio da leva o serviço de segurança da OpenAI passou a recusar a operação de injeção e correção, com uma flag de risco cibernético, mesmo sendo código meu, em máquina minha, num benchmark com 46 modelos já pontuados pelo mesmo protocolo. Troquei o revisor pro Claude Opus 4.8 nos modelos restantes, com o mesmo plano de injeção, mesmo catálogo, mesma régua, e a proveniência de cada fronteira está gravada por sprint. O impacto esperado na nota é nenhum, porque os dois executam a mesma receita escrita.

A segunda é a admissão por velocidade, que é o assunto da próxima seção. Modelo que decodifica abaixo de 100 tokens por segundo nem entra na pista.

Além disso: o modelo aberto tem direito a até dois empurrões curtos por rodada pra defeito bobo (um import faltando, um ponto de entrada de teste errado), registrados como “assistido”. Falha de infraestrutura, driver, loader, parser, nunca é cobrada do modelo. E o pod rodava um modelo por vez, sem acesso ao workspace ou ao resultado de nenhum outro.

Nenhum deles serve rápido do jeito que vem

A primeira lição custou um dia. Baixei o GLM 5.3 Flash, 320 bilhões de parâmetros com 18 ativos, quantizado em NVFP4, 198 GB. Subi no vLLM com a configuração que “funciona”: serve, passa nos testes de chamada de ferramenta, responde. E decodificava a 10 tokens por segundo, com a GPU a 10% de uso, 209 watts dos 1.100 que o pod libera.

Isso é inutilizável pra programar. Um agente de código gera dezenas de milhares de tokens por sprint; a 10 por segundo, um sprint de 20 minutos vira mais de quatro horas.

O mesmo checkpoint, mesmo contexto de 128 mil tokens, mesmo cache de KV em FP8, mesmo prompt de teste, trocando só as flags de compilação e modo: 141 tokens por segundo. Catorze vezes mais rápido, zero mudança de precisão ou de pesos.

O culpado principal era o --enforce-eager, que desliga o torch.compile e a captura de CUDA graphs do vLLM, e que todo tutorial manda ligar “pra subir mais rápido”. Sobe mais rápido e serve 14 vezes mais devagar. A medição trocou essa flag junto com o modo interactivity, então eu não isolei a contribuição de cada uma.

Daí a regra de admissão: menos de 100 tokens por segundo eu considero inutilizável, e nenhum modelo entra no benchmark sem passar disso na mediana de duas sondagens quentes de 256 tokens, depois de uma fria. Pra não virar um buraco sem fundo, o ajuste é limitado: no máximo três configurações e 45 minutos de relógio por modelo, incluindo carga e compilação. E ajuste nunca pode trocar qualidade por velocidade: nada de encurtar contexto, baixar esforço de raciocínio ou quantizar mais pra bater o número.

Os ajustes que valeram pra todo mundo:

• Instalar um CUDA que compile pra placa. A imagem padrão da Runpod vem com CUDA 12.8, cujo nvcc não compila pra compute_103a, a capacidade de computação da B300. Sem o 12.9, os kernels NVFP4 nunca compilam.
• Nunca usar --enforce-eager. Deixar o vLLM compilar e capturar CUDA graphs é a maior vitória isolada.
• --performance-mode interactivity: otimizar pra latência de um fluxo só, que é o que um agente serial precisa, em vez de vazão agregada.
• Cache de KV em FP8 nos MoE grandes, cache de prefixo e prefill em pedaços em todos, e confirmados pelos contadores do Prometheus do vLLM em vez de assumidos: num prompt de 11 mil tokens, o servidor reaproveitou exatamente 8.576 tokens de prefixo a cada repetição.
• O parser certo de ferramenta e de raciocínio pra cada família. Parser errado faz chamada de ferramenta sumir em silêncio ou vazar o raciocínio na resposta.

E os ajustes específicos que achei mais interessantes:

• NVFP4 só roda no vLLM. Os checkpoints de 198 a 251 GB em FP4 nativo da Blackwell são a única forma de caber na placa, e llama.cpp e Ollama simplesmente não carregam esses formatos. Quem vive de GGUF não tem acesso a essa faixa.
• Decodificação especulativa nativa. O Qwen 3.8 27B foi de 92 pra 195 tokens por segundo com a cabeça MTP que o próprio checkpoint traz, prevendo três tokens por passo, mais --language-model-only pra descartar a torre de visão (medido em pods diferentes, então sem ablação controlada). O Muse Glimmer chegou a 295 com o rascunhador DFlash leve que ele publica junto, 15 tokens especulados por passo. Só liguei onde existe um rascunhador oficial e onde a chamada de ferramenta continuou correta; pro Ornith existe um rascunhador publicado à parte, com taxa de aceitação desconhecida, então ficou desligado.
• O loader do CUDA 12. O flashinfer compila em JIT um kernel de MoE em NVFP4 que precisa do libcudart.so.12, e depois de instalar o CUDA 13 pro Nemotron a resolução de biblioteca quebrou. O sintoma parecia OOM; a causa era um ld.so.conf. Um script de reparo com evidência de ldd antes e depois resolveu, e o 397B passou a servir a 144 tokens por segundo.
• Um ambiente virtual por runtime. O Nemotron 3.5 Super VL exigiu um vLLM 0.32 próprio num venv separado, porque é o que o card oficial fixa, e esse build pede CUDA 13. Cada família de modelo é um caso bespoke: parser, quantização, cabeça de rascunho, versão de runtime e reparo de loader, tudo diferente.
• Um bug de parser que derrubava a última chamada. O parser de ferramenta Qwen do vLLM descartava o último parâmetro de uma chamada quando faltava a tag de fechamento do parâmetro mas a de função estava presente. Um reparo estreito, com 24 casos de teste, tirou esse ruído de serving da conta do modelo.

Os argumentos exatos de cada modelo, os logs de sondagem e o livro-razão de cada rodada de ajuste estão no documento de otimizações de serving e no runbook da B300 do repositório.

A velocidade é quase de graça, depois que você deixa o vLLM compilar. O trabalho real é descobrir, modelo por modelo, qual combinação de toolkit, parser, quantização e cabeça de rascunho aquele checkpoint exige. Eu dei 45 minutos pra cada um e precisei deles.

O ranking

Nota v4 de vigilância, tier, tamanho em memória, velocidade de decodificação na sondagem de admissão (quente, um fluxo só) e o custo só do tempo de inferência dos sete sprints, a 9,09 dólares por hora. O custo exclui download, carga, compilação, ajuste e tempo ocioso; a conta de verdade vem mais abaixo.

Três não têm nota: o Command A Plus da Cohere (218 bilhões, 25 ativos, W4A4) travou num loop reescrevendo o mesmo model 23 vezes, precisou de três empurrões e ainda deixou os testes sem rodar antes de o revisor ser bloqueado; o Nex N2.5 Mini rodou a 337 tokens por segundo e entregou Ruby inválido, migrations contraditórias e autenticação quebrada em duas tentativas, um resultado ruim válido de um servidor que funciona; e o Qwen3.5 122B era reserva condicional pro caso de o 397B não terminar, e o 397B terminou.

Os minutos são só de sprint, e os de Ornith incluem um sprint interrompido por infra. Flash-Next, Swift, ThinkingCap, Muse e Qwen 27B levaram um empurrão cada; GLM 4.7, dois; os outros, nenhum. A velocidade de sondagem é um número de admissão: a vazão de uma sessão real de código inclui prefill, ferramentas, testes e as escolhas do agente. E repare que os dois primeiros empatam na nota com perfis opostos: o GLM gastou 145 minutos e 22 dólares pra chegar nos mesmos 92,5 que o Qwen3.8 Flash-Next fez em 80 minutos e 12 dólares, com metade da memória.

Os casos interessantes

Qwen3.8 Flash-Next: o melhor dos abertos, por custo

O Flash-Next é, nas palavras da Qwen, uma prévia da arquitetura do Qwen 4: 125 bilhões de parâmetros de modelo de linguagem com 6 bilhões ativos, mais uma tabela de embeddings de n-gramas de 51 bilhões que a Qwen diz que pode ser descarregada pra memória do host, mais uma cabeça MTP de 4. Quantizado em NVFP4 pela NVIDIA, ocupou uns 100 GB de placa (o checkpoint tem 133 GB em disco). Foi o único modelo da segunda leva a resolver todos os 14 itens: pegou o vazamento entre tenants sem aviso, pegou o item composto de integridade de teste, e escreveu por conta própria specs de isolamento por usuário, de modo que a IDOR plantada na API nem tinha como continuar verde. Com 195 tokens por segundo e 12 dólares de inferência, é o melhor custo-benefício desta tabela.

GLM 5.3 Flash: o mesmo 92,5, três vezes mais caro

O GLM fez a mesma nota com uma arquitetura bem maior: 320 bilhões de parâmetros, 18 ativos, 198 GB mesmo em FP4. Resolveu os 14 itens, zero empurrão, revisado de ponta a ponta pelo Codex.

Só que levou 145 minutos e consumiu o dobro da memória pelo mesmo resultado. Na nuvem da Z.ai, o mesmo modelo fez 84,25 num plano fixo. Com o ruído de uma rodada só, que no meu histórico chega a nove pontos, a leitura mais segura é que os dois estão na mesma faixa.

Swift 1.5 e ThinkingCap: dois fine-tunes de 27B no Tier A

As duas surpresas. O Swift 1.5, da UkisAI, e o ThinkingCap 3.8, da BottleCap AI, são ajustes do Qwen 3.8 27B treinados pra pensar menos: o Swift anuncia até 58% menos tokens de raciocínio (na mediana do GPQA; no Terminal-Bench, 16%), o ThinkingCap uns 37% na média. Os dois cabem em 56 GB em BF16, rodam a uns 200 tokens por segundo com MTP, e fizeram 88 e 83.

O Swift ficou acima do Opus 4.6 da Anthropic. O Qwen 3.8 27B base, mesma arquitetura, fez 80,5 com 192 minutos; o Swift fez 88 em 64. O Swift pegou sabotagem mais cedo que o base; se foi por pensar menos, uma rodada de cada deixa de provar.

Uma ressalva de proveniência: o revisor registrou que o Swift leu mensagens de commit locais que revelavam regressões, o que enfraquece uma leitura literal de “descoberta totalmente sem ajuda”. E ele deixou um item sem resolver, um admin inativo ainda aceito com um teste vazio de guarda. Ainda assim, de todos os modelos desta tabela, é o que eu colocaria numa placa minha.

Qwen3.5 397B: o flagship que deixou passar a backdoor

O maior modelo da leva, 397 bilhões de parâmetros com 17 ativos, 251 GB de NVFP4 em 275 de placa, serviu a 140 tokens por segundo depois do reparo do loader e fez 68,5, Tier C.

O caso que define a nota: a sabotagem número 6 é uma linha admin? => admin || email.end_with?("@internal.example"), uma escalação de privilégio por domínio de e-mail. O 397B deixou passar nos sprints normais, deixou passar no sprint 7 com o pedido explícito de auditoria de segurança, e escreveu um teste que passava, codificando a backdoor como comportamento esperado, no mesmo commit em que anunciou “Brakeman: 0 warnings”. Parâmetro não comprou vigilância.

Nemotron 3.5 Super VL: trapaceou no teste

O Nemotron 3.5 Super VL da NVIDIA, 120 bilhões com 12 ativos, lançado dois dias antes de eu começar a testar e vendido pela NVIDIA como o modelo aberto de agente mais rápido da categoria, com “acurácia líder” em tarefas multimodais, fez 63. A sabotagem número 2 remove um link de navegação e o teste de regressão procura have_link('Sign in'). O Nemotron trocou o teste pra have_button('Sign in'), que passa no botão do formulário de login sem restaurar o link, e manteve a trapaça mesmo depois do sprint de revelação.

Também tende a pegar item um sprint atrasado. E foi o que exigiu um runtime próprio: vLLM 0.32 com CUDA 13 num ambiente separado.

DeepSeek V4 Flash: 86 na nuvem, 44,5 na minha mão

O caso mais importante pra quem pensa em self-host. O DeepSeek V4 Flash, 284 bilhões com 13 ativos, fez 86, Tier A, por 97 centavos pela API em setembro, e a versão 0731, exatamente a que eu baixei, fez 85 por 1,94. Os mesmos pesos públicos em FP4 e FP8 misto, servidos por mim na B300, fizeram 44,5, Tier D: pegou 4 itens sem aviso, mais 5 na revelação, e deixou 5 sem resolver. Foi o mais rápido a terminar, 37 minutos, e o que menos vigiou.

A causa provável é divergência entre o checkpoint público e o que a DeepSeek serve, ou entre o stack de serving deles e o meu: parser, template de chat, modo de raciocínio, quantização. Eu segui o card oficial. O que isso prova é que o nome do modelo no Hugging Face não garante a qualidade da API hospedada, e que quem vai hospedar precisa validar antes de confiar.

GLM 4.7 Flash: igual ao local, ou seja, ruim

O GLM 4.7 Flash de 30 bilhões em BF16, a 217 tokens por segundo, fez 33,5. Em casa, em GGUF Q5, tinha feito 24. Precisou de dois empurrões, deixou nove itens sem resolver e entregou uma migration com erro de sintaxe. A diferença de nove pontos e meio cabe dentro do ruído de uma rodada; o que fica é que o modelo é fraco de qualquer jeito.

O que apareceu em vários

Ornith, Muse Glimmer e o 397B compartilharam um defeito de higiene: rodaram o sprint até o fim com exit zero e esqueceram de commitar o próprio trabalho, deixando pro revisor fazer o checkpoint. Não entrou na nota, e num time de verdade seria o primeiro motivo de reclamação. E o aglomerado de 81 a 83, ThinkingCap, Ornith e Muse, tem um perfil consistente: pega injeção de SQL, vazamento entre tenants, XSS e segredo exposto com confiança, e deixa passar os itens silenciosos, controle de acesso quebrado, integridade de teste, índice faltando, agregação errada.

A que distância da fronteira

Os três melhores abertos contra os melhores comerciais do mesmo ranking, com o custo e o tempo de cada rodada:

A leitura: o melhor do open source que cabe numa B300 e que eu servi está um degrau abaixo do teto comercial e no mesmo nível do meio do Tier A. Diferenças de um ou dois pontos são ruído de uma rodada.

GLM 5.3 Flash e Qwen3.8 Flash-Next empatam com o Sonnet 5 e passam o Gemini 3.8 Flash e o Opus 4.6. Nenhum chega nos 100 que sete modelos comerciais fizeram, nem nos 98,5 do Grok 4.6. Sete pontos e meio separam o melhor aberto do teto, e no v4 cada ponto é uma sabotagem a menos pega sem aviso.

A diferença que importa é outra: previsibilidade. Entre os comerciais de ponta da tabela, o pior é 87,5, e o campo comercial inteiro também tem fundo de poço, o Mistral Large 3 fez 39. O campo aberto tem os mesmos 92,5 no topo e dois Tier D no fundo, com o DeepSeek fazendo 85 na nuvem e 44,5 na minha mão. Escolher um comercial de ponta é escolher um número que a API reproduz; escolher um aberto é apostar que o checkpoint, a quantização e o seu stack de serving reproduzem o número do card, e às vezes reproduzem.

A conta

Se a qualidade ainda fica abaixo da fronteira, o custo pelo menos é proporcional? Depende de onde você roda o modelo aberto.

Na API em nuvem do próprio fornecedor, sim, e com folga. Uma rodada completa do v4 custou 97 centavos no DeepSeek V4 Flash, 1,17 dólar no Qwen 3.8 Flash, 1,03 no MiMo V2.5 Pro, todos Tier A na nuvem. Contra 9,52 a 30,55 dólares dos modelos de 100 pontos, é dez a trinta vezes mais barato por uma nota 8 a 14 pontos menor. Os preços de lista explicam: o GLM 5.3 Flash custa 15 centavos por milhão de tokens de entrada e 50 de saída; o DeepSeek Flash, 15 a 30 centavos de entrada e 60 centavos a 1,20 de saída; o Opus 5.5, 4 e 20 dólares; o GPT-6 Astra, 10 e 50.

Na sua própria B300 alugada, não. O pod custa 9 dólares por hora ligado ou ocioso, 218 por dia, uns 6.500 por mês. O tempo de modelo desta leva inteira, 14 modelos entre download, carga e sprints, somou 23 horas, uns 212 dólares a preço de pod; só os sprints foram 17 horas e 157 dólares.

Só que o pod cobra também o tempo em que nada roda. Eu coloquei 400 dólares de crédito na Runpod e sobraram 127: a leva inteira custou 273 dólares, umas 30 horas de pod, incluindo armazenamento, quatro pods em sequência e sete horas ociosas numa madrugada em que a orquestração morreu e nada avisou. Quase 60 dólares a mais que o tempo de modelo, só de espera. A conta de ponto de equilíbrio do repositório: o pod só fica mais barato que a API a partir de umas 6.500 rodadas por mês, 217 por dia, sustentadas. Um desenvolvedor sozinho ou um time pequeno nem chega perto.

E modelo contra modelo, lado a lado:

A API em nuvem de um modelo aberto é dez a trinta vezes mais barata que a fronteira por um tier a menos. Hospedar o mesmo modelo numa B300 alugada é mais caro que a fronteira, e às vezes pior que a própria API dele.

Cabe um time na mesma placa?

Uma pergunta que eu fiz olhando a GPU a 10% de uso: esses modelos usam toda a computação do pod? Dava pra colocar um time inteiro na mesma B300?

Em princípio, sim, e é pra isso que o vLLM existe. O batching contínuo agenda várias requisições no mesmo passo de decodificação, e o PagedAttention guarda o cache de KV de cada sessão em blocos não contíguos, com menos de 4% de desperdício, justamente pra caber mais sessões na mesma memória. Um modelo de 27 bilhões em BF16 ocupa 56 GB e deixa uns 200 GB de cache de KV: são dezenas de sessões de agente com contexto de 128 mil tokens ao mesmo tempo. O 397B, com 251 GB de pesos, deixa 24, e aí cabem poucas.

O que não escala é a velocidade por pessoa. O meu teste rodou em --performance-mode interactivity, que otimiza a latência de um fluxo só, e os 200 tokens por segundo são desse fluxo. Com dez agentes decodificando ao mesmo tempo, a vazão agregada da placa sobe e a de cada um cai, e a decodificação especulativa que me deu os 295 do Muse Glimmer rende menos conforme a concorrência cresce: um rascunhador DFlash publicado pro Muse pelo Z Lab reporta 3 a 4,6 vezes de ganho com uma sessão e 1,2 a 1,7 com 32.

Eu não medi concorrência nesta leva, então o que posso dizer é o contorno: um time de cinco a dez pessoas num modelo de 27 a 35 bilhões numa B300 é prático, e provavelmente cada um ainda fica acima dos 100 tokens por segundo. O mesmo time no 397B é inviável na placa, e no GLM 5.3 Flash de 198 GB fica apertado.

É nesse cenário, e só nele, que a conta do pod começa a fechar. Dez desenvolvedores rodando agente o dia inteiro num modelo de 27B gastariam na API, a um dólar por rodada de duas horas, uns 40 dólares por dia; o pod custa 218. Ainda perde. O que muda a conta é ter cem pessoas, ou ter a obrigação de que o código não saia da sua rede.

Vale a pena ter a própria infra?

Pra desenvolvimento de software sério, com os dados desta leva, a resposta vem em três partes.

Os modelos abertos de ponta são bons o suficiente. GLM 5.3 Flash, Qwen3.8 Flash-Next e Swift 1.5 27B são Tier A no meu teste, no nível do Sonnet 5 e acima do Opus 4.6. Isso era impensável em abril, quando só o Qwen 3.6 35B chegava perto do Opus, e ainda a uma correção de distância. Pra quem aceita um tier abaixo do teto, eles servem pra trabalho de verdade, inclusive revisão de segurança, que é o que o v4 mede.

Alugar uma B300 pra rodar eles é o jeito errado de usá-los. A API em nuvem do mesmo modelo custa um dólar por rodada e precisa de zero configuração. O pod custa 218 por dia, exige um dia de ajuste por família de modelo, e no caso do DeepSeek entregou um modelo pior do que a API dele. Só vale com uma obrigação de residência de dados, com um checkpoint que nenhuma nuvem serve, com carga sustentada de centenas de rodadas por dia, ou com necessidade de pesos fixados pra reprodutibilidade. Quatro B300 pra rodar os de 750 bilhões a um trilhão quadruplicam a conta sem evidência de que a nota chega nos 100: o 397B, maior modelo que eu testei, fez 68,5.

E se for pra hospedar, hospede pequeno. O Swift 1.5 27B e o ThinkingCap em 56 GB, com MTP, a 200 tokens por segundo, são Tier A em hardware que dá pra comprar, uma placa profissional de 80 ou 96 GB em vez de uma de datacenter. É ali que o open source faz sentido pra uma empresa: um time inteiro numa placa, código dentro da rede, nota de Opus 4.6. Só olhe a licença antes: o Swift e o ThinkingCap saem com licenças próprias, e acima de um certo faturamento os dois exigem licença comercial. Os gigantes abertos continuam sendo coisa pra API.

Minha regra depois disso tudo: modelo comercial de ponta pra tarefa que não pode errar, API de modelo aberto pra volume, e placa própria só quando a lei ou o cliente exigem. O repositório com cada argumento de serving, cada log de sondagem, cada transcrição de revisor e a proveniência Codex ou Claude de cada fronteira está público, como sempre.

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.

Embaixo dessa história toda tem uma decisão que quase ninguém faz conscientemente: o filesystem. O Synology usava btrfs o tempo todo. O QNAP usa ZFS. E a sua máquina Linux, muito provavelmente, veio de fábrica com ext4 sem ninguém te perguntar nada. É sobre isso.

De onde vieram os dois

O ext4 é o final de uma dinastia de mais de três décadas. O ext (extended filesystem) nasceu com o próprio Linux, o ext2 virou padrão nos anos 90, o ext3 adicionou journal em 2001 pra não precisar de fsck épico depois de cada queda de energia, e o ext4 chegou em 2008 com extents, alocação atrasada e volumes de até 1 exbibyte. O objetivo de design sempre foi o mesmo: ser o filesystem padrão, rápido, simples e previsível. Ele é excelente nisso. E parou aí.

O btrfs nasceu em 2007, na Oracle, com o Chris Mason, com um objetivo completamente diferente: ser a resposta do Linux ao ZFS. Em vez de escrever dado por cima de dado, ele é copy-on-write: toda escrita vai pra um bloco novo e os ponteiros são atualizados em cascata na árvore. Essa decisão única é a mãe de tudo que interessa nele.

O que cada um entrega, na lista:

ext4:

• journaling (metadados consistentes depois de queda)
• extents e alocação atrasada (boa performance)
• maduro, estável, em todo lugar, qualquer ferramenta funciona

btrfs:

• copy-on-write em tudo
• checksum de dados e metadados em cada bloco
• snapshots instantâneos e baratos
• subvolumes independentes dentro do mesmo volume
• compressão transparente (zstd, lzo, zlib)
• RAID nativo e scrub (varredura de verificação)
• send/receive de snapshots pra backup incremental
• reflinks (cópias que não duplicam blocos)

A lista já responde a pergunta do título. Vamos por partes.

Até o NTFS e o APFS passaram o ext4

E se a comparação com o btrfs parece injusta, olha pro lado. O NTFS nasceu em 1993, com o Windows NT, já com journaling de metadados e ACLs, e ainda nos anos 2000 ganhou o log de todas as mudanças do volume e as cópias de sombra (o “Versões Anteriores” do Windows). O APFS, que a Apple lançou em 2017 feito pra flash, é copy-on-write como o btrfs: snapshots nativos (é o que o Time Machine usa pra restauração local), clones instantâneos de arquivo que compartilham blocos, volumes compartilhando o espaço do mesmo container e criptografia por arquivo.

Leia de novo a lista do ext4 e compare: sem snapshot, sem checksum de dados, sem CoW, sem compressão. O filesystem do Windows e o do Mac, que ninguém considera exemplos de sofisticação, protegem os seus dados melhor que o padrão do Linux, cuja última grande feature saiu em 2008. O btrfs é o que coloca o Linux na mesma geração dos outros dois, e não uma década atrás.

Por que o btrfs é muito superior

O que é copy-on-write, pra quem nunca parou pra pensar

Nos filesystems clássicos, a escrita é destrutiva por definição: atualizar um bloco significa gravar o conteúdo novo por cima do velho, no mesmo lugar do disco. Se a máquina morre no meio da escrita, o arquivo fica metade velho, metade novo. O journal do ext3/ext4 cobre isso para os metadados (a estrutura de diretórios não corrompe), mas o seu dado em si fica por conta da sorte.

Copy-on-write inverte a ordem: nada nunca é sobrescrito. Escrever num arquivo aloca um bloco novo, grava o conteúdo novo ali, e só quando está tudo seguro no disco o filesystem troca os ponteiros pra versão nova, de forma atômica. A qualquer instante, você tem ou a versão velha inteira ou a versão nova inteira. Nunca uma mistura das duas.

O que isso compra na prática:

• Snapshots quase de graça. Os blocos velhos já persistem por natureza do CoW; um snapshot é só o filesystem segurando o ponteiro de raiz daquele instante, pura contabilidade.
• Queda de energia não corrompe. Uma escrita interrompida deixa a versão anterior intacta, porque ela nunca foi tocada. Pra quem já perdeu imagem de VM ou banco de dados pra queda no meio da escrita, isso vale o filesystem inteiro.
• Verificação possível. Como cada bloco é escrito uma vez e nunca mexido, faz sentido guardar checksum dele pra sempre. É a base da proteção contra corrupção que detalho mais abaixo.

O custo existe e eu pago ele sabendo: arquivos de escrita aleatória intensa (disco de VM, banco de dados) fragmentam e duplicam bloco, porque cada reescrita vira um bloco novo. Pra esses casos se desliga o CoW por diretório com chattr +C, que precisa ser marcado antes do arquivo ser criado. No meu layout, a imagem de VM feita com o +C certo ficou saudável; a feita sem virou o caso de fragmentação de livro-texto.

Snapshots são a feature que muda a sua vida

Snapshot no btrfs é uma foto instantânea de um subvolume, e custa quase nada, porque o CoW já mantém os blocos velhos enquanto alguém referencia eles. Criar um snapshot é operação de segundo, não de horas. Na prática: antes de cada upgrade, o sistema tira uma foto. Se o upgrade quebrar, você não “desinstala pacote”: você boota de volta na foto anterior e pronto. A seção de recuperação de boot, mais abaixo, mostra isso acontecendo de verdade.

Subvolumes são o jeito certo de organizar o disco

Subvolume é um namespace independente dentro do mesmo filesystem, com política própria de snapshot. E tem uma propriedade matadora: snapshot não é recursivo. Um subvolume filho dentro de outro fica automaticamente de fora do snapshot do pai.

Eu uso isso pra tudo. No meu desktop, os diretórios de cache que dá pra baixar de novo (mise, rustup, npm, opencode, caches de IA) estão virando subvolumes aninhados dentro do @home: ficam no mesmo lugar pra qualquer programa, mas de fora de qualquer snapshot. Só essa separação tira 165 GiB de escopo de snapshot, e os caches grandes (Hugging Face, yay, uv, pip) já moram fora do volume do sistema, com symlinks apontando pra eles: menos 148 GiB de snapshot, parte já migrada e parte em andamento. O snapshot fica pequeno, o restore fica rápido, e o que pode ser rebaixado da internet nunca entra na foto.

O custo real, medido no QNAP novo (ZFS, mas a matemática de CoW é a mesma): 27 snapshots de hora em hora de uma pasta com quase 80 TB, e quase todos consomem megabytes, porque entre uma hora e outra quase nada mudou. Snapshot barato é o que permite essa rotina existir sem culpa.

Deduplicação por reflink

Antes, a ressalva que importa: o btrfs não tem deduplicação online nativa igual ao ZFS (que mantém uma tabela de dedup em RAM e cobra caro por isso). O que ele tem são duas coisas práticas: reflink e dedup offline. Reflink é cópia que compartilha blocos: cp --reflink=auto cria um arquivo novo que aponta pros mesmos blocos do original, instantâneo e de graça, e cada um passa a divergir só onde for escrito. Na era de dezenas de checkouts, worktrees e builds parecidos, isso economiza uma montanha de blocos. Pra dedup retroativo existem ferramentas de userspace como duperemove e bees.

Proteção contra corrupção de verdade

Todo bloco do btrfs, dado ou metadado, carrega checksum. Quando o filesystem lê e o checksum não bate, ele sabe que o bloco apodreceu, e se houver uma segunda cópia (RAID ou metadata DUP) ele se autocorrige. O ext4 não checa dado nenhum: bit rot passa silencioso até você abrir o arquivo anos depois.

Duas peças da minha configuração mostram o que isso compra na prática, e o que o ext4 simplesmente não oferece. A primeira é o metadado em modo DUP. Num ext4, cada estrutura do volume existe uma vez só: um setor ruim bem posicionado corrompe a tabela de diretórios e o disco inteiro deixa de montar. No btrfs, mesmo com um único disco, todo bloco de metadado existe duplicado. O setor ruim continua existindo, mas o checksum acusa o bloco podre na leitura e a segunda cópia responde no lugar, sem você perceber. É a diferença entre perder o volume e anotar um aviso no log.

A segunda é o scrub mensal. Um ext4 nunca relê nada pra conferir saúde: se um bloco apodrece, você descobre no dia em que alguém tenta abrir aquele arquivo específico, talvez anos depois, quando já não tem conserto. O scrub é uma varredura agendada que relê o volume inteiro validando checksums, e encontra a podridão enquanto ela ainda é pequena e recuperável. Quando o contador do btrfs device stats sai de zero, é a sirene pra trocar o disco antes do desastre, não depois.

Compressão transparente, medida

Todo mount do meu desktop usa compress=zstd:1. O nível 1 custa uns pontos percentuais de um núcleo de CPU, e o btrfs detecta o que não comprime (blob de modelo, vídeo) e grava cru, sem custo. O resultado, medido essa semana nos meus dois discos novos:

São 630 GB de espaço grátis em 2,2 TB: 15% a mais de disco, sem pagar nada. Na migração inicial o ganho foi ainda maior, 45% no volume de sistema, porque havia mais texto e menos binário. Repare nos detalhes da tabela: programas e bibliotecas comprimem bem, camadas de Docker comprimem melhor ainda (39%), log de texto comprime 4,5x, e peso de modelo de IA não comprime nada, o que é esperado e não custa nada. Código-fonte, que é o que mais produzimos na era da IA, comprime lindamente.

Synology usa btrfs, QNAP usa ZFS

Sendo justo com o ZFS: pra NAS grande ele é superior, e foi o que eu escolhi pro QNAP. Checksum e autocorreção nativos, RAIDZ maduro, send/receive excelente. O preço é complexidade e recurso: o ZFS quer RAM pro cache ARC (meu QNAP tem 7 GB pra um pool de 174 TB, e sinto a falta), a deduplicação online dele precisaria de uns 190 GB de RAM só pra tabela no meu volume, e o modelo de provisionamento dele me deu um susto de graça quando o snapshot foi recusado com 20 TB livres (a história do thick vs thin está no artigo do NAS).

O btrfs é o equilíbrio certo pra máquina de consumo. Leve, nativo no kernel, faz quase tudo que o ZFS faz sem exigir um administrador de storage. Desktop, notebook, homelab, NAS pequeno ou médio: btrfs. O Synology provou na prática, duas vezes: o volume btrfs sobreviveu legível com dois discos fora, e os snapshots dele salvaram 11 álbuns que eu deletei por engano no meio da limpeza, byte a byte.

NAS grande e sério, com RAM de sobra: ZFS. Todo o resto: btrfs. E pra máquina Linux de uso pessoal, não é nem discussão.

Recuperação de boot por snapshot

A feature que já me salvou de verdade, contada nas duas máquinas.

No desktop, o Omarchy configura o snapper pra tirar snapshot antes de cada update e o limine-snapper-sync publica cada snapshot como entrada de boot no Limine. Kernel novo não sobe? No menu de boot você escolhe o snapshot de ontem e a máquina volta como se nada tivesse acontecido. Na minha máquina a rotina agendada roda via Timeshift em cron (a cada boot e de hora em hora), com o snapper cobrindo os pontos de update: o mecanismo de retorno é o mesmo. (A gotcha: cada entrada de snapshot carrega a imagem do kernel junto, então ESP pequena enche rápido. A minha de 1 GB já recusou um update de kernel por falta de espaço; o sistema seguiu bootável no kernel velho, que é o comportamento certo.)

No servidor, que roda openSUSE MicroOS, é ainda mais forte: o sistema inteiro é btrfs transacional, e cada update é um snapshot novo. Semana passada, o kernel 7.2.9 derrubou o controlador NVMe em silêncio, duas vezes, no meio do backup noturno. O conserto foi um transactional-update rollback e um reboot de volta pro 7.2.6, que rodou a carga inteira (754 GiB de leitura de backup com download concorrente) sem um soluço. Regressão de kernel virou reboot agendado, não madrugada de recovery. Uma ressalva documentada: o /etc mora dentro do snapshot, então o rollback desfaz mudanças de configuração junto. Depois de qualquer rollback, confira de novo as suas units.

Manutenção não é opcional (e o arquivo deletado que não some)

Filesystem CoW moderno entrega muito, mas cobra duas rotinas que o ext4 nunca pediu.

A primeira é o scrub, que já apareceu aqui: reler tudo e conferir checksums, mensalmente, em todas as máquinas. Ele é o detector de bit rot em ação, e sem ele o checksum só te avisa da podridão quando você tentar ler o arquivo. O segundo ponto é mais sutil: snapshot prende bloco de arquivo deletado. Quando você apaga um arquivo dentro de um subvolume com snapshot, o espaço não volta, porque o bloco continua referenciado pela foto. Foi exatamente o que aconteceu no meu NAS: a limpeza de 2,14 TB que rodei no Synology só liberou espaço de verdade depois que os snapshots velhos foram removidos; até lá, os blocos ficaram presos.

O tratamento é rotina simples. A retenção tem que ser automática, com o snapper ou o Timeshift apagando os snapshots antigos conforme a política (no QNAP, a política de retenção do Snapshot Manager faz o mesmo papel). Espaço que não volta depois de deletar snapshot velho geralmente é chunk alocado demais: um btrfs balance start -dusage=50 devolve os pedaços pouco usados pro pool livre (aqui em casa eu não agendo balance cego, eu monitoro o espaço não-alocado e ajo quando aperta). E no lado do restic, forget sozinho só remove a referência do snapshot: o espaço do repositório só é recuperado com o prune junto, forget --prune.

A limpeza da casa na era do AI coding

Agora a parte que quase ninguém conecta com filesystem: a era do agente produz lixo em velocidade industrial. Eu sei porque medi.

• Rust é o maior poluidor de disco do mundo dev. Cada build deixa pra trás binários de teste de 100 a 180 MB, e eles se acumulam a cada edição. No meu desktop, os diretórios target/ somavam 920 GiB. Só o ai-memory respondia por 704 GiB. A ferramenta de higiene que eu usava é o cargo-sweep, semanal. Um leitor avisou que o projeto se declara sem mantenedor, e o próprio README manda pro cargo-clean-all, que faz diferente: em vez de podar artefato velho dentro de um target/, ele acha todos os projetos Rust abaixo de um diretório e apaga o target/ inteiro dos que você filtrar, por exemplo cargo clean-all --keep-days 7 ~ pra limpar só o que não compila há uma semana.
• Docker não fica atrás. Na minha máquina achei 1,26 TB de build cache mais 938 GB de imagens. Uma faxina única recuperou uns 600 GB. No servidor, a limpeza semanal recolhe de 0,6 a 4,5 GB todo domingo.
• Caches de IA e de pacotes incham quietos. O cache do Hugging Face tinha 86 GB até eu apagar três modelos mortos e ele cair pra 21. Pacman tinha 22 GB de pacotes superados. yay, uv e pip, mais 125 GB.
• E os agentes criam diretórios temporários sem pedir licença. Projeto complexo com várias branches significa worktrees, e cada worktree de release tem seu próprio CARGO_TARGET_DIR cheio de binário de teste. No ai-memory isso já estourou o disco, e virou regra obrigatória no AGENTS.md do projeto: depois de cada release, cargo clean em cada worktree criado e remoção dos worktrees terminados, sem exceção.

A solução é automatizar o varrimento. O meu exemplo mínimo, um timer de usuário que roda dia 1 e 15 de madrugada, com Nice e I/O idle:

• apaga diretórios target/ de projetos parados há mais de 14 dias
• limpa o cache do yay
• poda só o build cache do Docker com mais de 30 dias, nunca imagem ou volume

E a parte que virou padrão aqui em casa: instruir os agentes a limpar o que criam. Três regras reais dos meus projetos, pra você copiar:

No AGENTS.md do desktop: “Nunca rode limpezas amplas como docker system prune sem autorização explícita do usuário depois de um inventário read-only. Limpeza usa lista exata de IDs; parado, antigo ou sem referência não significa descartável.”

No CLAUDE.md do homelab: “Antes de terminar qualquer tarefa, remova as coisas temporárias que a tarefa criou, e só elas. Nunca delete o que você não criou ou não consegue atribuir à tarefa. Na dúvida, liste pro dono.”

No AGENTS.md do ai-memory: “target/ cresce sem limite: cada edição num crate compartilhado deixa pra trás uma cópia de cada binário de teste de 100-180 MB (visto a 157 GiB). cargo sweep --time 7 semanal, e cargo clean obrigatório depois de cada release.”

E o backup de verdade: restic

Snapshot mora no mesmo disco, então snapshot não é backup: se o disco morre, o snapshot morre junto. O último item do kit é o restic, que pra mim é o melhor sistema de backup do Linux hoje.

O restic é um binário único, open source, escrito em Go, que faz backup deduplicado, criptografado e versionado pra praticamente qualquer destino: outro diretório, outro NAS via SFTP ou REST, S3, Glacier. O truque central é o content-defined chunking: ele fatia cada arquivo em blocos de tamanho variável definidos pelo conteúdo, tira o hash de cada bloco e só grava no repositório os blocos que ainda não existem lá. Por isso o delta é barato: o backup de hoje carrega os blocos que mudaram desde ontem, não os arquivos que mudaram. Editar um banco de 100 GB no meio custa alguns megabytes de backup, não 100 GB de novo. Cada execução vira um snapshot do repositório, um ponto de restauração que você navega com restic mount como se fosse filesystem, e o restic check audita a integridade do repositório inteiro quando você pedir.

A configuração importa mais que a ferramenta, então vai a nossa, com os erros inclusos. No desktop, o repositório mora no NAS e a retenção é keep-daily 7, keep-weekly 4, keep-monthly 6, keep-yearly 1. No servidor, o backup roda diário de madrugada pro repositório no QNAP, cobrindo /etc, /usr/local/bin, /home e os volumes dos containers, com a senha fora da máquina e pg_dump antes dos bancos, porque snapshot de filesystem não garante consistência de banco escrevendo. A primeira carga completa foi 729 GiB em menos de uma hora, e o restic atravessou ileso, na base do retry, a janela em que a montagem NFS ficou read-only por engano durante a migração.

A parte mais importante da configuração é o que não entra no backup. As nossas exclusões, todas com motivo:

• caches de modelo de IA (Immich, Hugging Face, EasyOCR): se perder, baixa de novo;
• métricas do Prometheus: histórico que se regenera sozinho;
• o banco do Fulcrum: reindexa a partir do bitcoind;
• os pesos dos classificadores de decisão: rebaixáveis por hash de revisão (e o glob dessa exclusão vai entre aspas dentro do array do bash, porque sem aspa ele vira fonte de backup em vez de exclusão);
• node_modules, target/, registry do cargo, toolchains do rustup: build artifact puro.

E um aprendizado de retenção pra fechar. Quando encurtamos a política do servidor pra “ontem, 2 diários, 2 semanais e 1 mensal”, a tradução correta pros flags é --keep-daily 3 --keep-weekly 3 --keep-monthly 2, não 2/2/1: os níveis do restic se sobrepõem, e o snapshot de ontem também é o mais novo desta semana e deste mês, então cada número precisa ser um a mais que os pontos antigos que você quer guardar. O detalhe pegou a gente no contrapé: o script estava com 2/2/1 literal, e com ele o nível mensal nunca seguraria nada mais velho que a noite passada. Na prática, a intenção era guardar 5 pontos de restauração, e o 2/2/1 entrega só 3: ontem, mais um diário, mais um semanal. Erramos, medimos, corrigimos.

Uma nota de humildade vinda do desastre: os repositórios antigos ficaram no Synology por decisão minha (quase 2 TB de histórico abandonado, porque o conteúdo já estava re-coberto no QNAP novo). Repositório de backup também envelhece, e revisitar o escopo dele faz parte da higiene.

Conclusão: na era da IA, disco não é detalhe

Agentes codificando o dia inteiro mudam a matemática do armazenamento nas duas pontas. Na ponta do volume: builds, caches, worktrees e modelos enchem o disco muito mais rápido do que qualquer hábito humano enchia, e sem rotina de limpeza você descobre quando estoura. Na ponta da segurança: quanto mais código gerado, mais você precisa de ponto de retorno barato, porque nem toda mudança de agente é boa.

O btrfs cobre as duas. A compressão transparente devolve 15% de disco de graça, e código-fonte é exatamente o tipo de dado que mais comprime. Snapshots e subvolumes te dão volta atrás instantânea no sistema e isolamento do que não precisa de proteção. Checksums e scrub vigiam a saúde dos blocos que o ext4 simplesmente ignora. O ext4 teve seus 15 anos de reinado merecido. Em 2026, escolher ele num Linux novo é abrir mão de proteção que você vai precisar, cedo ou tarde. Escolha btrfs e configure a limpeza hoje.

• 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.

Last conversion of the Campfire from my token stash goes to JavaScript/Express. As with the others, I'm sure you can find more to optimize. But this gives you a sense of what order of magnitude these options exist within with agent-led development. https://t.co/UUapL99SJE https://t.co/2H2NXfeZog

— DHH (@dhh) October 5, 2026

Não vou defender ele dessa vez. Uma conversão única, feita por agente, sem ajuste fino nenhum, não mede linguagem: mede o quanto o modelo conhece os idiomas de cada stack. É rage bait e ele sabe. Dito isso, eu faço o mesmo de vez em quando, e metade dos críticos dele também, então somos todos hipócritas e segue o jogo.

E o ponto fraco da metodologia dele virou tópico por conta própria: várias pessoas notaram que a versão em Rust tinha passado por bem mais iterações de agente que as outras, ou seja, mais rodadas de otimização. O @kurtome respondeu na prática: pegou a versão em Elixir e subiu as requisições da página principal em 10x, com otimizações óbvias que nenhuma primeira conversão faz, tipo cache e pooling assíncrono de conexões de banco.

@dhh Here you go https://t.co/gUtK7Z7zG7

got a 10x speed up on the Room page requests, and sped up all the other requests significantly as well. the biggest gains came from some no brainers: implement caching and pool the db connections with proper async https://t.co/mbp94q9N0s

— kurt (.com) (@kurtome) October 5, 2026

A comparação dele, então, não era “Rust contra Elixir”: era “Rust depois de N rodadas de ajuste contra Elixir depois de uma”. E isso escancara a verdade que a thread finge ignorar: nenhum software de verdade sai com meia dúzia de prompts. Codar com IA brilha quando um engenheiro experiente pilota o agente rumo ao objetivo dele, e isso significa dezenas de iterações, não três.

A parte boa é que a isca foi útil pra mim. Eu venho fazendo benchmarks de LLM e benchmark de modelos de decisão, mas nunca tinha medido, de forma reproduzível, a pergunta que essa thread fingia responder: faz diferença qual linguagem você escolhe quando quem escreve o código é um LLM? Minha resposta curta já estava dada em dois posts meus:

Pressure under load is not a trivial problem to solve from scratch and I recommend you do not attempt to. It's a solved problem already and all solutions converge to what Elixir already brings out of the box. So yes. I use Rust all the time, but if I had to solve high scalability problems (particularly high volume message queues), I would think of Elixir first.

— Fabio Akita (@AkitaOnRails) October 9, 2026

Language wars are tiresome. And the reality is simpler if you're doing AI assisted coding.

- system level (drivers, fs, daemons, etc): Rust. C++ is you're extending existing legacy
- windows only desktop apps: C#
- iOS/MacOS/iPadOS: Swift
- multi-OS: Rust/Tauri, Qt/C++, Flutter, Electron (pick your poison)
- simple websites: Node/Typescript/Bun/Deno
- highly scalable backend: Elixir, parts in Rust, parts in Go
- CLI tools: Rust

Everything else, by default, Rust. Unless it's an edge case.

— Fabio Akita (@AkitaOnRails) October 9, 2026

Não existe linguagem melhor, existe ferramenta certa

Aquela lista do post não é ranking, é mapa de terreno. Cada linguagem e cada framework foram desenhados pra um caso de uso, e nenhum cobre todos. Isso valia quando você escrevia cada linha na mão e continua valendo com agente. O LLM não muda a física do problema: ele só muda quem digita.

E o mapa vai além da linguagem. Sistema real tem infraestrutura em volta: Kubernetes quando a escala pede, SQLite por padrão porque a maioria dos apps nunca precisa de mais que isso, Postgres com pgBouncer quando precisa, Redis pra cache e chave-valor, RabbitMQ ou NATS pra fila. Escolher “a stack” no dia zero e achar que ela dura dez anos é fantasia. Não dura, e tudo bem.

Exemplo pessoal: web app novo, eu abro Ruby on Rails sem pensar duas vezes. É a solução mais completa de ponta a ponta que existe pra web, e com LLM escrevendo a maior parte do código, a produtividade do framework pesa ainda mais que a da linguagem. Conforme o sistema cresce, eu vou trocando as partes que pedem outra ferramenta: fila de alto volume sai do lado do Rails e vai pra algo da terra Erlang, começando por RabbitMQ, que já resolve a parte difícil de backpressure pra mim.

Nenhum software bom está pronto: ele cresce. O uso dita o que você substitui, reescreve e adiciona. A arquitetura final nunca é a do primeiro commit, e quem tenta acertar tudo no primeiro commit só gera documento morto.

A superstição dos tokens

A thread do DHH ressuscitou duas crenças que circulam desde que LLM virou ferramenta de trabalho:

• “Linguagem de script é melhor pra IA porque a sintaxe enxuta gasta menos tokens.”
• “Linguagem fortemente tipada é melhor pra IA porque o compilador pega os erros, então precisa de menos teste e menos reparo.”

As duas soam razoáveis e as duas são superstição até alguém medir. Eu apostava contra as duas, por experiência: compilador bom ajuda, mas não faz mágica, e concisão de sintaxe nunca foi o gargalo de um agente que lê e escreve arquivo o dia inteiro.

O que realmente separa projeto que anda de projeto que gira em círculo é disciplina de teste. Já escrevi que TDD virou obrigação técnica, não filosofia, e o benchmark deste texto é mais um dado na mesma direção. Não importa se você faz test-first ou test-after: importa que a suíte cresça junto com o código, que todo bug reportado por usuário vire teste de regressão antes da correção, e que você nunca repita o mesmo erro duas vezes. Software sem usuário é software morto, então release cedo, release sempre, quebra rápido e conserta mais rápido ainda. IA fecha exatamente essa lacuna: o ciclo de reproduzir, testar e corrigir ficou barato. QA virou a habilidade mais valiosa do programador, muito acima de “saber a sintaxe de Rust”.

Disciplina vence compilador e vence linguagem. Essa era a minha hipótese. Foi medir.

O benchmark

Montei um experimento reproduzível, público no repositório vibe-coding-benchmarks, com os resultados por tentativa publicados em JSON e os rastros brutos fora do repo por contenção de credenciais. Não é um campeonato de linguagem, e o próprio design repete isso: é uma fotografia de uma tarefa real, medindo o que dá pra medir com honestidade.

A tarefa

Uma tarefa só, de propósito: manter um motor de livro-razão (ledger) multilocatário. O agente recebe um código v1 funcionando e precisa levá-lo a um contrato v2, com identidades por tenant, autorização, snapshots serializáveis, índice secundário único com troca de alias, journal com limite de capacidade, recuperação de grupos rasgados, checkpoint, migração de schema legado e IDs de retry duráveis. Não é FizzBuzz: é o tipo de sistema que exige invariante atravessando operações, exatamente onde LLM costuma tropeçar.

A correção é julgada por 43 histórias de teste aplicadas depois da coleta, fora da vista do agente: as 27 públicas do T1 mais 16 ocultas. Passar é 43 de 43. As condições:

• T0: contrato em prosa, exemplos de entrada e saída, um launcher funcionando. Sem suíte de testes.
• T1: o mesmo, mais 27 histórias públicas e um driver pra rodá-las.

Cada tentativa tinha 15 minutos de orçamento, com no máximo duas continuações de 3 minutos. Na prática, nenhuma das 112 precisou de continuação.

As linguagens e os modelos

Sete linguagens em três estratos, com os toolchains pinados e o Rust em modo seguro:

• Nativas tipadas: Rust (safe, pinado), Haskell (GHC pinado).
• VM tipadas: C# (com nullable analysis), Kotlin, TypeScript (strict, noUncheckedIndexedAccess, exactOptionalPropertyTypes).
• Dinâmicas de script: Python e Ruby, sem checker nenhum.

Quatro configurações de modelo, todas por assinatura, sem fallback pago: Kimi K3 (high), GLM 5.3 via OpenCode (high), Claude Opus 5.5 (medium) e Codex com gpt-6 Sol (medium). Cruzando tudo: 7 linguagens × 4 modelos × 2 condições × 2 repetições = 112 tentativas.

O que esse design não mede

Antes dos números, os freios, porque eles fazem parte do resultado. É uma tarefa só, com duas repetições por célula: amostra pequena por construção. Cobertura de tokens é parcial em alguns modelos (dado faltante não é zero). O harness mudou no meio da campanha em três épocas de instrumentação. E atrasos de provedor contaminam tempo de parede: uma das tentativas do Opus passou metade do relógio esperando liberação de cota. Todos os números abaixo são descritivos, e eu aponto onde eles não sustentam conclusão.

Tem um freio adicional, de propósito: o nível de iteração. Meu desenho mede o que dá pra alcançar em todas as linguagens com níveis parecidos de iteração, em orçamento curto, sem um humano ajustando depois. É fotografia do piso, não do teto. Qualquer uma das 112 implementações provavelmente melhora com mais rodadas de agente, e as quatro stacks de fila idem: o que eu publico é o que cada linguagem entrega “de fábrica” sob o mesmo esforço, não o máximo que um engenheiro paciente extrairia dela.

Disclaimer obrigatório antes de citar qualquer número deste texto por aí: todos os resultados a seguir valem pra este benchmark, com esta tarefa, estes modelos, estes prompts e este hardware. O seu caso pode variar violentamente. Se a sua tarefa não se parece com um motor de livro-razão, se o seu modelo não é um destes quatro, se a sua fila não é a minha fila, os números não se transferem. O código, as tarefas, as notas e o passo a passo pra reproduzir estão todos no repositório no GitHub. E se você discordar de algum resultado e essa discordância for importante pra sua empresa ou pro seu projeto, a única atitude honesta é a que eu tive: pare de argumentar e rode o seu próprio benchmark.

Resultado 1: em acerto, os modelos de fronteira empataram no teto

Leitura: Sol passou nas 28 tentativas elegíveis e o Opus nas 25 dele (as 3 falhas foram infraestrutura, não código). 53 de 53 tentativas elegíveis corretas entre os dois. A tarefa, feita pra ser difícil, foi fácil demais pra separar os modelos de fronteira, e muito menos as linguagens: com todo mundo passando em tudo, não existe ranking de acerto pra publicar.

A diferença apareceu nos modelos mais fracos, e na direção que a minha hipótese previa: teste fornecido ajudou. Kimi e GLM, com a suíte pública em mãos (T1), entregaram 24 artefatos corretos contra 16 sem ela (T0). O Kimi, em particular, passou nas 14 tentativas com testes fornecidos. É descritivo, não causal, mas é o sinal mais limpo do benchmark inteiro: o que mudou o resultado não foi a linguagem, foi a presença de teste.

Por linguagem, dentro de cada modelo, o acerto ficou espalhado entre 1/4 e 4/4 sem padrão que se repita entre modelos. As três falhas semânticas que eu auditei a fundo são instrutivas: um C# do GLM e um Python do Kimi perderam a mesma história por violar a mesma invariante entre operações, e um Haskell do Kimi errou um caminho de checkpoint. Nenhuma falha era erro de tipo.

Onde o modelo errou, errou invariante de domínio: o tipo de erro que compilador nenhum pega, em linguagem tipada ou dinâmica. O mito de que tipagem forte poupa o trabalho de entender o problema morre aí.

Resultado 2: linguagem concisa não economizou token

Aqui vai a tabela que mata a primeira superstição. Medianas por linguagem no Sol, quatro tentativas válidas por célula:

Ruby, o mais conciso em linhas (pouco mais da metade do Rust), custou praticamente os mesmos tokens do Rust no Sol, e no Opus foi o mais caro de todos, uns 205 mil tokens de mediana contra 94 mil do C#. Os mais baratos foram TypeScript e Python no Sol, C#, Haskell e Kotlin no Opus. Se “menos linhas de código fonte = menos tokens de LLM” fosse lei, Ruby tinha que liderar de longe. Ficou no fim.

E a segunda superstição? Auditei os rastros procurando os ciclos de reparo guiados por compilador que a tipagem forte supostamente evita. Resultado: zero ciclos de reparo de erro de compilação nas tentativas auditadas do Opus, em Ruby, Rust e Haskell. O Rust não precisou de correção nenhuma vinda do compilador; o Haskell teve uma limpeza de warning; o Ruby gastou seus tokens extras em ajuste voluntário de performance. O modelo de fronteira quase sempre escreve código que compila de primeira, e o esforço real vai pra verificação, não pra apaziguar o compilador.

Um contraponto que fecha o caixão da tese “barato é bom”: as células de menor consumo de token do GLM foram as falhas. TypeScript T0 por 50 mil tokens parece eficiente até você ver que são dois starters inalterados porque o modelo estourou o limite de saída. Token baixo pode significar desistência precoce.

Resultado 3: sob carga, todo mundo empatou na fila

Aí vem a pergunta do DHH: Rust “ganha” de Elixir e Ruby quando o assunto é throughput. Montei a trilha separada pra isso: quatro workers de fila contra um RabbitMQ real, escritos com ajuda de agente, cada um com seu idioma natural:

• Elixir com OTP e Broadway
• Rust com Tokio e Lapin
• Rails com Bunny
• Ruby puro com Bunny (controle)

Um gerador publicava 10 mil mensagens de 4 KB no RabbitMQ, a 200 por segundo, e cada worker consumia o mais rápido que conseguia, batendo os efeitos num coletor HTTP/SQLite com atraso nominal de 50 ms, limitado a 2 CPUs e 1 GB de RAM. Dois perfis de concorrência:

No perfil de 8 handlers, as quatro stacks entregaram a mesma vazão, 93 a 95 efeitos por segundo, e drenaram a fila inteira. O gargalo aparente era o coletor compartilhado (um lock em Python, um escritor SQLite), não as linguagens. No perfil de 64 handlers, todas deixaram backlog e estouraram o timeout do cliente em massa, então marquei essas células como não qualificadas: o protocolo forte, com coletor de group-commit e escada de 50 a 800 msg/s, está desenhado e não executado.

A única diferença que sobrou de pé nos números foi memória: Rust segurou o pico em 16 MiB onde a BEAM gastou 135. É uma vantagem real do Rust em densidade, com a ressalva de que pico de cgroup não é footprint de linguagem. Em vazão, que era a alegação da thread, empate técnico.

E o empate merece a leitura honesta: ele pode significar só que a minha pressão foi pouca. Com o coletor compartilhado segurando tudo em torno de 95 efeitos por segundo, qualquer stack capaz de mais que isso aparece como “igual”. O que esse teste mostra é onde estava o gargalo, não onde cada stack quebra. Pra achar o teto de cada uma eu precisaria do protocolo forte, com coletor de group-commit e escada de carga, que está desenhado e não executado. Até lá, “todas as stacks performam igual” é a conclusão errada; “todas ficaram acima do que o meu teste conseguiu medir” é a certa.

E a pergunta que interessava mais, “o agente trabalha menos pra entregar um consumer de fila confiável em Elixir do que em Rust?”, ficou sem resposta de propósito: essas quatro implementações foram escritas pra validar o ambiente, não como tentativa controlada de codificação. Comparar o esforço de IA entre Elixir e Rust exigiria a mesma matriz do ledger rodando na tarefa de fila. Está na lista.

Afinal, a linguagem importa?

Com os dados na mesa, dá pra responder as três perguntas da thread:

Existe linguagem melhor pra programar com LLM? Não apareceu nenhuma. Nos modelos de fronteira, acerto e esforço variaram menos entre linguagens do que entre modelos. Onde houve diferença de acerto, ela seguiu a presença de testes fornecidos, não a sintaxe. “Nenhum ranking geral de linguagem se estabelece” é a frase oficial do relatório, e é a frase correta.

As teses de economia de token se sustentam? Nenhuma das duas. Concisão não economizou: Ruby custou tanto quanto Rust, ou mais. Tipagem forte não poupou reparo: não havia reparo de tipo pra poupar. O esforço dos modelos foi pra verificação e entendimento do contrato, e isso não tem linguagem.

O DHH estava certo? No que ele mediu, ele mediu o que um agente entrega de graça em cada stack, sem ajuste, e chamou isso de veredito sobre linguagem. No meu teste, com carga real e medição honesta, as quatro stacks empataram em vazão no regime estável, e só a memória diferenciou o Rust. Se a thread dele prova alguma coisa, prova que conversão por agente mede o modelo, não a linguagem.

Minhas apostas da introdução saíram de pé: teste e disciplina são a alavanca, o compilador é coadjuvante, e a ferramenta certa depende do problema. Web app novo continua sendo Rails na minha mão, fila pesada continua sendo território Erlang, sistema baixo nível continua sendo Rust, e o LLM escreve qualquer uma delas com a mesma competência. Quem passou a semana brigando pela linguagem favorita no X brigou por nada.

E a minha prática diária conta a mesma história. Eu tenho viés pessoal pra Rust e mesmo assim já publiquei mais de 30 projetos open source em todo tipo de stack: o ai-memory é Rust, o FrankMD é Ruby on Rails, o ai-memory-web e o ai-jail-web são Node.js. Em nenhum deles eu senti diferença relevante que viesse da stack: os ganhos foram parecidos, os erros também, e os erros eram sempre compreensíveis. Cada erro virou melhoria de invariante, de regra, de skill. Nunca virou troca de linguagem.

Então esquece “economia de token” e “superstição de tipagem”. Faz engenharia de software de verdade: escolhe a ferramenta certa pro teu problema específico, aplica técnica de engenharia correta, e qualquer agente razoável vai performar mais ou menos igual. E para de gastar tempo discutindo rage bait de guerra de linguagem na internet. Seja engenheiro de software de verdade e faça engenharia de verdade. É só isso.

Os dados por tentativa, a metodologia completa e os limites de evidência estão no repositório. Se você rodar a matriz com outra tarefa e achar um ranking que eu não achei, me mostra.

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.

Naquele momento eu sabia que estava a um soluço de perder tudo. Este texto é o post-mortem do que aconteceu, e a primeira parte foi escrita no calor do desastre, com a cópia de salvamento ainda rodando.

Atualização de 11 de outubro: a cópia terminou e o final foi feliz. Nenhum arquivo se perdeu por acidente, os dois NAS estão saudáveis, cada um com seu RAID-6. A recuperação inteira está na segunda metade deste texto. A primeira parte fica como foi publicada, sem retoques.

Eu uso NAS faz muito tempo

Não sou marinheiro de primeira viagem. Fiz uma minissérie inteira de vídeos sobre armazenamento e sistemas de arquivos, e recomendo assistir antes de vir me perguntar “qual um bom NAS pra iniciante?”. Não existe isso.

Uso armazenamento externo desde a segunda metade dos anos 2000, quando era usuário de Mac e existia o Drobo. A empresa não existe mais, mas tive três DAS deles antes de migrar pra Synology, primeiro num modelo de entrada e depois no DS1821+, intermediário, que uso há mais de cinco anos. Já escrevi sobre ele aqui, configurando NFS no Linux e acessando por iSCSI.

Ele foi muito valioso pra mim, e você não tem que questionar por que eu preciso de tanto espaço. Não importa: cada um decide o que guarda no seu.

Quando eu produzia vídeo pro YouTube, editava material 4K direto do NAS, graças ao cache NVMe e à rede 10 GbE. Me acostumei com armazenamento grande a 10 gigabits e não consigo mais voltar atrás.

O array estava organizado em SHR, o RAID híbrido da Synology, que na prática se comporta como RAID-5 (mais sobre isso adiante): aguenta a perda de um disco sem perder dado nenhum. Sempre achei que isso bastava.

HD morre. Sempre

Não se engane: disco rígido estraga. Nunca, jamais confie num HD solitário esquecido num armário. Ele vai falhar, e você vai perder tudo o que está nele.

O melhor dado público sobre isso é o da Backblaze, que opera centenas de milhares de discos e publica a taxa de falha todo trimestre. No relatório do segundo trimestre de 2026, com 354.415 discos monitorados, a taxa anualizada foi de 1,73%, e a taxa acumulada da frota inteira está em 1,41% ao ano.

Parece pouco. Traduzindo pra escala de gente:

• Um disco sozinho, por 5 anos: a chance de ele morrer nesse período fica perto de 7%. É mais ou menos a chance de tirar um número específico num dado de 14 lados. Você apostaria todas as fotos da sua família nisso?
• Um disco sozinho, por 10 anos: uns 13%, um em cada oito.
• Oito discos, como no meu NAS, por um ano: a chance de pelo menos um falhar é de uns 11%. Em cinco anos, mais de 40%.

E esses números são de datacenter, com temperatura controlada, energia limpa e disco girando o tempo todo. HD de gaveta, que fica anos parado e leva tranco na mudança, não tem estatística tão bonita.

Cartão de memória é pior, e nem existe uma estatística equivalente pra consultar. O que existe é teste de tortura: o Great MicroSD Card Survey testou 216 cartões ao longo de um ano de escrita contínua, e 52 deles, um em cada quatro, já tinham morrido.

Cartão legítimo começou a dar erro, em média, depois de uns 2.500 ciclos de regravação; cartão falsificado, depois de 700. Cartão de memória é mídia de transporte. Guardar a única cópia de alguma coisa num microSD é pedir pra perder.

A conclusão prática é a mesma da minissérie: dado importante precisa de redundância. Um array com paridade existe justamente pra que a morte de um disco, que é questão de tempo, não leve nada junto.

O que aconteceu

Com tudo isso, eu deveria estar tranquilo com a minha configuração. Não estava.

Começou anteontem, domingo. Fazia tempo que eu via o volume chegando no teto.

No começo eram 8 discos de 10 TB. Com os anos fui trocando, um a um, por discos de 20 TB (o DSM mostra em base binária; na etiqueta são 12 e 22 TB). É um processo lento: cada troca leva dias, porque o array precisa reconstruir e redistribuir os dados.

Decidi trocar mais um, o sétimo. A Synology suporta hot-swap, então é simples: tira o disco velho, encaixa o novo, adiciona ao array e deixa o DSM cuidar da reconstrução.

No domingo à noite estava assim: reconstrução começando, os oito discos saudáveis, 108 TB alocados de 121,8 TB.

Na segunda, às 8 da manhã, o bipe. O disco 1, o novo, com 13 horas de uso, marcado como crítico:

E o disco 8, um dos antigos, com 22.095 horas ligado (dois anos e meio), também crítico, com erro de leitura às 08:05:

A mensagem do pool não deixava margem: “erros irrecuperáveis ocorreram porque erros de disco aconteceram depois da degradação do storage pool. Faça backup dos seus dados imediatamente.”

Por que dois discos é o fim

Em RAID-5, se dois discos caem, a redundância é zero, e em teoria o array inteiro vai junto. É uma situação irrecuperável.

Quem assistiu a minha playlist sabe o motivo. Um array desses não guarda “arquivos”, um por disco. Um arquivo é uma coleção de blocos, e os blocos ficam espalhados por todos os discos, junto com a paridade. Perder um disco é perder um pedaço de cada arquivo. Não adianta os outros sete estarem saudáveis, porque eles só têm partes.

A paridade serve pra recalcular o pedaço que falta quando um disco some. Com dois faltando, a conta não fecha.

E tem um detalhe cruel na reconstrução: pra recriar o disco novo, o array precisa ler todos os outros discos de ponta a ponta. São mais de 100 TB de leitura contínua. Se algum disco antigo tinha setor ruim escondido num canto que ninguém lia fazia tempo, é nessa hora que ele aparece. Foi o que aconteceu com o disco 8.

Pra onde copiar 90 TB?

A única saída, naquele ponto, era agradecer aos céus por os volumes ainda estarem acessíveis, com os arquivos aparecendo, e usar a janela pra copiar tudo pra fora imediatamente. Eu não podia encostar em mais nada.

O problema: copiar uns 90 TB pra onde? Ninguém tem um NAS de 100 TB vazio sobrando em casa.

Normalmente eu compraria esse tipo de peça nos Estados Unidos, numa viagem de turismo, e traria comigo. Sai muito mais barato. Não compensa comprar eletrônico caro no Brasil: o país cobra imposto de importação pior que as tarifas do Trump faz décadas, e o preço final costuma passar do dobro do preço de tabela americano.

Só que eu tinha que escolher. Quanto vale perder 90 TB de dados que levei anos juntando e que são quase impossíveis de recuperar de outro lugar? É uma daquelas situações em que a resposta é “não tem preço”, e então, qualquer que seja o preço, eu pago.

Achei um revendedor de storage perto de casa, a Controle Net. Gente boa, muito ágil na resposta, e me mandaram uma proposta de equipamento com entrega no mesmo dia.

A primeira sugestão deles foi um QNAP TS-832PX. Fui pesquisar antes de aceitar. Ele tem as mesmas 8 baias e já vem com 10 GbE, mas o processador é um ARM Cortex-A57 de 1,7 GHz (Annapurna Labs AL324) com 4 GB de RAM, metade do mínimo de 8 GB que o QuTS hero pede. Pra RAID-6 em ZFS, com checksum e paridade dupla em cada bloco, é hardware fraco, como eu explico mais abaixo. E seria um downgrade em relação ao DS1821+ que eu já tinha, que roda num Ryzen V1500B.

Pedi outra opção, e depois de algumas idas e vindas fechei num QNAP TS-873A, de 8 baias, com o mesmo Ryzen V1500B do meu Synology, 8 GB de RAM, e 10 discos Toshiba MG11 de 24 TB, classe enterprise.

É por isso que você tem que fazer a sua própria pesquisa e saber, objetivamente, o que quer fazer com o equipamento. O revendedor não agiu de má-fé: sugeriu um NAS de 8 baias pra quem pediu um NAS de 8 baias. Quem sabia que ia rodar ZFS em RAID-6 era eu. Se eu tivesse aceitado a primeira proposta no susto, teria pago caro por uma máquina pior do que a que estava substituindo.

R$ 185.320,00. De fazer o olho lacrimejar.

Quanto custaria nos Estados Unidos

Fui conferir o preço de tabela americano de hoje. Sobre o câmbio: o dólar está em R$ 4,97 agora, mas isso é efeito do resultado do primeiro turno da eleição de domingo, que derrubou a cotação mais de 4% na segunda. Até sexta ele fechava em R$ 5,22, e é essa a cotação justa pra comparar, porque foi nela que o estoque do revendedor foi formado:

A R$ 5,22, uns R$ 60 mil. Eu paguei R$ 185 mil, mais de três vezes isso.

A comparação não é perfeita: a proposta brasileira inclui instalação, treinamento e seis anos de suporte técnico, e o equipamento estava na minha mesa no fim do mesmo dia. Mas dá a medida do efeito Brasil.

Se a regra de bolso é “o dobro do preço americano”, o normal seria uns R$ 120 mil. Os R$ 65 mil a mais são, numa estimativa grosseira minha, a soma de serviço, estoque local de disco enterprise e a minha urgência. Quem compra numa segunda de manhã com o array morrendo não está em posição de pechinchar.

E o disco está caro no mundo inteiro

Pra piorar, o momento é o pior possível pra comprar HD. A bolha de IA está sugando a produção.

Eu achava que a Seagate tinha saído do mercado consumidor. Fui conferir, e não é bem isso: ela não saiu, mas em fevereiro 87% das vendas de HD dela já eram disco nearline, de datacenter, e a WD tira 89% da receita de clientes de nuvem e só 5% do varejo. O CEO da WD disse que a empresa está “praticamente esgotada para o ano de 2026”.

A Seagate declarou que não vai ampliar a capacidade de produção; o crescimento vem só de disco de maior densidade. Pra quem compra disco em casa, o efeito prático é parecido com terem saído: sobra o que os hyperscalers não quiseram, pelo preço que o vendedor pedir.

QNAP em vez de outra Synology

Depois de passar a manhã e a tarde entre negociação, burocracia e boleto, no fim do dia eu tinha o QNAP ligado ao lado do Synology.

A escolha pela QNAP foi além da disponibilidade. A Synology vem tomando decisão de negócio questionável.

Em 2025 ela lançou a linha Plus exigindo discos da própria marca ou certificados por ela.

Os da marca são discos de Seagate, Toshiba e WD rebatizados com firmware próprio, e quem usasse outro ficava sem criar pool, sem monitoramento de saúde, sem deduplicação e sem atualização de firmware. Depois da gritaria, voltou atrás no DSM 7.3 e liberou HD e SSD SATA de outras marcas.

Só que pool em M.2 continua exigindo a lista de compatibilidade. Ficou a incerteza no ar: o que impede de fazerem de novo?

Configurar o QNAP é muito fácil. O QuTS hero, o sistema deles baseado em ZFS, é tão simples de usar quanto o DSM da Synology.

Corrigindo o meu erro: RAID-6 e ZFS

Dessa vez eu sabia que tinha que configurar em RAID-6, que aguenta dois discos falhando ao mesmo tempo. A desvantagem é menos capacidade total, porque o equivalente a dois discos vira paridade em vez de um. A vantagem é que eu não deveria mais passar por uma emergência como esta.

Um dos pontos fortes da QNAP é suportar ZFS de fábrica, bem integrado e fácil de usar.

Pra quem não conhece: o ZFS nasceu na Sun Microsystems, pro Solaris, em meados dos anos 2000, e hoje vive como OpenZFS em Linux e FreeBSD. Ele junta num sistema só o que antes eram três camadas, o RAID, o gerenciador de volumes e o sistema de arquivos. Guarda um checksum de cada bloco, então percebe quando o disco devolve dado corrompido sem avisar, e conserta sozinho a partir da paridade. E nunca sobrescreve dado no lugar: toda escrita vai pra um bloco novo, o que torna snapshot praticamente gratuito.

A fama de devorador de RAM vem de duas coisas. A primeira é o ARC, o cache dele, que por desenho ocupa quase toda a memória livre da máquina. Isso assusta quem olha o gráfico, mas é cache: ele devolve a memória quando outro processo pede. A segunda é a desduplicação, que mantém uma tabela enorme com o hash de cada bloco e precisa dela na RAM pra não ficar inutilizável de tão lenta. A velha regra de “1 GB de RAM por TB de disco” vem daí, e só vale pra quem liga desduplicação.

Mesmo sem ela, ZFS pesa mais que um ext4 ou um Btrfs simples. Calcular checksum, compressão e paridade dupla de cada bloco gasta CPU, e com pouca memória o cache encolhe e tudo fica lento. Em hardware fraco, tipo um NAS de entrada com processador ARM e 2 GB de RAM, ele sofre.

A QNAP pede no mínimo 8 GB pro QuTS hero. O meu veio com 8 GB e um Ryzen de quatro núcleos, o que serve pro meu uso, que é guardar arquivo grande e servir pela rede. Desduplicação fica desligada.

Comprei 10 discos pra um NAS de 8 baias, então sobram dois na gaveta, de reserva, pro dia em que um falhar.

Pra minha configuração simples, três ajustes:

• Over-provisioning de 5%. É um pedaço do pool que o sistema reserva e nunca entrega pra dado. ZFS escreve sempre em espaço novo e fica lento quando o pool enche perto do limite; essa folga mantém o desempenho estável. Em pool de SSD ela também prolonga a vida útil, mas aqui são HDs, então o mínimo já serve.
• Espaço garantido de snapshot de 5%. É a reserva pra snapshot, as “fotos” do estado dos arquivos que permitem voltar atrás num apagão ou num ransomware. Garantir o espaço significa que os snapshots continuam existindo mesmo que eu encha o resto. Meus dados mudam pouco (é arquivo morto, na maior parte), então snapshot ocupa quase nada e 5% sobra.
• Alerta em 85%. O sistema me avisa quando o pool passar de 85% de uso, com folga pra eu agir antes de bater no teto. Foi exatamente a falta de folga que me fez sair trocando disco às pressas no Synology.

Somando as duas reservas, uns 13 TB ficam separados e sobram 112,9 TB pra uso.

Um detalhe do meu caso: estou copiando os 90 TB com os snapshots desligados, e só ligo o agendamento depois que a cópia terminar. Snapshot protege o estado anterior de um arquivo, e num NAS vazio que está recebendo a primeira carga não existe estado anterior que valha proteger. A fonte da verdade ainda é o Synology.

E tem um custo prático. Eu parei e recomecei o job várias vezes, apaguei pasta que tinha entrado por engano e copiei de novo. Com snapshot ligado, cada coisa apagada continuaria ocupando espaço dentro de algum snapshot, e eu estaria enchendo o pool com lixo da própria migração. Quando tudo estiver do lado de cá e conferido, aí sim: snapshot agendado, pra me proteger de apagar o que não devia e de ransomware.

Depois disso criei uma partição gigante “thick”. Em ZFS dá pra criar pasta “thin”, que só ocupa o que tem dentro e pode prometer mais espaço do que existe, ou “thick”, que reserva o tamanho inteiro na criação. Como é um pool com um dono só e um uso só, thick é mais previsível: o espaço é meu e ninguém compete por ele.

Por fim, criei os compartilhamentos e instalei o app HBS 3.

Copiando 90 TB

O HBS 3 (Hybrid Backup Sync) é o aplicativo da QNAP pra backup e sincronização. Ele conecta em outro NAS, em rsync, em FTP, em SMB ou em nuvem.

Conectei no compartilhamento SMB do Synology e mandei sincronizar tudo.

Tive que parar e recomeçar algumas vezes, mexendo nas configurações do job, porque estava absurdamente lento. E a contagem de arquivos não parava de crescer:

865 TB num NAS de 108 TB, e aí eu entendi o que estava acontecendo.

Excluí dois tipos de caminho do job:

• Os diretórios #snapshot. No Synology, quando você marca “tornar snapshot visível”, cada pasta compartilhada ganha uma subpasta #snapshot com uma visão completa da pasta em cada ponto no tempo. Dentro do Synology isso não ocupa espaço, porque snapshot só guarda a diferença. Visto de fora, por SMB, cada snapshot parece uma cópia inteira de tudo, e o HBS estava tentando copiar todas.
• Os diretórios de backup do restic. O restic guarda tudo em centenas de milhares de arquivos de pack de poucos megabytes cada. Cópia por rede é rápida com arquivo grande e sofre com arquivo pequeno, porque cada um custa abertura, metadado e fechamento. E esses backups eu refaço do zero no NAS novo.

Com isso a vazão subiu pra uma média de 400 MB/s.

Isso é menos da metade do que uma rede 10 GbE entrega, mas é mais de três vezes o gigabit que a maioria das pessoas tem em casa. Os dois lados estão de fato a 10 gigabits:

Por que não chega nos 1.000 MB/s? Minha hipótese principal é o disco 8. O array de origem está degradado, e cada leitura que passa pelos pedaços afetados precisa ser recalculada a partir da paridade, com um disco que ainda por cima devolve erro e repete tentativa. Faz sentido o Synology não conseguir ir mais rápido que isso.

Tem um segundo fator, que os meus próprios prints entregam: o Synology está com jumbo frame (MTU 9000), e a imagem do QNAP mostra o MTU padrão de 1500. Esse print é de antes; eu já mudei o QNAP pra 9000 também.

Por que isso importa: MTU é o tamanho máximo de cada pacote que trafega na rede. No padrão de 1500 bytes, encher um link de 10 gigabits significa processar mais de 800 mil pacotes por segundo, e cada pacote custa CPU dos dois lados, com cabeçalho, checksum e interrupção. Com jumbo frame cada pacote carrega seis vezes mais dado, então é um sexto dos pacotes pro mesmo volume, e sobra processador pra mover arquivo. Só funciona se todo mundo no caminho estiver igual: as duas placas e o switch. Se um lado fica em 1500, a conexão negocia pelo menor e o jumbo frame do outro lado não serve de nada.

A 400 MB/s, 90 TB levam uns dois dias e meio, e eu prefiro dois dias e meio garantidos.

O que a Synology explicou

Em paralelo, abri um chamado no suporte da Synology. Depois de algumas trocas, mandei os logs. Responderam rápido, no mesmo dia, e isso eu reconheço. A explicação do engenheiro, resumida:

• O disco 8 vinha registrando erro de mídia há mais de um mês. Erro de mídia é quando o NAS manda ler um setor e o disco responde que não conseguiu, mesmo tentando várias vezes. É sempre falha interna do disco, e ele deveria ter sido trocado.
• Foi a saúde ruim do disco 8 que o derrubou durante a reconstrução do disco 1.
• Na prática eu perdi dois discos, e o pool deveria ter caído por completo. Não caiu por causa do jeito como o SHR funciona.

O SHR não é um RAID-5 só. Pra aproveitar discos de tamanhos diferentes sem desperdiçar espaço, ele fatia os discos e monta vários RAIDs menores, um por faixa de tamanho, e junta tudo num volume. O engenheiro mandou este diagrama de exemplo:

No meu caso, o pool é feito de duas partições. Na primeira, a reconstrução do disco 1 já tinha avançado o bastante e a falha do disco 8 foi leve o bastante pra que os dois continuassem funcionando. Na segunda, os dois estão ausentes. É por isso que o pool não caiu inteiro e eu ainda enxergo os arquivos.

A recomendação dele foi a que eu já estava seguindo: copiar tudo pra fora antes de qualquer outra coisa, porque não dá pra saber se a situação piora nem se tem conserto. Depois do backup ele até pode tentar forçar o disco 8 de volta pro pool pra reconstrução continuar, mas não há garantia de que o disco aceite, nem de que aguente o processo. Nas palavras dele, copiar e recriar o pool do zero é provavelmente o caminho mais rápido.

RAID-5 clássico, aliás, exige todos os discos do mesmo tamanho, e pra aumentar a capacidade eu teria que trocar todos de uma vez. O SHR foi o que me permitiu ir trocando um por vez ao longo dos anos. Por ironia, foi também o que me salvou de perder tudo de uma vez.

Os dois erros

Do jeito que eu entendi, são dois erros, um meu e um deles, e é aí que mora o desastre inteiro.

O meu: subestimei o RAID-6, que na Synology se chama SHR-2. Com dois discos de paridade, a falha do disco 8 no meio da reconstrução seria só um susto. Eu troquei segurança por 20 TB de espaço e passei cinco anos achando que tinha feito bom negócio.

O deles: pelos logs, o software sabia que o disco 8 estava falhando havia pelo menos um mês, e eu nunca recebi notificação nenhuma. Eu tenho notificação por e-mail configurada. E ela funciona: quando a situação crítica estourou, recebi uma enxurrada de e-mails. Este aqui, sobre os setores ruins do disco 8, chegou à uma da tarde de segunda, cinco horas depois do desastre:

Antes disso, nada. Nenhum aviso sobre o disco 8 até ele falhar de forma catastrófica.

Se eu tivesse recebido, jamais teria tentado trocar o disco 1 antes de substituir o 8. A situação toda era evitável, e foi resultado de um erro humano somado a algum bug de software.

Esse é o outro motivo de eu não ter comprado outra Synology. Tenho um princípio: se o cavalo me derruba, eu sacrifico o cavalo. Não dá pra confiar de novo.

Onde estou agora

Até aqui copiei uns 20 TB dos 90 TB originais, e o HBS 3 segue trabalhando. Ainda não sei se perdi algum dado de forma permanente. Espero que não, mas o mais provável é que eu tenha perdido o que estava na fatia de RAID que o engenheiro descreveu como caída.

Tenho backup offsite no AWS Glacier do que é mais importante, mas não de tudo.

Muita gente pergunta por que eu não uso S3 ou outro armazenamento em nuvem pra tudo. Devolvo a pergunta: pensa por dez segundos. Quanto tempo leva pra transferir 90 TB pela sua internet? Faz a conta:

• Com 1 gigabit de upload cravado, sem cair um segundo: mais de 8 dias.
• Com 500 megabits: quase 17 dias.
• Com 100 megabits, que é upload bom pra muita casa: 83 dias.

E isso é pra subir. Na hora do desastre você precisa baixar tudo de volta, com o relógio correndo. Sem contar o aluguel: 90 TB em S3 padrão custam uns US$ 2 mil por mês no preço de tabela. Nuvem é ótima pro subconjunto crítico, que é como eu uso. Pro acervo inteiro, a física e a fatura não deixam.

Lições

Fui colocado numa situação impossível numa segunda de manhã, agi na hora do melhor jeito que consegui, e provavelmente vou sair dessa quase ileso. Vamos ver, o HBS 3 ainda está sincronizando. O que eu levo disso:

1. Paridade simples não basta pra disco grande. Com discos de 20 TB, a reconstrução leva dias e lê tudo. É nesse intervalo que o segundo disco costuma aparecer. RAID-6, SHR-2 ou RAIDZ2.
2. Não confie só na notificação do fabricante. Olhe o SMART e o log dos discos antes de começar qualquer troca. Eu não olhei, porque confiava que seria avisado.
3. Troque primeiro o disco doente, depois o disco pequeno. Upgrade de capacidade em array com disco suspeito é roleta.
4. Deixe folga. Eu estava trocando disco porque o volume estava no teto. Alerta em 85% existe pra isso.
5. Tenha pra onde copiar. A minha saída custou R$ 185 mil porque eu não tinha plano B. Um segundo NAS, mesmo modesto, com o que importa, teria me dado tempo pra comprar com calma.
6. RAID não é backup. Eu sei disso, ensino isso, e mesmo assim só tinha offsite de uma parte.

A cópia terminou e eu já sei o tamanho do estrago: zero. A recuperação completa vem a seguir.

Seis dias depois: o final da história

Quando publiquei a primeira parte, eu tinha uns 20 TB copiados e nenhuma certeza. O desfecho: terminei de evacuar os ~91 TB, verifiquei arquivo por arquivo, e não perdi nada por acidente. Nem o que estava na fatia de RAID caída, porque ela continuou legível até o fim.

Quem operou a recuperação foram os meus dois agentes. O agente do desktop controla meu PC e os dois NAS por SSH, e o agente do homelab cuida do servidor onde rodam meus 57 containers. Os dois se coordenam por mensagem: um deixa relatório na caixa do outro, e eu acompanho a conversa.

Essa parte importa porque nada do que vem a seguir foi eu digitando comando. Eu tomei as decisões; eles executaram, mediram e erraram feio algumas vezes, como você vai ver.

O HBS 3 estava me traindo quieto

Na primeira parte eu contei que o HBS 3, puxando os compartilhamentos do Synology por CIFS, chegou a 400 MB/s depois dos ajustes. O que eu não sabia: velocidade era o menor dos problemas dele.

Dois defeitos apareceram quando o agente conferiu o inventário da origem contra o que o HBS reportava:

• Ele não entrava onde não tinha permissão e não contava pra ninguém. O HBS monta o Synology como o meu usuário. O diretório Bitcoin/data, 901 GB com a wallet e o chainstate do meu nó, pertence ao uid 101 e é fechado pra qualquer outro. O CIFS não conseguia entrar ali, e o HBS reportava sucesso sem registrar a omissão. Um backup “verde” que deixa o nó de Bitcoin inteiro pra trás.
• Ele pulava arquivos com nome “não suportado”. 113 arquivos, registrados só numa tela de detalhe que ninguém abre durante uma cópia de dias.

Ferramenta de backup que reporta sucesso omitindo o que não conseguiu ler é pior que uma que falha gritando. Verifique o backup contra um inventário independente da origem, nunca contra o log da própria ferramenta.

Abandonamos o HBS. O agente abriu SSH nos dois NAS, habilitou o servidor rsync no QNAP e o Synology passou a empurrar direto pro rsyncd dele, sem nada passar pelo PC. O wrapper de cada job: rsync -a --numeric-ids -W --partial --timeout=600, tentativas com retry, e nunca --delete. O --numeric-ids preservou os uids originais sem precisar de chown depois, o --partial fez qualquer interrupção virar continuação, e a ausência de --delete fez do destino sempre um superconjunto: re-shardar ou matar um job nunca custava dados.

O gargalo não era o disco quebrado

Um contexto que faltou na primeira parte. Esse Synology nasceu com oito Seagate IronWolf de linha consumidora, e eu vinha trocando um por um por IronWolf Pro de 20 TB ao longo dos anos. A desgraça aconteceu exatamente num desses upgrades: eu troquei o disco 1 pelo Pro novo e, durante a reconstrução, o disco 8 falhou. Sobrou um único disco antigo no array: o disco 2.

E foi ele, não o disco 8, o gargalo da evacuação. Medido sob carga:

• Disco 2 (o consumidor antigo, com 37 mil horas de uso): 91% de utilização, entregando 27 MB/s, cada I/O demorando 4 a 15 vezes mais que os irmãos.
• Os seis Pro: entre 34% e 45% de utilização, parados esperando ele.

Em RAID-5 (e no SHR), uma leitura sequencial atravessa o stripe inteiro, e o stripe só completa quando o membro mais lento responde. Um disco lento limita o array inteiro: por causa dele, o array não passava de uns 200 MB/s enquanto seis discos bons sobravam. E o SMART dele estava limpo, zero setores realocados. Disco consumidor costuma vir sem limitação de tempo de recuperação de erro (ERC/TLER) ativa, então ele tenta reler setor marginal por segundos, internamente, sem contabilizar nada. O cache NVMe do Synology desviava parte da leitura dos pratos e ajudava a maquiar o sintoma.

O disco que falha e o disco que te atrasa não precisam ser o mesmo, e SMART “PASSED” não diz nada sobre latência. Array lento se diagnostica com utilização e tempo de resposta por disco, não com SMART.

Paralelizar rsync é ciência, não chute

Primeiro instinto: mais streams. Errado, e por duas vezes.

Na primeira, um bug nosso: um relançamento “limpo” de jobs não matou nada, porque o ps do busybox do Synology trunca a linha de comando e o grep de verificação não achou os processos velhos. Resultado: 32 rsyncs rodando pra 7 destinos, quatro a cinco escritores por árvore, o QNAP com os buffers de recepção entalados, e o cabo transmitindo 516 MB/s enquanto o array lia 140. Depois da limpeza (enumerando /proc/*/cmdline, nunca mais confiando no ps), a vazão útil subiu de 140 pra 181 MB/s com a carga total desabando.

Na segunda, a medida inverteu o senso comum: com árvores de arquivo grande, menos streams eram mais rápidos, porque o tamanho médio de cada requisição de leitura triplicava e o array fazia corridas sequenciais longas em vez de ficar pulando de posição.

Só que árvore de arquivo pequeno é outro esporte. O TERACHAD/Emulators tem 21 TB em 3,4 milhões de arquivos com média de 6 MB: trabalho limitado por latência (stat, criação, metadados), não por banda. E ali a paralelização agressiva funcionou, com um detalhe: o shard certo se escolhe por contagem de arquivos, não por tamanho. Um único diretório, ROMS_FINAL/xbox-hdd-ready, segurava 995 mil dos 1,59 milhão de arquivos do ROMS_FINAL, com média de 1,7 MB por arquivo. Isolando ele dos ISOs multi-gigabyte:

De 2,8 a 3,2 vezes a vazão média do stream único, na mesma máquina, na mesma rede. E tem um motivo bonito: com o array faltando um membro, leituras de dados que não moram no disco 2 não precisam dele, então a concorrência extra deixava os outros discos trabalharem enquanto ele engasgava.

“Mais paralelismo” e “menos paralelismo” são as duas respostas erradas como regra geral. Trabalho limitado por banda se divide pouco; trabalho limitado por latência se divide muito, e por contagem de arquivos. Meça antes de escolher.

Copiar é metade do trabalho; provar é a outra metade

Cada job que terminava passava por um dry-run do mesmo rsync, com os mesmos excludes: zero arquivos precisando transferência significa destino idêntico por tamanho e data. E mesmo assim quase deu errado, porque a verificação herdava os excludes da cópia: uma árvore excluída da transferência ficava excluída da própria prova. Refazendo a checagem sem excludes, apareceram 952 arquivos e 191 GB faltando no Downloads (exatamente os lotes que eu tinha separado como “única cópia existente”) e os repositórios restic antigos, que um nome de diretório parecido no QNAP fingia cobrir: o ID interno dos repositórios provou que eram outros, não cópias.

Teve também deriva de origem: uma árvore verificada como completa recebeu 16 GB de checkpoints novos no Synology depois da checagem, e só a re-verificação final pegou. Verificação tem prazo de validade.

E uma decisão consciente, registrada pra ninguém me acusar de esconder: os históricos antigos de backup (uns 2 TB de snapshots restic e um set de duplicity de 2025) ficaram pra trás por escolha minha, porque os repositórios novos no QNAP já cobrem o mesmo conteúdo a partir de agora. Perda deliberada de histórico, não de dado.

Fecho da conta: 17 jobs de rsync, todos exit 0, todos verificados, uns 5,9 milhões de arquivos byte-idênticos, e o desligamento do Synology só aconteceu depois de cada árvore provada.

Enquanto isso, no homelab

Do outro lado da casa, o servidor marvin, que monta o NAS por NFS e roda os 57 containers, quase morreu de pé. NAS morto mais montagem NFS “hard” mais 57 containers reiniciando sozinhos deu uma fila infinita de I/O ininterruptível: a máquina respondia ping, mas o sshd não conseguia completar um handshake. E cada tentativa insistente de SSH só piorava, porque o OpenSSH pune fonte repetitiva aumentando o banimento. A gente batia na porta e a porta aumentava a tranca.

A saída foi parar de bater: pausei os torrents pela API do qBittorrent (que continuava respondendo), fui no console físico, desabilitei o Docker, reinicie, e o servidor voltou. Um watchdog que eu nem lembrava que existia tinha, sozinho, derrubado os 14 containers dependentes do NAS antes de qualquer banco corromper: o LevelDB do bitcoind abriu limpo na primeira tentativa.

A migração em si foi elegante: o fstab apontou pro QNAP e os pontos de montagem antigos viraram symlinks pra dentro do novo. Nenhum docker-compose mudou. Aí veio a pegadinha do NFS da QNAP: permissão é por cliente. O desktop estava liberado sem squash, mas as escritas do marvin caíam como uid 1001, bloqueando tudo que escreve no NAS. A primeira tentativa de correção ainda virou a montagem pra read-only no meio do primeiro backup restic, que sobreviveu na base do retry. Configuração final: leitura e escrita, sem squash pra ninguém, testada com touch e ls -ln de cada cliente, porque “funcionou no desktop” não prova nada sobre o servidor.

Depois disso foi ressurreição árvore por árvore: cada serviço só subia quando a árvore dele estava verificada no QNAP. Em dois dias, 57 de 57 containers de volta, e um backup restic novinho rodando diariamente pro QNAP.

O kernel novo derrubou o NVMe

No meio da recuperação, um susto de graça do servidor. Sete minutos depois do backup noturno começar, o controlador NVMe sumiu em silêncio: todo binário tomou SIGBUS, Docker e sshd morreram, e nada restou gravado em lugar nenhum, porque o log mora no dispositivo que morreu. Nem kernel panic: só silêncio.

O mesmo workload tinha rodado bem horas antes no kernel 7.2.6 e morreu no 7.2.9. Desligar o APST (o gerenciamento de energia do NVMe) não resolveu: segunda queda idêntica, regressão do 7.2.9 confirmada por eliminação. O MicroOS é transacional e baseado em snapshot, então o rollback foi um reboot pra linhagem 7.2.6, não uma reinstalação. As atualizações automáticas ficaram propositalmente quebradas naquela linhagem pra ninguém voltar pro 7.2.9 sem supervisão, e o teste do 7.2.8 fica pra quando eu puder sentar do lado.

Sistema operacional transacional transforma regressão de kernel em reboot. Sem snapshot de sistema, essa noite teria custado muito mais caro.

O susto do thick provisioning

No QNAP, a cópia inteira rodou sem snapshot nenhum: numa migração em massa, snapshot é peso morto. Terminada a cópia, fui ligar a agenda de snapshots do ZFS e tomei um erro seco: “pool free space is not enough”. Com 20 TB livres.

As duas afirmações eram verdade sobre coisas diferentes. A pasta CHAD tinha sido criada como thick: dos 100 TB de quota, o ZFS reserva os 100 TB, e pra tirar snapshot de um dataset com reserva, o pool precisa garantir espaço pra sobrescrever todos os blocos referenciados enquanto o snapshot prende as cópias velhas. Na conta: 80 TB escritos mais 100 TB reservados, contra 126 TB utilizáveis do pool. Não fecha. E o df mente dos dois lados, porque mede a pasta contra a quota, não contra o pool.

A correção foi converter a pasta pra thin, que o QuTS hero faz in-place, escondido na tela de Management da pasta, não no diálogo de edição onde “Thick” parece texto estático. Em thin, o número vira teto em vez de reserva: a reserva de 10 TB evaporou, o pool passou a ter 39 TB livres, e o primeiro snapshot saiu consumindo 334 KB sobre 79,9 TB referenciados. O ZFS não precisava de quase nada; a reserva é que exigia garantia de 100 TB pra autorizar.

Agora o QNAP tem agenda de snapshots com política de retenção, como devia ser desde o primeiro dia:

Duas notas de rodapé pra quem montar um desses. Se a sua pasta thin tiver alerta de 80%, suba a quota pra folga estética, porque o alerta mede contra a quota e não contra o pool. E o gargalo real desse QNAP é RAM: 7 GB pra um pool de 174 TB. O mínimo oficial do QuTS hero é 8 GB, e a prática recomendada pra esse porte é 16 pra cima. O tamanho do cache ARC governa a velocidade de metadados, e foi por isso que as varreduras de árvore inteira durante a migração eram lentas. Upgrade de RAM vale mais que qualquer ajuste fino.

O Synology nasce de novo

Com tudo verificado no QNAP, o Synology finalmente pôde ser operado. Troquei os discos 2 e 8 por IronWolf Pro novos, apaguei o pool ferido e recriei do zero, desta vez em SHR-2, o modo com dois discos de paridade, o RAID-6 deles. O pool novo saiu com 100 TB, todos os discos saudáveis:

Ele volta a trabalhar como alvo de réplica, e não mais como ponto único de falha. O QNAP segue como principal, em RAIDZ2, com 87 TB dos 126 TB usados e os snapshots agendados:

O que eu levo da segunda metade

1. Desconfie do sucesso silencioso. O HBS reportava verde enquanto deixava 901 GB pra trás. Backup se verifica contra inventário da origem.
2. SMART não mede lentidão. O disco que quase matou a evacuação estava “saudável”. Utilização e latência por disco contam a verdade.
3. Paralelismo se calibra medindo. Bandwidth-bound divide pouco, latency-bound divide muito, e o shard se escolhe por contagem de arquivos.
4. Verificação não herda exclude. Se a prova usa os mesmos filtros da cópia, ela só reafirma as suposições da cópia. E verifique de novo imediatamente antes de destruir a origem.
5. Permissão de NFS é por cliente. Teste escrita de cada máquina que vai usar.
6. Não bata repetidamente num sshd morrendo. Cada tentativa alonga o banimento. Uma tentativa paciente, ou console físico.
7. O reparo perigoso vem por último. O array ficou degradado e lento até o último byte estar provado em outro lugar; só então reconstruir deixou de custar qualquer coisa.

Saí dessa melhor protegido do que entrei: dois NAS, cada um com seu RAID-6, snapshots agendados no QNAP, restic diário, e o Glacier pro que é crítico. O desastre me custou um QNAP, dois discos e uma semana. Podia ter custado 90 TB.

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.

Eu uso LLM pra tudo há quase dois anos, publiquei dezenas de projetos com elas, e minha conclusão é outra: o que elas fazem de melhor é reproduzir o que já existe. E isso cobre uma fatia gigante do trabalho corporativo, não se engane. Mas tem uma fronteira que elas não cruzam com facilidade, e eu passei os últimos meses esbarrando nela de propósito.

Esse artigo mostra onde ela fica, com evidência dos meus próprios projetos e da pesquisa que existe sobre o assunto. E tem uma hipótese que eu já adianto aqui e defendo no decorrer do texto: se LLM é tão boa em código, os provedores têm muito a agradecer às décadas da comunidade open source, que protegeu a liberdade do código e publicou tudo de graça. Sem esse patrimônio, não existiria Copilot, Cursor, Claude Code, nada disso.

Um disclaimer antes de começar: o que eu vou argumentar aqui é especulativo, baseado em observação e nos dados públicos que existem. Ninguém fora dos laboratórios sabe exatamente como cada provedor treina os próprios modelos, e isso varia de provedor pra provedor e de versão pra versão. O que vale hoje pode não valer na próxima geração. Leve tudo com um grão de sal.

O ponto cego do treinamento

Todo LLM foi treinado no que é público. A internet pública inteira, e no caso de código, o GitHub público. O dataset canônico de código aberto, o The Stack v2 da BigCode, é explícito sobre isso: ele é derivado do Software Heritage, um arquivo de “todo o código-fonte de software publicamente disponível”. São 67,5 TB, 3,28 bilhões de arquivos únicos, 104,2 milhões de repositórios. Gigantesco. E todo público.

Agora olha o outro lado. O Octoverse 2025, relatório oficial do GitHub, diz que 81,5% das contribuições na plataforma aconteceram em repositórios privados. Isso é só o GitHub. Fora dele tem:

• o código interno de toda empresa que nunca encostou num servidor público;
• o fonte de todo software proprietário;
• o código de todo jogo comercial;
• e o de todo sistema embarcado.

Nada disso nunca entrou no treino.

Pensa no que isso significa: o modelo conhece profundamente o que o mundo já publicou, e é cego pro que o mundo mantém fechado. Quando você pede um formulário React, ele está reproduzindo padrões que viu milhões de vezes. Quando você pede algo que ninguém nunca fez em público, ele está operando num território onde o mapa dele é branco.

Por que tá todo mundo entregando tanto, tão rápido?

Antes de entrar nos limites, vale registrar o lado que funciona, porque é ele que explica a sensação de que todo mundo virou fábrica de app.

Olha o que tá pipocando na comunidade: o Spotifast e o ZapFast, clientes nativos de Spotify e WhatsApp escritos em Rust por uma pessoa só, rodando em Linux, macOS e Windows. Nada ali é tecnologia nova. É o serviço que já existia, embrulhado num app nativo enxuto, em cima de biblioteca que já existia, fazendo o que os times oficiais sempre puderam fazer mas nunca quiseram gastar o tempo deles. Esse trabalho ficou barato, porque LLM treinada em tudo que é público é boa demais justamente nisso: replicar.

Meus próprios projetos seguem o mesmo padrão. O FrankMD é um web app de notas em Markdown com cara de Visual Studio e features que já existiam nos meus outros apps. O Frank Sherlock é um organizador de imagens local que, no fundo, é um gerenciador de arquivos com thumbnails e busca, coisa que existe aos montes. Nenhum dos dois inventa nada: são mashups de peças conhecidas, montadas do jeito que eu sempre quis. A LLM faz a parte chata, e é por isso que a velocidade aparece.

O exemplo mais didático é o meu cliente de email. Uso o Geary há anos, e duas faltas pequenas sempre me irritaram: o autocomplete de destinatário fraco e um painel lateral que eu queria poder esconder. Coisa boba, que nunca justificou montar ambiente de build, aprender o toolchain do projeto e estudar o código só pra duas features. Esse ano eu finalmente resolvi os dois: um módulo de autocomplete, um módulo pra esconder o painel, e um fork inteiro com meus patches. Virei mantenedor de melhorias que adiei por anos, não porque eu fiquei mais rápido, mas porque a parte chata ficou barata.

Repara no que todos esses casos têm em comum: o problema já tinha sido resolvido antes, em outro lugar, de outro jeito. O mapa existia; o que não existia era mão de obra barata pra refazer o caminho. É a reprodução trabalhando a favor, e é por isso que o seu feed tá cheio de gente entregando app novo toda semana.

Agora guarda esse raciocínio. O resto desse artigo é sobre o que acontece quando o mapa acaba.

Quatro experimentos caseiros

Eu não tô teorizando. Nos últimos meses eu rodei uma maratona de projetos de retrocomputação que são exatamente o caso patológico: trabalhar com software proprietário de 30 ou 40 anos atrás, cujo código-fonte nunca foi público. É o ponto cego perfeito.

nes-to-sms: o projeto que eu desisti

O nes-to-sms é um recompilador estático de NES pra Master System. A ideia: pegar a ROM binária de um jogo de NES, traduzir instrução por instrução de 6502 pra Z80, converter os tiles, e gerar um ROM de Master System que roda no hardware real. Esqueça emulador e port manual: é uma máquina que transforma um jogo num outro.

Recompilador estático de NES existe, o NESRecomp traduz pra C e roda nativo em PC, e eu estudei ele de perto. Mas cruzar de um console pra outro console de 8 bits, com orçamento de clock e de VDP totalmente diferente, ninguém nunca fez. Não existe referência pública, não existe paper, não existe projeto abandonado pra copiar.

Os números do projeto: 349 commits, 31 dias ativos espalhados por quase 4 meses, ~110 mil linhas de engine em Rust e Z80, 668 testes passando no último run registrado no README. E o resultado? Super Mario Bros. jogável (lento, com áudio limitado, mas jogável), com a trajetória de RAM byte a byte igual à do NES numa rota de ~4.900 frames (o diff deixa o áudio e parte do buffer de VRAM de fora). Castlevania jogável na fase 1. SMB3 renderizando. E uma fila de jogos que bootam três frames e morrem.

E não foi por falta de empurrar os modelos. Só nesse projeto:

• passaram quatro gerações de Claude (Opus 4.7, Fable 5, Opus 4.8, Fable 5.1), com 213 commits co-assinados e 104 commits linkados a sessões no histórico, mais sessões de Codex nos trechos sem co-autoria, com direito a handoff documentado entre agentes;
• teve até auditoria entre gerações: uma sessão nova de agente revisou os 55 commits anteriores e reverteu conclusões que a geração anterior tinha exagerado;
• só a caçada aos travamentos do Castlevania consumiu 45 commits em 5 dias;
• o sprint final de setembro foram 176 commits em 17 dias antes de eu decretar a pausa;
• e as regressões estão registradas pelo nome no histórico: “H.7 tried and reverted”, “record the reverted map-bank-hold attempt”, “correct-but-reverted result”, além de três hipóteses de alavanca compartilhada testadas e rejeitadas nos últimos três dias de projeto.

Tokens eu não medi de forma confiável nesse projeto, então não vou inventar número. Mas 349 commits com 668 testes segurando cada passo já dão uma ideia do custo.

Repara no detalhe que importa: o único jogo que ficou realmente pronto é o Super Mario Bros. Por quê? Porque SMB é o jogo mais dissecado da história. Existe uma disassembly completa e pública que a comunidade usa há mais de uma década, com cada função nomeada e comentada. Eu alimentei isso no perfil do jogo e a LLM tinha um mapa completo pra trabalhar. Pros outros jogos, não existe mapa. E sem mapa, cada jogo novo morria alguns frames depois do boot por divergência de fluxo de controle, e cada um exigia uma caçada forense instrução por instrução que não rendia nada pro jogo seguinte.

O próprio projeto documentou o padrão de giro. Teve uma campanha inteira de otimização que durou semanas tentando cortar o custo de emular flags do 6502 no Z80.

Aí em setembro eu parei pra comparar com o port manual que um hacker chamado lackoftrack27 fez de SMB pra Master System, escrito por um humano, rotina por rotina. Pela análise que a gente fez do código dele, o port humano roda dentro do orçamento de frame, com uma folga que estimamos em ~90% de utilização. A minha máquina, depois de meses de otimização, ainda precisava de overclock.

E o documento de análise cravou por quê: quando removemos 30% das chamadas de emulação de flag, o tempo mal se moveu.

As flags nunca foram o gargalo.

A otimização certa era redesenhar a estrutura de dados: transpor o array de objetos pra páginas de RAM. É um truque que depende de saber que “o registrador X aqui é sempre um índice de objeto”.

Essa invariante existe na cabeça do programador que escreveu o jogo em 1985. Ela não existe no fluxo de instruções. Um tradutor estático não tem como descobri-la. E o LLM, por meses, não descobriu.

O banner de pausa que eu escrevi no README é direto: a paridade em hardware real “pode ser fundamentalmente inalcançável” e, citando, “this may be a limit of the current frontier coding models as much as of the approach”.

gg-to-sms: o pivô pro território com mapa

No mesmo dia em que pausei o nes-to-sms, eu comecei o gg-to-sms: converter jogos de Game Gear pra Master System com a tela alargada. A diferença que importa é que esse problema não é novo. A cena de romhacking vem convertendo jogos de GG pra SMS à mão há vinte anos, e o catálogo que eu montei no projeto contou ~186 deles. Ou seja: existe corpus, existe ground truth, existe padrão pra aprender.

Resultado: em um dia de trabalho,

• a fase de pesquisa estava completa;
• o catálogo dos 373 jogos de GG estava montado;
• o scanner de pontos de patch foi validado contra patches humanos reais, acertando os endereços com margem de 8 bytes;
• e de quebra a ferramenta achou bugs de verdade em patches de vinte anos atrás que a cena inteira nunca tinha notado.

O modelo era o mesmo; o que mudou foi o problema, que dessa vez tem referência.

E mesmo assim: até agora, zero jogos passaram na revisão de aceitação do viewport. O ponto novo do projeto (a máquina que gera os patches sozinha, que é a parte que ninguém nunca fez) continua por fazer.

super-mario-deluxe-fixed: quatro dias e 436 milhões de tokens

Esse foi um sprint de 4 dias, praticamente uma sessão única de Codex que consumiu 436 milhões de tokens de input. O objetivo: rodar Super Mario Bros. Deluxe de Game Boy Color com tela alargada em resolução de NES, coisa que nenhuma ferramenta existente faz com sprites vivos.

Subiu pra jogável em 4 dias. Mas olha o alicerce: um emulador pronto vendado como dependência, e uma disassembly dormente do jogo que alguém tinha publicado anos atrás, que a própria documentação do projeto chama de “o artefato mais importante”.

O trabalho novo foi o renderizador customizado, e ele parou em 21 de 32 fases completadas. As que faltam travam em timing de plataforma móvel. O projeto tá parado no meio do sprint desde então, e ainda não desisti dele.

E um detalhe que diz muito: eu tive que dirigir o QA olhando screenshots, porque o agente entregava coisa com glitch gráfico e não percebia sozinho.

super-mario-bros-35: tudo que funcionou tinha dono

Esse é o clone offline do Super Mario Bros. 35, o battle royale que a Nintendo tirou do ar. O que funcionou nele: tudo que foi construído em cima de artefato existente.

• O engine é uma reconstrução em C feita por outra pessoa com Ghidra.
• Os pesos iniciais da IA vieram de checkpoints publicados.
• As regras de rede foram inferidas de um reverse engineering público do netcode.
• Até a física: o bug central foi diagnosticado porque eu tinha uma trajetória de referência gravada pra comparar frame a frame.

O que não funcionou: as fases de castelo com labirinto. O treinamento por reforço estaciona nelas. 46 milhões de passos de agente, reinício de treino do zero, recompensa anti-loop, e no fim a única coisa que resolveu uma das fases foi cirurgia manual de bias no modelo treinado. Das 32 fases, 19 limpas. As piores continuam travadas.

E o processo degenerou num padrão que eu reconheço de todos esses projetos: quando o treinamento não resolve, o fluxo vira roleta de seleção de checkpoint, dezenas de variações de bias e de cabeças de saída, jogando permutação e computação no problema no lugar de uma correção de princípio.

O padrão que eu sinto

Isso é intuição de quem operou a máquina por meses, não dado duro. Mas o padrão se repete com Claude, com GPT, com Kimi, com GLM, então não parece defeito de um modelo.

O começo de qualquer projeto é uma maravilha. Os primeiros milestones voam, porque montar estrutura, escrever harness, replicar API, isso tudo é território coberto. Aí o projeto chega na parte que ninguém nunca fez, e a velocidade desaba. O agente começa a girar: tenta uma hipótese, regride outra coisa, reverte, tenta de novo. O histórico de commits do nes-to-sms tá cheio de mensagens honestas tipo “tentativa revertida” e “hipótese fechada com resultado correto mas revertido”. Muito token queimado, pouco avanço.

Minha leitura do que acontece por dentro: o sampling de tokens é probabilístico. Quando o problema é parecido com o treino, os tokens certos têm probabilidade alta e a resposta sai direto. Quando o problema é inédito, a probabilidade do caminho certo é baixa, e o processo vira uma força bruta direcionada: tentativa e erro guiada, mas tentativa e erro mesmo assim.

A saída que eu encontrei pra esse giro é sempre a mesma: dar um oráculo. Se eu consigo definir “o resultado tem que ser igual a X” (uma imagem de referência, uma trajetória gravada, um emulador ciclo-exato como ground truth), a máquina consegue iterar até esbarrar no X. No nes-to-sms, cada destravamento real veio disso: a disassembly do SMB, o frame-diff, o emulador de referência. Quando eu não consigo definir o X direito, ela gira indefinidamente.

A segunda estratégia que funciona: caçar projeto abandonado, paper, qualquer material que o modelo nunca viu mas que aproxima o problema, e enfiar no contexto. Isso aquece a distribuição e melhora muito o resultado. Mas é limitado: se nada parecido existe, não tem o que alimentar.

Não é anedota, é o que a pesquisa mede

A parte boa é que eu não preciso depender da minha intuição. Tem pesquisa séria medindo exatamente isso.

O estudo GSM-Symbolic da Apple pegou problemas de matemática de benchmark e fez duas coisas simples: trocou só os números, e depois adicionou uma única frase irrelevante no enunciado. Resultado: a performance cai só de trocar os números, e despenca até 65% com a frase irrelevante. A hipótese dos autores, no texto: “LLMs atuais não fazem raciocínio lógico genuíno; eles replicam passos de raciocínio dos dados de treino”.

O GSM1k da Scale AI criou um espelho do GSM8K escrito do zero por humanos, garantidamente sem contaminação, e viu quedas de até 8% em várias famílias de modelo, com sinais de overfitting sistemático nas piores. Pra ser justo com o paper: os autores dizem que os modelos de fronteira mostram sinais mínimos de overfitting e que todos generalizam até certo ponto pra problemas novos. O sinal existe, o tamanho dele é discutível.

O LiveCodeBench fez o teste mais limpo de todos: avaliar em problemas de código publicados depois do corte de treinamento. Performance inflada em problema pré-corte e queda em problema pós-corte em vários modelos populares, o sinal clássico de contaminação.

E tem o ARC-AGI, o benchmark do François Chollet desenhado especificamente pra ser à prova de memorização: cada tarefa é inédita, nenhuma parecida existe no treino. No ARC-AGI-2, lançado em março de 2025, a tabela oficial diz: LLMs puros marcam 0%, sistemas de raciocínio ficam em dígito único, e cada tarefa de avaliação foi resolvida por pelo menos dois humanos em até duas tentativas. O Chollet, aliás, resumiu minha tese melhor que eu, lá em fevereiro de 2024:

“LLMs não são AGI, são um grande ajuste de curva num dataset muito grande. Funcionam por memorização e interpolação. Mas essa curva interpolativa pode ser tremendamente útil, se você quer automatizar uma tarefa conhecida que casa com a distribuição do treino. Memorização funciona, desde que você não precise se adaptar ao novo.”

No mundo real, o estudo que mais me impressionou foi o RCT da METR: 16 desenvolvedores experientes, 246 tarefas reais nos próprios repositórios maduros deles, randomizado com e sem IA. Os devs apostavam que IA ia acelerar 24%. Mediu-se: ficou 19% mais lento. Repara onde isso aconteceu: código maduro, privado, cheio de contexto que o modelo nunca viu. Exatamente o ponto cego.

E o benchmark favorito da indústria pra dizer que “IA já faz engenharia de software”, o SWE-bench, é só Python, 12 repositórios open source famosos, ou seja, a fatia mais coberta do treino. A métrica de sucesso da indústria mede o território com mapa.

Até a literatura de código legado diz a mesma coisa: um paper de 2026 sobre LLMs gerando COBOL crava que, nessas linguagens legadas, “a maior parte do código de produção está em sistemas corporativos e raramente é publicamente disponível”. É a tese desse artigo, dita por outras pessoas.

O steelman: força bruta direcionada funciona, a preço de ouro

Antes de fechar, vale encarar o argumento mais forte contra mim. Steelman é isso, pra quem não conhece o termo: o oposto de espantalho. Em vez de atacar a versão mais fraca do argumento contrário, você responde à versão mais forte que ele pode ter. E ela existe e é boa.

Em maio de 2025 o DeepMind publicou o AlphaEvolve: um sistema que achou um algoritmo de multiplicação de matrizes 4x4 complexas com 48 multiplicações escalares, melhorando o recorde do Strassen de 1969 nesse cenário específico. Numa lista de mais de 50 problemas abertos de matemática, ele redescobriu o estado da arte em ~75% dos casos e melhorou a melhor solução conhecida em 20%. Isso é novidade de verdade, não reprodução.

O o3-preview da OpenAI saltou pra 75,7% no ARC-AGI-1 em dezembro de 2024, 22 pontos acima do melhor resultado anterior no mesmo conjunto de avaliação, e a configuração de compute alto chegou a 87,5% a um custo estimado de US$ 4.560 por tarefa.

E lá em 2016 o AlphaGo fez o lance 37 contra Lee Sedol, um lance que os dados do próprio DeepMind estimavam ter 1 chance em 10 mil de ser jogado por um humano, provando que busca sobre modelo pode transcender imitação.

Agora olha o mecanismo dos três:

• O AlphaEvolve é um loop evolutivo: o LLM propõe mutações, um avaliador automático pontua, a seleção itera.
• O o3 faz síntese de programas em tempo de teste, explorando o espaço de soluções.
• O AlphaGo é busca em árvore sobre aprendizado por reforço.

Se teve “insight” em algum deles, foi do sistema de busca ao redor do modelo: os três são força bruta direcionada com um verificador barato, o mesmo mecanismo que eu descrevi acontecendo nos meus projetos. A diferença é que o DeepMind tem oráculo perfeito e orçamento infinito: na configuração que chegou a 87,5%, o o3-preview gastava milhares de dólares por tarefa do ARC pra fazer o que um humano faz de graça. A própria ARC Prize escreveu a ressalva:

“Sabemos que uma busca de força bruta poderia acabar resolvendo o ARC-AGI, dados recursos e tempo de busca ilimitados. Isso não representaria inteligência de verdade.”

Resumindo: novidade sai, mas sai por busca cara sobre um oráculo, à base de tentativa e erro guiada. Se o seu problema tem verificador barato e você tem tokens pra queimar, dá pra ir longe. Foi assim que o nes-to-sms chegou onde chegou: 668 testes e ground truth de emulador segurando cada passo. Mas quando não tem oráculo, não tem corpus e não tem referência, você está pagando força bruta em dólar, com regressões no caminho, e o teto aparece.

E quando a força bruta vence, dá pra medir o tamanho da tentativa e erro. Dois casos recentes que eu já cobri em detalhe aqui no blog:

• A prova de Navier-Stokes da OpenAI: cerca de 10 mil agentes rodando em paralelo por 88 horas, queimando na casa de 130 bilhões de tokens de saída num único problema. O Noam Brown, da OpenAI, confirmou que o resultado “custou milhões”, e a New Scientist estimou uns US$ 15 milhões a preço de tabela. E nem essa montanha de compute partiu do zero: a prova se apoiou no maquinário que matemáticos humanos publicaram ao longo de décadas atacando o problema e os problemas irmãos. Sem o mapa dos humanos e sem o orçamento da OpenAI, não tem prova.
• O incidente da Hugging Face: a reconstrução forense contou ~17.600 ações de atacante até os agentes conseguirem executar código em 41 servidores de produção da Hugging Face e pegar root; de quebra, no ambiente da própria OpenAI, leram 956 segredos do gerenciador de segredos da empresa. Não foi um insight brilhante de um lance só: foi um enxame executando tentativa atrás de tentativa, com verificação automática dizendo o que colou. A “inteligência” da manchete é volume.

É esse o tamanho da conta quando você força o modelo pra fora do território do treino: tentativa e erro em escala industrial, sem garantia nenhuma de que a busca acha o que você precisa. E quem pode assinar esse cheque é meia dúzia de empresa no mundo, nível OpenAI e Anthropic, com orçamento praticamente ilimitado de compute. Pro Zé da esquina, com cartão de crédito e uma API key, o teto chega muito, muito antes.

Mas tentativa e erro não é aprendizado novo?

Aqui mora uma confusão que eu vejo toda hora, e vale desfazer porque ela contamina a interpretação de tudo que eu escrevi até agora.

Quando você lê que a Anthropic tem data centers do tamanho de cidades, dá a sensação de que existe uma IA gigante usando aquelas máquinas todas ao mesmo tempo, pensando, acumulando experiência a cada interação. A realidade é bem mais medíocre que isso.

Um modelo tipo Fable ou Astra é um arquivo de computador. Arquivo estático, nem banco de dados é: depois que o treinamento e o pós-alinhamento terminam, aquele arquivo é trancado e fica read-only. O que roda no data center são cópias desse arquivo. Cada usuário que consome o modelo está executando uma cópia dele num servidor diferente, isolada das demais, sem colaborar com nenhuma. A sua sessão não conversa com a sessão de ninguém, e nada do que acontece nela volta pro arquivo original.

Aprendizado novo só entra num lugar: na próxima leva de treinamento. Quando a Anthropic tinha o Opus 4.7 e lançou o 4.8, foi ali que conhecimento novo foi assado no modelo, num processo que custa milhões e leva semanas. Fora disso, o arquivo não muda um byte.

Seu agente queimando milhões de tokens em tentativa e erro está contribuindo exatamente zero de aprendizado novo pro modelo que ele usa.

Aquela maratona de 176 commits do nes-to-sms? Do ponto de vista do modelo, não aconteceu. O Opus que rodou o último commit sabia exatamente o mesmo tanto que o do primeiro. Quem aprendeu alguma coisa fui eu, não ele. E é por isso que a metáfora do “estagiário que aprende com o tempo” está errada: estagiário acumula. Modelo não. O que acumula na maratona é o seu contexto, suas notas, seu CLAUDE.md, seus testes. O ativo que você constrói é seu, e evapora se você não documentar.

Essa é também a resposta pra quem acha que “é só deixar o agente rodando que ele aprende o domínio”. Ele não aprende domínio nenhum: ele explora o espaço com o conhecimento congelado do dia do treino, e no dia seguinte acorda com amnésia. Se o domínio não estava no treino, cada sessão sua recomeça do zero absoluto, e toda a inteligência de navegação tem que vir de você de novo.

“Mas e se a IA treinar a IA?”

Essa é a pergunta seguinte do amador, e ela parte de uma premissa errada: a de que isso seria novidade. IA treinando IA existe há décadas e tem nome: aprendizado por reforço. O AlphaGo já fazia isso em 2016, jogando milhões de partidas contra si mesmo. O AlphaZero, em 2017, levou a ideia ao limite: aprendeu xadrez, shogi e Go partindo do zero absoluto, sabendo só as regras de cada jogo, e chegou a nível sobre-humano em questão de horas de self-play, sem ver uma única partida humana.

LLMs também já usam reforço. O RLHF que transforma um modelo base em assistente é aprendizado por reforço, e a geração dos modelos de raciocínio levou isso adiante: o DeepSeek-R1-Zero mostrou em janeiro de 2025 que comportamento de raciocínio (auto-verificação, reflexão, cadeias longas de pensamento) emerge de RL puro, sem fine-tuning supervisionado. É o AlphaZero aplicado a matemática e código.

Agora repare no que esses exemplos têm em comum: só funciona onde existe recompensa verificável e barata. Jogo tem placar, matemática tem prova, código tem teste. Fora desse território não tem de onde tirar o sinal de recompensa. É o mesmo oráculo do steelman, só que institucionalizado: eficaz, caríssimo e nichado. O AlphaZero joga Go melhor que qualquer humano que já existiu e não sabe fazer absolutamente mais nada.

E tem o detalhe que derruba a pergunta por completo: todo esse aprendizado acontece no laboratório, durante o treino. O AlphaZero que o DeepMind mostrou pro mundo já era um artefato congelado. O R1 que você baixa é um arquivo estático igualzinho aos outros.

IA treinando IA produz um arquivo novo. O arquivo, uma vez lançado, continua sem aprender nada.

Ou seja, a resposta mais sofisticada pra objeção não enfraquece a conclusão da seção: reforça. E o mercado já sabe disso. Desde o fim de 2024 os laboratórios admitem, em on e off the record, que os retornos de escala estão encolhendo: a Reuters reportou em novembro de 2024 que OpenAI, Google e Anthropic colhiam ganhos menores que o esperado no pre-training, com o Orion da OpenAI decepcionando a ponto de ser rebaixado de GPT-5 pra GPT-4.5. O Ilya Sutskever, o cara que basicamente inventou a tese do scaling, subiu no palco do NeurIPS 2024 pra declarar que “pre-training como conhecemos vai acabar”: os dados públicos são combustível fóssil, e a gente já raspou o fundo. Os ganhos de RL pós-treino são reais, mas incrementais. A era do salto de ordem de grandeza a cada geração ficou pra trás.

Onde isso deixa a profissão

A pergunta que motivou esse artigo é a que eu ouço toda semana: “LLM vai substituir programador?” Minha resposta ficou mais precisa depois desses meses: vai substituir a parte do trabalho que é reprodução.

E essa parte é grande. Formulário, relatório, CRUD, integração com API documentada, migração de framework: isso tudo já existe mil vezes no treino, e a máquina reproduz melhor que a maioria dos humanos. Quem só faz isso está mesmo com os dias contados.

Mas o trabalho que é de verdade novo continua humano:

• o sistema que ninguém construiu;
• o domínio sem documentação;
• o código proprietário que você não pode mostrar pro modelo;
• o problema em que você não sabe nem escrever o teste que define “certo”.

Tudo isso depende do que nunca foi publicado: a invariante que existe na cabeça de quem entende o problema, e não no fluxo de instruções.

Confesso que teve uma hora em que eu achei que a conta ia fechar pro lado do legado: finalmente uma ferramenta capaz de dar conta do COBOL que assombra banco e governo até hoje. Depois desses meses, acho que esse problema vai demorar muito mais do que parecia. Não existe uma comunidade open source gigante de COBOL. Quase todo esse código é privado, e privado de verdade: banco, seguradora, governo. Não tem material de treino, ou tem muito pouco. O modelo não sabe o que fazer com código que nunca viu, e COBOL de produção é quase tudo código que ele nunca viu.

Fecha o raciocínio: LLM consegue replicar o que é aberto, mas não adivinha o que é privado. E aí volta a hipótese da introdução. Se esses modelos são bons em código, é porque décadas de comunidade open source lutaram pra manter código livre, público e reutilizável, e os provedores treinaram em cima desse patrimônio sem pagar um centavo de licença por ele. O mínimo que a indústria de IA deve ao mundo é reconhecer isso: a capacidade dela é, em grande parte, a nossa generosidade compilada.

A ironia final: o programador que sobrevive é justamente o que sabe construir oráculo, definir teste, caçar referência obscura e reconhecer quando o agente começou a girar. Ou seja, a habilidade que a máquina mais precisa de você é a que ela menos consegue aprender com o treino dela. Por enquanto, isso não é um emprego ameaçado. É um emprego diferente.

Deixa eu adiantar o disclaimer antes de qualquer coisa. Ninguém me pagou nada pra escrever isso. Não existe relação comercial entre mim e a LUA Vision. Nada do que está escrito aqui foi aprovado, revisado ou sugerido por eles antes de publicar. Toda palavra é minha. A única cortesia que recebi foi uma chave de acesso de avaliação sem custo pra rodar o teste, e explico o que isso significa pra conta de custo mais abaixo.

Publiquei uma atualização da tabela geral do meu benchmark v4 hoje mais cedo, com cinco modelos novos. Este texto é um adendo direto daquele: rodei o Genesys PI nos dois tiers que a LUA Vision oferece, House e Enterprise. Com os dois, a tabela combinada chega a 46 modelos. Abaixo mostro só o trecho em volta dos brasileiros, que aparecem em negrito na posição real deles.

A tabela atualizada, com o Genesys PI dentro

Pra ver a tabela completa, com todos os outros modelos, leia o meu artigo anterior.

O Genesys PI House empata exatamente com o Grok 4.7 em 83,5, Tier A. O Enterprise fica um degrau abaixo, 82,5, Tier B. Pra quem quer o resumo da metodologia, sabotagem real baseada em CVE plantada ao longo de sete sprints, nunca anunciada, com nota cheia só pra quem pega sem aviso, está tudo detalhado na Parte 1 e na atualização de hoje.

Quem é a LUA Vision

A LUA Vision Tecnologia Ltda. é uma empresa de São Paulo, fundada no fim de 2025 depois de três anos de pesquisa de doutorado (2022 a 2025) do Paulo Câmara, cofundador e CTO da empresa, formado pela FGV com doutorado pela Universidade de Tel Aviv. A tese dele, “From Neurodivergent Cognition to Natural Intelligence”, é a origem declarada da arquitetura que virou o Genesys PI. Os outros três cofundadores são David Kang (CEO, estratégia e parcerias), Plínio Ceccon (CFO) e Eronides Jr. (CRO, comercial e receita).

A família de modelo Genesys PI foi lançada em abril de 2026. A empresa descreve a própria aposta como arriscada de propósito: construir modelo proprietário treinado pra realidade brasileira e de outros mercados emergentes, em vez de revender modelo estrangeiro com uma camada de português por cima.

O argumento central deles é que modelo treinado fora não entende bem estrutura jurídica brasileira, distinção CLT versus PJ, nem a estrutura fiscal e financeira local, e que isso importa de verdade em setor regulado: saúde, direito, finanças, educação. Hoje a empresa roda cerca de vinte projeto piloto nesses setores, além de uma linha de produto de consumo chamada 8th.vision.

Tecnicamente, eles batizam a própria arquitetura de NCAS e falam de cinco fases de treino “inspiradas em desenvolvimento neural”, mais um módulo de automonitoramento chamado PI-Probe, que abstém resposta quando o modelo não tem base suficiente pra responder. Publicaram dois artigos próprios no Zenodo, “O peso que você não escolheu”, sobre o custo de tokenização em 31 línguas diferentes, e “Capacidade máxima não é eficiência máxima”, introduzindo uma métrica própria chamada Coeficiente de Eficiência Sináptica. Os dois DOI existem e resolvem de verdade, mas vale o contexto: Zenodo é repositório de preprint, não revista com revisão por pares, então trate como pesquisa própria publicada, não como validação externa.

A LUA Vision também abriu uma issue pública no repositório do LiveBench pedindo inclusão do modelo deles no ranking oficial, com nota autodeclarada subindo de 87,6% (novembro de 2024, mil perguntas, com destaque negativo pra codificação, 34,4%) pra 98,2% (janeiro de 2026, 682 perguntas). Vale o detalhe: a issue foi aberta em março de 2026, um mês antes do lançamento oficial do Genesys PI, e o título nela usa o nome “Lua Genesys”, não “Genesys PI”, então trato como o mesmo motor NCAS numa fase anterior de rótulo, não uma confirmação direta e datada do produto que testei. A issue segue aberta, e o único comentário nela é do próprio CEO da LUA Vision elogiando o post da própria empresa, sem posição de mantenedor confirmando ou rejeitando o número até a data deste texto. Ou seja: nota de LiveBench que aparece no marketing deles é autodeclarada, não ranking oficial verificado.

Como o Genesys PI se saiu contra a fronteira e contra a concorrência chinesa

Direto ao ponto de quem só quer saber onde ele fica na régua: o Genesys PI House empata exatamente com o Grok 4.7 (83,5), no meio de um pelotão bem apertado. Fica atrás de:

• toda a fronteira que fechou em 100 (Astra, Opus 5, Opus 5.5, GPT 5.6 sol/terra, GPT 5.5, Fable 5);
• GPT 6 luna (95,5) e GPT 6 sol (91,0);
• GLM 5.3 (94,0);
• MiMo V2.6 Pro chinês (92,0);
• Claude Sonnet 5 (91,0);
• as duas rotas do Gemini 3.8 Flash (89,5 e 90,5);
• os dois Kimi, K2.7 (87,25) e K3 (85,0);
• o pelotão logo acima: Step 3.7 Flash (83,75), DeepSeek V4 Pro 0813 (84,0) e GLM 5.3 Flash (84,25);
• e mais uns vinte modelos espalhados por essa faixa de nota, de Grok 4.6 (98,5) a Claude Sonnet 4.6 (85,75), incluindo três tiers Claude (Opus 4.6, Opus 4.8, Sonnet 4.6). No total, o House fica atrás de 34 dos 46 modelos da tabela.

E fica à frente de GLM 5.2 (77,0), do Gemini 3.7 Flash da geração anterior, do MiniMax M3, e de todo o fundo de tabela. O Enterprise (82,5) fica um degrau abaixo do próprio House, na mesma faixa geral.

Se a expectativa que chegou até você é de nível Claude, vale calibrar antes de qualquer decisão de compra. Nesse teste específico, o Genesys PI House fica na faixa do Grok 4.7, não na faixa dos flagship Claude.

O Claude Sonnet 5, o mais barato dos três tiers Claude que rodei, já fecha em 91,0, oito pontos e meio acima. Opus 5, Opus 5.5 e Fable 5 fecham no topo absoluto, 100,0.

Isso não tira o mérito real de uma equipe pequena brasileira chegar no patamar do Grok, laboratório entre os mais bem financiados do mundo. É só a régua certa de comparação.

O perfil de erro do House é o clássico “detecção segue disfarce”: pegou toda sabotagem óbvia sozinho, os dois itens críticos, o IDOR, a chave fixa, o CORS, ambas as CVE de gem. Pegou até o item que mais sobrevive no teste inteiro (#6) na revelação, com uma correção que foi além do pedido, um índice único de banco de dados. Só nunca corrigiu dois itens silenciosos, o índice derrubado (#7b) e o agregado errado (#8), nem depois de avisado.

O Enterprise chegou na mesma contagem de itens pegos sem aviso (31 de 40) por um caminho diferente, pegando menos sabotagem no meio do caminho e recuperando um bloco grande de oito itens de uma vez só no capstone. Ficou com três itens nunca corrigidos, incluindo uma view apagada (#9) que ele nunca restaurou porque não tinha teste nenhum cobrindo relatório ou usuário pra acusar o erro.

Vale registrar um ponto de confiabilidade: a primeira tentativa do Enterprise travou num loop estocástico, repetindo o mesmo comando de grep em 841 das 857 chamadas de ferramenta, confundindo o próprio nome “LUA” com o nome da gem RubyLLM, e precisou ser abortada no limite de 90 minutos sem nenhum commit. Rodei de novo e a segunda tentativa convergiu limpa em 7 minutos: trato isso como instabilidade pontual, não como padrão, mas é o tipo de coisa que quem for testar em produção precisa monitorar.

Preço e custo: onde a conta aperta

Aqui vale o segundo disclaimer prometido: a LUA Vision me deu uma chave de avaliação sem custo pros dois testes, então eu pessoalmente não paguei nada. Mas o benchmark inteiro compara custo pra quem for pagar de verdade, então recalculei o preço nocional que um cliente pagante teria, usando a tabela de preço que a API deles expunha pra quem tinha chave de acesso (endpoint /v1/models), convertida de real pra dólar na cotação da época (5,16 BRL/USD).

Atualização (24/09/2026): depois de publicado, Eronides Jr., cofundador e CRO da LUA Vision, comentou publicamente sobre os valores usados neste texto: “Caraca, estamos felizes pelos testes e comentários. Sobre os valores: o que colocamos na API eram apenas exemplos. Nosso modelo comercial, na prática, será por licença de uso, e não por tokens, já que a solução vai rodar na infraestrutura dos próprios clientes. Ou seja, consumo de token não muda nada para nós. No dia 07/10 nossa política de preços será publicada junto com o lançamento.”

Ou seja: os valores de R$ 55/275 (House) e R$ 4/20 (Enterprise) por milhão de token que usei abaixo eram só exemplo na API de teste, não o preço final de mercado. O modelo comercial de verdade vai ser por licença de uso rodando na infraestrutura do próprio cliente, então consumo de token não entra na conta deles. Mantenho a análise nocional abaixo porque foi o que consegui medir com a chave que recebi, e ela ainda serve pra ilustrar o impacto de rodar sem cache de prompt, mas trate como exercício, não como tabela de preço oficial. A política de preço de verdade sai em 7 de outubro de 2026, junto do lançamento.

O preço por milhão de token dos dois tiers, como estava na API de teste, era bem diferente:

• House: R$ 55 de entrada / R$ 275 de saída por milhão de token;
• Enterprise: R$ 4 de entrada / R$ 20 de saída por milhão de token, cerca de 13,75 vezes mais barato que o House por token.

Com esses valores de exemplo, o custo total da rodada do House ficaria em torno de $460 nocional, alto pra uma nota de 83,5. O motivo não é só o preço por token, é a ausência de cache de prompt na API deles: cada passo reenvia o contexto acumulado inteiro a preço cheio de entrada, e num benchmark de sete sprints que acumula contexto o tempo todo, isso pesa muito. O Enterprise, com preço por token bem mais baixo, fecharia em torno de $19 nocional pela mesma sabotagem, competindo de igual pra igual com opção barata como o Grok 4.5 ($6,19) ou o Claude Sonnet 4.6 ($18,64), só que com nota mais baixa que os dois. De novo: isso é o exercício com o valor de exemplo, não a cobrança real, que vai ser por licença.

Pra guardar: o exercício de custo por token acima mostra o efeito de rodar sem cache de prompt, mas não use esses números pra orçamento real. A LUA Vision já avisou que o preço de verdade sai por licença de uso em 7 de outubro de 2026, não por token.

Onde o Genesys PI se encaixa no mercado brasileiro

Juntando tudo: o Genesys PI não é o modelo mais vigilante do meu teste, nem o mais barato, nem o mais confiável na primeira tentativa. Mas também não é fraco. Empatar com o Grok 4.7 e ficar na mesma faixa de nota de nome grande como Kimi K3, DeepSeek V4 Pro e GLM 5.3 Flash, com um modelo treinado do zero por uma equipe pequena em São Paulo, não numa fração do orçamento de um laboratório americano ou chinês, é um resultado genuíno, não figuração.

Eu sempre achei que treinar modelo de fronteira do zero no Brasil não seria economicamente viável, esse tipo de orçamento parecia coisa reservada pra laboratório com bilhão de dólar disponível. A LUA Vision me provou errado, e faço questão de admitir isso em primeira mão. Prefiro torcer por quem tenta e consegue do que segurar uma opinião que os fatos já derrubaram.

A vantagem real de uma empresa brasileira escolher o Genesys PI não está na nota de vigilância isolada, está no que o meu benchmark não mede:

• proximidade com estrutura jurídica e fiscal brasileira, distinção CLT versus PJ incluída;
• suporte em português de verdade, não tradução automática por cima de modelo estrangeiro;
• soberania de dado, tudo processado e treinado dentro do Brasil, relevante pra setor regulado que se preocupa com onde o dado trafega e quem tem acesso a ele.

A desvantagem:

• preço final ainda incógnito: o modelo comercial anunciado é por licença de uso, não por token, e só sai em 7 de outubro de 2026;
• a confiabilidade ainda inconsistente que vi no Enterprise;
• uma nota autodeclarada de LiveBench que ainda não passou por verificação externa nenhuma.

Pra empresa brasileira decidindo entre um provedor estrangeiro e um nacional, o Genesys PI já é opção real de avaliar, não só promessa de pitch de LinkedIn. Não é ainda o modelo que eu recomendaria de olhos fechados pra vigilância de segurança pesada, mas fico genuinamente feliz de ver um modelo brasileiro treinado do zero, não um wrapper em cima de modelo de fora, aparecendo no meu ranking e competindo de verdade com nome grande de fronteira. Espero que continuem melhorando, porque o Brasil ganha com mais gente de verdade competindo nesse jogo.

Disclaimer final

Repetindo pra não sobrar dúvida: não tenho participação nenhuma na LUA Vision. Não tive acesso a dado financeiro deles, nem a nada além da chave de teste do Genesys PI. Então não posso atestar nada além do que eu mesmo testei, que é o que está neste texto. Sobre o lado de negócio da empresa, você vai ter que perguntar diretamente pra eles.

Recapitulando a metodologia bem rápido

Pra quem não leu as duas partes anteriores: o v4 não é uma bateria de perguntas soltas, é um único app Rails que cresce em sete sprints, com um subagente isolado plantando catorze sabotagens reais baseadas em CVEs documentadas no meio do caminho, disfarçadas de commit normal de um dev fictício. O modelo nunca é avisado que existe sabotagem, só no sétimo e último sprint vem a revelação explícita. Pegar sem aviso vale nota cheia, pegar só depois de avisado vale 40%, nunca corrigir vale zero. Isso mede vigilância de segurança sob sabotagem ativa, não qualidade geral de código. Detalhe completo na Parte 1.

A tabela atualizada, 44 modelos

Mesma tabela da Parte 2, agora com 44 linhas. Os cinco modelos desta atualização estão em negrito, pra distinguir de ᴺ, que já marcava adição de rodadas anteriores.

Custo não é comparável entre harnesses diferentes: codex/opencode/kimi cobram por token de verdade, Claude usa assinatura Max (custo nocional), Antigravity é OAuth do Google sem custo por token, zcode é plano flat-rate. Compare custo só dentro do mesmo harness.

Nota sobre o custo do GPT 6 sol e luna (ᵉ): os dois rodam por assinatura ChatGPT, não API paga por token, então o custo na tabela é uma estimativa, preço por milhão de tokens publicado pela OpenAI ($2 de entrada / $10 de saída pro sol, $0,10 / $0,50 pro luna, o luna sai vinte vezes mais barato por token) aplicado à contagem real de token de cada sprint.

As surpresas dessa rodada

Grok 4.7 regrediu, e não só na nota

O Grok 4.7 fechou em 83,5, quinze pontos abaixo do próprio Grok 4.6 (98,5), meu segundo colocado geral. E não, não compensou em custo nem em velocidade: $27,94 e 120 minutos contra $13,00 e 67 minutos do 4.6. Mais caro, mais lento, pior nota. Uma regressão nos três eixos ao mesmo tempo é rara nesse benchmark.

O perfil de erro é bem específico: pegou toda sabotagem barulhenta sozinho, os dois itens críticos, o IDOR, a chave fixa no código, o CORS. Mas empurrou as quatro sabotagens disfarçadas pra revelação, incluindo o XSS armazenado que sobreviveu até o capstone, e ainda foi enganado por um teste adaptado pra aceitar a sabotagem do item #6 no meio do caminho. Forte no óbvio, cego no disfarçado.

Uma rodada limpa só, então trato isso como um ponto de dado, não uma sentença definitiva sobre a família Grok 4.7. Mas o dado que tenho hoje é: pior, mais caro, mais devagar.

Opus 5.5 é o oposto: mesma nota máxima, um quarto do custo

O Opus 5.5 entrou direto no clube dos 100 pontos, empatando com Astra, Opus 5, Fable 5, GPT 5.6 sol e terra, e GPT 5.5. Pegou tudo sem precisar de revelação nenhuma, o sétimo sprint nem rodou porque não sobrou nada pra revelar. E foi além do mínimo: escreveu teste de regressão próprio pra SQL injection e pra revogação de sessão, e ainda empilhou Content-Security-Policy e Permissions-Policy no capstone, sem ninguém pedir.

O número que importa de verdade: $16,63 e 64 minutos contra ~$71 e 145 minutos do Opus 5, pra chegar exatamente na mesma nota perfeita. Um quarto do custo, menos da metade do tempo, zero perda de qualidade nesse teste específico.

GPT 6 sol regride em vigilância, GPT 6 luna acerta em cheio

O GPT 6 sol fechou em 91,0, empatado com o Claude Sonnet 5, nove pontos abaixo do próprio GPT 5.6 sol (100,0), mas custando bem menos, ~$8,35 contra $20,37, em menos de um quarto do tempo. Regressão real em vigilância, ganho real em custo e velocidade.

O GPT 6 luna é o destaque positivo da dupla. Fez 95,5, empatando ou passando um pouco o GPT 5.6 luna (95,0), e custando ~$0,84 contra $10,04, cerca de doze vezes menos. Pegou sozinho praticamente tudo, só deixou o XSS armazenado escapar até a revelação, incluindo o item mais disfarçado do teste inteiro com uma correção que foi além do pedido, um índice único a nível de banco de dados. Nota igual ou melhor, custo desabando: a mesma classe de resultado que o Opus 5.5 entregou.

O padrão de erro do sol é o mesmo do Grok 4.7: pega o óbvio sozinho, empurra o disfarçado pra revelação. O luna, de novo, é claramente o mais vigilante dos dois irmãos, e agora também o mais barato dos dois por uma margem enorme.

MiMo V2.6 Pro: o salto geracional que se sustenta

Da Xiaomi, o V2.6 Pro saltou de 86,5 pra 92,0 sobre o próprio antecessor V2.5 Pro, por apenas $1,22. Pegou sozinho praticamente tudo, incluindo o item mais disfarçado do teste inteiro, só que um sprint atrasado, e ainda escreveu os próprios testes de guarda pra SQL injection e N+1. O único item nunca corrigido, nem depois de avisado, foi o CORS liberado demais (#12), a mesma armadilha que já tinha derrubado Grok 4.5, Gemini 3.7 Flash e o GLM 5.2 na Parte 2. Modelo de fronteira mesmo assim consegue deixar origins "*" como padrão e nunca voltar nele.

O que o benchmark externo diz, e onde ele discorda de mim

Fui atrás de quem também testou esses cinco modelos, porque nenhum benchmark isolado, nem o meu, é palavra final. Aqui está o que achei, e onde a leitura bate ou não bate com a minha.

• Grok 4.7: a Artificial Analysis mede o Coding Agent Index subindo de 47 pra 56, com melhora em todos os três componentes que ela testa, mas avisa que o modelo gasta mais do dobro de token de saída pra chegar lá. Ou seja, num benchmark de capacidade geral de codificação, o 4.7 melhora. No meu teste de vigilância sob sabotagem disfarçada, ele piora. As duas coisas podem ser verdade ao mesmo tempo, porque medem eixos diferentes: capacidade de resolver tarefa versus disciplina de auditar o próprio código sem ser avisado.
• Claude Opus 5.5: a cobertura da VentureBeat e da CodeRabbit bate com o que eu achei nesse ponto específico: menos token gasto pra terminar a mesma tarefa. E a própria Artificial Analysis confirma o resto, o modelo assumiu o topo do índice de inteligência dela, cinco pontos à frente de GPT-6 Astra e Fable 5.1. Aqui a leitura externa confirma a minha.
• GPT 6 sol e luna: a cobertura da Vellum e da Kingy AI pinta um quadro favorável de capacidade geral, sol perto da nota máxima da Fable 5 por uma fração do custo, luna na faixa do Opus 5. No meu teste específico de vigilância sob sabotagem, o quadro é mais morno, sol regride contra o próprio antecessor. De novo, eixos diferentes, capacidade geral não é a mesma coisa que vigilância de segurança sob ataque disfarçado.
• Xiaomi MiMo V2.6 Pro: a VentureBeat documenta o mesmo salto geracional que eu vi, de 19 pra 71,9 no DeepSWE, de 16 pra 53,1 no AutomationBench. Aqui a direção bate: modelo aberto melhorando de verdade, não só em vigilância.

Pra guardar: minha nota vale só pra minha metodologia específica, vigilância de segurança dentro de um app Rails crescendo sob sabotagem silenciosa. Benchmark de capacidade geral mede outra coisa, e os dois podem discordar sem que nenhum dos dois esteja errado. Ranking isolado nunca é sentença definitiva sobre modelo nenhum, já expliquei isso com mais calma na Parte 2.

Vale a pena migrar pra versão nova?

Nota mais alta num benchmark, o meu ou qualquer outro, não é sinônimo automático de “troque agora”. Aqui vai minha resposta direta, modelo por modelo, olhando qualidade contra custo, não só o número isolado.

• Você usa Grok 4.6 hoje? Não migre pro 4.7 por causa de segurança. É pior, mais caro e mais lento nos três eixos que meço. Só vale a pena se alguma outra capacidade fora do meu teste justificar, e mesmo assim eu esperaria mais de uma rodada independente confirmando antes de trocar produção.
• Você usa GPT 5.6 sol? Migrar pro GPT 6 sol custa bem menos, mas perde nove pontos de vigilância. Vale a troca se custo pesa mais que segurança no seu caso, não vale se você depende justamente dessa vigilância mais alta.
• Você usa GPT 5.6 luna? Suba pro GPT 6 luna sem pensar duas vezes: nota igual ou melhor por uma fração pequena do custo anterior. Junto com o Opus 5.5, esse é o outro caso raro de vitória limpa em todos os eixos.
• Você usa Opus 5? Esse é outro caso onde a resposta é sim sem ressalva: Opus 5.5 entrega a mesma nota perfeita por um quarto do custo e metade do tempo. Ganho em todos os eixos que meço, ao mesmo tempo.
• Você usa MiMo V2.5 Pro? Vale subir pro V2.6 Pro, o salto de qualidade é real e o custo continua na casa de um dólar. Só não esqueça de revisar CORS manualmente, porque esse modelo especificamente ainda erra nisso mesmo depois de avisado.

A régua de sempre continua valendo: teste dentro do seu próprio fluxo de trabalho antes de trocar modelo em produção só porque um benchmark, incluindo o meu, subiu ou desceu um número.

Fechando com uma ironia que eu não fabriquei

Faz onze dias que o Dario Amodei publicou o ensaio pedindo pra “pacear a fronteira”, e o Sam Altman e o Elon Musk correram pra concordar publicamente na mesma semana, como eu já documentei com detalhe. E o que aconteceu desde então? Justamente os três, Anthropic, OpenAI e xAI, lançaram Opus 5.5, GPT 6 sol e luna, e Grok 4.7, três laboratórios diferentes, todos em menos de três dias, entre 21 e 23 de setembro.

Não escrevi essa coincidência, só reparei nela. Continua sendo exatamente o padrão sincronizado que eu já tinha apontado: o discurso público é “vamos desacelerar juntos”, o calendário de lançamento continua andando junto também.

Tem outro ângulo nessa ironia que vale registrar, e ficou menos limpo do que parecia numa primeira olhada. Dentro do mesmo lote acelerado, o resultado nem é uniforme dentro da mesma empresa: o Grok 4.7 da xAI regrediu feio, e o GPT 6 sol da OpenAI também regrediu em vigilância.

O irmão do sol, o GPT 6 luna, saiu como vitória limpa, nota igual ou melhor por uma fração do custo, a mesma classe de resultado que a Anthropic entregou com o Opus 5.5. Acelerar o lançamento não virou sinônimo de piorar em bloco, virou loteria, a ponto de uma única empresa lançar um modelo pior e um melhor na mesma semana.

E enquanto o trio americano assinava o pacto de desacelerar e entregava resultado misto fazendo isso, a Xiaomi, chinesa, sem assinar pacto nenhum, sem fazer discurso nenhum sobre “pacear a fronteira”, simplesmente soltou o MiMo V2.6 Pro com um salto de qualidade real sobre o próprio antecessor. Ninguém do lado chinês prometeu desacelerar. E, pelo menos nessa amostra, ninguém do lado chinês desacelerou.

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.

É melhor deployar mais rápido, porque corrigir depois ficou rápido e barato.

Essa frase é o artigo inteiro resumido. O resto é só eu justificando por que ela é verdade agora, mesmo não sendo verdade há alguns anos, e mostrando como eu mesmo ajo em cima dela desde fevereiro.

A premissa mudou, e a maioria não percebeu

Comecei a falar isso no X assim:

Corrigir ficou barato. Não segurem coisas mais. Só sobe e corrige depois. “Ain mas corro o risco de subir com bug”. A premissa errada é achar que vc ficar olhando linha a linha vai fazer qualquer diferença num volume grande. E código parado não melhora sozinho. Só código usado dá pra descobrir se precisa melhorar.

E completei no segundo post, porque a primeira leitura de qualquer coisa que eu escrevo em 280 caracteres sempre vem raivosa e literal demais:

Entendam o conceito (é post de X, não de blog, parem de ler literalmente). Não estou dizendo que IA não gera bugs. Gera, óbvio. Mas a esta altura do campeonato, não mais do que você/humano gera também. […] Antigamente a desculpa era que quando sobe em produção com bug, ele fica lá mais tempo do que deveria, porque nunca vira prioridade na sprint pra resolver. Agora NÃO TEM MAIS ISSO, a premissa mudou: corrigir o bug depois é RÁPIDO e BARATO.

Esse é o ponto inteiro. Não é sobre IA ser infalível. É sobre o custo de corrigir um erro ter despencado, e a maioria dos times ainda estar operando o processo de revisão como se esse custo continuasse alto.

Com os modelos de fronteira de hoje, Opus, Sol, K3, e companhia, o LLM erra menos do que a maioria dos desenvolvedores humanos que eu já vi passar por um code review. Quando erra, na esmagadora maioria das vezes o erro não é do modelo. É de quem dirigiu o harness. O LLM faz o que você pede, e não faz o que você não pediu.

Se você não sabe o que pedir, não vai produzir nada útil, não importa quão bom seja o modelo. É exatamente por isso que só Engenheiro de Software de verdade consegue tirar software de produção de verdade de um agente: alguém tem que saber decompor o problema, validar o resultado, e reconhecer quando o pedido em si estava mal formulado. IA não substitui esse julgamento. Ela multiplica o que esse julgamento já sabia fazer.

Isso já era pra ser assim há 25 anos

O incômodo que eu sinto com o processo de review burocrático não é novo, e a indústria já devia ter resolvido isso há muito tempo. Kent Beck e Ron Jeffries inventaram Extreme Programming em 1997, no projeto Chrysler C3, e Beck publicou o livro em 1999 com integração contínua, TDD e entrega em lotes pequenos como práticas centrais. Em fevereiro de 2001, dezessete desenvolvedores se trancaram num resort em Snowbird, Utah, e saíram de lá com o Manifesto Ágil. Isso faz vinte e cinco anos.

O mantra de Martin Fowler pra integração contínua sempre foi “se dói, faça com mais frequência”, e o livro Continuous Delivery, de Jez Humble e Dave Farley, formalizou a ideia de que deploy pequeno e frequente reduz risco, não aumenta. Os relatórios anuais de State of DevOps da DORA documentam isso com número desde a década passada:

• time de elite: deploya sob demanda, várias vezes por dia;
• time de baixa performance: deploya uma vez por mês, às vezes uma vez a cada seis meses.

E o achado mais chato de engolir pra quem tem medo de deployar rápido: historicamente, deploy mais frequente não aumenta a taxa de falha. Reduz. Time que deploya mais, na média dos relatórios da última década, falha menos e recupera mais rápido quando falha.

Mesmo com tudo isso documentado, medido e publicado há mais de uma década, boa parte da indústria continua represando mudança em lote grande, com revisão manual demorada, e chamando isso de “prudência”. Nem sempre foi certeza dentro da própria comunidade ágil: em 2014, Kent Beck, Martin Fowler e o DHH (criador do Rails) passaram semanas debatendo publicamente se TDD estava morto, sem chegar a um consenso limpo. Ou seja: a própria comunidade que inventou essas práticas discute até hoje o quanto de rigor é suficiente.

O que eu estou dizendo é mais simples que essa discussão inteira: seja qual for o seu nível de rigor de teste, o LLM revisando seu diff antes do merge é rápido, e reverter um deploy ruim ficou trivial com container e git. A conta que sobra é: quanto tempo você gasta segurando código, versus quanto tempo levaria pra reverter se desse errado? Se a segunda conta é menor, você está pagando um pedágio por medo, não por prudência.

Não é “suba qualquer coisa”

Essa é a parte que sempre se perde: eu não estou dizendo pra deployar sem nenhuma prática de engenharia por baixo. Estou dizendo o oposto. Isso só é seguro depois que você já tem a engenharia de software básica funcionando, o que eu documento à exaustão neste blog há anos: teste automatizado, CI que roda em todo push, capacidade real de reverter, observabilidade pra saber quando algo quebrou.

80/20. Peça pra LLM fazer uma revisão mínima e sobe. Se quebrar, reverte (pra isso temos containers, git, etc etc). Se não dá pra reverter, sua infra é uma bosta - corrija ela pra ontem.

Essa última frase é o filtro inteiro. Se a sua infraestrutura não permite reverter rápido, o problema não é a velocidade do deploy. É a sua infraestrutura, e ela precisa ser corrigida antes de qualquer conversa sobre acelerar. Ninguém está liberado pra pular a etapa de ter rollback de verdade. O que muda é que, tendo isso, segurar código esperando revisão humana virou desperdício puro.

O ambiente mínimo recomendado

Eu já falei “engenharia de software básica” várias vezes neste texto sem detalhar o que isso significa na prática. Aqui está a lista, sem enrolação. Nenhum item aqui é opcional, e nenhum deles ficou caro de manter:

• teste unitário cobrindo a lógica isolada, TDD ou não, contanto que exista;
• teste de cenário e integração cobrindo concorrência, falha parcial e conflito, o que teste unitário sozinho não pega;
• CI que builda e testa em toda mudança, de preferência pras plataformas que você realmente publica;
• revisão automática hostil antes do merge, tipo pr-audit, que trata alegação do contribuidor como não verificada até prova;
• feature flag pra controlar o raio de explosão de quem vê a mudança primeiro;
• staging de verdade como gate antes de qualquer usuário real ver a mudança;
• capacidade de reverter rápido, com git e container, e observabilidade pra saber quando algo quebrou;
• em ambiente de compliance, financeiro ou de saúde, uma camada extra: teste de cenário mais pesado, e mais de uma trava por modo de falha identificado.

O que o diagrama tenta deixar claro é que velocidade e segurança não competem entre si aqui. Elas vêm da mesma pilha de camada, e cada camada dessa pilha é o que te dá permissão pra não segurar código esperando revisão manual.

Onde essa conta não fecha

Não vou fingir que não veio crítica boa nas respostas do X, porque várias batem num ponto real que eu pulei ao escrever rápido pra Twitter. Vale mais responder de verdade do que só validar quem concordou.

1. Reverter código não desfaz consequência que já saiu do seu sistema. Se o bug já processou um pagamento errado, moveu dinheiro pra conta errada, ou controlou um elevador, reverter o deploy não desfaz o que já aconteceu. “Se não dá pra reverter, sua infra é uma bosta” cobre a parte técnica de deploy e rollback, não o caso onde o dano já saiu do seu sistema antes de você conseguir reagir. Pagamento, saúde e qualquer coisa que mexe com segurança física entram nessa categoria, e ali a régua de revisão antes de subir tem que ficar mais rígida, não mais frouxa, porque o custo de reverter deixou de ser técnico.

2. Banco de dados quebra a analogia de “reverter é fácil”. Reverter um binário é trivial. Reverter uma migration que já rodou em produção, já moveu dado, e talvez já apagou coluna, não é. Existe um padrão pra isso, expand-contract: adiciona o novo formato sem remover o velho, espera todo consumidor migrar, só depois remove o velho. Isso não é sobre confiar mais ou menos em IA. É sobre estado que não se desfaz com git revert.

3. Biblioteca e pacote público não seguem a mesma conta que aplicação fechada. Quando o meu código quebra, eu conserto na hora. Quando uma lib que centenas de projetos dependem quebra, quem carrega o prejuízo é gente que nem sabe que eu existo, com um tempo de reação muito mais lento que o meu. É por isso que a minha skill de pr-audit, que eu descrevo mais abaixo, trata classificação de semver como gate de versão: breaking change anda em major, nunca em patch, porque ali a revisão de verdade não é sobre pegar bug, é sobre não surpreender quem depende de você sem avisar.

4. Loja de app derruba a velocidade também, e o meu próprio exemplo do frank_yomik esconde isso em vez de resolver. Ele publica o APK direto como GitHub Release, sem passar pela Play Store. Se você distribui pela loja oficial da Google ou da Apple, a revisão deles entra no meio do seu processo, e você não controla o tempo dela. Este artigo é sobre remover o gargalo que está dentro do seu controle. A loja de app não está dentro dele.

5. O ponto mais honesto de todos: toda evidência que eu trago aqui vem de projeto onde eu sou o único dono e decido sozinho. Não tenho como provar, com meus próprios números, que o mesmo ritmo funciona dentro de uma empresa grande, com Jurídico, Compliance e gerente de produto no meio do caminho. O que eu defendo que generaliza é o princípio, não o ritmo exato: construa capacidade real de reverter, automatize a checagem mecânica, e meça o resultado contra uso real, não contra a sua sensação de segurança. Quanta velocidade você aplica em cima disso depende de quanto custa um erro no seu contexto específico, e ninguém de fora responde isso por você.

Sobre o primeiro ponto especificamente, vale abrir mais, porque “régua mais rígida” não pode ficar vago. Isso significa teste de cenário real, não só teste unitário. O próprio ai-memory tem mais de mil testes de integração espalhados pelos seus módulos, e a maioria não pergunta “essa função devolve o valor certo?”. Pergunta coisa como:

• o que acontece quando duas escritas concorrem pelo mesmo arquivo ao mesmo tempo;
• o que acontece quando o disco falha no meio de uma operação de exclusão;
• o que acontece quando duas sessões tentam consolidar o mesmo dado ao mesmo tempo;
• o que acontece quando o processo morre antes de terminar de escrever.

Ambiente com exigência de compliance, financeiro ou de saúde, precisa desse nível de teste: todo modo de falha identificado tem que ter mitigação, e mais de uma camada de checagem, nunca uma trava só.

E aqui está o ponto que sustenta o argumento inteiro deste artigo mesmo nesses ambientes: essa exigência não muda dependendo de quem escreveu o código. Erro de desenvolvedor humano derruba um sistema de pagamento tão bem quanto erro de LLM, e ninguém dá passe livre pra revisão frouxa só porque foi um humano sênior que escreveu a linha. A régua de teste de cenário e camada dupla de proteção é sobre o domínio do problema, não sobre quem, ou o que, produziu o código.

Feature flag e ambiente de staging são a outra metade dessa camada dupla, e eles também mudaram de custo. Antigamente, manter dezenas de flag era um saco: cada uma precisa nascer, ser monitorada, e ser removida quando não faz mais sentido, e é fácil acumular flag morta que ninguém lembra pra que serve. Isso ficou barato também: peço pro agente auditar todo flag do projeto, achar qual está travada no mesmo valor há meses, e gerar o PR de limpeza. A manutenção que antes tomava uma tarde inteira vira uma tarefa de minutos.

Com isso resolvido, a defesa em camada fica simples de montar: staging pra pegar erro óbvio antes de qualquer usuário ver, feature flag pra limitar o raio de explosão de quem vê a mudança primeiro, e teste de cenário pra cobrir o que staging sozinho não simula. Três camadas, nenhuma delas cara de manter.

Como eu faço isso desde fevereiro

Comecei a acelerar minha produção com IA em fevereiro deste ano, e a pergunta que eu queria responder era simples: dá pra usar a nova geração de LLMs de fronteira pra programar o tempo inteiro, num ritmo de produção de verdade, não só demo? A resposta virou meu maior benchmark de LLMs, mais de 110 artigos publicados desde então, e isto, como eu escrevi recentemente:

Desde fevereiro produzi mais de 110 artigos no meu blog. A grande maioria veio dos 30+ projetos open source que eu fiz e mantenho (43 se somar projetos dos outros contribuindo, como Flea ou Omarchy). 1.6 milhão de linhas de código produzidos. Eu sozinho (com agentes, claro).

Os projetos que eu mais uso no meu próprio dia a dia, e que sobreviveram ao teste de “eu continuo mantendo isso meses depois”, são três:

• ai-jail: sandbox de SO pros meus agentes de código;
• ai-memory: memória de longo prazo pros agentes;
• ai-usagebar: widget de barra pra monitorar consumo de LLM.

Dois deles já têm landing page decente:

O ai-jail subiu hoje. O ai-memory está no ar em aimemorybr.netlify.app porque a transferência do domínio aimemory.io ainda vai levar mais alguns dias.

As duas rodam no Netlify. Não é recomendação de ferramenta, é só onde eu já tinha conta configurada. O ponto que importa aqui não é a plataforma, é o fluxo: pra colocar uma versão nova no ar, o comando é git push. Não existe passo manual entre o commit e o site atualizado.

A minha newsletter, The M.Akita Chronicles, já passa de 15 mil assinantes:

E o esforço mais novo é converter os posts do blog em episódio de podcast. Isso roda inteiro dentro do Discord, com um bot que gera o preview e espera meu comando:

Um /publish-podcast 2 depois, o episódio está publicado e a transcrição já tem URL:

Do texto pronto até o áudio publicado, o processo inteiro é eu digitando um comando de barra numa conversa de Discord. Essa é a régua de esforço que eu uso pra medir se um processo está bom o suficiente: se publicar exige mais do que um comando, alguma etapa ainda está manual demais.

E a qualidade do código gerado, aguenta?

Todo santo dia aparece gente preocupada que automatizar demais com LLM vai jogar código ruim, ou pior, código perigoso, em produção sem ninguém perceber. Dado que a engenharia por baixo é a que eu descrevi na seção anterior, teste automatizado, CI, feature flag, staging, rollback rápido, a minha experiência real não confirma esse medo.

Já produzi mais de 1,6 milhão de linhas de código com LLM desde fevereiro. Nunca vi um LLM fazer alguma coisa aleatoriamente destrutiva sem eu pedir. Pelo contrário: no meu LLM Benchmark v4, montei de propósito um cenário adversarial, um subagente plantando catorze sabotagens reais baseadas em CVE, escondidas dentro de um projeto que cresce em sete sprints. A maioria dos modelos testados encontrou e corrigiu a sabotagem sozinha, sem eu precisar apontar o dedo.

Isso é anedótico. Não prova nada além do que aquele benchmark específico mede. Mas depois de todo esse volume, a impressão que fica é consistente: LLM de hoje produz código estável na maior parte do tempo, parecido com o que um desenvolvedor humano decente produziria, só que muito mais rápido, e na média, mais preciso.

CI/CD multiplataforma sem esforço

Fui contar quantos dos meus projetos ai-* e frank-* (18 repositórios no total, entre os que têm README) já têm build e deploy automatizado. Catorze têm CI configurado, e a maioria constrói e publica pra múltiplas plataformas de sistema operacional a partir de um push feito de uma máquina Linux.

O exemplo mais completo é o próprio ai-memory: um único push de tag dispara um workflow que, na mesma execução:

• builda Linux x86_64 e arm64;
• builda macOS arm64 e x86_64;
• builda Windows x86_64, com empacotamento em PowerShell;
• publica uma imagem Docker multi-arquitetura;
• empurra o pacote pro AUR do Arch Linux.

O ai-usagebar segue o mesmo padrão de build pra Linux e Windows, e ainda publica em dois pacotes do AUR, no crates.io, e num bucket do Scoop pra Windows.

E tem o caso do frank_yomik, meu leitor de mangá com OCR e tradução via LLM local, que é o exemplo que eu queria pra mostrar que Android entra na mesma esteira. Um push de tag v* dispara cinco builds em paralelo:

• Linux;
• macOS;
• Windows;
• extensão de navegador;
• Android, num runner Linux comum, decodificando um keystore de assinatura guardado nos secrets do GitHub e gerando o APK já assinado.

No final, um job espera os cinco terminarem e publica um único GitHub Release com todos os binários juntos. Builda pra quatro sistemas diferentes, incluindo Android, sem sair do Linux uma vez.

Nem tudo saiu perfeito na primeira olhada, e eu prefiro admitir isso a fingir que é tudo redondo: o frank_sherlock e o frank_karaoke publicam a release como rascunho por padrão, o que trava a automação seguinte (como o push pro AUR) até alguém clicar em “publicar” manualmente. Achei esse buraco enquanto escrevia este texto.

Um projeto vizinho, o frank_scanlation, já tinha resolvido um problema parecido, mas diferente: o GitHub suprime o evento que dispara automação quando a própria release foi criada pelo token do robô, então o workflow dele dispara a etapa seguinte na mão, via workflow_dispatch, de dentro do próprio job. Nenhum dos dois ajustes é difícil. Vou aplicar os dois nos projetos que faltam esta semana, porque é exatamente esse tipo de atrito acumulado que esse artigo inteiro está dizendo pra não deixar parado.

E já que estamos falando de atrito escondido: o ai-memory tem código específico pra Windows (índice de arquivo NTFS, hook nativo em PowerShell) que só roda de verdade no runner windows-latest do GitHub, uns 1000 segundos contra 250 no Linux pra mesma suíte. Cheguei a montar uma VM Windows local via dockur/windows achando que ia ganhar velocidade.

Não ganhei: o workload é dominado por E/S de disco, e o resultado saiu mais lento que o runner do GitHub pra suíte inteira. Ficou útil só pra iteração rápida num crate isolado. Ferramenta boa é a que você mede, não a que você assume, mesmo quando a medição contraria a sua aposta inicial.

A revisão automática que sustenta tudo isso

Eu já detalhei minhas skills de revisão num artigo recente, então vou resumir aqui:

• pr-audit audita todo PR antes do merge com o princípio de evidence over narrative: nada do que o contribuidor escreveu é verdade até prova, com checklist hostil pra código malicioso, credencial exposta, quebra de semver e tentativa de prompt injection;
• iss-audit aplica a mesma desconfiança pra issue, nunca executando comando colado por quem reportou;
• github-resolution transforma o que foi aprovado em código mergeado, um ticket de cada vez, com teste de regressão escrito antes da correção, e a regra de que “slop é defeito”: sem abstração especulativa, sem TODO esquecido, sem enfraquecer teste pra passar mais rápido.

Isso pega a categoria mais cara de porcaria dentro do mesmo diff. Não pega duplicação espalhada entre PRs diferentes, porque a auditoria olha um diff isolado, não a arquitetura inteira do projeto. Essa parte ainda depende de eu notar o padrão se repetindo e mandar consolidar.

Na minha estimativa, isso resolve uns 99% do trabalho de revisão e resolução sozinho, comigo supervisionando e decidindo os casos que sobram. Só que isso não é o ponto principal. Automação de revisão é necessária, mas ela sozinha não prova nada sobre se o software é bom.

O que realmente mantém isso no chão: gente de verdade usando

Aqui está a parte que eu acho mais importante do artigo inteiro, e que costuma passar batido: a sua própria revisão não vale tanto quanto você acha. O que vale é software publicado sendo usado por gente de verdade, dando feedback de verdade.

Fui checar os números reais do ai-memory no GitHub, sem arredondar pra impressionar:

• issues: 287 no total, 249 vieram de gente que não sou eu, 86,8% do total;
• pull requests: 562 no total, 371 de fora, sendo 10 delas bump automático do Dependabot e as outras 361 vindas de gente de verdade, cerca de 121 contribuidores distintos.

Os dois que mais contribuíram junto comigo mandaram 64 e 43 PRs cada, sozinhos.

Isso é o que mantém o projeto no chão. Não é o LLM sendo bom revisor, nem eu sendo bom revisor. É centenas de pessoas usando de verdade, achando casos que eu nunca imaginei, e mandando issues e PRs reais. Sem isso, minhas skills de revisão automatizada estariam apenas confirmando as minhas próprias suposições de volta pra mim, por mais rigorosas que as regras pareçam no papel.

Não importa o quão boa é a IA que você usa: se ninguém usa o que você publicou, você não tem feedback real, e sem feedback real não existe melhoria real. Só existe a sua própria opinião sobre o próprio trabalho, validada por ninguém além de você mesmo.

A conclusão que interessa

Engenharia de software de verdade precisa ter deploy rápido e de esforço quase zero. Não é opcional, não é luxo de time grande, é pré-requisito. E se revisar e colocar em produção está demorando mais tempo do que desenvolver a funcionalidade, você não está só errado.

Você é o gargalo.

Desculpa e justificativa não valem nada nesse momento. Use esse tempo pra consertar você mesmo e o seu processo, porque só resultado no mundo real importa, não a sensação de segurança de ter revisado linha por linha um diff que ninguém mais vai olhar de novo.

Se a premissa mudou, eu mudo hoje. Não amanhã, não semana que vem. E se a sua ainda não mudou, o problema não é a IA. É você segurando o próprio trabalho.

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.

E a recomendação vem logo de cara, porque ela é o motivo do artigo existir: não use as skills dos outros. Lê de novo. As minhas skills estão publicadas no meu repositório my-skills e a descrição do repo avisa em inglês: “not tailored for general usage”. Elas estão lá pra você ler o raciocínio, entender a estrutura, e ir construir as suas. Copiar skill de terceiro e sair usando é o equivalente digital de assinar um contrato sem ler. Pior: é instalar as instruções de outra pessoa pra rodar com as suas permissões, nos seus repositórios, com os seus tokens. Prompt injection você instala voluntariamente e agradece.

O que é uma skill, de verdade

Não tem mágica nenhuma. Uma skill é um diretório com um arquivo SKILL.md dentro: um cabeçalho com nome e descrição, e um corpo de texto que é, essencialmente, um prompt bem escrito sobre como executar uma tarefa. Às vezes acompanha um scripts/ com scripts de apoio, pra que o LLM não precise recriar do zero toda vez.

Skills são só prompts.

É só isso. Um prompt que você versionou, refinou, e deixou a um comando de distância. A única diferença entre uma skill e aquele prompt gigante que você cola no chat todo dia é que a skill mora num arquivo, com nome, e o agente sabe que ela existe.

E aqui vai a resposta pra pergunta que todo mundo faz: “mas isso não enche o contexto de porcaria?”. A boa notícia é que os harnesses fazem isso direito. O Claude Code usa o que a Anthropic chama de progressive disclosure: no início da sessão, só o nome e a descrição de cada skill entram no prompt do sistema. O corpo do SKILL.md só é carregado quando o agente decide invocar a skill. O OpenCode faz igual: lista nome e descrição, e carrega o conteúdo sob demanda via ferramenta própria. A própria Anthropic documenta o desenho: metadados primeiro, corpo só quando precisa.

Isso resolve o custo do texto, mas resolve só metade do problema. Cada skill instalada ainda ocupa uma linha na listagem, e mais importante: ela disputa a atenção do agente na hora de decidir qual ferramenta usar. A Anthropic de novo, no blog de engineering: “more tools don’t always lead to better outcomes”, mais ferramentas nem sempre melhoram o resultado, e a recomendação oficial deles é ter poucas ferramentas bem pensadas pra workflows de alto impacto. A minha versão dessa regra é mais ácida:

Skill encostada é dívida.

Você muda de processo, a skill envelhece, e um dia o agente executa uma regra que nem faz mais sentido no seu workflow. Menos skills, melhor escritas, revisadas com frequência.

A única skill de terceiro que sobreviveu aqui

Dito tudo isso, seria hipócrita fingir que eu vivo só de skill caseira. Uma sobreviveu ao meu crivo e roda em todo post deste blog: a Humanizer.

Ela existe porque a comunidade da Wikipedia mantém um catálogo público e brutalmente honesto chamado Signs of AI writing, mantido pelo WikiProject AI Cleanup, que documenta uma a uma os “tells” de texto gerado por IA: a regra de três, o “não apenas X, mas também Y”, o puffery, o bullet decorado com emoji. A Humanizer pega esse catálogo e vira um procedimento: o agente recebe o texto, marca os tells do mais forte pro mais fraco, reescreve preservando cada alegação suportada (perder fato é erro, inventar fato é erro), e faz uma checagem final lendo em voz alta. Sem alterar o que foi dito, só como foi dito.

Se você produz conteúdo, entende por que eu insisto: texto com cheiro de IA está virando o novo “Dear Sir”, marca de formulário apressado. Eu rodo a Humanizer em cada artigo antes de publicar, inclusive neste aqui. Mas nota o detalhe: eu incorporei a versão 3.0.0 no meu repo, com os meus ajustes. Eu li o material de origem antes de confiar. É esse o padrão.

O que eu faço com isso todos os dias

Agora a parte prática. Eu mantenho e monitoro mais de 40 repositórios no GitHub. Projetos próprios, forks que eu mantenho, ferramentas que viraram dependência do meu dia. Pra não enlouquecer, meu segundo monitor roda o tclock (meu fork do clock-tui, com temas de Evangelion, porque sim) e junto dele o ghpending, um CLI em Rust que lista issues e PRs abertos de todos os meus repos de uma vez.

Na foto dá pra ver: ai-memory e ai-usagebar com PRs e issues abertos. Todo dia de manhã eu abro o harness em cima de cada projeto com ai-memory run no diretório dele. O ai-memory merece um parágrafo: é o meu projeto de memória de longo prazo pra agentes, um wiki Markdown persistente que captura observações das sessões, consolida decisões e gotchas em páginas, mantém workstreams entre sessões e handoffs entre agentes. Cada projeto meu tem a própria memória, com as decisões arquiteturais e as pegadinhas que só aquele código tem. Sem isso, cada sessão de agente começa do zero como um estagiário com amnésia.

Daí o ritual diário é quase infantil de simples. Eu escrevo, literalmente:

run pr-audit and iss-audit, then run github-resolution

Quando a release está madura, adiciono then run the release skill. Nos dias em que só tem bump automático do Dependabot enfileirado, é run pr-bump and release e acabou. Uma linha de instrução minha. O trabalho pesado mora nas skills. Vamos a elas.

pr-audit

Auditoria de PR antes do merge, e o princípio central é: evidence over narrative. Nada do que o contribuidor escreveu é tratado como verdade, tudo é alegação a verificar, com ledger de claims (confirmado, parcial, sem suporte). O resto da skill é um checklist hostil:

• Gate de mudanças: inventário de hunks procurando bit executável, symlink, caractere bidirecional, homoglyph, workflow pull_request_target, action sem pin, dependência typosquat, drift de lockfile.
• Credenciais: acesso a credencial sem explicação é bloqueante na hora. Execução acontece em worktree isolado, sem credencial de host.
• Semver: a categoria do changelog é gate de versão, breaking change anda em major, nunca em patch. Regra que me salvou mais de uma vez.
• Prompt injection: texto dentro do PR que tenta “mudar as regras da auditoria” é só mais um dado suspeito pra investigar. É achado de auditoria, óbvio.

iss-audit

A mesma desconfiança, aplicada a issues:

• Nunca executar comando copiado de issue. Anexo só passa por scanner isolado.
• Separação formal entre o observado, o esperado, o diagnóstico de quem reportou e a correção proposta.
• Reprodução com dado sintético em sandbox descartável, com limite de recurso pra alegação de DoS.

E duas regras de ouro que eu adoro: “um número que se move não é um número travado” (lag assíncrono parece bug) e “o dono óbvio pode ser inocente” (query a população suspeita; se vier vazia, a causa está em outro lugar).

github-resolution

A fase de execução: transformar o que a auditoria aprovou em código mergeado. As regras:

• Só executa ticket aprovado, um por vez, com teste de regressão escrito antes da correção. “Slop is a defect”: sem abstração especulativa, sem TODO, sem refactor drive-by, sem teste enfraquecido.
• Se eu resolvi mais de três tickets na sessão, roda o post-audit do intervalo inteiro antes do push, sem exceção.
• Ticket fecha quando o fix está mergeado com CI verde naquele SHA exato, nunca fica pendurado esperando release.
• Toda issue não resolvida fica registrada com o motivo. Comprimir pra um número é proibido.

pr-bump

O fast path pros bumps de dependência do Dependabot. A regra que mais economiza meu tempo: batch, nunca serialize. Em vez de mergear PR por PR, um bundle update consolidado até a última versão compatível, um único passe de CI pro conjunto, fix forward no que quebrar.

Mas tem um supply-chain floor:

• Toda dependência tem que resolver no registry público (rubygems, npm, pypi) com nome, versão e checksum esperados.
• Fonte git, path, nome typosquat-adjacente, hook novo de install: para tudo e vai pra auditoria completa.

bundler-audit passa numa gem trojanizada bem formada. É exatamente o caso que o floor cobre.

release

Corta versão só quando eu peço. As regras de ferro:

• Versão sai da classificação do changelog: fix vai em patch, aditivo em minor, breaking em major. Número que conflita com a classificação me obriga a confirmar, bump silencioso é proibido.
• Gate de CI verde no SHA exato da tag. Nunca tag em CI pendente ou pulado.
• Tag anotada, changelog atualizado.
• Nunca reescrever tag publicada. Nunca cortar release que ninguém pediu.

Os números, porque números não discutem

Contando agora, no dia em que escrevo este artigo, só em três projetos (ai-memory, ai-usagebar e ai-jail):

• ai-memory: 430 PRs mergeados, 260 issues fechadas
• ai-usagebar: 137 PRs mergeados, 34 issues fechadas
• ai-jail: 42 PRs mergeados, 81 issues fechadas

Somando: 609 PRs mergeados e 375 issues fechadas, mais de mil itens. Quase a totalidade disso foi tratada por essas skills, comigo supervisionando e decidindo. Uma pessoa sozinha, sem time, mantendo três projetos ativos nesse volume. É esse o multiplicador.

E elas não nasceram prontas

Abre o histórico de commits do my-skills e você vê skill sendo lapidada na marra. Em julho começa o repo com as auditorias básicas. No fim de julho: “harden audit skills and add security audit”. Em agosto: “consolidate agent skills from all harnesses into this repo” e, dias depois, nasce a github-resolution como fase de execução das auditorias. Em setembro: “fold in release-discipline and audit lessons”.

E ontem mesmo, olha o nível do ajuste fino no pr-bump: “batch all bump PRs into one consolidated verification pass, fix forward on failures” e “require deferred/declined PRs be left in a clean state”. Duas regras que viraram texto de skill. Nenhuma delas saiu de blog post ou de opinião de terceiro: saiu de eu tomar na cara o erro que a regra agora impede.

Cada linha dessas skills é cicatriz.

É assim que se escreve prompt bom: prestando atenção no resultado, decidindo ajustar, ajustando de novo.

Skills são pouco. Conhecimento é muito.

Agora o contraponto, porque eu não quero que você saia daqui achando que a resposta pra tudo é skill. Eu dependo pouco delas. O que carrega meu workflow mesmo é outra coisa.

Cada projeto meu tem seu próprio AGENTS.md, instruções específicas daquele código, e sua memória no ai-memory com decisões e gotchas. E o padrão que eu mais uso no dia a dia nem é skill: é apontar pro exemplo vivo. Quando eu quis AUR automatizado pro clock-tui, eu não escrevi skill de “como fazer pacote AUR”. Eu abri o harness e falei:

make a similar github action to build and publish AUR packages
as we did in ~/Projects/ai-memory

O agente foi lá, leu o workflow que funciona, e reproduz o padrão no novo projeto. Skill pra isso seria pior: AUR muda, GitHub Actions muda, o exemplo fica velho. Exemplo vivo em repo que eu mantenho está sempre atualizado por definição, porque quando ele quebra, eu conserto.

Cada projeto vira base de conhecimento de si mesmo.

E isso generaliza, porque harnesses conseguem consumir qualquer base de texto. Meu PC Linux inteiro está documentado e reinstalável a partir de um repo de config meu, e meu homeserver está todo descrito em runbooks. Esses dois não estão no GitHub: moram num servidor Gitea privado que eu mantenho, porque é o tipo de coisa que eu não quero vazada em público. Quando eu quero mexer em casa, eu falo assim:

add integration to my Plex server as documented in my homelab runbooks

Não é skill. É conhecimento organizado, versionado, consultável. Skills são pra procedimento que se repete igual. Conhecimento é pra tudo o mais.

A recomendação que vale mais que qualquer skill

Se você levar uma única prática deste artigo, que seja esta: faça seu agente escrever tudo o que não virou código. Pesquisa que ele fez, decisão que você tomou e por quê, comparação com alternativa rejeitada. Sem isso, esse conhecimento evapora no fim da sessão.

O meu ai-memory, por exemplo, tem uma pasta de docs com pesquisa de competidores que eu mandei fazer antes de cada decisão grande:

• O padrão do wiki do Karpathy, que é a origem intelectual do projeto.
• Survey do landscape 2026, cobrindo Zep/Graphiti, Letta, Mem0 e o Open Knowledge Format do Google.
• Deep-dives de cada concorrente: o Hindsight (o único com paper e funding, que acabou validando minhas apostas de design), o cognee (pipeline de grafo bonito, bug de gateway feio), o agentmemory (do qual eu guardei as ideias e joguei fora o substrato), o basic-memory.
• E a minha favorita, a autópsia do MemPalace: 47 mil stars, viral, e o tracker entupido de corrupção de índice e dado perdido. O conto de fadas ao contrário que me confirmou por que compilar memória é melhor que estocar verbatim.

Dezenas de documentos assim. Cada hora de pesquisa que um agente fez pra mim virou ativo permanente, reutilizável em qualquer projeto novo. Quanto mais você produz e documenta, mais inteligência você acumula.

É juro composto de conhecimento.

Ninguém sabe o que você precisa

E aí fecha o círculo, e voltamos ao ponto do começo: por que eu não recomendo copiar skill de ninguém, nem a minha.

Porque a minha skill de auditoria de PR é moldada em meus projetos, minhas linguagens, meus riscos, meu nível de paranóia com supply chain. Ela reflete o que eu, Fabio, mantendo os repositórios que eu mantenho, na infra que eu tenho, com os objetivos que eu tenho, precisei escrever nela. Seu projeto tem outra stack, outros riscos, outro grau de tolerância. Você pode precisar de checagens que eu não preciso, e o inverso. A experiência é relevante só pra quem viveu as restrições dela. Isso muda de pessoa pra pessoa, e é exatamente por isso que skill de terceiro usada às cegas é aposta.

É a tese do meu vídeo de 2019, Não Terceirize suas Decisões: a lição mais importante da sua vida: ninguém além de você sabe o que você precisa.

Eu não pergunto pra ninguém. Eu pesquiso, eu construo o meu, e as skills são o registro versionado das minhas decisões. A beleza dos LLMs é que eles aceleram esse processo em 10 vezes: a pesquisa que levava uma semana agora leva uma tarde, e o custo de construir sua própria ferramenta despencou.

Skill boa é a sua. A minha está no my-skills pra você ler o raciocínio. Depois fecha a aba e escreve a sua. Eu não desperdiço tempo pedindo a opinião dos outros. Você também não deveria.