The great shift
In the fall of 2024, I had an idea. I wanted to build a transformer that could take a person’s past running data and grade them on how well they ran a future race at a later time. Even after I painted out the big strokes, I knew that I had a steep learning curve ahead of me because I had never trained a transformer myself. I started prepping the data, but ultimately put the project aside until I had more time to devote to it.
By the time I returned to my idea, it was the fall of 2025, and the landscape had completely changed. Suddenly, I wasn’t limited by my familiarity with a specific library or toolkit. Instead, I was the idea generator, and my coding agents could piece everything together. A project that, as far as I could tell, had never been done before came together in just a few weeks in my spare nights and weekends.
That is when I realized the power that these tools held and how fundamentally the balance of power had shifted. I have come to see this as witnessing the commoditization of code and the evolution of research software engineering to research software architecture.
From production-limited to idea-limited
It’s tempting to just see AI coding agents as making research software engineers (RSEs) more productive, but that is missing the point. Coding agents are changing the very nature of the work and the skills needed to be successful. It’s akin to how the automation of textile factories changed that industry. Rather than helping individual weavers become more productive, the new technology fundamentally moved the production bottleneck from human labor to the ability to automate.
Science is going through a similar upheaval. Historically, RSEs were “builders of pipes.” But in the generative AI era, the pipes are produced on demand and, since they’re so cheap to generate, their durability is less important. This means that, instead of laboring to produce pipes, research software engineers should spend our time another way: thinking creatively about what is possible and what ideas should be explored. Think of it like the rate-limiting step of a reaction: research used to be human-production limited; now, it is idea-limited.
What does that look like in practice? In the past, RSEs relied on general-purpose libraries because code was expensive to reproduce. Now, code extensibility is less central because agentic tools make reuse and adaptation easy to accomplish.
Of course, the task of producing research software will still require infrastructure. But solid platforms, skills, and harnesses—not libraries—have become the necessary frameworks on which to build software, encouraging agents into patterns suitable for the tasks. Custom platforms are cheap to build and can provide a curated, purpose-built architecture needed by that particular problem space, as opposed to trying to fit our square peg (problem) into a round hole (library).
With platforms in place, teams can focus on the data, harnesses, evaluation, agent skills, and team conventions. Meanwhile, the actual generated code will be interacted with mostly by the coding agents and very rarely by the humans who drive them.
RSEs are now switching from the builders of code to the architects of code. That means they can shift their focus both upstream and downstream of the software creation process. Upstream, they will curate and maintain the raw data. Downstream, they will apply a discerning eye to creating useful, thoughtful prompts and developing rigorous evaluation systems. Gone are the days of the manual labor of writing code line by line. Instead of focusing on the logic of the code, RSEs will have to be clear about their specifications and their ability to test the agents’ interpretation.
Challenges to the transition
Many RSEs may scoff at the idea that they will no longer need to read generated code. But the reality is that the future—where we go straight from a dictated idea to the built code—is closer than we think. We may still need to intervene from time to time, but those instances will start to grow rarer as we develop increased trust with our agents, in the same way that we trust our compiler or hardware to execute on higher level code.
Instead, we will focus on evals and unit tests to make sure the code is reproducing the ideas dictated to our agents. RSEs will all shift towards the oft-maligned “prompt engineer.” We will also need to ensure the code and documentation we generate is accessible and interpretable by the agents themselves. Code will be the language of agents, not the language of humans.
This inevitable transition will reward some and penalize others. Engineers who have prioritized the craft of engineering may find that the role that used to bring them joy is no longer as in-demand. Whereas others, who saw coding as a tool towards scientific advancements and capabilities, will thrive as their productivity increases.
We will also need to redesign training and interview processes to better test for these architectural skills. Having a keen eye and being circumspect about assumptions will be the core driving skills, and should be elevated over the ability to write efficient, optimal code given a clear script.
Recommendations
For RSEs and software engineers in general: Cultivate skills like data collection, idea generation, and evaluation. Begin taking a higher-level view of the underlying code, as the trend moving forward will be to read fewer and fewer lines of code directly.
For primary investigators: Hire RSEs who can take ambitious problems and correctly frame them alongside agentic tooling. Focus on harness literacy, data skills, evals, and curiosity.
How Open Athena is facing the shift
At Open Athena, we are embracing these changes full-on. While our engineers are still known to read some lines of code, more and more, the errors we find are coming from our own framing and understanding, not from the use of agents to write code. That means we can now spend more of our time asking questions, investigating, and being creative.
We also continue to invest in our internal platform (Marin) and specifically in the “grug” philosophy of keeping our coding simple and avoiding unnecessary abstractions. Coding agents are great at taking simple code and using it as a template. As a result, we are less obsessed with perfectly re-usable modular code that is a jack of all trades but a master of none.
Another change is that we are retooling our hiring and onboarding processes. For example, we now allow engineers to use agentic coding tools during interviews because it better replicates the way engineers will work once they’re in the door. We are also seeking data and problem literacy over pure coding skills, as we believe these abilities provide the best way to partner with agentic tools and focus on the goal of advancing scientific discovery.
Cite this post
@misc{elmatad2026_research_software_engineering_in_the_age_of_agentic_tooling,
author = {Elmatad, Yael},
title = {Research Software Engineering in the Age of Agentic Tooling},
year = {2026},
month = {jul},
howpublished = {\url{https://oa-www-demo.pages.dev/blog/research-software-engineering-in-the-age-of-agentic-tooling/}},
note = {Open Athena Blog}
}