Why science is still hand-cranked
The bottleneck in discovery is not a shortage of ideas, instruments or even money. It is a loop that moves one turn at a time because a person has to be present for every turn. This is the observation AutoScientia was founded on, written down in the first month.
The loop, as it actually runs
Ask anyone who runs experiments how their week goes and you will hear the same shape repeated. A question forms. A protocol is written. Time is booked on an instrument, a cluster or a bench. The experiment runs. Results are analysed, doubts are raised, and a decision is made about what to try next. Then the whole thing starts again, with a human hand on the crank at every stage.
Every individual step has improved dramatically over the last few decades. Instruments are more sensitive, analysis is faster, literature is searchable, compute is cheap. And yet the loop itself — the sequence from question to answer to next question — looks almost exactly as it did before any of those improvements landed.
Why the loop resists scaling
The reason is structural rather than cultural. Three properties of the loop keep it sequential.
- Each step depends on the last. You cannot analyse a result you have not produced, and you cannot decide what to run next without an analysis. The dependency chain is real, and it converts directly into elapsed calendar time.
- The hand-offs carry tacit knowledge. Protocol details, instrument quirks and judgement calls live in people's heads. Handing them to a machine — or to another person — is where most of the delay and most of the misunderstanding is created.
- Capacity is scheduled, not summoned. Bench time, instrument queues and expert attention are all finite and booked in advance. A brilliant hypothesis that arrives on Tuesday may still wait three weeks for a slot.
Multiply those three by the number of turns a serious research question needs — dozens, sometimes hundreds — and the arithmetic explains why a discovery that takes six months of work takes years of calendar time.
What faster tools did not fix
It is worth being precise about this, because the usual response to the argument above is that better tools are already solving it. They are not, and the reason is that they improve steps rather than the loop.
| Stage | What improved greatly | What did not change |
|---|---|---|
| Question | Access to literature and prior work | A person still decides what to ask, and how many questions can be pursued at once |
| Design | Simulation, statistical tooling, templates | Design still happens one hypothesis at a time, reviewed by the same few people |
| Execution | Instrumentation, automation of single runs, cloud compute | Runs are scheduled and interpreted sequentially; a single failure costs a full cycle |
| Analysis | Faster software, better visualisation | Someone must still interpret, then decide what the next experiment is |
| Iteration | Nothing structural | The loop restarts by hand, at human speed, every time |
A ten-times faster microscope on a loop that runs one experiment per week does not produce ten times the discovery. It produces the same number of turns, each better observed.
What changes when the loop closes
The alternative is not a better single step. It is closing the loop: letting a system propose candidates, run many of them at once, score the results against an objective fixed in advance, and use what it learned to decide the next round — without waiting for a person to be available between turns.
Three things change at once, and they compound:
- Time per turn collapses. Parallel trials mean the cost of the hundredth experiment is closer to the cost of the first than to a hundred times it.
- Failure gets cheap. When a bad hypothesis costs a compute slot rather than a week of someone's life, it becomes rational to test more of them.
- Learning accumulates. Every result — including the ones that went nowhere — informs the next round, instead of ending up in a notebook nobody reopens.
Where the bottleneck moves next
Closing the inner loop does not remove the bottleneck. It relocates it. Three things take over as the binding constraint, and all three are human.
- Objectives. A loop optimises what it is told to optimise. Deciding what a good result actually looks like — and writing that down precisely enough that a machine can be held to it — becomes the scarce skill.
- Verification. Thousands of automated results require a verification capacity that grows with them. If checking cannot keep pace with producing, the output becomes noise with a percentage sign attached.
- Physical reality. Everything downstream of a simulation still happens in the world: synthesis, trial, deployment, regulation. No amount of compute compresses those steps, and pretending otherwise is the most common error in this field.
The practical consequence is that automation pays off most where the objective is already agreed and the constraint is the sheer number of trials. That is a narrower set of domains than the phrase “AI for science” suggests — and it is deliberately the set we start in.
What we are not claiming
Three limits, stated at the outset because they shape everything that follows.
This does not replace scientists. Choosing which problems matter, setting objectives, interpreting what a result means for the world and deciding when a system may act outside its sandbox are all human work, and they are the higher-leverage work.
Not every domain is ready. A loop can only be automated where outcomes are measurable and iterations are parallelisable. In wet-lab biology, for instance, the interface between software and a physical bench is the hard part, and it is not solved by better models.
Automation does not make results true. A fast loop that measures the wrong thing produces a large amount of confident nonsense. That is why the next pieces in this series are about definition and measurement rather than about models.
Key takeaways
- Scientific progress is limited by a sequential loop, not by the quality of individual tools.
- Dependency chains, tacit hand-offs and scheduled capacity are the three structural reasons the loop stays slow.
- Faster instruments improve steps; they do not improve turns per week.
- Closing the loop changes time per turn, the cost of failure and the accumulation of learning.
- Automation requires measurable objectives and human ownership of judgement — the two constraints we build around.
Running a loop that is slow by construction?
Tell us the objective, the cost of one iteration, and why it cannot be parallelised by hand.