AI agents are getting useful at research software maintenance
A new field report from OpenAI and academic partners points to a practical, less glamorous use for AI coding systems: repairing and modernizing the neglected software that underpins large parts of scientific research. The report does not present the systems as autonomous scientific thinkers. Instead, it shows them acting as fast software workers that can refactor code, replace outdated tooling, migrate frameworks, and in some cases deliver dramatic performance gains.
That distinction matters. Many research tools started as code written to support a single paper or a narrow lab workflow. Over time, those tools became embedded in broader scientific pipelines even though they were not built with long-term maintenance, testing, or portability in mind. When original authors move on and funding is scarce, labs are left depending on brittle codebases that remain mission-critical.
The cases described in the report suggest coding agents may be well suited to this kind of backlog. They can read large codebases, propose upgrades, translate from one framework or language to another, and generate surrounding infrastructure such as build systems, installation steps, and tests. But the report also draws a sharp boundary around what these systems can and cannot do. They may be able to rewrite software quickly, yet they are not reliable judges of whether the scientific behavior of the rewritten system is actually correct.
From build cleanup to full rewrites
The report covers eight case studies, most of them in biology. The work ranges from relatively contained maintenance tasks to substantial rewrites of aging scientific software.
One simpler example involved cyvcf2, a Python library used for reading genetic data. In that case, GPT-5.5 replaced an outdated build and installation setup with a more modern one. That kind of work is often tedious but important: if software becomes difficult to install or compile, it can remain scientifically relevant while becoming operationally fragile.
A more involved project centered on MHCflurry, an immunology model used to predict which targets immune cells will recognize. According to the report, Claude Code and Codex alternated between developer and reviewer roles while porting roughly 10,000 lines of code from TensorFlow to PyTorch. That is the sort of migration many teams postpone for years because it is expensive, risky, and easy to break.
The most ambitious example highlighted in the source text is rustar-aligner, a Rust rewrite of STAR, a widely used tool for mapping sequencing reads to genome locations. STAR contains more than 20,000 lines of C and C++ and is no longer actively maintained, despite remaining part of many research pipelines. Rebuilding a tool like that is not just a software exercise. It risks introducing subtle changes that could alter downstream analyses if results diverge.
Performance gains are real, but trust must be earned
The reported gains are significant enough to explain why labs are interested. The source text says coding-agent-led efforts produced speedups of more than 60 times in some cases. The clearest example is RustQC, which combined 15 separate quality-control tools into a single program. On a large dataset, runtime fell from 15 hours and 34 minutes to 14 minutes and 54 seconds. For researchers working with large biological datasets, that kind of reduction can materially change how often analyses are run and how quickly experiments can iterate.
But speed alone is not the main story. The more important question is whether rewritten tools still behave like the originals in scientifically meaningful ways. The report appears to treat that validation work as central, not optional.
For rustar-aligner, the team compared the rewrite against STAR using 10,000 short sequencing reads from yeast cells. For single-end reads, the new tool matched STAR in 99.815 percent of cases. For paired-end reads, agreement reached 99.883 percent. The comparison was not limited to mapped locations in the genome. It also included several key output fields produced for each read. The source text further notes that neither tool mapped reads the other failed to map.
Those are strong compatibility numbers, but they also illustrate the core limitation of AI-generated scientific software. A model can produce convincing code and even plausible tests, yet humans still need to define what equivalence means, select the right benchmarks, inspect edge cases, and decide whether deviations matter scientifically.
The bottleneck is shifting from coding to review
That may be the report's most important implication. If coding agents continue improving, the scarcest resource in research software may no longer be raw implementation time. The real bottleneck may become expert verification.
In that world, labs do not simply hand software to an agent and accept the result. Instead, they supervise a workflow in which the model produces candidate implementations at high speed while domain experts spend their effort checking outputs, reproducing prior behavior, and confirming that no scientific assumptions have been smuggled into the rewrite. The workflow changes, but the need for expert oversight does not disappear.
This is especially relevant in research environments because code correctness is only one layer of the problem. A refactor can be syntactically clean, computationally faster, and still scientifically wrong if it changes numerical behavior, default parameters, or hidden assumptions. The report's warning that these systems cannot judge whether the science is right is therefore more than a caveat. It is the condition for using them responsibly.
What this could mean for science infrastructure
If the findings generalize, coding agents could become valuable infrastructure tools for academia. Scientific fields often depend on software that is too important to ignore but too underfunded to modernize manually. AI systems may be particularly effective in that maintenance gap, where the problem is not inventing new science but translating old, fragile code into forms that are easier to run, review, and extend.
The promise is substantial: faster migrations, better performance, revived toolchains, and fewer abandoned codebases. The tradeoff is that trust still has to be built the slow way. Scientific software cannot be accepted because it reads well or compiles cleanly. It has to be tested against real workloads and judged by people who understand the science as well as the code.
That makes the field report less a story about automated discovery than about division of labor. AI may handle more of the software modernization work. Researchers remain responsible for establishing whether the resulting systems deserve to be part of the scientific record.
This article is based on reporting by The Decoder. Read the original article.
Originally published on the-decoder.com
