Benchmark COBOL da OpenAI perto de saturar. Bancos ainda não podem aposentar o mainframe
A OpenAI relata 97,9% na própria avaliação de migração COBOL e grandes ganhos em COBOL, Fortran e Visual Basic. O útil é como define sucesso: comportamento byte a byte, não código que compila.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
A frase mais importante no post de pesquisa da OpenAI de 19 de outubro não é uma pontuação. É um exemplo sobre arredondamento. A aritmética de ponto fixo do COBOL descarta os dígitos decimais excedentes, a menos que o programa peça arredondamento explicitamente. Uma reescrita em Java ou Python que arredonde esses valores, em vez disso, vai compilar, rodar sem erros e passar por uma revisão casual. Também vai produzir resultados financeiros diferentes, uma fração de centavo por vez, ao longo de milhões de transações.
Esse é todo o problema da modernização de legado em uma linha, e é por isso que a forma como a OpenAI mediu seus modelos importa mais do que o número da manchete.
Duas avaliações, duas habilidades diferentes
A OpenAI criou duas avaliações para o que chama de linguagens de programação com poucos recursos, aquelas com pouco código público para aprender, mas com muita infraestrutura crítica por trás. A OpenAI cita estimativas de que o COBOL sustenta mais de 40% dos sistemas bancários on-line e 95% das transações em caixas eletrônicos.
MultiLangBench pede que um modelo construa um engine de banco de dados compatível com SQLite do zero em uma de 20 linguagens, ao longo de uma sessão de codificação estendida. Testes adaptados da própria suíte do SQLite verificam os arquivos de banco de dados resultantes. No esforço máximo de raciocínio, o GPT-6 Astra atinge uma taxa média de aprovação de 87,4%, contra 26,8% do GPT-5.6 Sol. O COBOL ainda é a linguagem mais difícil, com 72,1%, acima de 10,9%. A OpenAI liberou a configuração da avaliação e a suíte de testes no GitHub.
A avaliação de migração COBOL pede que um modelo traduza programas COBOL existentes para C++, Java, Kotlin, Python ou Rust preservando o que eles fazem. Testes ocultos exigem paridade byte a byte nas saídas observáveis, e uma migração só conta se todos os testes passarem. O GPT-6.1 Sol chega a 86,6% com esforço de raciocínio baixo, contra 5,4% do GPT-5.6 Sol na mesma configuração, com 61% do custo de API. Com esforço maior, chega a 97,9%, o que a própria OpenAI descreve como perto de saturar a avaliação.
São tarefas diferentes com modelos diferentes. Os 97,9% são sobre migração; os 87,4% são sobre construir software novo. Nenhum dos dois é um resultado independente de produção.
Por que o critério de sucesso é a notícia
A maioria das demonstrações de modernização assistida por IA mede se o novo código compila, se parece idiomático ou se um revisor gosta dele. O teste de migração da OpenAI mede se o programa ainda faz exatamente o que fazia, até o byte. Essa é a definição correta, e é a mesma por trás da abordagem Dual Run do Google: a substituição é provada ao reproduzir o comportamento real contra o original, não ao ler o novo código.
Uma avaliação quase saturada também diz algo útil: a tradução de programas autocontidos não é mais o gargalo. O custo e o risco de uma migração se deslocam para tudo ao redor da tradução.
| Pergunta | Avaliação da OpenAI | Uma migração de mainframe em produção |
|---|---|---|
| Unidade de trabalho | Programas COBOL individuais | Milhares de programas, copybooks e jobs JCL |
| O que define o correto | Testes ocultos, saída byte a byte | Regras de negócio que ninguém documentou, além das expectativas dos reguladores |
| Dependências | Contidas no harness de teste | CICS, DB2, arquivos VSAM, agendas de processamento batch, feeds downstream |
| Evidência de equivalência | Todos os testes passam | Execuções paralelas com dados de produção, reconciliadas |
| Quem aprova | A avaliação | Donos do negócio, auditoria e os operadores do sistema |
O que 97,9% não diz a um banco
De onde vêm os testes. Na avaliação da OpenAI, alguém escreveu os testes ocultos que definem o comportamento correto. Em um sistema de pagamentos de 40 anos, essa definição é a parte difícil. As regras de negócio vivem no código, nos hábitos dos operadores e em sistemas downstream que dependem de peculiaridades. Como a conversão da AWS de Azure para AWS mostrou em outro contexto, trocar as chamadas visíveis é fácil; a semântica se esconde nas bordas.
O que o harness deixa de fora. A avaliação não consegue representar toda dependência externa: monitores de transação, layouts de arquivo, timing de batch, o relatório que um regulador recebe todo mês. A OpenAI diz isso diretamente: o uso em produção ainda exige revisão especializada e testes contra as regras de negócio e as dependências do sistema.
Quem desenhou o teste. São avaliações da OpenAI sobre os modelos da OpenAI. A suíte MultiLangBench liberada permite que qualquer pessoa inspecione e execute novamente a tarefa de banco de dados; os testes ocultos da avaliação de migração, por design, não são algo que você possa auditar de fora.
Como usar o resultado
A mudança prática está na economia do programa, não na governança. Se a tradução fica barata e precisa, o orçamento deve migrar para as duas atividades que decidem se uma migração dá certo: descobrir comportamento (instrumentar o sistema atual, capturar entradas e saídas, minerar as regras) e provar equivalência (execuções paralelas, reconciliação, aprovação formal pelas pessoas responsáveis pelos resultados).
Um teste útil para qualquer fornecedor que venda modernização liderada por IA: peça que mostre o harness de equivalência antes da demo de tradução. Se o harness não existe, os 97,9% pertencem aos programas de outra pessoa.