OpenAI lanza nuevas métricas para la programación de IA en idiomas con recursos limitados

OpenAI lanza dos nuevas evaluaciones dirigidas a "lenguajes de programación con recursos limitados": MultiLangBench requiere que los modelos implementen desde cero un motor de base de datos compatible con SQLite utilizando 20 lenguajes distintos; otra evaluación exige que los modelos migren programas COBOL a C++, Java, Kotlin, Python o Rust, manteniendo el comportamiento original. Los resultados oficiales muestran que GPT‑6 Astra alcanzó una tasa promedio de aprobación de pruebas del 87,4% en MultiLangBench, mientras que GPT‑6.1 Sol logró una precisión del 97,9% en la migración de COBOL bajo alta intensidad de razonamiento. Esto indica que la capacidad de programación de IA se está extendiendo desde lenguajes principales como Python y JavaScript hacia tecnologías heredadas aún utilizadas por bancos, gobiernos e instituciones de investigación. Sin embargo, estos resultados provienen de evaluaciones diseñadas y ejecutadas por OpenAI; el 87,4% representa el porcentaje de casos de prueba aprobados, pero no implica que el modelo haya implementado una versión de SQLite lista para producción, ni el 97,9% puede interpretarse como que los bancos puedan migrar sistemas críticos sin revisión humana.

Autor del artículo, fuente: OpenAI

En el campo de la programación con IA, los idiomas de bajos recursos se refieren a aquellos con menos código público, documentación y recursos de preguntas y respuestas disponibles para que los modelos aprendan, lo cual no implica que carezcan de valor real.

Python y JavaScript cuentan con un amplio ecosistema de código abierto, y los modelos pueden ver una gran cantidad de código, informes de errores y registros de correcciones durante el entrenamiento. En cambio, los materiales públicos disponibles para COBOL, Fortran, Visual Basic y OCaml son mucho menos abundantes, y gran parte de su código aún se encuentra almacenado en sistemas internos de empresas.

Al mismo tiempo, estos lenguajes aún cumplen tareas clave. OpenAI cita datos de IBM que indican que COBOL respalda más del 40% de los sistemas de banca en línea, el 80% de las transacciones de tarjetas de crédito presenciales y el 95% de las transacciones de cajeros automáticos; Fortran sigue utilizándose en pronósticos del tiempo y análisis de seguridad de reactores nucleares.

Mantener estos sistemas no es difícil solo por su sintaxis obsoleta. Los desarrolladores originales podrían haberse ido, la documentación no está completa y las reglas de negocio reales solo existen en el código. No hay ninguna explicación sobre por qué un programa trunca decimales o cómo maneja registros de cuentas inexistente, pero esto afecta directamente los resultados de cálculos financieros.

Por lo tanto, lo que la IA realmente necesita demostrar no es "si puede traducir COBOL a Python que parezca más moderno", sino si después de la migración sigue ejecutando las mismas reglas de negocio.

OpenAI lanzó MultiLangBench para este propósito. Requiere que el modelo construya, durante un proceso de programación prolongado, un motor de base de datos compatible con SQLite utilizando el idioma especificado.

El programa candidato recibirá un archivo de base de datos inicial y una consulta SQL; tras ejecutarla, producirá una base de datos modificada. El sistema de evaluación luego invocará la implementación oficial de SQLite para verificar si el contenido de la base de datos coincide con el resultado estándar. Mediante el uso del archivo de base de datos como interfaz común, se puede comparar el mismo conjunto de funciones entre lenguajes.

Cubre 20 lenguajes, incluyendo C, C++, COBOL, Fortran, Java, JavaScript, Lean, OCaml, Python, Rust, Visual Basic y Zig, evaluando la capacidad del modelo para organizar bases de código, gestionar estado, manejar errores, incorporar nuevas funciones y evitar romper funcionalidades existentes. Los casos de prueba se adaptaron del conjunto de pruebas existente de SQLite.

Con la máxima intensidad de razonamiento, la tasa promedio de aprobación en pruebas de GPT-6 Astra es del 87,4%, mientras que la de GPT-5.6 Sol es del 26,8%. OpenAI afirma que Astra mejora en las 20 idiomas:

COBOL aumentó del 10.9% al 72.1%, OCaml del 25.6% al 85.8%, Fortran del 21.4% al 83.5%, y Visual Basic del 27.5% al 89.4%. De las 20 lenguas, 19 superan el 83%, y COBOL sigue siendo la más difícil.

(Módulo interactivo con 20 idiomas intercambiables, donde puede ver los resultados y costos de cada modelo en cada idioma.)

Estos números deben entenderse correctamente. El 87.4% es el porcentaje promedio de casos de prueba aprobados y no indica que el modelo tenga un 87.4% de probabilidad de generar una base de datos completa, estable y completamente conforme a todas las especificaciones de SQLite. Los aproximadamente 12.6% de fallas en las pruebas aún podrían corresponder a problemas que impiden la implementación en producción, como transacciones, manejo de errores o consistencia de datos.

Demuestra que el modelo puede construir continuamente software más complejo en idiomas desconocidos, no que SQLite ya pueda ser reescrito por IA en una sola operación.

OpenAI también probó GPT-6 Luna, que tiene un costo más bajo. Su tasa de aprobación promedio en 20 idiomas fue del 40,3%, superior al 26,8% de GPT-5.6 Sol.

El costo promedio de la API de Luna es de aproximadamente $0.77 por muestra, mientras que GPT‑5.6 Sol es de aproximadamente $3.48, una reducción del 78%. Sin embargo, su mejora en capacidad no alcanza el nivel de Astra: Luna obtiene solo un 17.1% en COBOL, 31.4% en Fortran y 41.6% en Visual Basic.

Este conjunto de resultados presenta dos rutas diferentes: Astra utiliza más recursos de razonamiento para maximizar la completitud de tareas complejas; Luna procesa más muestras con costos más bajos, ideal para pruebas por lotes, análisis preliminares y tareas de apoyo de bajo riesgo.

El costo mencionado solo es una estimación de los gastos de la API en la evaluación y no incluye el esfuerzo humano requerido para la revisión de ingenieros, el entorno de pruebas, la aceptación del negocio y la corrección de errores. En sistemas heredados, los costos de llamada al modelo a menudo no son el mayor gasto en el proyecto de migración.

El segundo criterio de evaluación requiere que el modelo migre un programa COBOL a C++, Java, Kotlin, Python o Rust.

El enfoque de la prueba no es si el código de la traducción es limpio, sino si la salida observable de los programas nuevos y antiguos es idéntica byte a byte. Cada resultado de migración debe pasar todas las pruebas ocultas para considerarse exitoso.

OpenAI mencionó específicamente el ejemplo de números de punto fijo: COBOL puede descartar directamente los dígitos decimales adicionales por defecto, a menos que el programa exija explícitamente redondeo. Si el modelo modifica arbitrariamente el comportamiento a redondeo según los hábitos de programación modernos, el programa puede funcionar normalmente, pero los resultados financieros ya habrán cambiado.

Con una baja intensidad de inferencia, GPT-6.1 Sol alcanza una precisión de transferencia del 86.6%, mientras que GPT-5.6 Sol solo alcanza el 5.4%; el primero también reduce el costo estimado de la API en un 39%. Al aumentar la intensidad de inferencia, GPT-6.1 Sol alcanza el 97.9%, acercando esta evaluación al límite de saturación.

El 97,9% aquí se refiere al "porcentaje de programas que pasaron completamente los casos ocultos en esta prueba de OpenAI", no al "porcentaje de código que se puede migrar automáticamente y de forma segura en cualquier sistema COBOL".

Los sistemas bancarios reales pueden estar conectados a mainframes, bases de datos propietarias, programadores de procesamiento por lotes y protocolos de comunicación internos, además de presentar flujos excepcionales no cubiertos por los casos de prueba. OpenAI también ha indicado claramente que la migración a producción requiere una revisión de expertos y pruebas nuevamente según las reglas de negocio reales y las dependencias.

OpenAI ha subido al GitHub el entorno de evaluación MultiLangBench, el conjunto de pruebas y los resultados por idioma; los desarrolladores pueden revisar el contenido de las pruebas y volver a ejecutarlas con otros modelos o marcos de Agentes.

Esto tiene más valor que simplemente mostrar una tabla de resultados: el público puede observar en qué funciones de SQL falla el modelo y comparar si los resultados se ven afectados por los prompts, los permisos de herramientas, el presupuesto de razonamiento y la duración de ejecución.

Sin embargo, el artículo oficial solo anunció la publicación de MultiLangBench, sin mencionar que ya están disponibles la muestra completa del programa de evaluación de migración de COBOL y las pruebas ocultas. El puntaje del 97,9% de este último no puede ser verificado ni reproducido por terceros, como sí ocurre con MultiLangBench.

Ambas evaluaciones también fueron diseñadas por OpenAI y se utilizan principalmente para comparar sus propios modelos. Aún no cubren una gran cantidad de repositorios de código empresarial real, costos de mantenimiento a largo plazo, vulnerabilidades de seguridad, degradación del rendimiento ni cuánto tiempo requiere la revisión humana. Por lo tanto, los resultados demuestran en primer lugar el progreso del modelo en tareas controladas, no una validación final de la resolución del problema de modernización de software empresarial.

En los últimos dos años, las demostraciones de productos de programación con IA se han centrado principalmente en crear páginas web, aplicaciones móviles y herramientas de Python. Estos escenarios son intuitivos, pero no representan los problemas de software más costosos para las grandes empresas.

Lo que realmente les cuesta a los bancos, aseguradoras, gobiernos e instituciones de investigación es el código que ha estado en funcionamiento durante décadas y que nadie se atreve a modificar fácilmente. Puede que no sea moderno, pero contiene las reglas sobre las que dependen el procesamiento de cuentas, el cálculo de impuestos, la cadena de suministro y el funcionamiento de la infraestructura.

El significado de MultiLangBench es precisamente esto: ¿pueden las capacidades del modelo trascender el idioma de entrenamiento más común y aplicar métodos de ingeniería de software a pilas tecnológicas con escasos recursos, herramientas obsoletas y costos de error más altos?

Si esta capacidad continúa mejorando, el cambio más inicial que la IA podría traer no sería "eliminar todo el COBOL con un solo clic", sino ayudar a los ingenieros a leer código desconocido, completar pruebas, recuperar documentación faltante y localizar reglas de negocio, para luego realizar la migración verificada módulo por módulo. Los expertos humanos seguirán siendo los encargados de decidir qué comportamientos deben conservarse y cuándo se puede reemplazar realmente el sistema antiguo.