Can AI Agents Port Legacy Fortran to Kokkos? What One Workflow Shows

Yes, an autonomous agent can take a first pass at porting your Fortran to Kokkos, and a working example now exists. But the honest answer to the title’s question has a shape: delegate the small, self-contained, well-tested kernels; keep humans on the MPI- and OpenMP-entangled modules; and treat the study’s headline autonomy claim as exactly that, a claim by its authors, not a replicated result. The practical consequence is that the bottleneck in Fortran modernization moves. Writing portable kernels is no longer the scarce resource. Verifying that the port preserves the numerics is, and the verification has its own costs in storage, procedure, and human attention.

That conclusion rests on one primary study and a ring of 2026 papers around it. Here is what each can and cannot support.

What the agentic workflow actually does

The central artifact is arXiv:2509.12443, which describes a pipeline of specialized LLM agents that, in the authors’ words, “collaborate to translate, validate, compile, run, test, debug, and optimize Fortran kernels into portable Kokkos C++ programs without human intervention, bounded by configurable retry and optimization thresholds.” Read that sentence carefully, because it contains both halves of the story. The loop is genuinely broad: translation is one step among seven, and the pipeline keeps iterating on compile errors, test failures, and performance until it succeeds or exhausts a retry budget you configure. The autonomy, though, is “bounded by configurable retry and optimization thresholds,” which means a human still decides where the loop stops and what counts as done. The workflow automates persistence, not judgment.

The “without human intervention” phrasing deserves explicit caution. It is the authors’ own description of their system. An independent cross-platform study of LLM-assisted Fortran-to-C++ translation, arXiv:2504.15424, reaches a cooler conclusion: “The state of the art shows the code bases in Fortran can be translated to C++ readily, but also demonstrate that no LLM on either platform was free of error. We still require a human-in-the-loop for code translation.” Translation works; error-free translation does not. Any deployment of the agentic workflow should budget for a reviewing engineer, which is not a defeat for the approach. A first pass that a senior person reviews is still cheaper than a first pass a senior person writes, provided the review is real.

The evidence base is narrower than the ambition

The evaluation in arXiv:2509.12443 covered five kernels from the NAS Parallel Benchmarks and OpenBLAS (DGEMM), plus biharmonic, a multi-file kernel from the E3SM codesign suite, with each configuration run five times on an NVIDIA A100 to capture the non-determinism of LLM-driven pipelines. The five-times repetition is good practice; single-run LLM results are anecdotes. But the kernel selection matters more. In the paper’s own framing, CG, EP, MG, FT, and DGEMM are “self-contained single-file programs,” while biharmonic alone was included “to test the cross-file dependencies typical of real legacy codebases.”

So five sixths of the evaluation exercised the easy case, and the one production-shaped case is a single kernel from a single codebase family; the multi-run evaluation covered one GPU partition, the A100, with only single-run portability checks on the MI250 and GH200 partitions.

The paper does report how often the loop succeeds, and the numbers deserve a careful read. Across the 120-run matrix, GPT-5 produced a functionally correct baseline on 29 of 30 runs and completed the full optimization workflow on 24 of 30; o4-mini-high managed 28 and 17; the open-weights models reached a correct baseline on 19 of 30 but finished the full workflow on only 8 to 11 of 30. Token cost per kernel and performance against the Fortran baselines are published as well, with FT, the most expensive kernel for GPT-5, at just over two dollars. The authors frame the limit themselves: “These results show feasibility at the kernel level rather than deployment-level reliability, since even GPT-5 completed the full workflow on only 80 percent of runs.” What the paper does not report is human review effort: the loop ran autonomously, so no review hours were measured, and there are no results beyond the six benchmark kernels. You still cannot answer “how much engineer time does this save me?” from the published evidence. An 80 percent full-workflow rate for the best model is a concrete reason to budget a reviewing engineer; how long that review takes on your code is the number no study can hand you.

For scale calibration, consider where production codes actually live. The CReSS weather simulation, target of a validation-centric AI-assisted port described in arXiv:2608.13122, spans 599 Fortran 90 files, roughly 260,000 lines, and 387 OpenMP parallel regions. That is two-plus orders of magnitude beyond the agentic study’s benchmark kernels, and it is typical of the backlog labs actually carry.

A delegation-suitability checklist

The evidence across these studies supports a concrete triage. None of the rows below are laws; they are where the failure modes documented in 2026’s porting literature concentrate.

One row deserves explanation. “No reference data” is a harder blocker than it looks. Every verification method in this literature compares the port against something: reference outputs, a compiler-spread envelope, or long-run statistics. If your legacy module has no trustworthy baseline, the agent produces plausible-looking Kokkos that you cannot accept or reject, and the human ends up writing the tests anyway, often by writing a reference implementation. At that point the delegation saved little.

What numerical equivalence to demand

This is where the 2026 literature is most instructive, and where the most common misconception sits. Bit-for-bit equivalence is not the field’s default acceptance standard, and demanding it will cause you to reject correct ports.

The clearest methodology comes from arXiv:2610.12662, which evaluates LLM translation of legacy Fortran atmospheric physics to GPU-accelerated JAX. Its key move is to separate the equivalence threshold from the translation framework entirely: “The envelope is not computed by the framework. It is obtained once per scheme by a separate procedure that compiles the Fortran reference under a set of compiler configurations, runs each build on the same inputs, and compares the outputs pairwise; the resulting per-variable values are supplied to the comparison stage as its thresholds.” The logic is sound and portable. Compilers already reorder floating-point operations, so the spread your reference code exhibits across compiler configurations is the smallest tolerance that means “no real change.” A port inside that envelope is as equivalent as a recompile.

Standards vary by stage and project, legitimately. In the FESOM2 port reported in arXiv:2606.11356, the Fortran-to-C stage was accepted by statistical agreement over multi-year runs rather than bit-for-bit equivalence, while the C-to-C++/Kokkos stage used different criteria. At the strict end, the hand-driven Kokkos port SACRA-K in arXiv:2607.08743 was validated by “(i) close agreement in the waveforms, (ii) exact bitwise preservation of the π symmetry, and (iii) second order convergence” against its Fortran parent. SACRA-K sets the bar any agentic port should eventually be measured against: agreement on the physics, bitwise where the structure permits, and convergence order preserved.

The failure mode that ties this together is the FESOM2 halo bug. According to arXiv:2606.11356, a routine computed two atmosphere-ocean exchange coefficients over owned points only, while sea-ice thermodynamics read them at the halo; the bug was “silent on one rank and appears at some rank counts and not others,” breaking cancellation in the sea-surface-height calculation. An equivalence check run at a single rank count, which is the natural configuration for a quick pilot, would never see it. This is the concrete reason MPI-entangled modules stay in the human column: the verification itself must vary rank counts, and designing that campaign is expert work.

What the loop automates, and what stays with you

The agentic loop of arXiv:2509.12443 automates the tedious middle: the mechanical translation, the compile-fix-compile cycle, the retry-on-failure persistence within your configured thresholds. It does not automate three things.

First, the equivalence envelope. Per arXiv:2610.12662, thresholds come from a separate per-scheme procedure you must run and supply. Second, the verification data itself. In the CReSS port, arXiv:2608.13122 reports that “even a minimal dump configuration for one test case, one MPI process, one timestep, and the target kernels produced more than 400 GB of dump data,” and the authors conclude the workflow needs “a dump-data lifecycle strategy: selecting representative dump points, retaining reusable reference artifacts, and compressing or discarding raw dumps when they are no longer needed.” The same authors frame their outcome as “a scenario-specific validated GPU port, not a complete GPU port of all CReSS executions.” Verification at production scale is a storage and data-management project before it is a GPU project. Third, acceptance. Given arXiv:2504.15424’s finding that no tested LLM translated error-free, someone who understands the numerics reviews the output. That review is the human-in-the-loop, and it does not disappear because the loop ran autonomously up to it.

The manual baseline you are comparing against

Delegation competes with manual and directive-based porting, so the baseline matters. Two anchors from the porting literature. The pre-LLM Hybrid Fortran work on the ASUCA weather model, arXiv:1710.08616, kept “more than 85% of the hybridized codebase a one-to-one copy of the original CPU-only code,” while an equivalent OpenACC solution was estimated at over ten thousand added lines, 12.5% of the reference codebase. That same port reportedly ran up to 4.9x faster per GPU socket than a multi-core CPU socket, with 24 Tesla P100 GPUs replacing more than 50 18-core Broadwell sockets on a full-scale run. And SACRA-K, per arXiv:2607.08743, runs its smallest configuration about an order of magnitude faster on four accelerators than the Fortran code on one 72-core CPU node. These are author-reported figures from their respective papers, not independent benchmarks, but they establish the payoff scale: manual Kokkos and hybrid ports deliver, and their cost is measured in engineer-years, not GPU-hours. The FESOM2 porting paper, arXiv:2606.11356, puts the baseline cost plainly: getting large legacy codes onto GPUs has so far “required years of specialist engineering,” and “the scarce resource is therefore not only compute time.” An agentic first pass does not need to be perfect to beat that baseline; it needs to be reviewable.

Run a bounded pilot before committing a codebase

The defensible path, given everything above:

1. Pick one kernel that is single-file, self-contained, and has existing reference outputs or tests. NAS-class shape, not CReSS-class.
2. Derive the acceptance envelope first, using the compiler-variation procedure from arXiv:2610.12662: build the Fortran reference under several compiler configurations, compare outputs pairwise, take the per-variable spread as your thresholds.
3. Run the agentic workflow with explicit retry and optimization thresholds, multiple times. The A100 evaluation in arXiv:2509.12443 ran each configuration five times precisely because LLM pipelines are non-deterministic; one success is not a success rate.
4. Measure what the paper cannot supply for you: human review hours on the generated Kokkos, and outcomes on your own kernels. Token cost and success rates on the six benchmark kernels are published; the review burden on production code is not, and that is the number that decides whether delegation pays.
5. If the kernel touches MPI halos or shared-memory regions, add rank-count-varied equivalence runs before accepting anything, per the FESOM2 lesson.

Verdict

Delegate bounded first passes on small, self-contained, well-tested numerical kernels, gated by a compiler-variation-derived equivalence envelope and a one-kernel pilot. Keep manual or directive-based rewrite for MPI/OpenMP-entangled multi-file modules, where silent rank-count bugs and 400 GB verification dumps make both the porting and the checking expert work. Treat “without human intervention” as an author-reported claim from a single unreplicated study: the independent cross-platform evidence says no LLM translated Fortran to C++ free of error, and a reviewing engineer remains part of the system either way. Even partial success reshapes the modernization backlog labs never fund, but it moves the scarce resource from writing kernels to proving they still compute the same numbers. Budget for the proving.

Frequently Asked Questions

What is the recommended first step before using an AI agent to port Fortran code?

Pick one kernel that is single-file, self-contained, and has existing reference outputs or tests. NAS-class shape, not CReSS-class.

How should the acceptance threshold for a ported kernel be determined?

Derive the acceptance envelope first, using the compiler-variation procedure from arXiv:2610.12662: build the Fortran reference under several compiler configurations, compare outputs pairwise, take the per-variable spread as your thresholds.

What specific verification step is required for kernels involving MPI halos?

If the kernel touches MPI halos or shared-memory regions, add rank-count-varied equivalence runs before accepting anything, per the FESOM2 lesson.