Radar · 28/07/2026 · coding

OpenAI on agents in scientific computing: from genomics to software

OpenAI has published a field report on how scientists use coding agents to modernize research software and accelerate discoveries, in genomics and other areas of scientific computing.

For those building with AI, this matters because it shows adoption in complex vertical domains, where code has decades of history, data is sensitive, and errors are costly. If agents work well on inherited scientific pipelines, the leap to your enterprise stack (legacy systems, handcrafted business logic) becomes much closer. You can take inspiration from these scenarios to delegate maintenance tasks to your assistant that you’ve been putting off.

This site’s editorial line has been following this thread for some time: the coding agent matures when it stops being a demo and is measured against real tasks. The gap that benchmarks like SWE-bench didn’t cover was starting from vague requirements, and now you see it at work on actual research software.

In detail

The context of the field report is the shift from AI as a conversational assistant to AI as an operator that writes, modifies, and executes code in real environments. So far, coding agents have been tested on teaching repositories or clean issues, where the problem is well-defined and the initial state is known. The novelty here is the domain of application: scientific pipelines with legacy software, where upgrading an obsolete library or migrating a data format can require days of repetitive manual work. Researchers often find themselves maintaining code written decades ago by colleagues who are no longer around, with little documentation and cross-dependencies that break the system if touched in the wrong place.

OpenAI shares concrete cases in genomics, where researchers used agents to modernize analysis tools and speed up sequencing experiments. The interesting technical detail is that value lies in the combination of planning, tool access, and result verification. The model generates a hypothesis for a change, runs tests, and corrects course if the output doesn’t match what’s expected. It’s the same pattern Anthropic made public with its Cookbook on agentic patterns in production, and that various papers are formalizing: orchestration matters more than raw power of a single model. Having an agent that can read a compilation error and find the right documentation makes the difference between an experiment that runs and one that stays stuck. In these scenarios, the agent acts as a tireless junior collaborator, trying and retrying until the pipeline works.

The limits of what we know now are clear. The report is a story of adoption, with examples and anecdotes, but without strictly comparable metrics. We don’t know how much time was saved compared to manual work, or what percentage of changes required human intervention to complete. It points the direction for future developments without providing quantitative proof. It also signals that the learning curve for properly configuring the agent, defining tool boundaries, and setting up quality controls remains the real bottleneck, as the lesson from the course on building an end-to-end agent teaches. Experimentation in scientific computing shows that human intervention remains central for architectural decisions and validating results, while the agent handles the boring, repetitive execution work. Before letting an agent loose on your codebase, you need to have built a safe environment where damage is controlled and reversible.

Type to search across course, playbooks, skills, papers…