O ingrediente mais caro no treinamento de um modelo de programação não são mais as GPUs — são os problemas. Um modelo de código precisa de mais do que perguntas e respostas: precisa de um ambiente executável, um teste que julgue o certo do errado e salvaguardas contra o modelo espiando soluções antigas. A dificuldade precisa ser calibrada — fácil demais e ele não aprende nada, difícil demais e não consegue gerar uma única trajetória correta, queimando toda a execução. Historicamente, humanos faziam essa curadoria: devagar, caro e eternamente atrasados.
Neste mês, um laboratório de pesos abertos chamado Ornith devolveu essa tarefa ao próprio modelo. O resultado é uma história em duas camadas que vale a pena desmontar: uma mudança técnica genuína em como os dados de treinamento são produzidos, e uma lição dura sobre quanto de qualquer alegação de benchmark você deveria realmente acreditar.
O que realmente aconteceu
Em agosto de 2026, a Ornith lançou três modelos de pesos abertos — um MoE de 397B, um MoE de 35B e um modelo denso de 9B, todos sob licença MIT. A mudança principal está dentro do pipeline de treinamento: o modelo agora gera suas próprias tarefas de treinamento, constrói seus próprios scaffolds de resolução e executa suas próprias trajetórias de solução — e os três entram juntos no aprendizado por reforço. A escrita de problemas saiu das mãos humanas.
Os números evoluíram rápido. No Terminal-Bench 2.1, o Ornith 1.0 marcou 77,5 há dois meses; o novo 397B marca 86,1 — um ganho de 8,6 pontos, cerca de 11%, em dois meses. Na mesma tabela, a Ornith reporta o Claude Opus 4.8 com 85,0. Um modelo de pesos MIT disponível para download gratuito acima de um carro-chefe fechado de fronteira — pelo menos no papel.
O versionamento conta a história real do método: o v1.0 aprendeu a resolver problemas; o v1.5 aprendeu o que praticar. A habilidade mais difícil é a segunda — decidir quais tarefas autogeradas valem o custo computacional. É exatamente aí que vivia o gargalo humano.
Então, a lacuna de verificação
Aqui é onde a história se divide. O 86,1 é um número auto-reportado: a Ornith o executou em seu próprio ambiente, com sua própria configuração, e o site nota que é uma média de cinco execuções. O Terminal-Bench 2.1 também mantém um leaderboard oficial em que cada entrada é re-executada e verificada pela equipe. Em 19 de agosto de 2026, esse painel tinha 17 entradas — e o Ornith 1.5 não estava entre elas.
Compare o mesmo modelo nas duas tabelas e a diferença é brutal. A submissão oficial da Anthropic — Claude Code + Opus 4.8 — foi verificada em 78,9%, ficando em quinto lugar; a primeira posição é do Claude Code + Fable 5, com 83,8%. A própria tabela da Ornith lista esse mesmo Opus 4.8 com 85,0 — uma diferença de 6,1 pontos para um modelo idêntico.
Benchmarks de agentes como o Terminal-Bench medem a stack inteira: modelo mais scaffold, timeout, janela de contexto e alocação de recursos. Mude a configuração e o significado do número muda. As regras de submissão do painel oficial até proíbem modificar timeouts ou configurações de recursos — justamente porque, caso contrário, as equipes poderiam inflar pontuações ajustando configs em vez de modelos. A mesma lição sobre quem pode verificar a saída de um modelo apareceu esta semana em um palco bem diferente: um único modelo de IA escrevendo quase um milhão de linhas de Lean para verificar uma prova matemática.
Por que isso é um sinal, não uma nota de rodapé
Duas mudanças estruturais estão por baixo deste único lançamento.
Primeiro, o muro de dados está começando a se tornar autosserviço. O insumo mais escasso no treinamento de IA está migrando de dados humanos curados para computacional mais a qualidade do verificador. Se os modelos conseguem gerar seu próprio currículo em escala, laboratórios de pesos abertos podem iterar em capacidade de programação num ritmo que não depende mais de contratar mais anotadores. É um princípio de auto-jogo estilo AlphaGo aterrissando no benchmark comercialmente mais disputado do mercado — e isso compõe a concentração de computacional que sinalizamos no início da semana, na qual os vencedores são os laboratórios que podem pagar tanto pelo computacional quanto pelo ciclo de verificação.
Segundo, a credibilidade dos benchmarks está se tornando um campo de batalha próprio. Quando pontuações auto-reportadas podem divergir das verificadas em seis pontos no mesmo modelo, “quem mediu, e com qual config” agora faz parte da avaliação — não é uma nota de rodapé. O leaderboard verificado está se tornando a moeda, o que é bom para os compradores: devolve o ônus da prova ao fornecedor.
O que fazer com isso
- Avaliando agentes de código? Consulte o leaderboard oficial verificado, não a tabela do fornecedor. Pergunte qual scaffold e configuração produziram qualquer pontuação apresentada a você, e se timeouts ou configurações de recursos foram alterados.
- Comprando um modelo? Exija uma re-execução. Uma alegação que só se sustenta no ambiente do próprio fornecedor é um sinal mais fraco do que uma replicada na sua configuração. O 86,1 da Ornith é um dado interessante; ainda não é um dado independente.
- Construindo modelos? Currículos autogerados são agora um padrão comprovado de engenharia de dados para RL de código. O fosso está migrando para o verificador — o ambiente de avaliação e a qualidade dos testes — em vez do banco bruto de problemas.
- Lendo qualquer manchete de benchmark de 2026? Aplique o teste de duas perguntas: foi verificado por terceiros, e a configuração mudou?
A conclusão não é nem “o código aberto venceu” nem “os números são falsos”. É que a IA começou a produzir seu próprio material de treinamento — e que o sistema de medição da indústria está correndo para alcançar o que isso significa.
