Mistral published a customer case study on September 9 detailing how it used its own AI agents to migrate a European energy operator's reservoir simulator from Fortran 77 to C++. The full codebase runs to 300,000 lines; this project touched 40,000 of them. The team started with nothing in place — no test suite, and no documentation gathered in one location.
The report spells out exactly what makes Fortran 77 hard to work with: no modules, no namespaces, no structured types. Program state lives in COMMON blocks — essentially global memory shared across the entire program. Variables are implicitly typed by their first letter, and names are capped at six characters, so reading the code is largely guesswork.
The first attempt handed the whole task to an agent working on its own. After a week, it hadn't worked. The team switched to a human-in-the-loop approach broken down by module, splitting each one across four roles — planning, coding, testing, and code-quality review — in a loop of plan, implement, test, and repeat. The human's main job was unsticking the agents when they got stuck.
Documentation first, then the code
The documentation pass ran on Vibe CLI, spinning up more than a hundred agents in parallel. Each agent could pull in relevant PDFs through a document library and Mistral OCR — the physical assumptions behind industrial software are often buried only in paper reports or scanned files, which is the most labor-intensive part of a project with no centralized documentation.
Module splitting followed a rule of thumb: keep each module's Fortran code to roughly 10,000 lines or fewer.
Numerical agreement as the acceptance bar
What held the project together was a parity-checking harness with three parts: a set of subroutines that export the Fortran codebase's runtime state, a test framework that loads those checkpoints into C++, and a handful of Skill.md files that guide the agents on how to use the first two correctly.
The report gives a concrete example: an agent inserted a line into the Fortran code to print out the value of the variable RHOG, which came out to 42.71834 in that run. It then used that same number as a reference checkpoint to test the migrated C++ module.
"Numerical agreement is the cheapest, most convincing proof that a module is done."
The bigger lesson here may have less to do with which model Mistral used. Power grids, oil and gas, weather forecasting, and aviation all sit on core computational code from the 1970s and '80s — often with the same profile: no tests, no documentation, and the original authors long since retired. For years, proposals to rewrite that code have stalled on sign-off: with no baseline, nobody wants to be the one who approves the rewrite. Mistral's approach hands that sign-off to numerical checkpoints instead, a step that has little to do with whose agents you use — it just requires a runnable legacy codebase to start from.
The report is upfront about its favorable starting conditions: the Fortran codebase was self-contained and already runnable. It lists three categories of cases that would be considerably harder — code that depends on external systems, code with no runnable baseline to check against, and code whose physical assumptions were never documented at all. As for how much faster this was than a manual rewrite, the report doesn't give a number.
Sources: Mistral official blog, CocoLoop; line counts, the module-size threshold, agent role breakdown, and the RHOG checkpoint value verified against the official case study.