IA em COBOL, Fortran e Visual Basic: testes da OpenAI

A OpenAI publicou testes com COBOL, Fortran e Visual Basic. Veja os números do MultiLangBench e o que eles mudam na migração de sistemas legados.

Modelos de fronteira ficaram melhores em COBOL, Fortran e Visual Basic, e a distância para as linguagens populares encolheu. A OpenAI publicou em 19/10/2026 os resultados de duas avaliações criadas para medir exatamente isso, e o número mais útil para quem opera sistemas legados não é o recorde de acurácia. É o desempenho em COBOL, que segue sendo o caso mais difícil e o mais próximo da realidade de bancos, seguradoras, prefeituras e empresas de médio porte.

A leitura prática é dupla. O custo de experimentar caiu, porque modelos mais baratos chegaram a resultados que antes exigiam o modelo mais caro. O custo de errar não caiu, porque os testes exigem paridade byte a byte nas saídas observáveis e a própria OpenAI afirma que uso em produção ainda depende de revisão especializada. Quem trata o resultado como autorização para reescrever tudo de uma vez troca um problema conhecido por um problema silencioso.

Resumo rápido

A OpenAI publicou em 19/10/2026 resultados sobre programação em COBOL, Fortran e Visual Basic.

No MultiLangBench, o GPT-6 Astra chega a 87,4% de aprovação média nas 20 linguagens, contra 26,8% do GPT-5.6 Sol.

COBOL sai de 10,9% para 72,1%. É a linguagem mais difícil do conjunto, mesmo com o avanço.

Na migração de COBOL, o GPT-6.1 Sol alcança 86,6% de acurácia com baixo esforço de raciocínio, contra 5,4% do GPT-5.6 Sol.

Paridade byte a byte e revisão especializada continuam obrigatórias antes de qualquer produção.

O que a OpenAI publicou

O material descreve duas avaliações. A primeira é o MultiLangBench, que pede ao modelo para construir do zero um motor de banco de dados compatível com SQLite, em 20 linguagens diferentes. A segunda mede migração de código COBOL para C++, Java, Kotlin, Python ou Rust, com a exigência de preservar o comportamento do programa original. São tarefas longas, com muitas etapas encadeadas, e não exercícios de sintaxe.

A escolha das linguagens não é casual. COBOL sustenta mais de 40% dos sistemas bancários online, 80% das transações presenciais com cartão de crédito e 95% das transações em caixas eletrônicos, segundo dado citado pela OpenAI a partir da IBM. Fortran aparece em previsão do tempo e em análise de segurança de reatores nucleares. São áreas em que o software precisa continuar funcionando por décadas, com regras estáveis e pouca gente nova entrando para mantê-lo.

Esse é o ponto que interessa ao gestor brasileiro. O problema não é a linguagem ser antiga. É a combinação de documentação incompleta, profissionais escassos e um custo de erro que cresce com o tempo. Qualquer avanço em compreensão e reescrita desses sistemas tem efeito direto em filas de manutenção e em projetos que ficam anos parados por falta de quem consiga tocar o código.

MultiLangBench: os números por linguagem

O resultado geral é grande. O GPT-6 Astra atinge 87,4% de aprovação média nas 20 linguagens, contra 26,8% do GPT-5.6 Sol. A melhora aparece em todas as linguagens testadas, não apenas nas mais populares. O dado importante está na distribuição: o Astra passa de 83% em 19 das 20 linguagens, e COBOL é a exceção, com 72,1%.

Linguagem	GPT-5.6 Sol	GPT-6 Astra	Leitura
COBOL	10,9%	72,1%	Maior salto relativo, ainda o mais difícil
Fortran	21,4%	83,5%	Já entra na faixa de uso com supervisão
Visual Basic	27,5%	89,4%	Bom desempenho em código corporativo
OCaml	25,6%	85,8%	Mostra que o ganho não é só em linguagens antigas
Média das 20	26,8%	87,4%	Melhora em todas as linguagens

Há também um modelo mais barato na comparação. O GPT-6 Luna atinge 40,3% de média, com custo estimado de API de US$ 0,77 por amostra contra US$ 3,48 do GPT-5.6 Sol, cerca de 78% menor. Não é o modelo para tarefa crítica, mas é uma opção para triagem, classificação de trechos e geração de rascunhos que depois passam por revisão.

Para transformar isso em decisão de orçamento, vale montar a conta em planilha, cruzando volume de módulos, custo por amostra e horas de revisão humana. Um roteiro de como estruturar esse tipo de análise está em como usar IA para planilhas, fórmulas e análises. O ponto central é que o custo do modelo raramente é o maior item. O maior item é o tempo de quem valida o resultado.

Migração de COBOL: acurácia, custo e o teste mais duro

Na avaliação de migração, o GPT-6.1 Sol chega a 86,6% de acurácia com baixo esforço de raciocínio. O GPT-5.6 Sol, no mesmo cenário, fica em 5,4%. O custo também cai 39% em relação à configuração anterior. Com esforço de raciocínio maior, a acurácia sobe para 97,9%.

O número de 97,9% parece perto de pronto, mas o critério da avaliação é rígido. Ela exige paridade byte a byte nas saídas observáveis e todos os testes precisam passar. Não basta compilar, não basta rodar sem exceção, não basta o resultado parecer certo. A saída tem que ser idêntica à do programa original, caso a caso.

Essa diferença entre “parece certo” e “é idêntico” é o coração do problema. Um migrador que acerta 97,9% dos casos ainda erra 2,1% deles. Em um sistema com milhares de regras, isso pode significar dezenas de divergências, algumas em cálculos de juros, multas, descontos ou limites de crédito. A conta fecha no relatório e não fecha no caixa.

Por isso o uso responsável começa pelo inventário, não pelo modelo. Antes de gerar código, é preciso saber quais programas existem, quais rodam em lote, quais têm interface com outros sistemas e quais concentram regras de negócio que ninguém documentou. Sem esse mapa, a migração vira tentativa e erro em um ambiente que não perdoa erro repetido.

A armadilha do arredondamento

O detalhe técnico mais importante do material é também o mais fácil de ignorar. COBOL usa aritmética de ponto fixo e descarta as casas decimais excedentes quando não há arredondamento explícito. Uma reescrita em linguagem moderna que arredonda de forma diferente pode rodar sem erro e produzir um resultado financeiro distinto do original.

É o tipo de falha que passa em teste de fumaça, passa em revisão de código e aparece meses depois, na conciliação contábil. Em valores unitários, a diferença é de centavos. Multiplicada por volume, vira divergência material. Em sistemas de folha, faturamento, seguros e tributos, esse é o risco que domina a decisão de migrar ou não.

A recomendação prática é tratar arredondamento como requisito funcional, não como detalhe de implementação. Cada regra de cálculo precisa declarar quantas casas são mantidas, quando o truncamento acontece e quando há arredondamento explícito. Depois, o teste de paridade precisa cobrir exatamente esses casos de fronteira, com valores que forcem a diferença. Se o time não sabe responder onde o sistema trunca e onde arredonda, ainda não está pronto para migrar aquele módulo.

Exemplo: uma seguradora de médio porte no Rio de Janeiro

Cenário hipotético, sem relação com empresa real. Uma seguradora de médio porte no Rio de Janeiro mantém um módulo em COBOL que calcula prêmio e pro rata de apólices de automóvel. O módulo tem 30 anos, três pessoas sabem mexer nele e a documentação cobre metade das regras. A diretoria quer reduzir dependência e avalia usar um modelo de linguagem para gerar uma versão em Java.

O caminho seguro seria em etapas. Primeiro, inventariar as entradas e saídas do módulo e congelar uma amostra de casos reais, incluindo apólices com cancelamento, endosso e sinistro. Segundo, gerar a versão candidata e rodar a amostra em paralelo, comparando saída byte a byte. Terceiro, revisar cada divergência com quem conhece a regra de negócio, com atenção especial a truncamento e arredondamento. Quarto, rodar em modo sombra por alguns ciclos, sem substituir o original. Só depois de tudo isso, migrar um único produto.

Nesse cenário, o valor do modelo não é entregar o sistema pronto. É reduzir o tempo de leitura e de reescrita inicial, que costuma ser a parte mais lenta. A decisão de trocar o cálculo segue sendo humana, e o aceite continua sendo do atuário e do time de controles internos, não do fornecedor de IA.

Como colocar isso em produção com segurança

O roteiro abaixo serve para bancos, seguradoras, prefeituras e empresas de médio porte que queiram testar sem apostar o sistema inteiro.

Inventário antes de código. Liste programas, dependências, jobs, arquivos de entrada e saída e donos de cada regra. Sem esse mapa, nenhum resultado de modelo é verificável.
Amostra de ouro congelada. Separe casos reais representativos, incluindo exceções e valores de fronteira. Guarde entrada e saída esperada, com versão e data.
Teste de paridade byte a byte. Compare a saída do código novo com a do original, campo por campo. Divergência de formatação também conta como divergência.
Revisão explícita de arredondamento. Documente truncamento, casas mantidas e regras de arredondamento por cálculo. Crie casos que forcem a diferença entre truncar e arredondar.
Migração por partes, com execução paralela. Um módulo por vez, em modo sombra, com critério de aceite definido antes de começar. Nunca troque tudo no mesmo ciclo.
Revisão especializada e contrato claro. A OpenAI afirma que produção exige revisão especializada e testes contra regras de negócio e dependências. Coloque isso no contrato com o fornecedor, com responsabilidade por divergência e prazo de correção. Um roteiro de cláusulas está em cláusulas para contratos com fornecedores de IA.

Segurança e tratamento de dados entram na mesma etapa. Código legado costuma vir acompanhado de bases com CPF, endereço e informação financeira. Se essas bases forem usadas em teste, o ambiente precisa de controle de acesso, registro de uso e base legal definida. Um guia de implantação com esse recorte está em segurança e LGPD na implantação de IA.

Erros comuns

Ler 87,4% como sinal verde para produção. Média alta convive com casos ruins. O que decide é o desempenho no seu conjunto de regras, medido com os seus dados.
Testar compilação em vez de comportamento. Código que compila e roda não prova nada. A prova é a saída idêntica, caso a caso.
Ignorar arredondamento e truncamento. É a divergência mais silenciosa e a que mais custa caro em sistemas financeiros.
Migrar o sistema inteiro de uma vez. Sem execução paralela e sem critério de aceite por módulo, não existe rollback seguro.
Deixar quem conhece a regra de negócio de fora. Modelo lê código, não lê intenção. A regra que ninguém documentou só existe na cabeça de alguém.
Usar o modelo como substituto do inventário. A ferramenta acelera a reescrita, mas não descobre sozinha quais dependências precisam continuar funcionando.

Perguntas frequentes

Isso significa que COBOL vai desaparecer?

Não. Os números mostram avanço em compreensão e reescrita, não substituição automática. Sistemas em COBOL continuam rodando e continuam precisando de manutenção. O que muda é a velocidade com que um time consegue ler, documentar e propor uma versão nova.

Qual modelo escolher entre Astra, Luna e GPT-6.1 Sol?

Depende do risco da tarefa. O Astra lidera em acurácia média no MultiLangBench. O Luna custa menos por amostra e serve para triagem. O GPT-6.1 Sol aparece na avaliação de migração com 86,6% em baixo esforço e 97,9% em esforço maior. Para cálculo financeiro, comece pelo maior esforço que o orçamento permitir e valide com paridade.

Dá para migrar sem parar o sistema?

Sim, com execução paralela e migração por módulo. O sistema antigo continua atendendo enquanto o novo roda em modo sombra. A troca acontece só quando a paridade é comprovada e o aceite formal está assinado.

Preciso de equipe especializada?

Sim. A própria OpenAI afirma que aplicar isso em produção exige revisão especializada e testes contra as regras de negócio e dependências do sistema. O modelo reduz esforço de escrita, não elimina o especialista que valida o resultado.

Isso vale para prefeituras e empresas de médio porte?

Vale, desde que o escopo seja pequeno. Um módulo de cálculo de tributo ou de folha já justifica um piloto. O erro comum é começar pelo sistema inteiro, que dilui o esforço e dificulta medir resultado.

Como começar sem risco alto?

Escolha um módulo com regra estável, dono identificado e volume de casos suficiente para testar. Congele a amostra de ouro, rode a paridade e trate o resultado como evidência técnica, não como anúncio interno. Depois decida se vale ampliar.

IA em COBOL, Fortran e Visual Basic: o que os novos testes da OpenAI mostram