La reescritura de 40.000 líneas de Fortran de Mistral muestra dónde se agota la autonomía de los agentes

40.000 de 300.000 líneas, para un cliente que nadie puede verificar

El equipo de IA Aplicada de Mistral afirma haber migrado 40.000 líneas de Fortran 77 a C++ para un operador energético europeo, el primer sprint de un trabajo de 300.000 líneas sobre un simulador de yacimientos intensivo en física. La empresa publicó el método en una entrada que también funciona como argumento de captación para ese mismo equipo.

Casi todo lo relativo al cliente queda fuera. Ni nombre, ni país, ni código, ni coste. Lo que sí dice la entrada es que el simulador no tenía suite de pruebas ni documentación centralizada, y que los ingenieros de yacimientos del cliente revisaron la arquitectura de destino.

Fortran 77 se estandarizó en 1977, y sus limitaciones condicionan lo que debe cambiar. No hay módulos, ni espacios de nombres, ni tipos estructurados. El estado del programa vive en bloques COMMON, memoria global compartida por todo el programa. Las variables se tipan implícitamente por su primera letra, de modo que un nombre mal escrito crea silenciosamente una nueva variable en lugar de fallar la compilación. Los nombres están limitados a seis caracteres. El lado de C++ también tuvo que integrar marcos modernos de computación científica como PetSc.

El primer intento produjo Fortran reescrito en C++

La parte más útil de la entrada es donde fracasa el primer intento. Mistral entregó una subrutina de Fortran a cada agente y los dejó trabajar de forma independiente durante una semana. El resultado se ejecutaba. No era modernización. Los bloques COMMON se convirtieron en estructuras globales uno a uno, y el flujo de control basado en GOTO sobrevivió intacto en lugar de reestructurarse en bucles o retornos tempranos. En palabras del propio Mistral, el resultado parecía Fortran reescrito con sintaxis de C++.

Un segundo intento añadió estructura: un planificador, un programador, un tester y un revisor de calidad de código trabajando juntos en cada módulo. La calidad mejoró sustancialmente. Después, la complejidad del código fuente alcanzó a los agentes, que topaban con un error, probaban unas cuantas correcciones y se estancaban sin nadie alrededor que los desbloqueara.

Lo que se entregó fue un término medio: un humano operando un flujo de trabajo de agentes programador, tester y revisor, migrando módulo a módulo e interviniendo cuando el bucle se atascaba.

La paridad numérica es el entregable real

Antes de escribir código de migración, Mistral construyó lo que denomina un arnés de paridad. Los agentes instrumentaron el Fortran para exportar instantáneas de estado en puntos que los ingenieros de yacimientos del cliente señalaron como críticos, y un framework de pruebas de C++ cargaba esos checkpoints y los comparaba con los módulos migrados. Archivos Skill.md indicaban a los agentes cómo usar el arnés correctamente.

Un ejemplo de la entrada: se insertó una línea en el Fortran para volcar el valor de RHOG, 42.71834 en esa ejecución. Esa misma cifra se convirtió en el checkpoint de referencia para el módulo de C++. Comprobar la igualdad entre ambas es barato y difícil de discutir, y por eso Mistral sostiene que el arnés pertenece al inicio de un proyecto de modernización, no al final.

Documentación antes de delegar

La segunda precondición es menos vistosa y, según el relato de Mistral, una de las mayores ganancias colaterales del proyecto. La documentación estaba dispersa en viejos PDF y enterrada en comentarios de Fortran. Como el código procedimental puede representarse como un único árbol de llamadas (caller-callee), el equipo analizó el código con un parser personalizado y luego usó Vibe CLI para lanzar más de cien agentes que lo documentaran, extrayendo los PDF relevantes mediante bibliotecas de documentos y Mistral OCR.

El trabajo empezó en las hojas del árbol y avanzó hacia arriba. Cada nodo lanzaba un subagente que lo documentaba y abría un pull request contra el repositorio original. Un agente revisor se ejecutaba en bucle según una programación cron, buscaba nuevos PR, los revisaba y programaba tareas de corrección.

Cómo no serán las 260.000 líneas restantes

Mistral traza la frontera por sí misma. Las 40.000 líneas eran funcionalidad central en un código autocontenido y ejecutable, con la física documentada en alguna parte, aunque mal. Las migraciones que dependen de sistemas externos, carecen de una base ejecutable o codifican física que nadie dejó por escrito traerían problemas que este sprint no tuvo que resolver.

El flujo de entrega es más estrecho que «los agentes hacen la migración». Los módulos se eligieron como subárboles independientes de tamaño manejable, empíricamente por debajo de unas 10.000 líneas de Fortran. Cada uno pasó por la misma secuencia: generar una arquitectura en C++, hacer que un ingeniero de yacimientos la revisara, dividir el diseño aprobado en una cola de tareas, ejecutar planificación, implementación y pruebas por tarea, y después hacer que un humano revisara los PR y solicitara cambios hasta que se fusionaran.

Tres reglas resumen la entrada: construir el arnés de paridad antes de escribir código de migración, poner en orden la documentación antes de apoyarse en los agentes y mantener puertas de revisión humana en el circuito, ya que tanto la autonomía total como las sesiones totalmente guiadas a mano perdieron frente al híbrido. Esa última afirmación proviene de un proveedor que vende proyectos de IA Aplicada, y la entrada no incluye ninguna comparación con otras prácticas de migración, ni cifras de precisión más allá de una variable volcada, ni plazos o costes para las 260.000 líneas restantes.