Mistral used AI agents and a human overseer to rewrite 40,000 lines of Fortran into C++

Everything in this workflow rests on a parity harness, and Mistral built it before attempting the migration ^[8]. Engineers added subroutines to the Fortran application that exported snapshots of its state, then wrote a C++ test framework that loaded those checkpoints ^[8]. Reservoir engineers picked which intermediate values mattered, not only the final outputs, so each migrated module had numbers to hit ^[9]. That is what let the agents rewrite instead of transliterate ^[10].

The alternative is worse than it sounds. Fortran 77 shares state through global COMMON blocks, and a variable's type can be inferred from the first letter of its name ^[6]. Control flow leans on GOTO ^[6]. Convert that line by line and you get C++ that compiles and carries every one of those decisions forward under newer syntax ^[7]. Mistral's first implementation attempt assigned one autonomous agent per Fortran subroutine ^[18], and by its own account the result was functional but poorly modernized code ^[3]. The multi-agent workflow that followed stalled on difficult bugs ^[3]. A human operator unblocked the stuck agents and reviewed pull requests until they merged, while reservoir engineers reviewed and approved the target architecture ^[4].

Documentation behaved differently, for structural reasons. A custom parser produced a caller-callee tree of the procedural program, and starting at the leaves Mistral used Vibe CLI to deploy over 100 agents that combined code comments with information pulled from legacy PDFs ^[11], with Mistral OCR supplying the content of the older documents ^[12]. Those agents opened pull requests against the original repository, and a reviewer agent periodically checked new ones and created follow-up tasks ^[13]. Mistral's explanation of the asymmetry is the one I would give: documentation divides cleanly along a dependency tree that already exists, while architectural decisions cross module boundaries and small numerical differences can undermine the simulator's output ^[14].

The scope is worth stating plainly. The sprint covered 40,000 lines of core functionality out of a simulator holding roughly 300,000 lines of Fortran ^[2], about 13 percent ^[20]. The repository arrived with no test suite and no centralized documentation, with years of engineering knowledge sitting in old PDFs, comments and the program itself ^[17]. Mistral has not said when the engagement began, how long the sprint took, or whether the migrated modules are running in production ^[16]. Mistral supplied models and tooling, and its applied AI engineers worked alongside reservoir specialists who understood the physics in the software ^[19]. The case study appeared on September 9th, one day after Mistral announced a Samsung-led Series D ^[5], which is roughly what you would expect of a document doing two jobs.

Transfer depends on conditions this engagement happened to satisfy. The legacy program has to be interruptible at internal boundaries, so state can be dumped and reloaded ^[8]. Someone on the customer's staff has to know which of those values carry the physics and which are incidental, because that judgement is what turns a snapshot into a test ^[9]. And the call graph has to be recoverable by a parser you are willing to write ^[11]. Where the middle condition fails, there is no harness, and the agents revert to the configuration that produced compiling code nobody wanted ^[3]. The Skill.md instruction files steering tool and test choice ^[15] are the cheap part.

RuntimeWire reads the engagement as technical consulting built around proprietary AI infrastructure rather than a customer handing over an old repository and collecting modern C++ ^[21]. On the evidence Mistral published, that reading is hard to argue with.