AI coding agents are starting to look useful for one of science's least glamorous problems: aging research software. A field report from OpenAI and academic partners describes eight case studies, mostly in biology, where systems such as Codex and Claude Code helped update, optimize, or rewrite tools that researchers still depend on.
The results are promising, but they also draw a clear boundary. Agents can move quickly through implementation work. They cannot reliably decide whether the science behind that work is correct.
Why old research code is such a hard target
Many important research tools did not begin as long-term software products. They often started as support code for a single paper, written by small academic teams without enough time or resources for robust testing, regular maintenance, or careful optimization.
Over time, some of that code becomes central to entire research fields. The tool may keep running in pipelines long after its original maintainers have moved on, even if the build process is outdated or the code is fragile.
The field report argues that AI coding agents could help close part of this maintenance gap. In the case studies, the agents worked on tasks ranging from straightforward modernization to full rewrites in newer programming languages.
One example was cyvcf2, a Python library used for reading genetic data. GPT-5.5 replaced its outdated build and installation process with a modern one. That kind of work may not change the science, but it can make a tool easier to install and keep alive.
Where agents delivered real speed
Some projects went far beyond maintenance. MHCflurry, an immunology model that predicts which targets immune cells will recognize, required a larger migration. Claude Code and Codex took turns acting as developer and reviewer while about 10,000 lines of code were ported from TensorFlow to PyTorch.
Another project, rustar-aligner, rebuilt STAR from scratch in Rust. STAR maps sequencing reads from cells to matching locations in a genome. The original has more than 20,000 lines of C and C++ and is no longer actively maintained, even though it remains part of many research pipelines.
To compare the rewrite with the original, the team tested both programs on 10,000 short sequencing reads from yeast cells. For single-end reads, rustar-aligner matched STAR in 99.815 percent of cases. For paired-end reads, the agreement rate was 99.883 percent.
The check included more than the mapped genome location. It also compared several other key fields produced for each read. Neither program mapped reads that the other failed to map.
The largest reported speedup came from RustQC, which combined 15 separate quality-control tools into one program. On a large dataset, runtime dropped from 15 hours and 34 minutes to 14 minutes and 54 seconds, a speedup of more than 60 times.
HelixForge also showed large gains. It replaced a tool for generating synthetic genomic data with a GPU-based version. In a test using data from one donor and a ten-million-base-pair section of the genome, HelixForge ran the full pipeline 59.6 times faster than BamSurgeon. The main compute step alone was 98.6 times faster.
Fast code still needs scientific review
The case studies point to the same practical lesson: speed is not the same as correctness. Agents handled well-defined coding tasks quickly, but they could not consistently judge whether their own output was scientifically valid.
Brent Pedersen, developer of cyvcf2, summarized the tradeoff this way:
"With coding agents, it's quite easy to go fast; for now, to go far in science, there's still a need for expert guidance, understanding, taste, and care,"
Philip Ewels, who led RustQC, described agents as
"eloquent, convincing, and confidently wrong in ways that are easy to miss."He did not allow the models to assess the accuracy of their own work. Instead, he created an independent test harness.
The bayesm case study shows why that matters. Its Rust rewrite ran between two and twenty times faster than the original, but early versions of two advanced methods contained problems that were difficult to detect from the output alone.
In one method, the agent inverted a key control parameter, making the program use reciprocal values instead of the intended ones. A separate bug affected the calculation itself. Researchers found it only after running a detailed calibration test against thousands of synthetic datasets with known results.
A method called HART also produced results that looked plausible overall while still containing multiple flaws. Those included unnecessarily expensive calculations and an incorrectly scaled correction factor. Plausible output was not enough to prove the implementation was right.
The best pattern was human tests, agent implementation
Across the projects, the strongest division of labor was consistent. Humans defined the goals, success criteria, and validation methods. Agents did much of the implementation work inside those boundaries.
The hifiasm project is a clear example. Hifiasm assembles a complete genome from many short fragments. Before asking GPT-5.5 to optimize it, the researcher created a test setup with separate training and validation datasets. The model then found changes that cut runtime on real human genome data by nearly 15 percent.
HI.SIM, a library for simulating genetic data, needed even less human involvement. GPT-5.2 optimized individual parts of the program in one pass. A second pass with a newer model found more improvements. Together, the changes reduced runtime by about 31 percent without changing the output.
The MHCflurry project also shows that model capability matters. An earlier attempt to port it to PyTorch had failed in early 2025. Developer Sergey Feldman later attributed that failure to the models available at the time rather than to the coding tools themselves. In his view, newer model generations became reliable enough to handle much of the work on their own.
Maintenance becomes the next bottleneck
The report also estimates that agents could save significant research time if they resolved between one-quarter and one-half of installation problems across 100 packages. The value of that saved time would range from $600,000 to nearly $5 million. For NumPy alone, the report estimates about 650 hours of maintenance work could be saved each year.
But cheaper rewrites also create new risks. If many alternative versions appear, user communities may fragment. Experienced maintainers, already limited in number, may have even more projects competing for their time.
The case studies handled ownership in different ways. Some changes were merged into the original projects. Because STAR was no longer maintained, rustar-aligner moved to the scverse research consortium. The author of FastQC declined to replace the original tool with the Rust rewrite, so the team added the improvements it found to the original Java version, achieving the same threefold speedup.
The report is not presented as a representative study. It looks back at completed projects and relies on the accounts of people involved. Still, its central message is hard to miss: as AI coding agents improve, the bottleneck shifts from producing code to validating results, reviewing scientific correctness, and assigning long-term maintenance responsibility.