The practice of research software is changing, and community norms are still catching up.

Two checks under pressure

Research software has long relied on two forms of verification. The first is engineering judgment: the standards and habits people acquire through training or experience — some identify as software engineers, many are researchers who have learned to write software to a high standard through their own work. The second is less visible — the understanding a person builds by writing the code themselves, line by line, and noticing when something does not behave as it should.

AI-assisted coding can bypass both. Code can arrive complete, plausible, and unread. Used carefully, the same tools can produce better-tested and better-documented software than many research groups manage today. Used carelessly, they can produce work that looks right but may be scientifically wrong — and telling the difference is not always easy. There is real promise in the idea that anyone can now write research software, but realising it will take deliberate work: building the practices that help people judge whether the code they produce can be trusted.

Done well, these tools can take on more of the routine work of research software, leaving people more time for the contributions that need human judgment: deciding what is worth building, weighing design tradeoffs, and helping others learn. Building the practices that get the community there is what this fund is for.

Five concerns motivating this fund

1. Quality could go either way. With good practice these tools can raise the floor; without it they can lower it. It is too early to say how this is playing out.
2. Validation risks becoming circular. When the code and the tests that check it come from the same model, a passing test suite may tell us less than it once did.
3. Decisions are being made without shared frameworks. Groups and institutions are often adopting tools ad hoc, with few shared ways to weigh cost, benefit, and risk.
4. Training and access are uneven. Educators have few places to compare what works, and capable tools are unevenly distributed across institutions and regions.
5. The record of how results were made can become incomplete. Prompting opens a gap between what a researcher intended and what the code does, and the reasoning that connects them is often not recorded. Reproducibility increasingly means capturing decisions as well as code.

In our conversations across the community we have found no shortage of ideas — and plenty of people eager to work on them together. This fund is intended to help those collaborations get started.

Where this came from

In March 2026, Schmidt Sciences and the Research Software Alliance co-led a three-day workshop in Edinburgh. Researchers, engineers, community leaders, and funders worked in groups spanning the breadth of the problem: frameworks for weighing costs and benefits, incentives for publishing and crediting software, verification and validation, the evolving RSE role, training, playbooks for managers and maintainers, access to AI tools, and how people collaborate with each other — not only with machines.

They left with forty-six candidate activities, ranked by impact and effort and with volunteers attached to each — ranging from writing sprints and communities of practice that could begin immediately, to tool-building, to longer studies of how verification and collaboration practices are actually changing.

Two documents came out of it: the workshop report and Reflections from Edinburgh, a statement of principles. They sit alongside the ADSA and US-RSE position statement on generative AI in the RSE workplace.

This fund aims to help turn that work into activity. The call is open to everyone, not only to people who were in the room.