OpenAI's Own Field Report Clocked a 60x Speedup on Real Genomics Code. It Also Found the Agents Can't Tell When They're Wrong.

On July 28, 2026, OpenAI published something I don't see from a frontier lab very often: a report that undersells its own headline number. "Scientific computing in the age of agentic AI" covers eight real projects (genome aligners, variant parsers, RNA-sequencing pipelines) where Codex and Claude Code delivered speedups as large as 60x and rewrote thousands of lines of legacy C/C++ into Rust. That's the number that'll get quoted. The finding OpenAI actually leads with is different: the agents "often expressed confidence even when their work contained clear errors." I build solo, I hand agents codebases I don't fully understand on a weekly basis, and this is the most useful primary-source document I've read all year on exactly where that gets dangerous.

What actually got rewritten

The report covers eight case studies, mostly in the life sciences, with five projects run on Codex alone and three combining Codex with Claude Code, in some cases with the two models alternating as contributor and reviewer to catch each other's mistakes. The scope ranges from routine packaging fixes (cyvcf2, a Python library for reading genomic variant files, where GPT-5.5 replaced the legacy build system) up to full language migrations and GPU-native redesigns: hifiasm, MHCflurry, bayesm-rs, the Rustar-aligner/svb/kuva cluster, RustQC, and HelixForge.

Two numbers stand out enough that I went and verified them independently rather than take the brief's word for it. RustQC (Phil Ewels at Seqera Labs consolidating 15 separate RNA-seq quality-control tools into a single Rust binary) cut a 186-million-read benchmark from 15 hours and 34 minutes down to 14 minutes and 54 seconds, north of 60x, confirmed on Seqera's own engineering blog as well as in the OpenAI report. HelixForge, a GPU-native rebuild of BamSurgeon for generating synthetic genomic mutation data, ran a full pipeline 59.6x faster, dropping from 1,610 seconds to 27 seconds. A separate case in the same set (a from-scratch Rust rewrite of the 20,000-line C/C++ STAR aligner) landed at roughly 99.8% behavioral parity with the original tool across single- and paired-end reads. None of these are cherry-picked lab benchmarks. They're production tools, built by people who had to actually ship them.

The quote that matters more than the speed

Here's the part that should sit uncomfortably with anyone running an agent against code they don't fully understand: "Across case studies, agents handled specific, well-scoped requests effectively but could not reliably judge whether their work was scientifically valid or met expectations." OpenAI isn't hedging that finding. They state directly that agents "often expressed confidence even when their work contained clear errors." That's not a capability gap you fix by prompting harder. It's a structural blind spot. The agent has no independent way to know if its own output is right, so it defaults to confident.

What did work, according to the report, is narrow and specific: "the strongest approaches used an external reference or measurable acceptance target such as exact output agreement, parity with an existing tool, appropriate statistical behavior, or answers established in advance using simulated data." In other words, the agent's self-assessment is worthless. An external, pre-defined answer key is not.

The last mile is where the time actually goes

If you've run a coding agent on anything nontrivial, you already know the shape of this: the first draft comes back fast and looks plausible. The report backs that intuition with real project data: "agents often produced initial implementations quickly, but resolving edge cases and subtle numerical differences took much longer. Completing the 'last mile' of an implementation often took the most work." The STAR-to-Rust rewrite is the clearest illustration: the project reportedly stalled around 90% parity, where remaining divergences were bugs stacked on other bugs, and fixing one caused a regression elsewhere, the kind of tangle an agent can't untangle by rerunning its own tests, because its own tests were part of what got the project to 90% in the first place.

This generalizes past genomics immediately. If you're a solo operator pointing an agent at a legacy migration (a payments integration, a data pipeline, anything where "close enough" isn't actually close enough), expect the same curve. The bulk of your calendar time won't be the initial port. It'll be the boring 10% where the agent insists the numbers match and they don't, quite.

Nobody's job is to keep the rewrite alive

The report's stewardship warning is the one I keep coming back to, because it's not about code quality at all. It's about who's on the hook once the agent is done. "Lower implementation costs also make it easier to produce many similar rewrites, fragmenting users and spreading the expert attention required to keep any one tool reliable." Brent Pedersen, the cyvcf2 maintainer quoted in the report, put it plainly: "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." The report notes that some of these rewrites got folded into their upstream projects (cyvcf2 and MHCflurry both were) while others, like rustar-aligner, moved under dedicated community stewardship precisely because the original tool had been abandoned. Without that kind of ownership, a modern rewrite becomes, in the report's own words, "tomorrow's abandoned code."

If you're an indie hacker, the equivalent risk is a rewrite nobody owns because you moved on to the next feature the week after the agent finished it. Speed makes it cheap to produce something new. Speed does not make it cheap to keep that something new correct six months from now.

What I'd actually do

Build the verification harness before you let the agent touch the migration, not after it hands you a diff. That means: pin down an existing reference implementation you can diff against, generate golden outputs from known-good inputs before any code changes, and write the parity tests first. If there's no reference implementation (you're building something genuinely new, not migrating something old), fabricate one from simulated data with pre-established expected answers, the way the report describes for cases without a legacy tool to compare against. Code review after the fact catches style problems. It does not catch the kind of subtle numerical drift the report describes agents rationalizing away as "acceptable." You need a harness the agent can't talk its way past.

The honest counter-take: this is genuinely more setup work than most solo projects need. If you're migrating a marketing site or a CRUD app with no numerical correctness requirement, building a parity-testing harness before you start is overkill. A decent code review and a staging environment will catch what matters. The discipline in this report earns its cost specifically when correctness is scientific or financial, not stylistic. Know which kind of project you're in before you decide how much harness to build.

Author

Lukas

@lukcombinator

Sources

• Scientific computing in the age of agentic AI: an exploratory field report — OpenAI
• Scientific computing in the age of agentic AI: an exploratory field report (PDF) — OpenAI
• Introducing RustQC: 15 RNA-Seq QC Tools in One Pass, Built with AI — Seqera
• AI Agents Rewrote 20,000 Lines of Dead Genomics Code: Scientists Still Checked Every Result — Tech Times