Mistral migró 40,000 líneas de Fortran con agentes: poner en orden la documentación fue lo primero (2026)

La publicación comienza con una frase sobre personas, no sobre herramientas:

"Los códigos base científicos heredados se acumulan a lo largo de décadas y, cuando los autores originales se van, el conocimiento integrado en el código se vuelve difícil de recuperar."

Fortran 77, como señala la publicación, "se estandarizó en 1977, como su nombre sugiere, y el código escrito en él refleja directamente esas limitaciones: sin módulos, sin espacios de nombres, sin tipos estructurados. El estado reside en bloques COMMON (memoria global compartida por todo el programa)". Los nombres de las variables tienen un límite de seis caracteres. Un nombre mal escrito crea silenciosamente una nueva variable en lugar de generar un error.

Mistral planteó tres preguntas antes de comenzar: "Cómo demostrar que el código base migrado coincide numéricamente con el heredado", "Cómo dividir la migración en partes manejables" y "Cómo utilizar mejor los agentes autónomos para acelerar el proceso". Observe el orden. La prueba de equivalencia fue lo primero, la estrategia de agentes fue lo tercero.

El mecanismo de prueba fue un arnés de paridad. El equipo añadió "subrutinas que permiten exportar el estado del código base de Fortran", "un marco de pruebas para cargar los puntos de control en C++" y "archivos Skill.md para guiar a los agentes a usarlos correctamente". Su evaluación: "Construir esta parte del arnés primero fue una inversión netamente positiva para el proyecto: hizo que las ejecuciones largas de los agentes fueran más seguras, y la paridad numérica es un argumento convincente y fácil de verificar para demostrar que una parte del código se ha migrado con éxito".

Luego, la fase de documentación. La documentación existente del proyecto "estaba dispersa en viejos PDF y comentarios enterrados en el propio Fortran". Mistral generó un árbol de llamadas (caller-callee) "analizando el código base con un analizador personalizado", luego "utilizó Vibe CLI para generar más de cien agentes para documentarlo", trabajando desde las hojas del árbol hacia arriba, abriendo una solicitud de extracción (pull request) para cada nodo. Y describen el resultado de esta manera:

"Uno de los mayores beneficios secundarios de todo el esfuerzo fue conciliar esta documentación y moverla junto al código."

La migración en sí requirió tres intentos. El primero: "dimos total autonomía a los agentes: un agente por subrutina de Fortran, cada uno traduciendo su función a C++ de forma independiente a lo largo de una semana. El resultado fue funcional, pero no podía llamarse modernización de código. Los bloques COMMON se convirtieron en estructuras globales, uno a uno. El flujo de control basado en GOTO se mantuvo intacto en lugar de reestructurarse en bucles o retornos tempranos. Parecía Fortran reescrito con sintaxis de C++ en lugar de código modernizado".

El segundo intento dio estructura a los agentes: "un planificador, un programador, un probador y un revisor de calidad de código trabajando juntos en cada módulo". La calidad mejoró, pero: "la complejidad del código fuente acabó alcanzando a los agentes. Se topaban con un error, intentaban algunas correcciones y se estancaban, sin nadie disponible para intervenir".

Lo que se entregó fue el término medio: "un humano operando un flujo de trabajo de agentes programadores, probadores y revisores, migrando el código base módulo por módulo".

And las tres lecciones, textualmente: construir primero el arnés de paridad, 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, porque no se puede migrar código que nadie puede leer"; y "a esta escala, los flujos de trabajo estructurados con filtros de revisión humana superan tanto a la autonomía total como a las sesiones manuales guiadas a mano".

No dice que los agentes no puedan migrar código heredado. Lo hicieron, y el propio enfoque de Mistral es que la traducción de sintaxis es "una tarea prácticamente resuelta". La parte difícil fue arquitectónica: pasar de código procedimental a C++ orientado a objetos significaba que "no hay una correspondencia línea por línea para verificar, que es lo que dificulta la verificación de la migración".

Tampoco se generaliza a todos los sistemas heredados. Mistral lo dice directamente: "El código base de Fortran era autónomo y ejecutable, lo cual es una condición inicial favorable. Las migraciones que dependen de sistemas externos, carecen de una línea base ejecutable o codifican física no documentada en ninguna parte presentarían desafíos adicionales no analizados en esta publicación".

Lea esa última frase despacio. Física no documentada en ninguna parte. Mistral señala, como límite de su propio método, el caso en el que el conocimiento nunca se escribió. No que estuviera mal escrito. No que estuviera desactualizado. Ausente.

Lo que sí cambia la publicación es la prioridad. La limitación principal en este proyecto no fue la capacidad de los agentes. Fue si las razones detrás del código existían en un formato que algo pudiera leer, y dónde terminaban residiendo esas razones una vez recuperadas.

Ya están circulando tres interpretaciones, y cada una de ellas omite la parte que importa.

"Despliegue cien agentes en su código base heredado". Los cien agentes funcionaron porque un analizador personalizado ya había producido un árbol de llamadas para asignarlos, y porque Mistral pudo explotar una propiedad del código procedimental: "todo el programa se puede dibujar como un único árbol de llamadas". Sin esa estructura, no hay nada sobre lo que desplegarse. Los agentes fueron el último paso, no el primero.

"La documentación fue un buen efecto secundario". Mistral lo llama un "beneficio secundario", pero su propia lista de lecciones lo clasifica como una condición previa: ponerlo en orden antes de apoyarse en los agentes. Un efecto secundario que debes producir primero es un requisito previo con mejores modales.

"Los agentes pueden reconstruir el conocimiento que se perdió". Reconstruyeron la documentación a partir de archivos PDF y comentarios de código que aún existían. Donde no existía nada, Mistral lo marcó como fuera de alcance. Este es el mismo límite que otros dos proveedores trazan con sus propias palabras. Cline describe su Memory Bank como "una metodología de documentación que transforma a Cline de un asistente sin estado a un socio de desarrollo persistente", una metodología, es decir, algo que hacen las personas, no algo que la herramienta deduce. OpenHands divide ambos explícitamente: "mantenga AGENTS.md para las instrucciones dirigidas a cualquier agente que trabaje en el repositorio; la memoria es para lo que el propio agente aprendió". Tres proveedores independientes, tres formas de decir que la intención escrita y el conocimiento derivado son materiales diferentes.

Esto no es una crítica a ninguno de ellos. Es la forma del problema.

Si desea ver los casos adyacentes que ya hemos cubierto: la versión general de "el conocimiento se va cuando la gente se va" está en qué pasa con el contexto de la IA cuando alguien se va, y la mecánica para convertir los documentos existentes en algo que un agente realmente consulte está en convertir los documentos del proyecto en memoria de IA. Este artículo es más acotado que ambos: trata sobre el registro que crea una migración y si ese registro sobrevive a la migración.

La fase de documentación de Mistral recuperó lo que el código y los PDF aún contenían. La categoría que no pudo recuperar, y que señaló como su propio límite, es la categoría para la que vale la pena planificar. He aquí cómo separar ambas antes de comenzar.

Paso 1: Clasifique su conocimiento según si un analizador podría regenerarlo

Tome un módulo y enumere todo lo que necesitaría un nuevo ingeniero. Luego, marque cada elemento según si una herramienta que solo lea el repositorio podría producirlo.

Gráficos de llamadas, firmas de tipos, qué función llama a cuál, qué hace mecánicamente una subrutina: regenerable. Mistral demostró esto a escala: un analizador personalizado más agentes reconstruyeron exactamente esta clase de conocimiento a partir de un código base sin documentación centralizada.

Ahora la otra columna. Por qué este solucionador y no la alternativa obvia. Cuál de estos dos bucles dijeron los ingenieros de yacimientos que debía permanecer idéntico bit a bit. Por qué se abandonó el intento de migración anterior en 2019. Qué "puntos intermedios señalados por los ingenieros de yacimientos del cliente" importan y cuáles son secundarios (Mistral menciona que esos puntos de control provinieron de los ingenieros, no del código). Nada en el repositorio dice nada de eso.

La segunda columna es su inventario real. Todo lo que está en la primera columna es un artefacto de compilación.

Paso 2: Capture las razones en el momento en que se expresan

Las razones de la columna dos surgen durante el trabajo, no antes. Llegan en un comentario de revisión, en una llamada con un experto en el dominio, en la frase que alguien dice cuando un agente se estanca. El segundo intento de Mistral es donde esto es más visible: los agentes "se topaban con un error, intentaban algunas correcciones y se estancaban, sin nadie disponible para intervenir". La intervención que desbloquea un estancamiento es exactamente un hecho de la columna dos, y se expresa verbalmente, no se confirma en el código.

Así que captúrelo en ese momento. Cuando un humano desbloquee a un agente, escriba una línea: qué concluyó el agente, qué era realmente cierto y por qué. Cuando un experto en el dominio vete un diseño, registre el veto y su razón junto al diseño, no en el hilo de la solicitud de extracción que se cierra en una semana.

Esta es la misma disciplina que describimos en lo que debería estar anotando cuando las propias explicaciones de un proveedor se vuelven menos confiables: el artefacto duradero es la decisión y su justificación, no la transcripción que la produjo.

Paso 3: Dé al registro un hogar que no sea el proyecto

La documentación de Mistral fue "junto al código", lo cual es el primer paso correcto: solicitudes de extracción en el repositorio original, revisadas por un agente en una programación cron. Los archivos del repositorio son duraderos, tienen versiones y viajan.

Pero una migración produce dos tipos de escritos con diferentes vidas útiles. La documentación del módulo describe el código, por lo que pertenece al código y muere con él si el código se vuelve a reemplazar. Las decisiones (por qué esta arquitectura, qué limitaciones no eran negociables, qué descartaron los expertos en el dominio) sobreviven tanto a Fortran como a C++. Son la respuesta a una pregunta que se hará el próximo proyecto.

Estas necesitan un hogar que no sea un directorio dentro de un repositorio. Los archivos de habilidades son un buen vehículo para los procedimientos, razón por la cual Mistral escribió "archivos Skill.md para guiar a los agentes a usarlos correctamente", pero un procedimiento no es una razón, un punto que hemos desarrollado detalladamente en por qué las habilidades de los agentes no son memoria. Y los archivos de instrucciones tienen su propio alcance: como descubrimos en lo que realmente leen los agentes de programación, los agentes leen sus archivos de instrucciones, no su árbol de documentación.

Una capa de decisión compartida es la pieza que no pertenece a ningún repositorio individual. MemoryLake almacena los hechos de la columna dos (las resoluciones, las limitaciones, los enfoques abandonados y el porqué) para que cada agente que trabaje en la migración lea el mismo conjunto, y para que el conjunto siga allí cuando finalice el proyecto. La configuración requiere tres pasos: comience aquí.

Paso 1: Cree una clave de API

Cree un espacio de trabajo para la migración y genere una clave de API. Limite el alcance de un espacio de trabajo al programa en lugar de a un solo repositorio: el árbol de origen y el árbol de destino son dos repositorios, y las decisiones se aplican a ambos.

Paso 2: Suba sus primeras memorias

Comience con las intervenciones. Cada vez que una persona desbloqueó a un agente, ese intercambio contiene un hecho que el código no menciona. Agregue a continuación las resoluciones de los expertos en el dominio, luego la lista de puntos de control y por qué se eligió cada uno. Los archivos PDF, las notas de reuniones y los hilos de revisión se pueden ingresar directamente; no es necesario convertirlos primero a markdown.

Paso 3: Conecte su IA y agentes

Conecte los agentes que realmente realizan el trabajo: el programador, el probador, el revisor. Cada uno lee el mismo conjunto de decisiones, por lo que un agente revisor puede marcar un cambio que contradiga una limitación que el programador nunca vio. Esta es la brecha que los flujos de trabajo estructurados cierran manualmente, con un humano en el bucle; una capa compartida cierra parte de ella antes de que el humano tenga que hacerlo.

Su primer sprint deja de producir conocimiento que solo existe en la cabeza de tres personas. Cuando un módulo se entrega a un nuevo flujo de trabajo de agentes, las limitaciones llegan con él.

El modo de fallo del segundo intento se vuelve más barato. Los agentes se estancan repetidamente en la misma clase de problema: una convención numérica, un contrato implícito, una suposición física. El primer estancamiento cuesta una intervención humana. Los estancamientos posteriores sobre el mismo hecho no cuestan nada, porque el hecho ahora es legible.

And el registro sobrevive al proyecto. El primer sprint de Mistral cubrió 40,000 de las 300,000 líneas, lo que significa que se avecinan cinco sprints más, probablemente con personas diferentes. Si el sprint seis comienza a partir de las razones o las vuelve a descubrir se decide ahora, según dónde las coloque.

Escriba el arnés de paridad antes del código de migración. La afirmación más contundente de Mistral es que la concordancia numérica es "la prueba más barata y convincente de que un módulo está terminado". Un arnés es también un registro escrito de lo que significa "correcto", el documento más reutilizable que producirá el proyecto.

Mantenga el conocimiento regenerable y el no regenerable en lugares separados. Mezclarlos significa que cada regeneración corre el riesgo de sobrescribir la parte que no se puede regenerar. Esta es la misma trampa que describimos en cómo los agentes registraron lo que ya era cierto durante un gran esfuerzo de prueba: el valor duradero estaba en el registro escrito, no en la ejecución que lo produjo.

Registre los vetos, no solo las decisiones. "Elegimos PetSc" es más débil que "elegimos PetSc después de descartar dos alternativas, por estas razones". Las opciones descartadas son las que impiden que el próximo agente las vuelva a proponer.

Ponga fecha a los hechos del dominio. Una limitación de un ingeniero de yacimientos en septiembre puede ser reemplazada en marzo. Las limitaciones sin fecha se siguen para siempre o se ignoran por completo.

Trate los filtros de revisión humana como una fuente, no solo como un control. La tercera lección de Mistral es que los filtros superan a la autonomía total. Cada filtro es también un momento en el que una persona expresa algo que el repositorio no contiene: captúrelo allí.

El informe de Mistral se leerá como una historia sobre agentes que migran código heredado, y en cierto nivel lo es. Pero sus propias tres lecciones colocan un arnés y una fase de documentación por delante de la estrategia de agentes, y el límite que trazan alrededor de su propio método es el código que "codifica física no documentada en ninguna parte".

Los agentes abarataron el trabajo mecánico. No hicieron recuperable la intención no documentada, y Mistral no afirma lo contrario. La migración terminará. El C++ eventualmente también será heredado. Lo que trasciende es la parte que alguien decidió escribir, y dónde la colocó.