Research Software Engineering in the Pre-AI Age

For many years, Research Software Engineering has filled an important gap in the digital research ecosystem. Researchers often have excellent ideas, deep domain knowledge and a clear sense of the questions they want to answer. However, the software needed to explore the answers to those questions can quickly become complex and the linchpin in the research methodology. A short, hacky script becomes a workflow; a workflow becomes a tool; that tool becomes something that other people depend on. At that point, software quality is no longer a technical nicety it becomes a proxy for research quality and an enabler for findable, accessible, interoperable and reproducible (FAIR) output.

That is where professional Research Software Engineers, Data Engineers and Data Scientists have traditionally added value. We help turn research ideas into software that is reliable, maintainable, usable and reproducible. We bring practices such as version control, testing, documentation, automation, deployment, user-centred design and long-term stewardship and operation into projects that are often under pressure to deliver results quickly. Just as importantly, we help researchers make good technical decisions early, when those decisions are still cheap to change, and work with agile methodologies to deliver iteratively.

However, that model is evolving. AI-coding agents (such as those provided by GitHub Co-Pilot) are making it easier than ever for researchers, PDRAs and PhD students to generate working code quickly. This is a genuinely useful development, and one we indeed should welcome, but it also raises an important question: if AI can now write code, what is the role of the human Research Software Engineer?

AI-coding Agents – what are they?

AI-coding agents are tools that can generate, modify, explain and sometimes test code in response to natural-language instructions (prompts). Many of them function inside a development environment (such as Visual Studio) with an embedded chat window, or through web platforms like GitHub, and can make changes across multiple files, run commands and even open pull requests. They are no longer just autocomplete systems; they are active participants in the software development workflow and are literally plugged into your source code as a co-developer.

Used well, they can be extremely helpful. They can remove friction, accelerate routine tasks and help people get started when a blank editor would otherwise be a barrier. They can suggest boilerplate, translate between programming languages, generate tests, explain unfamiliar code, draft documentation and help explore alternative approaches to feature design. In research contexts, that can be empowering: a researcher can test an idea quickly, automate a repetitive step or build a small proof of concept without waiting for formal development capacity. However, just like any tool, in the wrong hands, they can be damaging. A contextual understanding of what the tool is doing, as well as a critical assessment of its output, is essential. However, there is a pre-requisite: the reviewer needs the knowledge and experience of software architecture, design and syntactical nuance. Not all users of the tools will satisfy this requirement, and we should be mindful of that and the risks this poses.

What AI-coding Agents Are Good At

AI-coding agents are particularly good at well-scoped, well-described tasks. If the goal is to create a small parser, produce an example API call, write a first draft of a unit test, refactor a simple function, or explain an error message, they can save real time. They are also useful as a learning companion: they can provide examples, suggest code design patterns and reduce the cost of trying something new.

For an RSE team, these tools are not a threat to good engineering practice. They are an accelerator. They allow experienced engineers to spend less time on repetitive implementation detail and more time on the work that has always mattered most: understanding the research problem, designing the right solution, managing risk and technical debt creation, improving quality and helping software survive beyond the first successful run.

What AI-coding Agents Are Bad At

The danger comes when generated code is mistaken for “engineered” software – in other words, software that has been designed. AI-coding agents do not truly understand the research aim, the validity of the scientific method, the institutional or domain context, future users, data governance and security constraints, or the consequences of a subtle error in an analysis pipeline or computational model. They can produce plausible code that is fragile, insecure, difficult to maintain, ill-fitting for the problem or just plain wrong! Given how generative models work, this is likely to always remain so to one extent or another.

This is especially important in research. Research software often evolves under uncertainty: the requirements change as understanding develops, there may be no clear and obvious design at the outset, and yet the software may be used to support publications, policy decisions, clinical insights, future collaborations or funding proposals. A tool that appears to work today may still fail to meet the requirements of tomorrow: reproducibility, extensibility, performance, usability and security.

The phrase “vibe coding”, love it or hate it, captures both the excitement of opportunity as well as its risk. It is now possible to create something that looks convincing very quickly. As I mentioned earlier, that can be useful for exploration, but it can also conceal technical debt, untested, undocumented assumptions and hidden dependencies that have never had a discerning human cast an eye over them. In a research setting, speed is valuable but only if it does not undermine confidence in the result; your software can generate rubbish rapidly, but it is still rubbish.

Research Software Engineering and AI-agents

The role of the RSE is therefore not disappearing, far from in fact; it is becoming increasingly important, but also more strategic, far-sight. AI can help generate code, but RSEs help decide what code should exist, how it should be structured, how it should be tested, how it should be deployed, how it should be documented, and how it should support the research over time.

In that sense, AI-coding agents shift the focus of the RSE rather than remove the need for their expertise. They make implementation cheaper, but they do not make judgement cheaper and are no substitute for it. If anything, they increase the need for people who can assess whether a proposed solution is correct, robust and appropriate. The bottleneck moves from typing code to asking the right questions, framing the problem well, reviewing the output critically and integrating the result into a sustainable software project.

This is a familiar pattern in engineering. Better tools change the way professionals work, but they rarely remove the need for professional practice. Compilers did not remove the need for programmers; cloud platforms did not remove the need for infrastructure expertise; electronic notebooks or workflow engines did not remove the need for reproducible analysis, data science or engineering. AI-coding agents are another step along the same road. They are powerful tools, but they still need to be used within a disciplined approach to software engineering that maintains quality and research integrity.

So how about a concrete example? An AI agent may be able to produce a working data-processing script from a prompt, but an RSE will still ask whether the assumptions are explicit, whether edge cases are handled, whether the results can be reproduced, whether the code can be reviewed by collaborators, whether sensitive data is protected, whether it is properly documented and potentially publishable, and whether the code will still make sense when a PhD student leaves or a grant ends. Those questions are not incidental to the work; they are part of what makes research software trustworthy and a valuable research output and asset.

The RSE Service of the Future

As AI-assisted development becomes normal, the distinctive value of an RSE will sit even more clearly in the combination of technical skill, research understanding and service mindset. RSEs will still write code, but the most important contribution will often be shaping the system around the code: architecture, workflows, testing strategy, documentation, release processes, deployment, training, governance and long-term support.

There is also a growing role for RSEs as reviewers and educators. Researchers using AI tools will need help understanding when generated code is good enough for exploration, when it needs hardening, and when it should be replaced by a more carefully designed approach. RSE teams can provide patterns, templates, examples, training and lightweight review processes that let researchers benefit from AI without accidentally building fragile foundations into their work.

Your RSE department is still here and can provide this service. If institutions want to benefit from AI-enabled productivity without increasing risk, they will need RSE capacity not to just build software, but to set standards, advise on tooling, support communities of practice, delivery training and help researchers make proportionate decisions about quality and engineering approach.

Conclusion: Can an AI-coding Agent Replace an RSE?

For some tasks, yes. An AI-coding agent can replace the need for an RSE to write a small amount of routine code, draft a first version of a test, explain a syntax error or generate a throwaway prototype. That is useful, and it should free RSEs to focus on higher-value work.

But no, an AI-coding agent cannot replace the full role of an RSE. It cannot take responsibility for research context, stakeholder needs, institutional and domain constraints, maintainability, reproducibility, security, sustainability or the judgement required to balance all of those things. It can help produce code, but it cannot be accountable for the quality and consequences of the software in the same way a team of experienced and trained professional humans can.

The best answer is therefore not to ask whether AI replaces RSEs, but how RSEs, researchers and RSE teams can use AI well. Used carelessly, AI-coding agents may create more code than anyone can understand or maintain. Used thoughtfully, with RSE expertise wrapped around them, they can help researchers move faster while preserving the qualities that make research software reliable, reusable and secure.

Disclaimer

Structure drafted using Microsoft Co-Pilot. All thoughts and opinions are my own, and just that – personal opinions which may or may not be shared by my colleagues or employer.