Para provar que seus modelos entendem COBOL, a OpenAI (abre em nova aba) mandou-os escrever um SQLite (abre em nova aba) em COBOL. Nenhum banco do mundo roda SQLite em COBOL, e nenhum gerente de mainframe pediria isso. A escolha diz muito sobre o que a empresa conseguiu medir e sobre o que ainda não mediu.
No dia 19 de outubro, a OpenAI publicou o post de pesquisa Advancing coding in low-resource programming languages (abre em nova aba) com dois testes. O primeiro, MultiLangBench, pede ao modelo um motor de banco de dados compatível com SQLite, escrito do zero, em 20 linguagens. O segundo pede a migração de programas COBOL existentes para outras linguagens sem alterar o comportamento. O primeiro foi aberto ao público. O segundo, não. Quem quiser avaliar o anúncio precisa começar por essa assimetria.
Os números que a OpenAI divulgou
No MultiLangBench, com esforço máximo de raciocínio, o GPT-6 Astra teve taxa média de aprovação de 87,4% nas 20 linguagens. O GPT-5.6 Sol, usado como base de comparação, ficou em 26,8%. Segundo a empresa, o Astra passou de 83% em 19 das 20 linguagens. A exceção foi o COBOL, a mais difícil, com 72,1%. O GPT-6 Luna, modelo mais barato, ficou em 40,3% de média.
| Linguagem | GPT-5.6 Sol | GPT-6 Luna | GPT-6 Astra |
|---|---|---|---|
| COBOL | 10,9% | 17,1% | 72,1% |
| Fortran | 21,4% | 31,4% | 83,5% |
| OCaml | 25,6% | 34,1% | 85,8% |
| Visual Basic | 27,5% | 41,6% | 89,4% |
| Média (20 linguagens) | 26,8% | 40,3% | 87,4% |
A OpenAI pôs preço na Luna: US$ 0,77 por amostra, em média, contra US$ 3,48 do GPT-5.6 Sol, cerca de 78% a menos. O custo do Astra em esforço máximo, o modelo que puxa a manchete, não está entre os números que a empresa destacou. O detalhe pesa porque o próprio benchmark define a pontuação como um par: custo de API e taxa de aprovação. Publicar só metade do par para o modelo principal é uma escolha editorial.
Na migração de COBOL para C++, Java, Kotlin, Python ou Rust, o critério de sucesso é paridade byte a byte da saída em testes ocultos. O GPT-6.1 Sol, com esforço baixo de raciocínio, acertou 86,6%, contra 5,4% do GPT-5.6 Sol, a 61% do custo de API. Com esforço maior, chegou a 97,9%. O modelo é outro: o Astra aparece no MultiLangBench e o GPT-6.1 Sol na migração. A empresa não explica, nos números divulgados, por que cada teste tem seu campeão.
Como o MultiLangBench funciona
O repositório no GitHub (abre em nova aba), sob licença Apache 2.0, descreve o mecanismo com precisão. O modelo recebe a documentação oficial do SQLite 3.40.1, de 2022, e precisa entregar um executável que aceite o caminho de um arquivo de banco como argumento de linha de comando e uma consulta SQL pela entrada padrão. A avaliação usa testes convertidos da suíte TCL do próprio SQLite. Dos 51 mil testes TCL, 24 mil foram convertidos.
Cada teste tem três partes. O initial_database é o SQL que cria o banco inicial. O user_query é o SQL que o candidato precisa executar para modificar esse banco. O validation_query roda depois no SQLite 3.40.1 verdadeiro, e o teste só passa se a saída for exatamente a string esperada. O nome de cada teste é o hash SHA-256 dessas três partes. O teste falha se a saída divergir, se o programa travar ou se passar de 60 segundos.
As regras contra trapaça são boas. Todo vestígio do SQLite precisa ser removido do ambiente, e não há acesso à internet. Se o modelo escrever a solução em outra linguagem, a nota é zero. Soluções que misturam linguagens também reprovam. Isso fecha a saída óbvia de escrever o motor em C e embrulhá-lo numa casca de COBOL. Um modelo que tira 72% em COBOL escreveu, de fato, um interpretador SQL funcional em COBOL.
Para o desenvolvedor que pretende rodar o teste, há uma recomendação que define o que os números querem dizer. Como os 24 mil testes custam caro, o README orienta usar apenas os 272 cujos nomes começam com 00, 01 e 02. Quem rodar a suíte completa deve informar isso. São 272 casos, numa tarefa só, repetida em 20 linguagens. O tamanho da amostra merece lembrança antes de qualquer conclusão sobre um ponto percentual a mais ou a menos.
O problema de usar o SQLite
O SQLite é um dos programas mais estudados do planeta. Seu código-fonte em C está em domínio público há décadas, e a suíte TCL de onde saíram os testes também é pública. Tirar o SQLite do ambiente de execução impede a cópia na hora da prova. Não impede o que o modelo absorveu no treino. A OpenAI não detalha, no que divulgou, como tratou o risco de contaminação.
Isso não anula o resultado. Saber de cor como o SQLite funciona em C e reescrevê-lo em COBOL, sem bibliotecas e com nota zero para qualquer desvio de linguagem, continua sendo um trabalho difícil. Mas muda a natureza da tarefa. O MultiLangBench mede, em boa parte, a capacidade de transpor uma especificação conhecidíssima para uma linguagem com pouco código disponível. Não mede a capacidade de entender um sistema que o modelo nunca viu, e é aí que mora o COBOL real.
O código COBOL que move bancos não está no GitHub. Está em mainframes, em copybooks que ninguém documenta desde os anos 1980, em regras de negócio que existem só no código. Um benchmark construído sobre o software aberto mais conhecido do mundo é, por definição, o oposto desse ambiente.
A migração de COBOL: o teste que importa e que ninguém pode ver
O segundo teste é o que interessa a quem paga a conta de um mainframe. Migrar programas preservando o comportamento é o problema de negócio. A exigência de paridade byte a byte é rigorosa e adequada. Em COBOL, a diferença entre um sistema certo e um errado costuma estar no arredondamento de um campo decimal ou no alinhamento de um relatório de saída. Um critério frouxo, como "a saída parece correta", não serviria.
Só que os testes são ocultos, e o README do repositório não descreve essa avaliação. Ninguém de fora sabe quantos programas foram migrados, de que tamanho, com que complexidade, nem quantos casos de teste cada um teve. Paridade byte a byte vale exatamente o que vale a cobertura dos testes. Um programa que passa em dez entradas felizes e quebra na décima primeira, a de fim de mês, também tem "paridade" nos testes que existem.
Nada do que foi publicado indica se os programas dependiam de CICS, JCL, DB2 ou VSAM. É esse ecossistema que torna a migração de mainframe cara e lenta. Um programa COBOL batch isolado, que lê um arquivo e escreve outro, é um exercício. Uma transação CICS que conversa com DB2, é disparada por um JCL e depende de três copybooks compartilhados com outros quarenta programas é um projeto de anos. O salto de 5,4% para 86,6% é impressionante, mas não se sabe em qual desses dois mundos ele aconteceu.
A própria OpenAI reconhece o limite. A empresa diz que o uso em produção ainda exige revisão de especialistas e testes contra regras de negócio e dependências. A ressalva não é protocolar. Ela informa que a validação semântica, a parte mais cara de qualquer migração, continua com o cliente.
O que ainda não existe
Não há, até agora, reavaliação independente. O benchmark saiu no dia 19, e a cobertura especializada do dia seguinte, como a do AICoder (abre em nova aba), repete os números da OpenAI e informa que eles são da própria empresa. É reprodução de comunicado, não teste.
Também não há comparação com modelos de outras empresas. Toda a régua é interna: GPT-6 contra GPT-5.6. Um salto de 26,8% para 87,4% entre gerações da mesma casa mostra progresso da OpenAI sobre si mesma. Não diz nada sobre a posição dela no mercado.
Faltam ainda casos de uso em produção. A empresa não citou banco, seguradora ou órgão de governo que tenha migrado sistemas com esses modelos. O post oficial no X vai na direção contrária e pede aos clientes que digam onde a OpenAI deve trabalhar. É uma frase de quem ainda está montando o produto, não de quem já o entrega.
Os avanços mais recentes dos nossos modelos trazem capacidades mais fortes para construir e migrar software em linguagens de programação de poucos recursos, como COBOL, Fortran e Visual Basic. Essas linguagens movem software do qual bancos, governos e empresas dependem. Progresso aqui significa entender décadas de lógica de negócios e ajudar desenvolvedores a modernizar esses sistemas preservando o que funciona. Estamos construindo essas capacidades em torno dos desafios que desenvolvedores e clientes corporativos nos trazem. Se a sua equipe trabalha com esses sistemas, diga quais linguagens e fluxos de trabalho devemos atacar em seguida.
Quem ganha e quem perde
A OpenAI ganha um argumento de venda para um mercado onde o dinheiro é grande e a paciência é curta. Para justificar o tamanho desse mercado, a empresa cita a IBM: o COBOL estaria por trás de mais de 40% dos sistemas de banco online, de 80% das transações presenciais com cartão e de 95% das transações em caixas eletrônicos. Também lembra que o Fortran sustenta a previsão do tempo da NOAA e as análises de segurança de reatores da comissão nuclear americana. Há uma ironia nisso. A OpenAI usa estatísticas da IBM, dona do mainframe e vendedora de ferramentas próprias de modernização com IA, para bater à porta dos clientes da IBM.
Ganha também o desenvolvedor que já trabalha com essas linguagens. Um modelo que escreve Fortran e Visual Basic com mais de 83% de aprovação numa tarefa grande vira ferramenta útil para ler, documentar e reescrever código legado. O ganho é maior para quem conhece o sistema, porque é essa pessoa que vai pegar o erro dos 13% ou 28% restantes. A ressalva da OpenAI sobre revisão especializada, lida ao contrário, é uma valorização desse profissional.
Perde quem vende migração como trabalho braçal de tradução linha a linha, cobrado por hora. Se a conversão mecânica fica barata, o valor migra para a descoberta de regras de negócio, o desenho de testes de equivalência e a gestão de dependências. Consultorias que sabem fazer isso continuam com mercado. As que só sabem traduzir, não.
Perde também, em parte, o GPT-5.6 Sol. Na tabela da própria OpenAI, a Luna, mais barata, supera o Sol em todas as linguagens destacadas por cerca de um quinto do custo. Para quem tem pipeline rodando no Sol, o recado é direto.
O que é exagero e o que é real
É real que os modelos novos escrevem COBOL, Fortran e Visual Basic funcionais numa escala que a geração anterior não alcançava. O MultiLangBench é aberto, tem regras claras e regras contra atalhos. Qualquer um pode rodá-lo e conferir. A métrica que junta custo e acerto é mais honesta do que a média solta que costuma aparecer nesses anúncios.
É exagero ler o resultado como prova de que a modernização de mainframes está resolvida. O teste aberto mede uma tarefa que nada tem a ver com o COBOL de produção e usa um software que os modelos provavelmente conhecem de cor. O teste que se aproxima do problema real é fechado, não tem tamanho declarado e não diz nada sobre o ecossistema que torna essas migrações caras. Os números de 86,6% e 97,9% podem ser verdadeiros e, mesmo assim, ter pouco a dizer sobre um sistema de cartões com trinta anos de remendos.
Julgamento
A OpenAI fez um avanço técnico genuíno e o embrulhou num argumento comercial maior do que ele. O avanço está no MultiLangBench, e merece crédito justamente por ser verificável. O argumento comercial está na migração de COBOL, e por enquanto se apoia apenas na palavra da empresa. Quem decide orçamento de modernização com base nos 97,9% está comprando um número que não pode auditar.
O caminho para o desenvolvedor é rodar o MultiLangBench na própria infraestrutura e, mais importante, montar a própria versão do teste de migração: programas COBOL reais da casa, com dependências reais e testes de paridade byte a byte sobre dados de produção mascarados. Se o GPT-6.1 Sol passar nesse teste, a OpenAI terá provado o que anunciou. Até lá, a empresa provou que seus modelos escrevem um SQLite em COBOL. É um feito, mas é outro problema.