What I found interesting at RSECon26

A short report back from the 10th Research Software Engineering Conference, Sheffield

Dr. Kolen Cheung, Research Software Engineer

Research Software & Analytics Group, University of Exeter

October 7th, 2026

AI at RSECon26

The two key themes of RSECon26: RSEs as part of the research journey, and enhancing credit & reproducibility. My impression is that AI was the central theme.

15 / 106

AI, ML or LLMs in the title

27 / 106

substantially about AI (my reading)

37 / 106

mention AI, ML or LLMs in the abstract

The 106 talks, posters, workshops and other contributions in the programme, keynotes included.

This year RSECon26 said it centres around two key themes: RSEs as part of the research journey, and enhancing credit and reproducibility. But my impression is that AI was the central theme. From the programme, many of the talks were either directly or indirectly related to AI. Out of 106 talks, posters, workshops and so on, 15 have AI, machine learning or LLMs in the title, about a quarter are substantially about it, and over a third mention it in the abstract.

AI at RSECon26, by type

Type	Total	AI in title	Substantially AI	Mentions AI
Talk (incl. 3 keynotes)	54	8	13	19
Poster	24	3	5	6
Workshop	9	1	4	4
Birds of a Feather	8	1	2	5
Walkthrough	8	2	3	4
Research Software Publication	3	0	0	0
Total	106	15	27	37

By type, about half of those substantially about AI are talks, 13 of the 54, and proportionally it is highest in the workshops, 4 of 9. And the panel on the RSE profession listed the rollout of generative AI among its challenges.

RDSci Connect

• A meetup for research data scientists, the day before the conference.
• First RDSci meeting? A future RDSciCon!?
• We discussed what activities we do, and how AI has impacted each of them.

The day before the conference there was RDSci Connect, a meetup for research data scientists. Is this the first RDSci meeting? Maybe a future RDSciCon! It was interesting to have discussions to define the activities we do, and how AI has impacted each of them. This is my group’s board: programming changed the most, and user stories, design decisions and communication with PIs the least.

Where does the rigour go?

Arfon Smith’s keynote (2026), slides.

In many domains, faster science is a good thing. Unverified science is not.

What happens when the capacity to produce software grows much faster than the capacity to review and absorb it?

Much of science remains expensive to verify. Which parts of science we make cheaper to verify, and why, is a choice.

The keynote by Arfon Smith, “Where does the rigour go?”. I resonate a lot with this one, and I already quoted him in my fellowship application. In many domains faster science is a good thing, unverified science is not. Writing code has become cheap, but shipping, verifying and maintaining it has not, and which parts of science we make cheaper to verify is a choice.

Evolving the RSE role in the age of AI

Druskat et al. (2026), slides.

The original value of RSEs: Bridging the worlds of research and software engineering

Producing code is cheap. Knowing if it is correct, appropriate, reproducible, worth sustaining is not.

The “GenAI-RSE paradox”: More generated code → more need for RSEs

Stephan Druskat and colleagues, from the ReSA workshop in Edinburgh, asked how AI affects the RSE role. Their answer is that AI will likely change the practice of RSEs, from writing code to designing it to verifying it, but not the value of RSEs, which is bridging research and software engineering. This is close to what I am exploring around the value of RSEs.

An AI usage intensity spectrum

Sparks, Sufi and Nenadic (2026), slides, CC BY 4.0.

From EVERSE’s RSQKit, a spectrum of how intensely you use AI, from no AI, through chat and editor integration, to local agents and fully autonomous ones. The question they ask is where do you sit, where do you want to sit, and where should your project sit. Their guidance is at everse.software/RSQKit/ai.

Code translation with LLMs

Thompson and Tamuri (2026), slides.

We will discuss our experiences in developing a Claude Code plugin to support domain experts in statistics in translating Stata packages to R and Python.

• A demonstration of AI capability.
• But is it a valid move to attach the original licence to machine-generated code?
• Translating someone’s open source project with an LLM is contested. Were the original authors consulted?

This is a demonstration of AI capability: a Claude Code plugin, with a workshop for statisticians, to translate Stata packages to R. But I, and others, raised the licensing and ethical issues, and from the response I don’t think they were on the presenter’s radar. Machine-generated code cannot be copyrighted, so is attaching the licence of the original a valid move? And rewriting open source projects with an LLM is contested, as chardet showed this year. In the whole process, the original authors were not consulted.

Social infrastructure

April Johnson (2026), slides.

• Engineering, science, education, learning, everything “depends on human connection”.
• “That means our ‘soft’ skills are our most vital”.
• Welcoming · listening · connecting · moving

April Johnson from 2i2c, on the human work of open scientific computing. Engineering depends on human connection, science depends on human connection, and so does everything. So our soft skills are our most vital: welcoming, listening, connecting and moving. To me, RSE is a very human activity, and connection and communication is our core value.

Life in Hut 23

David Beavan (2026), slides: the Turing’s Research Engineering Group.

• Interdisciplinary hub, pool of 30+ staff.
• Open and collaborative
• Regular team meetings, showcases and tech talks
• Line management and mentorship
• Hack week
• Away day(s)
• Newsletter
• Pulse check

Hut 23 at Bletchley Park, Bletchley Park’s engineering hut. Photo by John Keogh on Flickr, from the slides.

The Alan Turing Institute’s Research Engineering Group calls itself Hut 23, after Bletchley Park’s engineering hut. It is an interdisciplinary hub with a pool of 30 or more staff, and this is how they describe life there. It sounds much more integrated and collaborative than we are, but that could be a matter of presentation. What secret sauce do they have? Can we replicate some of that here?

Multi-user LLM inference for research

Ryan Daniels (2026), slides.

• Serving local LLMs with a custom-built system to university users and researchers at Cambridge.
• For sovereignty, privacy and cost.
• £120k + 3–5 people to develop and maintain the system (his answer to my question).

Finally, Cambridge serves local LLMs with a custom-built system to their users and researchers, for sovereignty, privacy and cost. I asked him what it takes, and his answer was £120k, plus 3 to 5 people to develop and maintain the system.