The Pulse
Mistral Agents Move 40,000 Fortran Lines to C++
Mistral AI says it helped a European energy operator migrate 40,000 lines of Fortran 77 from a reservoir simulator to C++. The company’s case study shows that testing, documentation and human review mattered more than giving coding agents f
AI.info Team ·
“It looked like Fortran retyped in C++ syntax rather than modernized code.”
Carlo Antonio Patti and Rasul Alakbarli, Mistral AI
Mistral AI says its agents helped a European energy operator migrate 40,000 lines of Fortran 77 to C++ in the first sprint of a much larger modernization project. The code belongs to a physics-intensive reservoir simulator with 300,000 lines, no test suite and no centralized documentation.
The company published the account on September 9, presenting the work as a case study in the limits of autonomous coding agents. Mistral’s engineers found that translating syntax was relatively straightforward, but reshaping a decades-old scientific program into maintainable object-oriented C++ required architectural decisions, numerical checks and repeated intervention from domain experts.
Fortran’s Global State Became the First Obstacle
Fortran 77 was standardized in 1977 and carries design assumptions that make direct modernization difficult. The language has no modules, namespaces or structured types. Program state often sits in COMMON blocks, shared memory structures that behave like global state, while implicit typing can allow a misspelled variable to create a new value instead of producing a compiler error.
Mistral contrasted a short Fortran routine for calculating gas density with a C++ implementation that uses explicit types, an object representing gas properties and a returned value. The new version does not preserve a line-by-line correspondence with the old one: arrays from COMMON blocks are consolidated, and a loop is moved to the caller. That makes the C++ easier to organize, but also makes equivalence harder to inspect by eye.
The simulator also needed to connect with modern scientific-computing frameworks, including PETSc. Before asking agents to rewrite modules, Mistral and the client had to establish a way to show that the new implementation still produced the same numerical results as the old one.
Mistral Built the Tests Before the Migration
The team created what it calls a parity harness. It added Fortran subroutines that export the program’s state, a C++ test framework that loads those checkpoints, and Skill.md files that instruct agents how to use the verification system.
The comparison covered final outputs as well as selected intermediate values identified by the client’s reservoir engineers. In one example, the Fortran program exported the value of a variable named RHOG, recorded as 42.71834 in that run. The C++ test used the same value as its reference checkpoint.
That arrangement gave the team a measurable signal when a migrated module matched the legacy implementation. It also reduced the risk of allowing an agent to run for a long period while introducing an unnoticed numerical error. Mistral says building the harness first was a net-positive investment and should be among the earliest steps in similar modernization work.
More Than 100 Agents Documented the Old Code
Documentation presented a separate problem. Relevant knowledge was spread across old PDF files and comments embedded in the Fortran source. Mistral parsed the code into a caller-callee tree, representing the program’s relationships as a hierarchy from lower-level routines to the functions that invoke them.
The company then used Vibe CLI to spawn more than 100 agents to document the tree. Agents could retrieve relevant PDFs through document libraries and Mistral OCR. Starting with the leaves of the tree, subagents wrote documentation and opened pull requests against the original repository. A reviewer agent monitored new pull requests on a scheduled loop and assigned follow-up tasks when changes were needed.
Mistral describes the documentation effort as one of the project’s largest side benefits. The work placed explanations nearer to the code before the migration team began making structural changes.
Full Autonomy Produced Functional but Dated Code
The first implementation attempt assigned one autonomous agent to each Fortran subroutine. The agents worked independently for a week and produced functional C++, but they largely preserved the old design. COMMON blocks became global structs, and GOTO-based control flow remained in place instead of being reorganized into loops or early returns.
Mistral’s second approach divided responsibilities among a planner, coder, tester and code-quality reviewer for each module. The result improved substantially, but the agents eventually stalled when they encountered difficult bugs. They tried several fixes and had no human available to resolve the underlying problem or change the plan.
The final workflow kept the same agent roles but added a human operator. The operator moved the migration forward module by module, intervening when agents became stuck and reviewing pull requests until they were ready to merge.
The First Sprint Covered 40,000 of 300,000 Lines
Working with the client’s reservoir engineers, Mistral divided the system into independent subtrees, generally smaller than about 10,000 lines of Fortran. Each module followed a fixed sequence: generate the target C++ architecture, review it with a reservoir engineer, break the approved design into tasks, run a plan-implement-test loop, and submit the resulting pull requests for human review.
The first sprint covered core functionality across 40,000 of the 300,000-line codebase. Mistral emphasizes that the starting conditions were favorable: the simulator was self-contained and runnable. Projects that depend on external systems, lack an executable baseline or contain undocumented scientific rules could pose harder problems than the case study addresses.
The company’s account offers a narrower claim than the idea of fully autonomous software migration. Agents handled large amounts of documentation, code production and review, but the project depended on a runnable legacy baseline, numerical checkpoints and reservoir engineers who could approve architectural decisions. For this system, the practical result came from putting agents inside a controlled workflow rather than removing people from it.