Mistral hat am 9. September 2026 einen Praxisbericht über die Migration eines wissenschaftlichen Fortran-77-Systems nach C++ veröffentlicht. Der Kunde ist ein europäischer Energieversorger; das gesamte Programm umfasst laut Mistral rund 300.000 Zeilen. Im ersten Sprint wurden 40.000 Zeilen migriert.
Mistrals erster autonomer Ansatz lieferte laut dem Unternehmen funktionierenden Code, aber kaum echte Modernisierung. Der spätere Workflow setzte deshalb zuerst auf Verifikation, Dokumentation und klar begrenzte Arbeitseinheiten.
Ohne Tests musste zuerst eine messbare Referenz entstehen
Das Ausgangssystem hatte laut Mistral keine zentrale Dokumentation und keine vorhandene Testsuite. Bei einem physikbasierten Reservoir-Simulator reicht ein Programm, das kompiliert und plausible Ergebnisse ausgibt, nicht als Nachweis einer korrekten Migration.
Mistral baute deshalb vor der eigentlichen Portierung einen Parity Harness. Zusätzliche Fortran-Subroutinen exportierten Zustände des laufenden Programms. Auf der C++-Seite lud ein Testframework diese Checkpoints und verglich sowohl Endergebnisse als auch ausgewählte Zwischenwerte.
Welche Zwischenwerte relevant waren, legten die Reservoir-Ingenieure des Kunden fest. Mistral nennt als konkretes Beispiel den Wert einer Variable RHOG, der in einem Lauf 42,71834 betrug und anschließend als Referenz für das migrierte Modul verwendet wurde.
Damit entstand eine maschinenprüfbare Definition von „fertig“, bevor Agenten größere Teile des Codes umschrieben. Ein Modell musste die fachliche Äquivalenz nicht selbst beurteilen, wenn ein deterministischer Test sie überprüfen konnte.
Mehr als hundert Agenten dokumentierten den Bestand
Fortran 77 erschwert die Migration durch seine Struktur. Zustand liegt häufig in COMMON-Blöcken, Typen können implizit aus Variablennamen entstehen, und moderne Konstrukte wie Namespaces oder strukturierte Typen fehlen.
Mistral erzeugte mit einem eigenen Parser zunächst einen Caller-Callee-Baum des Programms. Anschließend wurden über Vibe CLI mehr als hundert Agenten eingesetzt, um diesen Baum von den Blättern nach oben zu dokumentieren. Die Agenten verwendeten vorhandene PDFs, Kommentare im Code und Mistral OCR. Ergebnisse landeten als Pull Requests im Repository; ein weiterer Agent prüfte neue PRs regelmäßig und erzeugte bei Bedarf Korrekturaufgaben.
Diese Dokumentationsarbeit ließ sich stark parallelisieren, weil viele Teilaufgaben voneinander getrennt bearbeitet werden konnten. Die Agenten mussten dabei nicht gleichzeitig dieselbe Architektur verändern.
Volle Autonomie produzierte C++ mit Fortran-Struktur
Im ersten Migrationsversuch ließ Mistral jeweils einen Agenten eine Fortran-Subroutine unabhängig nach C++ übertragen. Nach einer Woche war das Ergebnis laut dem Bericht funktional, aber strukturell kaum modernisiert.
COMMON-Blöcke wurden praktisch eins zu eins in globale C++-Strukturen übertragen. GOTO-basierter Kontrollfluss blieb erhalten. Der Code war damit eher eine syntaktische Übersetzung als eine neue Architektur.
Im zweiten Versuch setzte Mistral mehrere Rollen pro Modul ein: Planung, Implementierung, Test und Code-Qualitätsprüfung. Die Qualität stieg laut Mistral, aber die Agenten liefen bei komplexeren Fehlern in Sackgassen. Nach mehreren erfolglosen Korrekturversuchen fehlte ein Mechanismus, der die Arbeit sinnvoll neu ausrichtete.
Das endgültige Verfahren behielt die spezialisierten Agenten, fügte aber einen Menschen als Operator und Review-Grenze hinzu. Der Mensch konnte festgefahrene Läufe abbrechen, Architekturentscheidungen klären und Pull Requests zurückweisen.
Mistral beschreibt unabhängige Module von empirisch weniger als ungefähr 10.000 Fortran-Zeilen als sinnvolle Arbeitseinheiten. Für jedes Modul wurde zuerst die Zielarchitektur erzeugt und mit einem Reservoir-Ingenieur geprüft. Erst danach entstand die Task-Queue für Implementierung und Tests.
Mehr Code pro Stunde löst das Prüfproblem nicht
Bei einer Migration dieser Art ist Codeerzeugung nur ein Teil der Arbeit. Die schwierigere Frage lautet, woran ein Team erkennt, dass sich das Verhalten des Systems nicht unbemerkt verändert hat.
Je mehr Code Agenten parallel erzeugen, desto wichtiger wird ein automatischer Prüfmechanismus, der ohne Modellbewertung auskommt. Das lässt sich auch auf normale Softwareprojekte übertragen. Ein Agent kann eine API umbauen, Datenbankcode ersetzen oder ein Frontend refaktorieren. Ohne Tests, reproduzierbare Builds und klar definierte Akzeptanzbedingungen wächst vor allem die Menge an Code, die anschließend überprüft werden muss.
Mistrals Fall hat klare Grenzen. Der untersuchte Fortran-Code war selbstständig lauffähig. Das Unternehmen weist ausdrücklich darauf hin, dass Systeme mit externen Abhängigkeiten, ohne ausführbare Referenz oder mit undokumentierter Fachlogik schwieriger wären. Eine konkrete Zeit- oder Kostenersparnis gegenüber einer manuellen Migration veröffentlicht Mistral nicht.
Aus den 40.000 migrierten Zeilen lässt sich deshalb keine allgemeine Produktivitätszahl ableiten. Der Bericht liefert stattdessen einen überprüfbaren Workflow: Agenten erhalten dort mehr Autonomie, wo Tests und menschliche Review-Grenzen das Ergebnis kontrollierbar machen.
Für größere Coding-Agent-Workflows wäre das auch bei Quavon die sinnvollere Messlatte. Nicht die Zahl geänderter Dateien entscheidet, sondern wie schnell sich nachweisen lässt, dass eine Änderung fachlich korrekt ist und ohne zusätzliche manuelle Recherche geprüft werden kann.
Quellen: Mistral, „Modernizing complex legacy code with AI agents“, 9. September 2026: https://mistral.ai/news/legacy-code-modernization/ RuntimeWire, „Mistral's 40,000-line Fortran migration kept humans firmly in the loop“, 9. September 2026: https://runtimewire.com/article/mistral-fortran-migration-human-review-ai-agents