El benchmark COBOL de OpenAI casi satura; el mainframe sigue siendo necesario
OpenAI reporta 97,9% en su evaluación de migración COBOL y avances en COBOL, Fortran y Visual Basic. Lo útil es cómo define el éxito: comportamiento byte a byte, no código que compila.
Escuche este artículo · 6 min
Narración completa del artículo, generada con IA.
La frase más importante del artículo de investigación de OpenAI del 19 de octubre no es una puntuación. Es un ejemplo sobre redondeo. La aritmética de punto fijo de COBOL descarta los dígitos decimales sobrantes salvo que el programa pida explícitamente redondeo. Una reescritura en Java o Python que redondee esos valores en su lugar compilará, se ejecutará sin errores y pasará una revisión superficial. También producirá resultados financieros distintos, una fracción de céntimo cada vez, a lo largo de millones de transacciones.
Ese es todo el problema de la modernización de sistemas legacy en una línea, y por eso la forma en que OpenAI midió sus modelos importa más que la cifra del titular.
Dos evaluaciones, dos habilidades distintas
OpenAI creó dos evaluaciones para lo que llama lenguajes de programación de bajos recursos, aquellos con poco código público del que aprender pero con una gran cantidad de infraestructura crítica detrás. OpenAI cita estimaciones según las cuales COBOL sostiene más del 40% de los sistemas de banca en línea y el 95% de las transacciones en cajeros automáticos.
MultiLangBench pide a un modelo construir desde cero un motor de base de datos compatible con SQLite en uno de 20 lenguajes, durante una sesión de programación prolongada. Las pruebas adaptadas de la propia suite de SQLite comprueban los archivos de base de datos resultantes. Con el máximo esfuerzo de razonamiento, GPT-6 Astra alcanza una tasa media de aprobados del 87,4%, frente al 26,8% de GPT-5.6 Sol. COBOL sigue siendo el lenguaje más difícil, con un 72,1%, frente al 10,9% anterior. OpenAI publicó la configuración de la evaluación y la suite de pruebas en GitHub.
La evaluación de migración COBOL pide a un modelo traducir programas COBOL existentes a C++, Java, Kotlin, Python o Rust preservando lo que hacen. Las pruebas ocultas exigen paridad byte a byte en las salidas observables, y una migración solo cuenta si pasan todas las pruebas. GPT-6.1 Sol alcanza el 86,6% con esfuerzo de razonamiento bajo, frente al 5,4% de GPT-5.6 Sol con la misma configuración, al 61% del costo de la API. Con más esfuerzo llega al 97,9%, que la propia OpenAI describe como cercano a saturar la evaluación.
Son tareas distintas con modelos distintos. El 97,9% se refiere a migración; el 87,4%, a construir software nuevo. Ninguno de los dos es un resultado independiente en producción.
Por qué el criterio de éxito es la noticia
La mayoría de las demostraciones de modernización asistida por IA miden si el código nuevo compila, si parece idiomático o si le gusta a un revisor. La prueba de migración de OpenAI mide si el programa sigue haciendo exactamente lo que hacía, hasta el byte. Esa es la definición correcta, y es la misma que hay detrás del enfoque Dual Run de Google: el reemplazo se demuestra reproduciendo el comportamiento real contra el original, no leyendo el código nuevo.
Una evaluación casi saturada también le dice algo útil: la traducción de programas autocontenidos ya no es el cuello de botella. El costo y el riesgo de una migración se trasladan a todo lo que rodea a la traducción.
| Pregunta | La evaluación de OpenAI | Una migración real de mainframe |
|---|---|---|
| Unidad de trabajo | Programas COBOL individuales | Miles de programas, copybooks y trabajos JCL |
| Qué define lo correcto | Pruebas ocultas, salida byte a byte | Reglas de negocio que nadie documentó, más las expectativas de los reguladores |
| Dependencias | Contenidas en el harness de pruebas | CICS, DB2, archivos VSAM, planificaciones batch, feeds posteriores |
| Evidencia de equivalencia | Todas las pruebas pasan | Ejecuciones en paralelo sobre datos de producción, conciliadas |
| Quién da la aprobación | La evaluación | Los responsables de negocio, auditoría y los operadores del sistema |
Qué no le dice el 97,9% a un banco
De dónde vienen las pruebas. En la evaluación de OpenAI, alguien escribió las pruebas ocultas que definen el comportamiento correcto. En un sistema de pagos de 40 años, esa definición es la parte difícil. Las reglas de negocio viven en el código, en las costumbres de los operadores y en sistemas posteriores que dependen de rarezas. Como mostró en otro contexto la conversión de Azure a AWS de AWS, cambiar las llamadas visibles es fácil; la semántica se esconde en los bordes.
Qué deja fuera el harness. La evaluación no puede representar todas las dependencias externas: monitores de transacciones, estructuras de archivo, tiempos de batch, el informe que recibe un regulador cada mes. OpenAI lo dice directamente: el uso en producción sigue exigiendo revisión experta y pruebas contra las reglas de negocio y dependencias del sistema.
Quién diseñó la prueba. Son evaluaciones de OpenAI sobre modelos de OpenAI. La suite MultiLangBench publicada permite a cualquiera inspeccionar y volver a ejecutar la tarea de base de datos; las pruebas ocultas de la evaluación de migración, por diseño, no son algo que se pueda auditar desde fuera.
Cómo usar el resultado
El cambio práctico está en la economía del programa, no en su gobernanza. Si la traducción se vuelve barata y precisa, el presupuesto debería pasar a las dos actividades que deciden si una migración tiene éxito: descubrir el comportamiento (instrumentar el sistema actual, capturar entradas y salidas, minar las reglas) y probar la equivalencia (ejecuciones en paralelo, conciliación, aprobación por parte de quienes responden por los resultados).
Una prueba útil para cualquier proveedor que venda modernización liderada por IA: pídale que muestre el harness de equivalencia antes de la demo de traducción. Si el harness no existe, el 97,9% pertenece a los programas de otra persona.