How Mistral used AI agents to modernize complex legacy code: from Fortran 77 to C++ in a reservoir simulator

🕒 Published on Zendoric: September 12, 2026 · 13:31
✨ AI-generated · how it's made
Mistral AI has published a case study, authored by Carlo Antonio Patti and Rasul Alakbarli on September 9, 2026, detailing how it helped an unnamed European energy operator migrate 40,000 of the 300,000 lines of a reservoir simulator written in Fortran 77 to modern C++.
Mistral AI has published a case study, authored by Carlo Antonio Patti and Rasul Alakbarli on September 9, 2026, detailing how it helped an unnamed European energy operator migrate 40,000 of the 300,000 lines of a reservoir simulator written in Fortran 77 to modern C++. The project is notable because it combines two problems typical of legacy scientific code: a codebase with no test suite or centralized documentation, and a language with no active developer ecosystem to lean on.
The article stresses that translating syntax from one language to another is a task today's models have already solved, but that migrating an entire system from a procedural paradigm to an object-oriented one demands non-trivial architectural refactoring. Fortran 77, standardized that same year, imposes strong structural constraints: there are no modules, namespaces or structured types; state lives in COMMON blocks (global memory shared across the whole program); variables are implicitly typed according to their first letter, so a misspelled name silently creates a new variable instead of raising a compilation error; and variable names are limited to 6 characters, which makes them cryptic. The article illustrates this with a real subroutine (GASDEN, which computes a first-degree Taylor expansion) and its C++ equivalent, where the scattered arrays of the COMMON block become a single parameter of type GasProperties and the loop over the grid moves into the code calling the function. That restructuring eliminates the line-by-line correspondence between old and new code, which complicates verifying that the migration is correct, especially when modern scientific computing frameworks such as PETSc also have to be integrated.
To solve that verification problem, the team first built a 'parity harness' before letting the agents loose: they added subroutines to export the Fortran code's state at checkpoints, a C++ test framework to load those same checkpoints, and Skill.md files guiding the agents on how to use them correctly. The agents then instrumented the Fortran to dump state snapshots (the article shows a concrete example with the variable RHOG taking the value 42.71834) and checked that the migrated C++ module reproduced those values exactly. Mistral considers this step — testing numerical parity before writing any migration code — should be among the first in any modernization project, because it makes long agent runs safer and provides cheap, convincing proof that a module is finished.
Another block of work was documenting the legacy code, whose documentation was scattered across old PDFs and stray comments inside the Fortran itself. Taking advantage of the fact that a procedural program can be represented as a single caller-callee call tree, the team generated that tree with a custom parser and used its Vibe CLI tool to launch more than a hundred agents to document it, starting from the tree's leaves and working up node by node; each agent could consult the relevant PDFs via document libraries and Mistral OCR, and opened a pull request to the original repository. A reviewer agent, run in a loop on a cron-style schedule, watched for new PRs, reviewed them and scheduled fix tasks when needed.
The article also recounts three successive attempts to calibrate how much autonomy to give the agents. In the first, one agent was assigned per Fortran subroutine, each translating independently over a week: the result worked, but could not be called modernization, since COMMON blocks were turned into global structs literally and the GOTO-based control flow was kept intact instead of being rewritten as loops or early returns; in practice it was Fortran retyped in C++ syntax. The second attempt replaced full autonomy with structure: one agent team per module made up of a planner, a coder, a tester and a quality reviewer. Code quality improved markedly, but the source code's complexity eventually outstripped the agents, which on hitting an error would try a few fixes and then stall with no one to step in.
The final solution was a middle ground: a human supervising a workflow of coder, tester and reviewer agents, migrating the code module by module. This preserved the quality of the second approach while adding a human checkpoint to unblock the agents when they got stuck. In practice, working alongside the client's reservoir engineers, they used the call tree to identify independent modules — self-contained subtrees of manageable size, empirically under about 10,000 lines of Fortran. Each module followed the same process: generate the target C++ architecture, review it with a reservoir engineer, and once approved, break it into a task queue; each task ran through a sub-workflow of plan → implement → test → repeat; and finally a human reviewed the resulting PRs and requested changes until they were merged.
The article is transparent about the scope achieved: the first sprint covered the core functionality, that is 40,000 of the 300,000 total lines, and it acknowledges that the starting Fortran was self-contained and runnable, a favorable starting condition. It explicitly warns that migrations depending on external systems, lacking a runnable baseline, or encoding physics not documented anywhere would pose additional challenges not covered in this case.
Mistral distills the experience into three principles applicable to any large-scale legacy system migration: build the parity harness before writing migration code, because numerical agreement is the cheapest and most convincing proof that a module is finished; get the documentation in order before relying on agents, since you cannot migrate code no one can read; and, at this scale, structured workflows with human review points beat both full agent autonomy and human-led manual sessions. The article closes by noting that Mistral's Applied AI team, dedicated to building end-to-end solutions on its models and enterprise platform, is hiring.
Taken together, the case illustrates a pattern likely to repeat across other scientific and industrial software modernization projects: AI agents speed up mechanical tasks (syntactic translation, bulk documentation, test generation), but full autonomy runs into the real structural complexity of legacy code, and designing harnesses for objective verification — here, numerical parity — proves as important as the agents themselves in making the work reliable and auditable.
🔗 Related on Zendoric
- Platform engineering for the agentic enterprise: how to manage applications, resources and AI agents · 2026-07-24
- Cursor's agent swarms: how they rebuilt SQLite in Rust and what it reveals about the real cost of models · 2026-07-28
- Europe's AI Act faces its first real test: 18,000 autonomous agent edits on a German wiki · 2026-09-08


