Mistral’s first fully autonomous attempt translated old Fortran into working C++. It also preserved the very architecture the team wanted to leave behind.
Mistral published a detailed legacy-modernization case study on September 9, 2026. Its team migrated 40,000 lines from a 300,000-line Fortran 77 reservoir simulator to C++. The project is useful because it records the failed approaches, not only the final workflow.
The hard part was proving the new code behaved the same
The source system had no test suite and no centralized documentation. That made a direct language translation dangerous. A clean-looking C++ function could compile and still change a numerical result after thousands of simulation steps.
Mistral built a numerical parity harness before the migration. That decision created an executable contract: run the original and migrated paths with the same inputs, then compare outputs within an acceptable tolerance. For scientific software, this is more valuable than asking a model whether its rewrite “looks equivalent.”
Three autonomy levels produced three different outcomes
| Approach | What happened | Lesson |
|---|---|---|
| One autonomous agent per subroutine | Generated functional C++ but retained global state and GOTO-shaped control flow | Local correctness can preserve system-level debt |
| Structured autonomous workflow | Improved organization but stalled on difficult bugs | More roles do not remove the need for escalation |
| Module-by-module human supervision | Planner, coder, tester, and reviewer roles worked through bounded units | Human review gates helped contain architectural and numerical errors |
The first failure is especially revealing. Assigning an agent to each subroutine optimizes for completing many small tasks. It does not automatically optimize for eliminating global variables, restructuring data flow, or replacing decades-old control patterns. The output can be correct at the function boundary and wrong for the modernization goal.
More than 100 agents mapped the code before translation
Mistral says more than 100 agents documented the caller-callee tree. That documentation work reduced a different risk: hidden coupling. In an old scientific program, a subroutine may depend on shared memory, implicit ordering, file formats, or side effects that are not visible in its signature.
I would copy this part before copying the code-generation part. A migration team needs a dependency map, state inventory, input-output catalog, and reproducible baseline before it needs a large pool of coding agents. Our guide to Codex versus Claude Code reaches the same practical conclusion: the harness and review boundary often matter more than the model label.
A reusable migration blueprint
- Freeze representative workloads: collect real inputs, expected outputs, and performance baselines before changing code.
- Build parity tests: define tolerances per calculation, not one universal floating-point threshold.
- Map dependencies: trace callers, shared state, files, external libraries, and initialization order.
- Choose module boundaries: migrate coherent units that can be tested in isolation.
- Separate roles: have planning, implementation, testing, and review operate with different prompts and evidence.
- Escalate ambiguity: stop when a numerical mismatch cannot be localized or when the agent proposes an architectural shortcut.
- Measure the new system: compare runtime, memory, reproducibility, maintainability, and defect discovery after parity passes.
A compiler passing is only the first checkpoint. For regulated, financial, climate, energy, or engineering code, teams also need audit logs that connect each changed module to its baseline tests and reviewer decision.
Why a runnable monolith was a favorable case
Mistral describes the simulator as self-contained and runnable. That is good news for parity testing. Many real legacy estates are harder: they depend on obsolete compilers, unavailable hardware, undocumented databases, nightly file transfers, or external services that no longer have test environments.
Before estimating a similar project, score four things: can the original system still run, can representative inputs be replayed, can outputs be compared automatically, and can modules be isolated without recreating production. A weak score on any one of them increases the human work sharply.
What the case study does not tell us
The published material covers the first 40,000 lines, not the entire 300,000-line migration. It does not provide the total calendar time, token or compute cost, number of human reviewer hours, defect density, performance change, or a control project completed without agents. Those missing figures make a return-on-investment claim impossible.
Mistral’s separate funding and sovereign AI strategy shows why enterprise modernization is commercially attractive. This case study is stronger when read as a workflow report, not as proof that every Fortran estate can be converted cheaply.
The failed autonomous run is the most useful result
The tempting headline is 40,000 lines migrated. The better lesson is that full autonomy created working code with the wrong structure, then a more organized agent workflow still stalled. The successful process became narrower, test-led, and human-supervised.
That is not a defeat for coding agents. It is a usable design pattern. Let agents accelerate dependency mapping, repetitive translation, test generation, and local debugging. Keep architecture, tolerances, escalation, and acceptance under accountable human control.
Read the primary case study
- Read Mistral’s legacy code modernization report.
- For a related developer-control example, see MustHave.ai’s report on GitHub Copilot Agentic Autofix.
Checked September 9, 2026. Project outcomes and workflow measurements are Mistral-reported. No independent cost or defect comparison was available.
