A medicinal chemist-turned-software-engineer on where LLMs belong in drug development - and where they do not.
I earned my Master's in Drug Discovery and Development at Imperial College London, after completing a BSc in Chemistry. It was research-led, most of it at the bench: activity-based probes for the kallikrein enzymes - the family behind the PSA test - developed as sharper, earlier markers for prostate cancer. The work was intellectually fascinating, but it also made the stakes concrete in a way a chemistry problem never had: a marker that misses is a diagnosis that arrives too late, for a real person.
My route into software was less conventional. Somewhere in all that science, I got curious about the tools doing the research - and started teaching myself to code in the evenings, diligently, one online course at a time. I am a self-taught software engineer and curiosity is the whole reason.
I found a way to bring both those interests together, working on data for compound prediction - using machine learning to help surface the molecules that might one day become medicines. The same pull - wanting to understand how the tools work, then build better ones - has led me to where I am now: head of the engineering team at TriloDocs, where we build software for regulatory medical writing, the clinical study reports and submissions that decide whether a drug reaches the people who need it.
So, I have ended up on both sides of a line most people never notice: the discovery world, where speed and prediction win and playing the odds is the whole game, and the regulatory world, where those same instincts can do real harm. When I say I am careful about large language models in regulatory writing, it is not because I distrust the technology - I have spent my working life building on it. It is because I have seen where it is extraordinary, and where it quietly breaks.
I learned early that the distance between a molecule, a regulatory document and a patient is much shorter than it appears. That is why choosing the right architecture is not an abstract engineering preference. It decides who the mistakes reach.
The mistake I keep seeing is treating "AI" as one decision: adopt it or resist it. It is not one decision. The only question worth asking is narrower - does the shape of the problem match the shape of the tool?
Finding a target or a molecule is a search through an enormous space where you do not know the answer in advance. You are navigating uncertainty, not eliminating it. Models that reason over probability distributions - protein structure, binding affinity, compound properties, the science-tuned models coming out now - are exactly right for this. AlphaFold changed protein-structure prediction; newer models like Boltz-2 push into binding affinity, reportedly estimating how strongly a molecule binds to its target in seconds.
Being fast and approximately right, then validating in the lab, beats being slow and precise.
The probabilistic nature is not a flaw to manage - it is the feature you are paying for. This is where these models will massively speed us up, and I am as excited about it as anyone.
A clinical study report is a factual record. There is exactly one correct number for how many patients experienced a given adverse event. One. And a CSR carries thousands of facts like it - so even a very low error rate, spread across that many individually consequential claims, becomes unacceptable.
"Approximately right" is not a minor limitation here. It is a failure condition. What goes into that document reaches regulators, and through them, patients. Hallucination is not an inconvenience to be cleaned up later. It is the thing you cannot ship.
The usual answer is: let the LLM draft, then have a human verify. The sophisticated version grounds the model first - retrieval, citation enforcement, guardrails - and yes, that lowers the hallucination rate. What it does not do is remove the need to check every claim against source; it just makes the checking feel optional until it is not. And that checking costs. If every figure and every claim have to be traced back to the source data anyway, you have not removed the labour - you have paid for it twice.
You have generated text you now cannot trust and bought yourself the job of proving each line.
A reviewer needs to understand what you are saying immediately, not wade through it. Good medical writing is short, specific and gets out of the way.
Left to their own devices, generative models drift the other way - towards hedging, padding, "it should be noted that," "a total of." You can prompt and constrain your way back to lean, but you are fighting the default, on every document, every time. Fluent, and quietly bloated. Precisely what a reviewer does not want.
The alternative is to keep the reasoning deterministic and treat generative models as optional rather than foundational. A deterministic system gives the same outputs for the same inputs, every time. That is not just tidy - it is testable: it can be regression-tested and behaves the same way release after release, which makes it far easier to validate than something that might answer differently tomorrow.
That is the architectural principle I brought to my work at TriloDocs - and the system we have built around it. It is not a ban on LLMs. We use them where they add value: to express an already established finding clearly and to support phrasing and narrative. What they never do is decide what is true. The facts and reasoning are deterministic; the prose is where a generative model earns its place.
Two things follow by construction. Lean writing, because the rules do not ramble. Second, a much smaller QC surface because you can point at the rule that produced a sentence. With a language model you might trace its sources or inspect its steps - but that is not the same as a rule that necessarily produced the result.
It also fails safely. If a deterministic rule cannot establish sufficient evidence, it produces no conclusion at all. A generative model is built to produce a plausible continuation - you can push it to abstain, but holding back is not its default. That instinct to answer anyway is exactly what you want in discovery, and exactly what you do not want in regulated documentation.
It was never "can an LLM draft a CSR?" It probably can, after a fashion. The real question is narrower: should the engine that decides what is true in a regulatory document be probabilistic at all?
For discovery, absolutely - bring on every model we can get. For the reasoning behind a document that goes to a regulator and through them to patients, our answer is no.
That is not a position on LLMs. It is a position on architecture. Different stages of clinical development carry different constraints, and the constraints - not the hype cycle - should decide what you build on. Discovery rewards probabilistic systems because uncertainty is part of the problem. Regulated scientific documentation demands deterministic systems because reproducibility is part of the requirement. The engineering skill is knowing which room you are in.