But can it run Doom?
Your LIMS might be powerful. It might even be adaptable. But can it run Doom? This week’s paper is about adaptability, scientific iteration, and why we built a completely unnecessary first-person shooter inside Dalea to test a much more useful idea: whether scientists can shape their software around the work they are actually doing.
A deliberately silly benchmark
There is a question engineers have been asking about new hardware for decades, usually as a joke: can it run Doom?
The question has survived because Doom has become an unlikely benchmark for general-purpose computing. Since id Software released the source code in 1997, people have made it run on an increasingly absurd collection of devices. The entertainment is partly in the mismatch between what the thing was designed to do and what somebody has managed to make it do instead.
But the joke also points to a useful underlying test. Doom is not a particularly demanding game by modern standards, but it is a real interactive application. It has to respond to input, update continuously, render a changing interface and keep track of state. If a system can accommodate all of that, it is probably more adaptable than a system that only lets you rearrange fields or call a predefined API.
So we tried it in Dalea.
This was not because we believe laboratories are suffering from an unmet need for first-person shooters. We wanted to test something much closer to the reason we are building Addons in the first place: whether someone can take an idea that Dalea itself was never designed around and make it part of the workspace anyway.
We connected an AI coding agent to the platform, described the game we wanted, and iterated on it a few times. About an hour later, Doom was running inside Dalea as an Addon.
The game itself is mostly a curiosity. What interested us was that, from Dalea’s point of view, Doom did not need any special treatment. Its levels could live in the same data environment as everything else. Players, save games and high scores could be represented as ordinary records. The interface could run as a full page or sit inside a document, and it could use the same permissions and data model as the rest of the workspace.
That means you can, if you are sufficiently committed to the bit, put Doom at the bottom of a protocol.
Nobody needs to do this. That is precisely why it is a useful demonstration.
If we had built another sample register, assay tracker or inventory view, it would have shown that Dalea can do things laboratory software is already expected to do. Doom tests the opposite boundary. It is deliberately unrelated to laboratory work, and therefore a better way of asking how much of the system is fixed in advance and how much can be shaped by the people using it.
The long tail of scientific software
That distinction matters because scientific software has a peculiar problem. The most common workflows are usually well served by standard products, as they should be. If thousands of laboratories need to track samples or document experiments, it makes sense for a vendor to build that functionality once, test it thoroughly and maintain it for everyone.
The difficult problems tend to live further out in the tail.
A group may need a particular way of reviewing one assay, a dashboard that combines measurements in a way that only makes sense for a specific study, or a visualisation that highlights exactly the features its researchers care about. An instrument may produce a strange export that someone cleans manually every week. A plasmid design tool may be almost right except for three missing features that happen to matter enormously to one team.
These are not necessarily product opportunities. Often they are too narrow for a software vendor to prioritise and too small to justify a conventional development project. They are nevertheless real problems, and the people who understand them best are usually the scientists dealing with them every day.
That has been true for a long time. In 1976, Eric von Hippel studied 111 scientific instrument innovations and found that around 80% of the improvements users considered significant had been invented, prototyped and first tested by users themselves [2]. The manufacturer often entered later, engineering the user’s prototype into something robust enough to sell.
The underlying division of labour is familiar even now. Scientists know what the tool needs to do because they understand the work. Turning that understanding into reliable software has traditionally required a different kind of expertise.
Scientists build anyway
Researchers build anyway. A survey of UK researchers found that 92% used research software and 56% wrote some themselves [3]. When a needed tool does not exist, the alternative to building something is often simply to continue working around its absence.
The spreadsheet is perhaps the clearest example. It remains one of the most successful tools ever made for letting domain experts construct their own small systems without becoming software developers first. Its flexibility is exactly why it is so useful in science.
It is also a good illustration of what happens when the software cannot adapt far enough to the domain.
Excel’s tendency to convert some gene symbols into dates was documented as early as 2004 [4]. Twelve years later, researchers screening 35,175 supplementary Excel files found gene-name errors in 987 of them, spread across 704 published papers [5]. In 2020, the committee responsible for human gene nomenclature changed its naming guidelines in part to avoid symbols that interfered with data handling. MARCH1 became MARCHF1; SEPT1 became SEPTIN1 [6].
The software did not adapt to biology. Biology adapted to the software.
That is an unusually vivid example of a much more mundane pattern. When the tools do not quite fit, people reshape their work around them. They add another spreadsheet, another manual export, a script running on one person’s laptop, or a small application commissioned from someone outside the team.
Each of those can solve the immediate problem. The trouble is that every new solution tends to become another place where data has to go.
A consultancy can build a perfectly good application, but it will often arrive with its own database and its own maintenance burden. A script may automate an important analysis while remaining tied to the laptop and assumptions of the person who wrote it. A spreadsheet can become critical infrastructure without ever becoming safe, governed infrastructure.
The result is a growing distance between where scientific work is recorded and where the software acting on it lives.
From describing the tool to building it
That distance is what we want Addons to reduce.
The important change over the last few years is not that scientists suddenly know what software they need. They have always known that. What has changed is the cost of turning a reasonably precise description into working software.
AI coding systems can now do a surprisingly large amount of that translation. The Doom experiment is a deliberately silly illustration. We described something complex and interactive, connected the agent to the platform, and within a short period had a working application.
But cheaper code does not solve the whole problem. If every generated tool becomes another standalone application with another login, another database and another integration, then we have mostly succeeded in making software fragmentation cheaper.
For this to become genuinely useful in scientific work, there also has to be a sensible place for that software to run.
This is what Addons are for
That is the role of a Dalea Addon.
An Addon is a small application that lives inside the workspace and works on top of the data already there. It can introduce a new interface, visualise data differently, automate a specialised workflow or combine existing information in a way that only makes sense to a particular group.
The ambition is not that Dalea should anticipate every interface scientists might ever want. It is almost the opposite. We want the platform to provide a reliable substrate on which those interfaces can be created when the need arises.
Doom is useful as a benchmark because nobody at Dalea would ever have put “support a first-person shooter” on a product roadmap. If something that far outside the intended use of the system can still be built on top of it, then the much more practical adaptations become easier to imagine: a plate-normalisation view, a stability-study dashboard, a specialised protein viewer, or a reader for one instrument’s peculiar output format.
The best example will probably be less impressive than Doom. It may simply be an interface that saves one researcher fifteen minutes of copying and pasting every time they run an experiment. The important thing is that the person closest to the problem can shape the tool around the work rather than waiting for the work to become common enough for a vendor to shape a product around it.
FIGURE 3: Example addon - Protein Viewer
Adaptability still needs boundaries
Of course, making software easier to create introduces another problem: software can be wrong.
That concern does not disappear because an AI wrote the code quickly. In March 2026, METR asked maintainers from projects including scikit-learn and pytest to review 296 agent-written pull requests that had already passed an automated grader. Around half would not have been merged [7].
So the useful version of this idea cannot depend on generated code simply being trusted. It has to depend on limiting what that code can do and making its actions visible.
Addons therefore operate through Dalea’s permission model. They declare which data they need to access and what they need to do with it, and those permissions have to be approved before the Addon can run. If a later version asks for more access, it has to be approved again. An Addon that only needs to read data does not need permission to write it, and activity happens inside the same environment as the rest of the work.
This is important because it preserves one of the main benefits of keeping the tool close to the data. There is no need to export a dataset into another application, maintain a second copy of it and then work out later which version should be trusted.
The interface comes to the data.
When one lab builds it, another lab can use it
There is a further consequence that may be more interesting in the long run.
The very specific problem in one laboratory is often not quite as unique as it first appears. Another group may use the same instrument, run a similar assay or be irritated by exactly the same missing feature. If the first group can turn its solution into an Addon, the second group does not necessarily have to build the same thing again.
An Addon can be shared, installed, changed and shared again. That makes it possible to imagine a marketplace of relatively small and specialised scientific tools, many of them created by the people who understood the problem well enough to solve it in the first place.
That resembles the way useful scientific methods already spread. Someone develops a technique for a particular purpose, someone else adopts it, and eventually another group modifies it for a context the original author had not considered.
There is a nice symmetry here with Doom itself. When John Carmack released the source code in 1997, he expected early modifications to be rough and fragmented, but hoped people would eventually coordinate around shared and improved versions [1]. The result was a modding culture that is still active almost thirty years later.
Scientific software is obviously not game modding. But there is something attractive in the same basic dynamic: lower the cost of adapting the system, let the people closest to the problem make the adaptation, and allow the useful ones to travel.
So, can it run Doom?
Yes.
It took a few prompts and about an hour, and it remains one of the least useful things anyone could reasonably build with Addons.
The reason we are proud of it is not that a laboratory information system can also be a games console. It is that Doom makes the adaptability of the underlying system unusually difficult to fake.
The useful version is likely to be much quieter: the view that makes an awkward assay easier to interpret, the small application that removes several manual steps from a workflow, or the specialised tool that would never appear on a vendor roadmap because only a handful of laboratories need it.
Scientists have always adapted their tools to the work in front of them. The interesting possibility now is that adapting the software itself can become part of that same process.
And if the resulting tool turns out to be useful to someone else, they do not have to start from scratch.
References
[1] id Software. DOOM source code release, 23 December 1997.
[2] von Hippel E. The dominant role of users in the scientific instrument innovation process. Research Policy, 1976;5(3):212–39.
[3] Hettrick S, Antonioletti M, Carr L, et al. UK Research Software Survey 2014. University of Edinburgh on behalf of the Software Sustainability Institute.
[4] Zeeberg BR, Riss J, Kane DW, et al. Mistaken identifiers: gene name errors can be introduced inadvertently when using Excel in bioinformatics. BMC Bioinformatics, 2004;5:80.
[5] Ziemann M, Eren Y, El-Osta A. Gene name errors are widespread in the scientific literature. Genome Biology, 2016;17:177.
[6] Bruford EA, Braschi B, Denny P, Jones TEM, Seal RL, Tweedie S. Guidelines for human gene nomenclature. Nature Genetics, 2020;52(8):754–8.
[7] Whitfill P, Wu C, et al. Many SWE-bench-Passing PRs Would Not Be Merged into Main. METR, 10 March 2026.