Mistral's 40,000-line Fortran rewrite shows where agent autonomy runs out

40,000 of 300,000 lines, for a client nobody can check

Mistral's Applied AI team says it migrated 40,000 lines of Fortran 77 to C++ for a European energy operator, the first sprint of a 300,000-line job on a physics-intensive reservoir simulator. The company published the method in a post that doubles as a recruiting pitch for the same team. The physics-heavy target fits Mistral's recent move into industrial simulation.

Almost everything about the client stays out of it. No name, no country, no code, no cost. What the post does say is that the simulator had no test suite and no centralized documentation, and that the client's reservoir engineers reviewed the target architecture.

Fortran 77 was standardized in 1977, and its constraints shape what has to change. There are no modules, no namespaces, no structured types. Program state lives in COMMON blocks, global memory shared across the whole program. Variables are implicitly typed by their first letter, so a misspelled name silently creates a new variable instead of failing to compile. Names are capped at six characters. The C++ side also had to integrate modern scientific computing frameworks such as PetSc.

The first attempt produced Fortran retyped in C++

The most useful part of the post is where the first attempt fails. Mistral handed one agent a Fortran subroutine each and let them work independently for a week. The output ran. It was not modernization. COMMON blocks turned into one-to-one global structs, and GOTO-driven control flow survived intact instead of being restructured into loops or early returns. In Mistral's own description, the result looked like Fortran retyped in C++ syntax: agents executing cleanly while missing the point, the same failure mode seen when agents run flawless work and still draw the wrong conclusion.

A second attempt added structure: a planner, a coder, a tester and a code quality reviewer working each module together. Quality improved substantially. Then the source code's complexity caught up with the agents, which would hit a bug, try a few fixes, and stall with nobody around to unblock them. The planner-plus-specialists setup echoes the multi-agent orchestration systems others are building.

What shipped was a middle ground: a human operating a workflow of coder, tester and reviewer agents, migrating module by module and stepping in when the loop seized up.

Numerical parity is the actual deliverable

Before writing migration code, Mistral built what it calls a parity harness. Agents instrumented the Fortran to export state snapshots at points the client's reservoir engineers flagged as critical, and a C++ test framework loaded those checkpoints and compared them against the migrated modules. Skill.md files told the agents how to use the harness correctly.

One example from the post: a line was inserted into the Fortran to dump the value of RHOG, 42.71834 on that run. The same figure became the reference checkpoint for the C++ module. Equality between the two is cheap to check and hard to argue with, which is why Mistral argues the harness belongs at the start of a modernization engagement, not the end.

Mistral's first sprint, by the numbers

Figure	Value
Fortran lines migrated in the first sprint	40,000
Total lines in the simulator	300,000
Module size cap chosen for the workflow	About 10,000 lines of Fortran
Agents spawned for documentation	More than 100
Fortran variable name length cap	6 characters
Reference checkpoint value (RHOG)	42.71834

Documentation before delegation

The second precondition is less glamorous and, on Mistral's account, one of the largest side-wins of the project. Documentation sat scattered across old PDFs and buried in Fortran comments. Because procedural code can be drawn as a single caller-callee tree, the team parsed the codebase with a custom parser, then used Vibe CLI to spawn more than a hundred agents to document it, pulling the relevant PDFs through document libraries and Mistral OCR.

Work started at the leaves of the tree and moved upward. Each node spawned a subagent that documented it and opened a pull request against the original repository. A reviewer agent looped on a cron schedule, looked for new PRs, reviewed them and scheduled fix tasks.

What the remaining 260,000 lines will not look like

Mistral draws the boundary itself. The 40,000 lines were core functionality in a codebase that was self-contained and runnable, with physics documented somewhere, however badly. Migrations that depend on external systems, lack a runnable baseline, or encode physics nobody wrote down would bring problems this sprint did not have to solve.

The delivery workflow is narrower than "agents do the migration." Modules were picked as independent subtrees of manageable size, empirically under about 10,000 lines of Fortran. Each went through the same sequence: generate a C++ architecture, have a reservoir engineer review it, break the approved design into a task queue, run plan, implement and test per task, then have a human review the PRs and request changes until they merge.

Three rules summarize the post: build the parity harness before writing migration code, get documentation in order before leaning on agents, and keep human review gates in the loop, since full autonomy and fully hand-driven sessions both lost to the hybrid. That last claim comes from a vendor selling Applied AI engagements, and the post carries no comparison against other migration practices, no accuracy figures beyond one dumped variable, and no timeline or cost for the remaining 260,000 lines. It also sits alongside independent evidence that AI-written code needs exactly the review Mistral insists on, since study findings show AI-written C++ runs hotter and takes longer to review.