Science Needs Continuous Integration, Not Autonomous Genius

I think the near future of AI-enabled science will look much more like continuous integration than like the arrival of an autonomous genius. That is a better future, too: treating every hypothesis, experiment, dataset, and analysis as an executable, reviewable artifact can make research faster without asking us to trust a language model’s taste in truth.

The seductive story is simple. Give a model the literature, let it notice a gap, have it propose experiments, send those experiments to robots or a simulation cluster, feed the results back, and let the system iterate around the clock. The loop compounds: more hypotheses generate more data; more data produces better rankings; better rankings concentrate expensive lab time on promising work. For software engineers, it is hard not to see the outline of an agent pipeline with tools, tests, queues, retries, observability, and a very expensive production environment.

That story is no longer purely speculative. Google’s AI co-scientist work describes a multi-agent system that generates and ranks research hypotheses and experimental proposals, with laboratory validation reported for some biomedical suggestions. Self-driving laboratories have also been used in areas including protein engineering, materials, and chemical synthesis: algorithms choose the next experiment, instruments execute it, and measurements update the next decision. Meanwhile, systems aimed at computational science can generate and iterate on the custom code needed to evaluate a hypothesis. The pieces of a closed loop are real.

But “the pieces exist” is precisely why I reject the autonomous-genius framing. It encourages institutions to optimize for the flashiest demo: an AI produces a surprising idea, a robot performs an experiment, and a paper announces discovery. That is the research equivalent of celebrating a coding agent that ships a feature once. The meaningful question is whether the system can keep producing results that survive reruns, handoffs, changed instruments, changed datasets, and hostile review.

A hypothesis is not a pull request

There is an important limit to the software analogy. Code has a specification often enough to support a crisp test suite. Nature does not. Experimental measurements are noisy, reagents drift, samples differ, instruments have calibration histories, and the thing we really care about may be only indirectly observable. A model can optimize an experimental objective while steering toward a measurement artifact, just as an agent can maximize a benchmark score by exploiting a leaky test.

That means an AI research loop needs more than a planner, an executor, and a result parser. It needs explicit uncertainty tracking; provenance for raw data and transformations; negative controls; calibration checks; predefined stopping rules; and independent replication paths. It should preserve the rejected hypotheses and failed experiments, not merely the attractive narrative assembled after the fact. If the agent changes its rationale after seeing the data, that revision is itself data. We should log it.

This is where engineering discipline can genuinely improve science. An experiment should be represented as something closer to infrastructure-as-code than a prose methods section: versioned parameters, declared dependencies, instrument configuration, sample identifiers, analysis environment, expected outputs, and safety constraints. The proposed Experiment-as-Code idea gets the core architecture right. Put an AI agent above a systems layer that validates plans, allocates constrained equipment, enforces policies, and records every action. Do not give a free-form model direct, opaque control of a lab.

The bottleneck moves from ideas to trustworthy feedback

When generating candidate hypotheses becomes cheap, choosing what to test becomes the scarce capability. A model can produce ten thousand plausible mechanisms before lunch. A wet lab cannot validate ten thousand mechanisms before its funding ends. Even a highly automated lab has limits: instrument time, consumables, biological material, operator oversight, and the cost of recovering from a bad run. The winning labs will not be those with the most verbose agent. They will be the ones with the best experiment-selection policy and the clearest account of what a result means.

This shifts the role of researchers, but it does not make them ceremonial approvers. Scientists will spend less time manually enumerating obvious possibilities and more time designing the objective function that tells the system what counts as progress. That is not clerical work. It includes deciding which outcomes would falsify a theory, which confounders deserve a control, what evidence is adequate for escalation, and where an optimization target is dangerously incomplete. In other words, the human contribution becomes more epistemic, not less.

Software engineers should recognize the risk immediately. Once an LLM is allowed to choose experiments based on previous results, it is operating in a feedback system. A small bias in data ingestion, a poorly chosen reward, or an unnoticed instrument quirk can compound over hundreds of iterations. The agent may become impressively efficient at learning the lab’s accidental preferences. The answer is not simply “keep a human in the loop.” A human clicking approve on a queue of plans is not a control system. The answer is independent checks that can detect when the loop is optimizing the wrong thing.

The strongest objection: autonomy is the point

The strongest counterargument is that I am importing process bureaucracy into a domain that desperately needs speed. If AI can search literature, formulate ideas, run simulations, and operate robotic experiments continuously, demanding elaborate versioning, replication, and human-designed gates will slow the very breakthroughs we want. Science already moves too slowly because researchers spend years on routine labor. An autonomous scientist that makes some mistakes could still deliver vastly more discoveries than cautious human teams.

That argument is right about the value of speed and wrong about where reliability belongs. We should absolutely automate routine labor and let agents explore aggressively in low-risk, high-throughput settings. But an unchecked agent is not faster when its conclusions create months of follow-up work, expensive dead ends, irreproducible papers, or unsafe experiments. Continuous integration did not slow software by making every engineer manually inspect every line; it made rapid change sustainable by automating verification and making failures visible. Research needs the equivalent: fast candidate generation, cheap screening, progressively stronger gates, and reproducible evidence packages before claims travel far.

The most profound change will therefore be institutional, not merely technical. Funding agencies and journals should reward machine-readable experimental records and independent reruns as first-class outputs. Labs should hire research-platform engineers alongside domain scientists, standardize instrument APIs and provenance schemas, and treat laboratory automation as shared infrastructure rather than proprietary theater. Model builders should publish the evidence trails behind generated research plans, not just polished hypotheses. If AI is going to make science continuous, then science must finally make verification continuous too.