El 19 de octubre de 2026, OpenAI presentó nuevos resultados sobre programación en lenguajes poco representados en los datos de entrenamiento. La investigación sobre OpenAI y COBOL incluye la construcción de un motor compatible con SQLite y la migración de programas existentes. Los resultados mejoran en las pruebas internas de la compañía, pero el punto crítico para quienes mantienen estos sistemas es conservar el comportamiento del software, incluidas las reglas que un código aparentemente más moderno podría alterar sin que nadie lo detecte.
¿Qué miden las dos pruebas?
OpenAI distingue dos capacidades distintas. MultiLangBench mide cuánto software funcional puede construir un modelo en veinte lenguajes de programación. La segunda evaluación analiza la traducción de programas COBOL preservando sus salidas de datos. Son benchmarks publicados por el propio proveedor, no un informe de migraciones bancarias completadas. El anuncio actualiza el panorama del coding agéntico de OpenAI: hace observables las tareas y los criterios de éxito concretos sobre los que verificar el progreso declarado.
Según los datos publicados por OpenAI, en MultiLangBench GPT-6 Astra alcanza una tasa media de superación de pruebas del 87,4%, frente al 26,8% de GPT-5.6 Sol, ambos en el nivel máximo de razonamiento. En la migración COBOL, GPT-6.1 Sol llega al 86,6% con razonamiento bajo, contra el 5,4% de su predecesor; con mayor razonamiento sube hasta el 97,9%. En MultiLangBench, GPT-6 Luna obtiene el 40,3%. Cada prueba tiene criterios diferentes: esos porcentajes no forman un ranking único ni comparable entre sí.
Our latest model advances bring stronger capabilities for building and migrating software in low-resource programming languages such as COBOL, Fortran, and Visual Basic.
, OpenAI (@OpenAI) October 19, 2026
These languages power software that banks, governments, and businesses depend on. Progress here means… pic.twitter.com/Mulo5P3iCO
Para quienes siguen la adopción de la inteligencia artificial en las empresas, la pregunta clave es entender qué se le está pidiendo exactamente al sistema. Escribir una función nueva y reemplazar un programa que lleva años en operación pueden requerir habilidades similares, pero conllevan riesgos muy distintos. En el segundo caso, una simplificación que parece razonable puede modificar una regla que nadie documentó en otro lugar. La evaluación, por tanto, debe conocer también qué es lo que el nuevo código debe conservar.
¿Cómo se controla un motor SQLite reconstruido?
El repositorio público de MultiLangBench explica el protocolo con detalle. El modelo recibe la documentación de SQLite 3.40.1 y debe producir un ejecutable en el lenguaje requerido. Cada caso parte de una base de datos inicial, aplica una consulta al programa candidato y verifica el resultado usando la implementación de referencia. Esto permite evaluar implementaciones escritas en lenguajes diferentes a través de una interfaz común, en lugar de juzgar únicamente si el código parece plausible a un lector.
El README del repositorio distingue también el material disponible del subconjunto sugerido. Alrededor de 24.000 casos se convirtieron desde la suite original; por razones de coste, el documento indica un subconjunto de 272 pruebas, permitiendo evaluaciones más extensas siempre que se declaren. No es correcto transformar el número de casos presentes en el repositorio en el número exactamente ejecutado en cada evaluación. El detalle importa porque un porcentaje solo es comparable cuando son explícitos la muestra, el entorno y las reglas de ejecución.
Las instrucciones imponen un entorno sin acceso a Internet y la eliminación de las copias de SQLite que el modelo podría reutilizar. Son condiciones diseñadas para aislar la habilidad observada. En los comparativos entre benchmarks, el perímetro de las herramientas disponibles forma parte del resultado. Aquí la pregunta es sobre la capacidad de construir una implementación desde cero: poder invocar el programa original cambiaría la tarea y haría menos informativa la puntuación obtenida.
¿Por qué conservar las salidas es más difícil que reescribir?
El criterio más relevante tiene que ver con la continuidad de las reglas de negocio. Un programa puede compilar, responder rápidamente y producir un archivo válido, pero tratar de forma distinta un caso límite. Como ejemplo ilustrativo: imaginemos un archivo en el que un campo vacío signifique “pendiente de verificar”. Una reescritura que lo convierta siempre en cero podría superar muchas pruebas ordinarias y cambiar el significado de los únicos registros todavía incompletos.
La comparación con la salida anterior sirve para identificar diferencias similares, pero no decide por sí sola si la regla antigua era correcta. Hay que distinguir dos trabajos: replicar el comportamiento existente y elegir conscientemente qué comportamientos modificar. Mezclarlos dificulta entender si una diferencia es un error de migración o un cambio intencionado. El control humano sigue siendo necesario, sobre todo cuando la decisión depende de una regla de negocio y no de la gramática del lenguaje.
OpenAI describe un caso concreto: la aritmética de coma fija de COBOL descarta los dígitos decimales sobrantes cuando no se solicita explícitamente el redondeo. Reescribir esa parte redondeando puede producir números diferentes sin que haya errores de ejecución. Por eso la prueba de migración exige correspondencia byte a byte de las salidas observables y considera exitosa una migración solo si supera todas las pruebas. El significado de “éxito” es más exigente que la simple compilación.
¿Un benchmark sustituye las pruebas de fiabilidad?
La documentación oficial de SQLite muestra la amplitud del problema de la robustez de una base de datos. Describe pruebas de agotamiento de memoria, errores de lectura y escritura, caídas del sistema, cortes de alimentación, archivos malformados y regresiones. La compatibilidad funcional observada sobre un conjunto de consultas es una dimensión útil. La capacidad de proteger datos y estado cuando el entorno falla es otra dimensión completamente distinta, que requiere pruebas diseñadas específicamente para esas condiciones.
El benchmark resulta más útil cuando ayuda a identificar los controles que faltan. En un sistema de archivo, por ejemplo, serían relevantes la recuperación tras una interrupción y la compatibilidad con las aplicaciones que lo consultan. Son verificaciones que hay que diseñar, no resultados atribuibles directamente a los modelos de la investigación. La suite publicada mide una parte de la funcionalidad: la fiabilidad de un sustituto requeriría también pruebas diseñadas sobre los errores y las dependencias del sistema original.
¿Qué hace reproducible la comparación?
Concretamente, el repositorio define el resultado a través de dos elementos: tasa de superación de pruebas y coste de las llamadas a la interfaz API. Una réplica debería declarar modelo, muestra, configuración y condiciones de ejecución, además del gasto observado. Conservar estos elementos permite entender si una diferencia proviene de un modelo mejor o de un presupuesto mayor. Registrar solo el porcentaje final elimina la información necesaria para repetir la comparación.
El nivel de razonamiento también requiere atención. En la migración COBOL, el 86,6% y el 5,4% se refieren ambos al nivel bajo de razonamiento; el 97,9% pertenece a una configuración más exigente, no especificada con una etiqueta precisa en el texto publicado por OpenAI. Confundirlos borraría una diferencia declarada. En la evaluación de la inteligencia artificial aplicada al software, la relación entre precisión y recursos empleados debe permanecer visible, especialmente cuando se decide qué configuración probar en un proyecto propio.
OpenAI y COBOL: resumen
- Confirmado: publicación de resultados el 19 de octubre y repositorio MultiLangBench accesible públicamente.
- No demostrado: que las puntuaciones equivalgan a la fiabilidad de una migración bancaria en producción.
- Por seguir: réplicas externas, muestras declaradas y verificaciones sobre las reglas específicas de los sistemas empresariales.
La lectura más amplia
El cambio más relevante es poder hacer observable una parte del trabajo sobre software heredado. Un banco de pruebas público permite discutir entradas, controles y errores concretos. Por eso el tema del control independiente de las evaluaciones de IA sigue siendo pertinente incluso cuando el material proviene de otro laboratorio: el acceso al método y la confirmación independiente son pasos distintos que no deben confundirse.
Las señales a seguir serán las implementaciones reproducibles, los defectos documentados y la comparación entre el tiempo ahorrado en la escritura y el requerido para la verificación. Un resultado cercano al máximo del benchmark puede indicar que la prueba necesita volverse más difícil, no que el problema industrial esté definitivamente resuelto. Para quienes mantienen sistemas críticos en América Latina y España, sean bancos, organismos gubernamentales o grandes empresas con legado COBOL de décadas, el progreso útil se mide en la calidad de los cambios que el equipo es capaz de aceptar, auditar y explicar.
