Hay otra gente que ya lo está explicando muy bien en este hilo, añadiré un poco más en ese sentido. Yo también opino que esto es humo "IA" con poca sustancia.
Da igual que los modelos famosos generen código gramaticalmente correcto y que puedan traducir entre COBOL y otros lenguajes. Eso NO es el problema principal que tendría que resolver un banco para cambiar sus rutinas en un mainframe. Para nada. Y lo digo con bastante conocimiento de causa, porque trabajé más de dos años en un proyecto de migración del core de un banco (spoiler: dicho proyecto NO terminó en solamente dos años, ni mucho menos).
El problema es que en un banco uno se encuentra con literalmente MILES de programas. Unos se ejecutan diariamente a todas horas, otros mensualmente (simplificando), y otros con periodicidades distintas o de forma esporádica. Y algunos a lo mejor dejaron de usarse hace tiempo, pero es difícil estar seguro de que ya no cumplan ninguna función. Muchos de esos programas fueron escritos hace 10 o 20 años, actualizados por última vez hace años, algo que no es para nada frecuente en otros sectores. Esto tiene muchas implicaciones. Muchos de los autores de esos programas, ya no están, o están a otra cosa y ni se acuerdan de la problemática en la que trabajaron en aquella época (o no en detalle). Muchos de estos programas son lógica de negocio con la que no se puede jugar sin entender. Esto es, un programador sin experiencia en la problemática concreta, no puede entender bien cuál es el funcionamiento correcto del programa. Y en el propio banco puede no haber nadie, o muy poca gente, que pueda ayudar a resolver dudas al respecto. Incluso si la hay, y continua trabajando allí todavía, esa gente tienen otras tareas.
Traducir todos esos programas automáticamente, se puede hacer sin "IA". Ello NO es el problema. El problema es que uno tiene que asegurarse, que los miles de programas que ya funcionan, siguen funcionando. Esto tiene muchas complicaciones, que son la verdadera complicación de la migración. En esencia, es muy difícil verificar que el programa traducido a un lenguaje y entorno distinto, tenga exactamente el mismo comportamiento que el original. Más todavía cuando hay relaciones muy complejas a veces difíciles siquiera de detectar entre los resultados del procesamiento de distintos programas.
Y me estoy saltando problemas finos que los veteranos se pueden imaginar. O sea la cantidad de trucos y detalles varios que hay en el código de los programas originales, retorciendo al máximo las posibilidades del lenguaje y el entorno disponibles. El copy/paste de estos trucos con distintas variaciones. Etc.
Los modelos de LLM son completamente inútiles para esto que estoy comentando someramente que es la gran dificultad, o sea la validación y ajuste fino de los programas traducidos para que en su conjunto hagan lo mismo que el conjunto de los programas originales. Que es lo complicado y lo que lleva muchísimo tiempo puesto que hay que hacerlo de forma escalonada y con una enorme planificación y con sistemas de detección de fallos y backup pogre en la migración. Y una monitorización con expertos, durante toda la migración.
Lo que los modelos de LLM pueden hacer, ya se puede hacer sin ellos, y de forma más fiable. Esto es, con un transpilador adaptado a las necesidades del entorno. Pero claro esto es un trabajo fino que requiere de gente que al menos haya estudiado/trabajado en serio teoría de lenguajes y/o compiladores. Nada que no se pueda encontrar por ahí de todas formas.
theobjective.com