This is the write-up of a short talk I gave at the RSA technical catch-up on 7 October 2026, reporting what I found interesting at RSECon26 in Sheffield. Each section is one talk or session, with a link to its slides. What I said is below each slide. In the write-up I kept more of the quotes than fitted on the slides.
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
| 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
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.
The questions discussed that day:
- What value do data science knowledge and skills bring to a research project?
- Which data science skills or areas of knowledge have changed most with the introduction of GenAI?
- How has GenAI changed the way those skills are used?
- Has GenAI made particular tasks easier or harder, and is that change positive, negative or neutral?
- How has GenAI affected programming, data exploration and visualisation?
- How has GenAI affected communication, including emails, meeting notes and discussions with PIs?
- How do we verify and trust GenAI outputs in research software and statistical work?
- Which skills still rely heavily on human judgement, listening and interaction?
- What support is needed from a data science community to maintain skills and navigate these changes?
- What guidance, good practices and learning time are needed for statistics, machine learning and GenAI?
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.
More from the slides. On where we are:
I’m “Claude-pilled”. I use these tools heavily and find them genuinely useful.
This room likely contains grief, enthusiasm, anger, denial and exhaustion.
The KPI of research software is research. New knowledge is the key performance indicator, and not the software itself. Sorry.
A suitably motivated PI can solve their own problems with […] less support.
tl;dr – A dramatic increase in production, without a corresponding increase in the capacity of communities to absorb it
AI is exposing a difference that has always been there, but historically was invisible. Essentially “craft lovers” and “results people” were indistinguishable.
On verification:
Andrej Karpathy: Verifiability is what drives the “jagged frontier” of AI capability. Software 1.0 automates what you can specify, Software 2.0 automates what you can verify
Great! So our job is to make all of science more verifiable so that AI can automate more of it?
And his answer, via David Hogg on astrophysics:
Its purpose is the people who do it. Automating it wouldn’t accelerate the discipline, rather it would remove the point of doing it.
Rigour has to move elsewhere (Fowler thesis): Friction of production used to do some hidden rationing for us. When production becomes cheap, verification must become an explicitly engineered system or process.
The problem isn’t that AI will produce “wrong” science. It’s a dramatic increase in the number of possibly correct things to check
“We have allowed execution to substitute for thought” — Hiranya Peiris
Generative tools can produce the outward signals cheaply, which means the information content drops for everyone.
So we can raise the bar: from presence to outcomes […] Can another human or agent actually regenerate the result from what is provided?
On what RSEs can do:
Curated skills lift agent pass rates from 34% to 50%, and self-generated skills provide no benefit. Models can’t author the procedural knowledge they benefit from consuming.
Domain-embedded RSEs are extremely well positioned because encoding judgment requires actually knowing the domain.
Formalisation tools such as Lean and mathlib are doing for maths proofs what CI did for code.
Verification by an opaque authority reintroduces the trust in authority the scientific method exists to remove.
“Everyone for AI is too for it, everyone against is too against it” – Daniel Jalkut. RSEs see the capability and failure modes – share what you’re learning.
The mathematicians just showed us all how it’s done. The Leiden Declaration […]. Notice who was in the room. Mathematicians, computer scientists, philosophers, historians, people working on formal verification methods. Cross-community people wrote the norms.
Science will no doubt produce more outputs. Whether it compounds into more knowledge is up to people like you.
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.
More on the value of RSEs, from the slides:
AI will likely change the practice of RSEs: Writing code (Programming) ↑ Designing software (Software Engineering) ↑ Verifying AI-generated software against research purpose / requirements / quality (Quality / Dependability / Security / Sustainability / Reproducibility Engineering)
AI will not change the value of RSEs. More people are building more software […] Practice shifts towards judgment, verification, validation, etc. More to verify, integrate, maintain
RSEs have this knowledge. Combining research expertise and software engineering expertise
RSE practice has changed and will continue to change. RSEs need to adapt to sustain value […] The community should control the discourse around AI in RSEng
The longer version is their paper, Research Software Engineers in the Age of GenAI: Same Value, Changing Practice. My own candidate for the value of RSEs, communication, is in the same place as their bridging.
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.
To be fair, the last slide does list “Are you complying with the original license? Who owns the copyright?” under further considerations, and the plugin copies the original licence file over. My questions are about what comes before that.
First, the licence. In the US, a work needs a human author to be copyrighted, and the Supreme Court declined to hear Thaler v. Perlmutter in March 2026, leaving that in place. If the translation is machine-generated, what does the copied licence actually license?
Second, translating someone else’s open source project with an LLM is contested. In March 2026, chardet 7.0.0 was released as an LLM-assisted “ground-up rewrite” of the LGPL library under MIT (Willison 2026), and from 7.3.0 under the even more lenient 0BSD. Mark Pilgrim, its original author, objected:
Licensed code, when modified, must be released under the same LGPL license. Their claim that it is a “complete rewrite” is irrelevant, since they had ample exposure to the originally licensed code.
Third, scale. A Claude skill that anyone can install makes rewriting software like this a mass-scale operation, which I think can be deemed unethical in itself. And 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.
The vocabulary of the talk, from the slides. It opens with one pattern, a slide each:
Engineering depends on human connection
Science depends on human connection
Education depends on human connection
Learning depends on human connection
Everything depends on human connection
That means our “soft” skills are our most vital
Then the skills she learned along the way, each from a role:
Community: Connecting, helping people learn from each other
Product Leader: Listening, designing what people actually need
Next up: Welcoming, making the path to belonging easier
Coach: Collaboration, faster, more agile ways of moving
Project manager: Coordinating, getting things done as a team
Change Leader: Moving, people and organizations when it’s time for change
The talk is in four parts, welcoming, listening, connecting and moving, each closing with “Be like …”. On listening:
2i2c’s impact depends on listening. Yours does, too.
Work on putting aside what you think you know and hearing what problems others face […] Learn other product management and design skills (they’ll help you listen and translate what you hear)
And on moving:
Communicate much, much more than you might imagine you need to – people need messages repeated
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
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.
References
Beavan, David. 2026.
“Life in Hut 23: The Turing Research Engineering Group.” Presentation. RSECon26. Zenodo, September 11.
https://doi.org/10.5281/zenodo.22513962.
Daniels, Ryan. 2026.
“Building Multi-User LLM Inference Services for Research.” Presentation. RSECon26. Zenodo, September 10.
https://doi.org/10.5281/zenodo.22697597.
Druskat, Stephan, Ben van Werkhoven, Daniel S. Katz, et al. 2026.
“Evolving the RSE Role in the Age of Generative and Agentic AI.” Presentation. RSECon26. Zenodo, September 9.
https://doi.org/10.5281/zenodo.22230055.
Johnson, April. 2026.
“Social Infrastructure: The Human Work of Open Scientific Computing.” Presentation. RSECon26. Zenodo, September 11.
https://doi.org/10.5281/zenodo.22688009.
Smith, Arfon. 2026.
“Where Does the Rigour Go? Research Software and the Future of Trustworthy Science.” Keynote. RSECon26. Zenodo, September 9.
https://doi.org/10.5281/zenodo.22672891.
Sparks, MICHAEL, Shoaib Sufi, and Aleksandra Nenadic. 2026.
“Emerging Practices for AI in Research Software Engineering: A Spectrum from EVERSE RSQKit.” Presentation. RSECon26. Zenodo, September 9.
https://doi.org/10.5281/zenodo.22668838.
Thompson, Stephen, and Asif Tamuri. 2026.
“Code Translation Using Large Language Models: What’s the Role of the Research Software Engineer?” Presentation. RSECon26. Zenodo, September 9.
https://doi.org/10.5281/zenodo.22666282.
Willison, Simon. 2026.
“Can Coding Agents Relicense Open Source Through a ‘Clean Room’ Implementation of Code?” Simon Willison’s Weblog, March 5.
https://simonwillison.net/2026/Mar/5/chardet/.
Social infrastructure
April Johnson (2026), slides.
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.
The vocabulary of the talk, from the slides. It opens with one pattern, a slide each:
Then the skills she learned along the way, each from a role:
The talk is in four parts, welcoming, listening, connecting and moving, each closing with “Be like …”. On listening:
And on moving: