Scientists are already using AI agents. Most of what they learn goes unpublished.

For most people, the way they write software only changed in late 2025. Until then, with AI, the main interaction was ‘autocomplete’, or word completion, where you type a line and the system finishes it. Now you describe what you want, and the system writes it – and every frontier model user interface released since has worked the same way. For anyone building data science tools for drug discovery, the workday looks different than it did a year ago.

Dr Srijit Seal is Principal Scientist at Human Chemical Company and a visiting researcher at Uppsala University, and he has worked through this change. He is direct about where his daily practice has landed.

“It’s been a few months now; I haven’t typed much code directly.”

He is describing where a computational scientist’s attention now goes, and he is not claiming the tools run unsupervised. Work that used to take weeks – eg, building the pipeline, setting up continuous integration/delivery (CI/CD), handling versioning, making the plots and writing the slides – now takes a fraction of the time.

Expanding the scope for scientists

The change in scope mattered more than the change in speed. Seal points out that teams used to be limited by what their members already knew. If you had read about a method somewhere, you could implement it, and if you had never come across it, you never built it.

For example, in toxicity quantitative structure–activity relationship (QSAR) modelling, a molecule could be protonated before training, so that the structure reflects how the molecule exists at a given pH. Protonation here means adding or removing hydrogen atoms to match the charge state at that pH. In practice, people often skipped this step, partly because nobody was sure whether the software they already used handled it. When the team ran the work through a model, the model added protonation without being asked.

”And we’re like, why is it doing this? And obviously it’s logical, right? Because if you want to predict toxicity at a particular pH, you would want to use how the molecule looks in that setting.”

The team would have accepted it immediately if anyone had raised it, and nobody had. Across a whole workflow, the effect is that more methods become available, rather than the same methods running faster. Keep the difference in mind when reading claims about productivity.

How we spend time in the age of automation

The work left to people has not gone away, and it is different work than before. Seal spends his time on data quality and compliance checking, which means confirming that outputs follow accepted practice and that the input data was sound to begin with.

”A lot of my time goes into cleaning data. A lot of my time goes into looking at where something is compliant [and] where something isn’t compliant with practices.”

The way he supervises the tools will be familiar to anyone who has run a group. He gives instructions, checks the output and redirects the work, comparing it to supervising capable students.

One consequence is that average work no longer sets anyone apart. A competent script, a standard model and a clean set of plots are now easy to produce, so there is little point competing with the tools for such purposes. What remains scarce is specialised data, experiments only your own lab can run and the judgment to decide which work to do at all. Seal says the premium on specialised knowledge has risen considerably, and AI will only create more opportunities.

Does AI help productivity?

Seal relays a second-hand account. A company rolled out coding agents in phases and stopped partway, so people hired later did not get access. By the end of the year, performance ratings differed between people with access and those without. The halted rollout accidentally produced the kind of controlled comparison the field needs.

He is careful about how much the account shows.

”It’s not necessarily that everybody who had access got a higher performance rating. But people who had a higher performance rating had access more often than not.”

The account shows a correlation, reported second-hand, with obvious selection effects and no published data to back it up. Yet it is also close to the best evidence a research director has when deciding whether to invest in agent tooling. Job adverts have changed faster than the published literature. Seal notes that two years ago almost nobody in computational drug discovery worked on agents, and now the word appears nearly everywhere. Practitioners rely on anecdotes because case studies have not been published – except for a few.

The entry barrier for biologists is lower

Scientists who do not think of themselves as software people should note that the usual route into computational discovery has been to hire technologists and teach them biology, because teaching biologists to build software was more challenging. However, the gap is narrowing, and Seal reports that his connections who would never have touched software before are now training and running their own models.

Most of the remaining judgment calls are scientific. When you pull data from several public sources, you have to decide what a data structure should hold, what to keep and what to discard, how good the data must be for the claim you want to make, and how to test the result. Current tools support those decisions reasonably well, so a scientist with deep domain knowledge and no engineering background is better placed than they may realise.

Contribute your knowledge from successes (and failures)

A lot of informative work is being done and not reported because practitioners assume it isn’t publishable.

”A lot of these scientists have tried out various things with agents, and they haven’t published those outcomes because they’re not sure, or they haven’t compared. This is a good time to sit down with: what have we actually learned when we have used agents?”

The bar is lower than people think.

”It doesn’t need to be a full-fledged article. It could be one or two case studies – and then bringing out what they learned from it.”

The key steps are: first, compare human and agent output on the same task. Second, report where the agent made mistakes and how you caught them. Third, describe how you put a system into a real pipeline rather than a demo. Negative results are welcome, and a documented workflow that produced unusable output is more useful than another success story with no baseline. Nobody is asking anyone to publish proprietary methods, because the useful contribution is what you learnt while doing the work.