Puntos clave
- OpenAI afirma que sus modelos más recientes mejoraron su capacidad para construir y migrar software en lenguajes de bajos recursos como COBOL, Fortran y Visual Basic.
- El flujo consiste en darle al modelo código heredado y lógica de negocio para que lo explique, proponga reemplazos listos para migrar y sugiera planes de refactorización.
- No es un IDE ni una herramienta dedicada: todo pasa por los canales habituales de modelos y API de OpenAI, con la página oficial en openai.com como punto de partida.
- El interés está en el impacto real: bancos y gobiernos dependen de estos sistemas, y modernizarlos sin romper lo que funciona es un problema costoso y de largo plazo.
Datos rápidos
| Tipo | Mejora de capacidades de modelos de lenguaje para código heredado |
|---|---|
| Dispositivos | Navegador y API; depende del canal de OpenAI que uses |
| Precio | No anunciado en el comunicado; consulta la página oficial |
| Idiomas | No especificados; verifica en openai.com |
| Lo destacado | Explicar, migrar y refactorizar COBOL, Fortran y Visual Basic |
| Dificultad | Alta: requiere conocer el sistema heredado y validar cada cambio |
| Categoría | Tech en tendencia |
| Creador | OpenAI |
| Sitio oficial | openai.com ↗ |
| Popularidad | 🔥 1,7M Popularidad |
| Última actualización |
Qué anunció OpenAI y por qué COBOL y Fortran vuelven al centro de la conversación
El 19 de octubre de 2026 OpenAI publicó un anuncio centrado en un tema que rara vez aparece en las noticias de inteligencia artificial: los lenguajes de programación de bajos recursos. La compañía afirma que sus últimos avances de modelo mejoran las capacidades para construir y migrar software escrito en COBOL, Fortran y Visual Basic. No se trata de lenguajes exóticos ni de nicho: son la base de sistemas que bancos, gobiernos y empresas de todo el mundo siguen usando a diario porque funcionan y porque reemplazarlos es caro y arriesgado.
El mensaje de OpenAI es explícito sobre la motivación: entender décadas de lógica de negocio y ayudar a los desarrolladores a modernizar esos sistemas preservando lo que ya funciona. La compañía enmarca estas capacidades alrededor de los problemas que le traen desarrolladores y clientes empresariales, y cierra invitando a los equipos a decir qué lenguajes y flujos deberían abordar después. Ese detalle importa: sugiere que la hoja de ruta se está construyendo con casos reales de migración, no con una lista cerrada decidida de antemano.
Para el público general, la noticia es una ventana a un mundo invisible. Cada vez que usas un cajero, declaras impuestos o cobras una nómina, es probable que haya COBOL o Fortran en algún punto de la cadena. Que un laboratorio de IA dedique esfuerzo a estos lenguajes conecta la conversación sobre modelos con infraestructura crítica que sostiene servicios cotidianos, y explica por qué ingenieros que normalmente no comentan anuncios de modelos se interesaron en este.
- Lenguajes de bajos recursos
COBOL, Fortran y Visual Basic tienen menos código público de calidad que Python o JavaScript, así que los modelos suelen rendir peor en ellos. Ahí está el valor del anuncio.
- No es un producto nuevo
OpenAI describe una mejora de capacidades de sus modelos, no una aplicación independiente. Se usa a través de los canales habituales de modelos y API.
- Invitación abierta
La compañía pide a los equipos que indiquen qué lenguajes y flujos priorizar, lo que deja la puerta abierta a que el soporte se amplíe según la demanda real.
Cómo funciona en la práctica: del código heredado al plan de migración
El flujo que describe OpenAI es conversacional y por etapas. Le entregas al modelo el código heredado junto con la lógica de negocio que lo rodea, y el modelo lo explica en lenguaje claro, genera reemplazos listos para migrar y propone planes de refactorización. Es decir, no se limita a traducir línea por línea: intenta reconstruir la intención del sistema, que es justo lo que se pierde cuando el equipo original ya no está y la documentación es escasa o inexistente.
Ese enfoque encaja con la naturaleza de estos lenguajes. En COBOL abundan los programas monolíticos con reglas de negocio enterradas en condicionales, copys compartidos y convenciones de nombres crípticas. En Fortran, mucho código científico y de simulación arrastra décadas de optimizaciones manuales que no conviene tocar a ciegas. Un modelo útil aquí debe explicar antes de reescribir, y ese orden es el que sugiere el anuncio.
Conviene ser claro sobre lo que esto no es. No hay un IDE en línea dedicado ni una interfaz de juego o herramienta visual: el trabajo pasa por los canales de modelos y API de OpenAI, y la página oficial en openai.com es el punto de referencia. Tampoco se anunciaron precios, límites de contexto ni métricas de rendimiento en el comunicado, así que cualquier cifra que veas por ahí deberías verificarla en la fuente oficial antes de tomar decisiones.
- Explicar primero
Pide al modelo un resumen del módulo, sus entradas, salidas y reglas de negocio antes de pedir código nuevo. Ese paso detecta supuestos que ni el equipo conocía.
- Reemplazos listos para migrar
El modelo puede producir versiones en un lenguaje moderno, pero trátalas como borradores: la equivalencia funcional se demuestra con pruebas, no con confianza.
- Planes de refactorización
Además del código, puedes pedir una hoja de ruta por fases que priorice módulos de bajo riesgo y alto valor, útil para justificar presupuesto interno.
- Sin cifras confirmadas
OpenAI no publicó precios ni benchmarks específicos para estos lenguajes en el anuncio. Comprueba disponibilidad y costes en la página oficial.
Estrategia recomendada: cómo migrar sin romper lo que ya funciona
El propio anuncio sugiere un orden sensato: primero inventariar los módulos objetivo en COBOL, Fortran o Visual Basic, y después probar el modelo en un módulo pequeño y bien cubierto por pruebas antes de escalar a sistemas centrales. Ese consejo es la parte más valiosa para cualquier equipo, porque el riesgo de estas migraciones no está en escribir código nuevo, sino en cambiar comportamiento sutil que nadie documentó y que solo se manifiesta en producción.
Una rutina que funciona bien es la de tres pasadas. En la primera, pides al modelo que explique el módulo y que enumere sus reglas de negocio y casos límite. En la segunda, le pides una reescritura moderna acompañada de pruebas que capturen esos casos. En la tercera, comparas resultados entre el sistema antiguo y el nuevo con datos reales anonimizados. Si algo difiere, vuelves a la explicación: casi siempre el modelo reveló una regla que el equipo había pasado por alto.
También conviene tratar la salida del modelo como material de revisión, no como verdad. Los sistemas bancarios y gubernamentales suelen tener requisitos de auditoría, trazabilidad y cumplimiento que exigen documentar cada cambio y quién lo aprobó. Guarda los prompts, las explicaciones generadas y las pruebas como parte del expediente de migración: además de ayudar a la auditoría, te dará contexto para la siguiente fase.
- Empieza pequeño y con pruebas
Elige un módulo con buena cobertura de tests y bajo acoplamiento. Si el modelo falla ahí, mejor descubrirlo antes de tocar el núcleo del sistema.
- Congela el comportamiento
Genera pruebas de caracterización del sistema actual antes de reescribir. Sirven como red de seguridad objetiva frente a cambios invisibles.
- Documenta cada paso
Guarda explicaciones, prompts y resultados. En entornos regulados, esa trazabilidad es tan importante como el código final.
- Valida con datos reales
Compara salidas antiguas y nuevas con datos anonimizados de producción. Las diferencias pequeñas suelen señalar reglas de negocio olvidadas.
Para quién es útil, cómo se compara y qué queda por resolver
El público natural son equipos de modernización en banca, seguros, sector público y grandes industrias, además de proveedores que hacen migraciones por encargo. También resulta relevante para desarrolladores que heredan un sistema antiguo sin documentación y necesitan entenderlo rápido. En cambio, si tu proyecto es nuevo y usas lenguajes modernos, este anuncio apenas cambia tu día a día: la mejora se nota donde el código escasea en los datos de entrenamiento.
Frente a alternativas, la diferencia es de enfoque. Las herramientas clásicas de migración automática traducen sintaxis con reglas fijas y suelen atascarse con la lógica de negocio. Los asistentes de código genéricos funcionan bien en lenguajes populares, pero rinden peor en COBOL o Fortran por falta de ejemplos. Lo que OpenAI promete aquí es comprensión semántica del sistema completo, no solo traducción, y eso es más ambicioso y también más difícil de verificar.
Quedan preguntas abiertas importantes. No se detallaron precios, límites, idiomas soportados ni métricas comparativas, y tampoco hay una lista cerrada de lenguajes más allá de los tres mencionados. Tampoco está claro cómo se manejarán los datos sensibles de clientes que suban código bancario o gubernamental. Lo más prudente es leer la página oficial en openai.com, probar con material no confidencial y decidir después de validar resultados en tu propio entorno.
- Comparado con traductores automáticos
Los traductores por reglas convierten sintaxis, pero no reconstruyen intención. Un modelo puede explicar el porqué de una regla antes de reescribirla.
- Comparado con asistentes genéricos
Los asistentes de código suelen brillar en lenguajes con mucho código público. COBOL y Fortran son precisamente donde más se nota la falta de datos.
- Límites y dudas
Faltan detalles sobre precios, privacidad de datos empresariales y métricas. Verifica todo en la página oficial antes de comprometer un proyecto crítico.
- A quién no le sirve
Si trabajas en proyectos nuevos con lenguajes modernos, el impacto práctico de este anuncio es limitado por ahora.
Guía paso a paso
Revisa el anuncio en la página oficial
Empieza por la página oficial de OpenAI en openai.com para leer el comunicado completo y comprobar qué modelos y canales menciona. Ahí es donde aparecerán los detalles de disponibilidad, precios y límites si se publican más adelante. No te fíes de resúmenes de terceros para datos concretos.
Inventaría tus módulos heredados
Haz una lista de los programas en COBOL, Fortran o Visual Basic que te interesan, con su tamaño, criticidad y cobertura de pruebas. Marca los que tengan bajo acoplamiento y buen respaldo de tests como candidatos iniciales. Este inventario te dirá si el caso de uso encaja con lo que ofrece el anuncio.
Prueba con un módulo pequeño
Elige un módulo acotado y pide al modelo que lo explique, enumerando entradas, salidas y reglas de negocio. Después solicita una reescritura moderna y pruebas que cubran los casos límite que haya identificado. Compara el resultado con el comportamiento actual antes de ampliar el alcance.
Valida con datos y revisa con el equipo
Ejecuta el sistema antiguo y el nuevo con datos reales anonimizados y compara salidas campo por campo. Lleva las diferencias al equipo que conoce el negocio para decidir cuál es el comportamiento correcto. Documenta cada discrepancia y su resolución como parte del expediente de migración.
Escala por fases y da feedback
Una vez validado el piloto, amplía a módulos de mayor criticidad en fases, manteniendo siempre pruebas de caracterización y revisión humana. Si tu equipo tiene necesidades específicas de lenguajes o flujos, el anuncio invita a comunicarlas a OpenAI. Ese retorno puede influir en lo que se priorice después.
Preguntas frecuentes
¿Qué es exactamente el soporte de lenguajes legacy de OpenAI?
Es una mejora de capacidades de los modelos de OpenAI, anunciada el 19 de octubre de 2026, para construir y migrar software en lenguajes de bajos recursos como COBOL, Fortran y Visual Basic. No es una aplicación independiente ni un IDE: se usa a través de los canales habituales de modelos y API de la compañía. El objetivo declarado es ayudar a modernizar sistemas antiguos de bancos, gobiernos y empresas preservando la lógica de negocio que ya funciona.
¿Cuánto cuesta y en qué dispositivos puedo usarlo?
El anuncio no incluyó precios ni una lista de dispositivos o planes específicos para estas capacidades. Como se apoya en los canales de modelos y API de OpenAI, el acceso y el coste dependerán del plan o del consumo de API que ya uses. Lo correcto es consultar la página oficial en openai.com, donde se publican las condiciones vigentes, y no asumir cifras que no aparezcan allí.
¿Cómo se usa para migrar código COBOL o Fortran?
Le entregas al modelo el código heredado junto con la lógica de negocio, y él lo explica, genera reemplazos listos para migrar y propone planes de refactorización. La recomendación práctica es empezar por un módulo pequeño y bien cubierto por pruebas antes de escalar a sistemas centrales. Después validas el resultado comparando salidas antiguas y nuevas con datos reales anonimizados y revisión humana.
¿Puedo confiar en el código que genera el modelo?
Trátalo como un borrador experto, no como una verdad verificada. Los sistemas bancarios y gubernamentales tienen reglas sutiles que rara vez están documentadas, y el modelo puede pasarlas por alto o interpretarlas mal. La forma sensata de trabajar es generar pruebas de caracterización del sistema actual, comparar comportamientos y hacer que alguien que conoce el negocio apruebe cada cambio antes de llevarlo a producción.
¿Qué lenguajes soporta además de COBOL, Fortran y Visual Basic?
El anuncio menciona esos tres como ejemplos de lenguajes de bajos recursos, pero no publica una lista cerrada ni promete soporte para otros. OpenAI invita a los equipos a indicar qué lenguajes y flujos deberían abordarse después, lo que sugiere que la cobertura puede ampliarse según la demanda. Para saber si tu lenguaje concreto está cubierto, revisa la página oficial y prueba con un módulo de muestra.
