Vibe Coding Is Quietly Changing How Scientists Solve Problems — and Not Always Safely

For most of the last two decades, the boundary inside a biotech R&D team was fairly stable: there were scientists who ran experiments, and there was a smaller group — often one overworked bioinformatician — who could actually write code. Everyone else who needed a script for QC filtering, a plate-reader parser, or a quick statistical model either learned just enough Python to be dangerous, waited in the bioinformatician's queue, or did it in Excel and hoped for the best.

That boundary is dissolving faster than most lab leadership has registered. Not because scientists suddenly learned to program, but because AI coding assistants have made the act of describing what you want in plain language a workable substitute for knowing the syntax to write it. This is what people mean by "vibe coding" — iterating on a script through natural-language description and immediate feedback rather than through deliberate, from-scratch authorship. For a domain expert who knows exactly what a correct output should look like but never learned to write a for-loop, that is a genuinely different mode of working, not just a faster version of the old one.

What this actually unlocks

The bottleneck shifts from "who can code" to "who understands the problem." A molecular biologist who has spent years staring at flow cytometry output knows immediately when a gating result looks wrong. That person, with an AI coding assistant, can now iterate on an automated gating script directly, testing it against data they understand intimately, rather than translating their intent to a bioinformatician through a ticket and waiting three days for a version that gets 80 percent of the intent right. The domain knowledge that used to be the hardest part to communicate is now the part doing the most work, because the person who has it is driving directly.

Small-scale automation that was never worth formally requesting now gets built. Most labs have a long tail of minor, repetitive data-wrangling tasks that were individually too small to justify a bioinformatics ticket but collectively cost real time — reformatting instrument exports, merging metadata sheets, generating the same summary plot every week. That tail is now getting automated by the people doing the work themselves, which is a genuine productivity gain that was previously invisible in any efficiency metric because nobody tracked the hours lost to it.

It changes who can ask a quantitative question at all. A researcher who can now get a working script for a basic statistical comparison, without first learning R from scratch, is a researcher who is more likely to actually check whether an effect is significant before building a narrative around it. That is a genuine, if underappreciated, improvement in scientific rigor at the margin — for the researchers who use the new capability to ask better questions rather than to skip asking them.

What it puts at risk

"It ran without an error" is not the same as "it is correct," and that gap is exactly where non-programmers are least equipped to notice a problem. An experienced developer reviewing generated code is checking for logic errors, off-by-one mistakes, silent type coercion, and edge cases the code was never tested against. A scientist without that background sees a script that runs and produces a plausible-looking number, and has no independent way to catch a subtle indexing error that silently shifted every sample's label by one row. This is not a hypothetical — it is one of the most common and hardest-to-detect failure modes in any data pipeline, AI-assisted or not, and it is precisely the category of error that domain review does not catch, because the output still looks scientifically reasonable.

Unvalidated scripts are drifting into GxP-adjacent workflows without anyone deciding that they should. A script that started as a personal convenience for exploratory analysis has a way of becoming the script the whole team uses for a report, then the script referenced in a batch record, without ever passing through a software validation step. Under Annex 11 of the EU GMP guidelines and 21 CFR Part 11, computerised systems used in regulated processes require documented validation appropriate to their risk and intended use. A script is a computerised system the moment its output feeds a regulated decision, regardless of who wrote it or how casually it began its life. Vibe coding does not create this risk — ad hoc scripting has always existed — but it dramatically lowers the barrier to producing that script in the first place, which means the volume of unvalidated code quietly entering regulated-adjacent workflows is growing faster than most QA functions have noticed.

Reproducibility gets worse before it gets better, if nobody manages it deliberately. A script iterated into existence through a series of conversational refinements, with no version control and no record of what changed between iterations, is harder to reproduce six months later than one written deliberately with documentation as a first-class concern from the start. The speed of vibe coding makes skipping that discipline more tempting, not less necessary.

The governance gap is the actual story

None of these risks are arguments for keeping scientists away from coding tools — that ship has sailed, and the productivity case for letting it sail is strong. The real story is that most life science organisations have detailed governance for who can run which instrument, but no equivalent governance for who can write which script and what happens before that script touches data that matters. That asymmetry existed before AI coding assistants; it is just becoming visible faster now that the volume of self-authored code has increased by an order of magnitude.

The fix looks less like restricting the tool and more like extending existing quality thinking to a new category of artifact: a lightweight risk tiering for scripts (exploratory versus feeds-a-report versus feeds-a-regulated-decision), a minimal code review step for anything above the exploratory tier, and version control as a default rather than an afterthought. None of that requires turning every scientist into a software engineer. It requires treating a script the way a well-run lab already treats a new analytical method — with a level of scrutiny proportional to what depends on it being right.

---

If AI-assisted coding has quietly become part of how your research team works and your quality processes have not caught up yet, that gap is worth closing deliberately rather than discovering it during a data integrity review. I help life science teams build governance that keeps pace with how people are actually working — reach out if this sounds like your organisation.