Em 19 de outubro, a OpenAI publicou os resultados de uma avaliação dedicada à migração de programas escritos em linguagens de programação legadas, incluindo COBOL, para linguagens como Java, C++, Kotlin, Python e Rust.
Segundo os resultados divulgados pela empresa, o GPT-6.1 Sol atingiu 86,6% de precisão com baixo esforço de raciocínio, contra 5,4% da geração anterior. Com maior esforço de raciocínio, o resultado chegou a 97,9%.
O critério de avaliação é rigoroso: uma migração só é considerada correta quando passa por todos os testes ocultos, que exigem paridade byte a byte nas saídas observáveis. Em outras palavras, o programa novo precisa produzir exatamente os mesmos resultados que o original.
É um avanço significativo para o universo dos sistemas corporativos. Mas existe uma questão que merece atenção: reproduzir fielmente o comportamento de um sistema não significa que todas as regras incorporadas a ele devam continuar existindo.
Vale destacar que esses percentuais foram divulgados pela própria OpenAI e correspondem a uma avaliação específica, não a uma garantia de desempenho em projetos reais de migração.
O que a paridade garante e o que ela não responde
A paridade byte a byte confirma que o sistema migrado reproduz os resultados observáveis do sistema original. Esse é um requisito importante para uma migração tecnicamente consistente.
Entretanto, essa equivalência também preserva comportamentos que podem ter surgido de decisões deliberadas, exigências regulatórias, ajustes operacionais ou soluções provisórias que permaneceram no sistema ao longo dos anos.
A própria OpenAI apresenta um exemplo esclarecedor: a aritmética de ponto fixo do COBOL pode descartar casas decimais excedentes, a menos que o arredondamento seja solicitado explicitamente.
Uma reescrita que passe a arredondar esses valores pode funcionar sem apresentar erros de execução, mas produzir resultados financeiros diferentes.
Agora, considere o cenário inverso. Se a migração preservar perfeitamente o truncamento original, estará tecnicamente correta segundo o critério de paridade. Mas isso não esclarece se o comportamento foi definido por uma exigência regulatória, por uma convenção de negócio ou por uma característica que permaneceu no código sem uma revisão posterior.
Para o teste de paridade, essas situações podem produzir exatamente o mesmo resultado. Para o negócio, porém, suas implicações podem ser muito diferentes.
Essa distinção foi destacada também por um profissional que relatou ter desenvolvido COBOL para grandes seguradoras e companhias aéreas. Ao comentar os resultados, ele observou que gostaria que os responsáveis pelo negócio aprovassem as regras antes de uma migração desse tipo.
A reflexão resume um ponto essencial: a validação técnica não substitui a aprovação de quem responde pelas decisões de negócio.
Quando o código se torna a especificação
Ao explicar por que a migração de linguagens legadas é complexa, a OpenAI reconhece três dificuldades recorrentes: documentação incompleta, ausência dos desenvolvedores originais e regras de negócio que existem apenas no código.
Em aplicações corporativas que estão em produção há décadas, esse cenário é recorrente.
A especificação foi documentada em determinado momento, mas o sistema continuou evoluindo. Novos produtos, alterações fiscais, exceções comerciais e ajustes operacionais foram incorporados ao longo do tempo.
Cada mudança deixou sua marca. Em alguns casos, a documentação não acompanhou essa evolução. Gradualmente, o próprio código passou a concentrar informações que já não estavam registradas em outros lugares.
É nesse contexto que surge uma pergunta fundamental para qualquer projeto de modernização:
A organização sabe exatamente quais decisões seu sistema está tomando em nome do negócio?
A OpenAI também ressalta que a aplicação desses modelos em ambientes de produção continua exigindo revisão especializada e testes relacionados às regras de negócio e às dependências dos sistemas.
Essa recomendação evidencia uma etapa que não pode ser ignorada: compreender e validar o funcionamento da aplicação antes de transformá-la.
O trabalho que precisa acontecer antes da migração
Se a inteligência artificial reduz o esforço necessário para traduzir código, a atenção dos projetos de modernização precisa se concentrar ainda mais na compreensão do sistema existente.
Isso envolve algumas etapas importantes:
Tornar as regras compreensíveis: identificar comportamentos no código e documentá-los em modelos de processo, tabelas de decisão ou especificações que possam ser analisadas também pelas áreas de negócio.
Classificar os comportamentos identificados: diferenciar regras de negócio, obrigações regulatórias, decisões operacionais e soluções provisórias que acabaram incorporadas ao sistema.
Mapear dependências: compreender interfaces, arquivos, rotinas batch, integrações e outros componentes que influenciam o funcionamento da aplicação.
Envolver os responsáveis pelo negócio: levar as regras identificadas às áreas de operações, finanças, compliance, risco e jurídico para que possam avaliar sua validade e necessidade.
Essas áreas não precisam interpretar código COBOL. Precisam compreender os processos e as decisões que o sistema executa para avaliar se continuam adequados.
A partir dessa revisão, duas formas de validação passam a trabalhar em conjunto: os testes de paridade verificam se o novo código reproduz o comportamento do anterior; a aprovação do negócio determina quais regras devem continuar orientando a operação.
Uma validação não substitui a outra.
Modernizar também significa decidir o que evoluir
Existe outro aspecto importante nessa discussão: modernizar não significa, necessariamente, reescrever toda a aplicação.
Dependendo das características do ambiente, a evolução pode combinar diferentes abordagens: preservar funcionalidades que continuam atendendo ao negócio, modernizar componentes específicos, integrar sistemas existentes por meio de APIs e desenvolver novas capacidades sem descartar toda a estrutura já consolidada.
A escolha depende de uma compreensão adequada da arquitetura, das regras de negócio, das dependências e dos objetivos da organização.
É justamente nesse cenário que a inteligência artificial pode ampliar as possibilidades de modernização. Ela pode apoiar atividades de análise, documentação, tradução e desenvolvimento, reduzindo esforços em etapas que historicamente exigiam muito trabalho especializado.
Mas a tecnologia não elimina a necessidade de conhecimento sobre os ambientes corporativos nem transfere para o algoritmo a responsabilidade pelas decisões de negócio.
A perspectiva da INTERON
A experiência da INTERON com aplicações corporativas e ambientes COBOL reforça a importância de tratar a modernização como um processo de evolução, e não apenas como uma substituição tecnológica.
Ao longo de sua trajetória, a empresa acompanhou desafios relacionados à continuidade de sistemas críticos, à preservação de regras operacionais e à necessidade de conectar aplicações consolidadas a novas tecnologias.
Essa experiência ajuda a compreender que o maior desafio de uma modernização nem sempre está na linguagem utilizada ou na plataforma de destino. Muitas vezes, está no conhecimento acumulado dentro da aplicação e nas decisões que sustentam processos essenciais para a organização.
Por isso, cada iniciativa precisa considerar não apenas o que pode ser tecnicamente transformado, mas também o que precisa ser preservado, ajustado ou substituído.
Os avanços da inteligência artificial representam uma oportunidade importante para acelerar a evolução de aplicações legadas. Entretanto, a velocidade da transformação não deve antecipar decisões que dependem de uma compreensão mais profunda do negócio.
A IA pode ajudar a traduzir o código. Mas compreender o que ele representa, validar suas regras e decidir o que deve continuar fazendo parte da operação ainda exige conhecimento, experiência e participação das pessoas responsáveis pelo negócio.
Afinal, antes de perguntar se um sistema pode ser migrado, é necessário compreender o que a organização realmente deseja preservar.
INTERON
Evolving Business Applications
Fonte dos resultados mencionados: "Advancing coding in low-resource programming languages", publicado em 19 de outubro de 2026.