AI Coding Agents in Life Sciences: Governance Before Autonomy

Validated Software Cannot Be Vibe-Coded

In most software, speed is the metric. In life sciences, evidence is. A change merged into a manufacturing execution system, a laboratory information management system, or any component of the quality management system is not done when it works. It is done when there is a documented, auditable record of why it was made, what it was checked against, and who approved it. That record is the deliverable, equal in weight to the code itself.

This is the precise reason regulated teams cannot accept “vibe coding” — generating a plausible change and shipping it because it looks right and the tests pass. A passing test proves behavior. It does not prove the change followed an approved design, respected the validated configuration, or carried the rationale an inspector will ask for. In a GxP environment, software whose justification you cannot reconstruct is software you cannot defend.

An AI coding agent is extraordinarily good at producing the first thing and indifferent to the second. It closes the generation gap and widens the evidence gap. That trade is acceptable in a marketing site. It is disqualifying in a system that touches patient safety or product quality.

What FDA Computer Software Assurance Actually Requires

The FDA’s posture here is not abstract. Its final Computer Software Assurance for Production and Quality Management System Software guidance sets out a risk-based approach: the rigor applied to a software feature should scale with the risk that feature poses. A feature whose failure could compromise a process tied to product quality or patient safety — a high process-risk feature under 21 CFR Part 820 — demands more assurance activity and more documented evidence than a low-risk one.

Read that as an instruction to anyone introducing AI into the toolchain. The question regulators ask is not “can your tool write the code?” That is assumed. The question is whether you can demonstrate, after the fact, that the change was developed under appropriate controls and that the assurance effort matched the risk. Computer software assurance is fundamentally about producing defensible evidence proportional to consequence.

So the real problem an AI coding agent introduces in life sciences is not capability. It is provability. You have to show the agent operated inside the approved patterns and constraints, and you have to produce the evidence of that compliance long after the change shipped, when an auditor opens the record cold.

Agents Need Validation Histories, Not Just Context Windows

This is where the architecture of most AI coding tools falls short of what a regulated team needs. The industry has invested enormously in context: larger windows, retrieval, shared memory, so the agent knows more about the codebase at the moment it acts. That is necessary and not sufficient.

A context window describes the present. It tells an agent what exists right now — the files, the conventions, the decisions it managed to retrieve this session. A validation history is something else entirely: a durable, auditable record of which decision applied to a change, which constraint was checked against it, and why the change was permitted to proceed. Context is ephemeral and informational. A validation history is persistent and evidentiary.

The distinction matters because regulators audit the past, not the present. An inspector does not care what was in the model’s context window last quarter. They care whether the change that shipped can be traced to an approved decision and a check that ran. Better recall improves what an agent knows; it does nothing to produce the record an audit consumes. We have made the same point about architectural drift: knowing a rule is not the same as being held to it, and only the second one leaves evidence.

Decision Traceability for AI-Assisted Development

Traceability is the spine of every quality system, and AI-assisted development has to inherit it rather than route around it. Every agent-driven change should carry who/what/why provenance that survives an audit: which decision or ADR governed it, what constraint was verified, what the verdict was, and when. The provenance has to be attached to the change, not reconstructed afterward from memory or commit archaeology.

This is harder with agents than with humans, and easier to get right if you build for it. Harder, because an agent can produce a high volume of changes quickly, and informal review does not scale to that rate. Easier, because an agent operates through tooling you control, so you can require that every change pass through a checkpoint that records the decision applied and the result. That checkpoint is the unit of enforcement provenance — the log line that says this change was checked against this constraint and either passed or was rejected.

Get this right and AI accelerates a validated team instead of endangering it. Teams evaluating where to start usually scope it to a single high-risk subsystem first; the use-case breakdowns walk through how that pilot is framed. The point is to make traceability automatic, so the evidence accumulates as a byproduct of how the agent works rather than as a separate documentation chore.

You Earn Autonomy by Proving Constraint First

The phrase “governance before autonomy” inverts the default order most teams reach for. The tempting path is to grant the agent latitude, watch it work, and add guardrails once something breaks. In a regulated environment that order is backwards. You do not earn the right to let an agent act freely by showing it usually behaves; you earn it by first proving every action it takes is constrained and traceable.

Autonomy, in other words, is a privilege extended to a system you can already audit. An agent whose changes are checked against approved decisions and logged with provenance can be given progressively more scope, because the evidence trail makes its work defensible. An agent without that scaffolding cannot be trusted with autonomy at any level, because nothing it does can be proven compliant later.

This is also why an agent is not a teammate you onboard and then trust on reputation. As we have argued in why AI agents are not employees, you do not extend judgment-based trust to a non-human actor; you constrain it mechanically and verify the constraint. Regulated industries simply make that requirement explicit and non-negotiable. The same discipline that satisfies an FDA inspector is what makes an audit trail hold up in financial services — the vertical changes, the underlying requirement does not.

Turning Regulatory Decisions Into Executable Constraints

This is the work Mneme is built for. The architectural and regulatory decisions that govern a validated system — the boundaries, the approved patterns, the configurations that may not change without revalidation — usually live in ADRs and quality documents that agents never consult and that no build step checks. Mneme turns those decisions into executable constraints: the agent retrieves them at generation time, and CI verifies them deterministically before the change merges.

Deterministic verification is what makes the resulting evidence defensible. The same change checked twice against the same constraint produces the same verdict, independent of the model that wrote it. That property is exactly what governance propagation describes — one enforced decision reaching every agent action, with a logged result each time. The log is not a side effect. In a regulated context it is the validation history, the traceability record, the proof of compliance an audit demands.

Life sciences makes the order of operations unavoidable, and the pattern generalizes to every audited sector — it is the through-line of AI governance for regulated industries. You constrain first, you prove it, and only then do you widen what the agent is allowed to do. Governance is not the tax you pay after adopting AI coding agents. It is the thing that makes adopting them possible at all.