Cómo Mistral usó agentes de IA para modernizar código legado complejo: de Fortran 77 a C++ en un simulador de yacimientos

Mistral AI ha publicado un caso de estudio, firmado por Carlo Antonio Patti y Rasul Alakbarli el 9 de septiembre de 2026, en el que detalla cómo ayudó a un operador energético europeo (no identificado) a migrar 40.000 de las 300.000 líneas de un simulador de yacimientos escrito en Fortran 77 a C++ moderno. El proyecto es relevante porque combina dos problemas típicos del código científico heredado: una base de código sin suite de pruebas ni documentación centralizada, y un lenguaje sin ecosistema activo de desarrolladores sobre el que apoyarse.

El artículo subraya que traducir sintaxis de un lenguaje a otro es una tarea ya resuelta por los modelos actuales, pero que migrar un sistema completo de un paradigma procedural a uno orientado a objetos exige refactorizaciones arquitectónicas no triviales. Fortran 77, estandarizado ese mismo año, impone restricciones estructurales fuertes: no hay módulos, ni espacios de nombres, ni tipos estructurados; el estado vive en bloques COMMON (memoria global compartida por todo el programa); las variables se tipan implícitamente según su primera letra, de modo que un nombre mal escrito crea silenciosamente una variable nueva en vez de generar un error de compilación; y los nombres de variable están limitados a 6 caracteres, lo que los hace crípticos. El artículo ilustra esto con una subrutina real (GASDEN, que calcula una expansión de Taylor de primer grado) y su equivalente en C++, donde los arrays dispersos del bloque COMMON se convierten en un único parámetro de tipo GasProperties y el bucle sobre la malla se traslada al código que llama a la función. Esa reestructuración elimina la correspondencia línea por línea entre el código antiguo y el nuevo, lo que complica verificar que la migración es correcta, sobre todo si además hay que integrar frameworks modernos de computación científica como PETSc.

Para resolver ese problema de verificación, el equipo construyó primero un 'arnés de paridad' antes de dejar actuar a los agentes: añadieron subrutinas para exportar el estado del código Fortran en puntos de control, un marco de pruebas en C++ para cargar esos mismos checkpoints, y archivos Skill.md que orientaban a los agentes sobre cómo usarlos correctamente. Así, los agentes instrumentaban el Fortran para volcar snapshots de estado (el artículo muestra un ejemplo concreto con la variable RHOG tomando el valor 42.71834) y comprobaban que el módulo migrado en C++ reproducía exactamente esos valores. Mistral considera que este paso —probar la paridad numérica antes de escribir código de migración— debería ser de los primeros en cualquier proyecto de modernización, porque hace más seguras las ejecuciones largas de agentes y ofrece una prueba barata y convincente de que un módulo está terminado.

Otro bloque de trabajo fue documentar el código legado, cuya documentación estaba dispersa en PDFs antiguos y comentarios sueltos dentro del propio Fortran. Aprovechando que un programa procedural puede representarse como un único árbol de llamadas (caller-callee), el equipo generó ese árbol con un parser propio y usó su herramienta Vibe CLI para lanzar más de cien agentes que lo documentaran, empezando por las hojas del árbol y subiendo nodo a nodo; cada agente podía consultar los PDFs relevantes mediante bibliotecas de documentos y Mistral OCR, y abría un pull request al repositorio original. Un agente revisor, ejecutado en bucle según una programación tipo cron, vigilaba los PRs nuevos, los revisaba y programaba tareas de corrección cuando hacía falta.

El artículo relata además tres intentos sucesivos para calibrar cuánta autonomía dar a los agentes. En el primero, se asignó un agente por subrutina Fortran, cada uno traduciendo de forma independiente durante una semana: el resultado funcionaba, pero no podía llamarse modernización, ya que los bloques COMMON se convertían en structs globales de manera literal y el flujo de control basado en GOTO se mantenía intacto en lugar de reescribirse como bucles o retornos tempranos; en la práctica era Fortran retecleado con sintaxis de C++. En el segundo intento se sustituyó la autonomía total por estructura: un equipo de agentes por módulo compuesto por un planificador, un programador, un probador y un revisor de calidad. La calidad del código mejoró notablemente, pero la complejidad del código fuente terminó por superar a los agentes, que al toparse con un error probaban unas pocas correcciones y se quedaban bloqueados sin nadie que interviniera.

La solución final fue un término medio: una persona supervisando un flujo de trabajo de agentes programador, probador y revisor, migrando el código módulo a módulo. Esto conservó la calidad del segundo enfoque añadiendo un punto de control humano para desbloquear a los agentes cuando se atascaban. En la práctica, trabajando junto a ingenieros de yacimientos del cliente, usaron el árbol de llamadas para identificar módulos independientes —subárboles autocontenidos de tamaño manejable, empíricamente menos de unas 10.000 líneas de Fortran—. Cada módulo seguía el mismo proceso: generar la arquitectura C++ objetivo, revisarla con un ingeniero de yacimientos, y tras su aprobación, dividirla en una cola de tareas; cada tarea se ejecutaba mediante un subflujo de planificar → implementar → probar → repetir; y finalmente una persona revisaba los PRs resultantes y solicitaba cambios hasta que se fusionaban.

El artículo es transparente sobre el alcance logrado: el primer sprint cubrió la funcionalidad principal, es decir 40.000 de las 300.000 líneas totales, y reconoce que el Fortran de partida era autocontenido y ejecutable, una condición de partida favorable. Advierte explícitamente que migraciones que dependan de sistemas externos, que carezcan de una línea base ejecutable, o que codifiquen física no documentada en ningún sitio, plantearían retos adicionales no cubiertos en este caso.

Mistral resume la experiencia en tres principios aplicables a cualquier migración de sistemas legados a gran escala: construir el arnés de paridad antes de escribir código de migración, porque la concordancia numérica es la prueba más barata y convincente de que un módulo está terminado; poner en orden la documentación antes de apoyarse en los agentes, ya que no se puede migrar código que nadie puede leer; y, a esta escala, los flujos de trabajo estructurados con puntos de revisión humana superan tanto a la autonomía total de los agentes como a las sesiones manuales dirigidas por personas. El artículo cierra mencionando que el equipo de Applied AI de Mistral, dedicado a construir soluciones integrales sobre sus modelos y su plataforma empresarial, está contratando.

En conjunto, el caso ilustra un patrón que probablemente se repetirá en otros proyectos de modernización de software científico e industrial: los agentes de IA aceleran tareas mecánicas (traducción sintáctica, documentación masiva, generación de pruebas), pero la autonomía plena tropieza con la complejidad estructural real del código heredado, y el diseño de arneses de verificación objetiva —aquí, la paridad numérica— resulta tan importante como los propios agentes para que el trabajo sea confiable y auditable.