Science Did Not Accelerate Alongside Code
In this guest post about Endura Therapeutics, Adrian Sanborn proposes a framework for understanding how AI is changing frontier research organizations: Foundries and Navigators. Foundries lower the cost and time of doing experiments through technologies such as next-generation sequencing, multiplexing, high-throughput microscopy, and physical automation. Navigators put models into the ordinary machinery of a company, helping teams analyze results, build tools, choose questions, and plan the next experiment faster. The question is not the abstract one of whether AI can do science, but the operational question of what happens when thinking accelerates while physical experiments remain the system’s bottleneck.
Software creates an easy but misleading analogy. Code can be generated quickly, data can be organized quickly, and system architectures can be changed in less time, so cheaper knowledge work often becomes more software and more builders. In science, however, every hypothesis is ultimately checked by a physical experiment that may take days or weeks to produce an answer. Analytical work has accelerated dramatically while experimental throughput has not, creating a new asymmetry between thinking faster and doing faster.
Foundries Make Data; Navigators Consume Less Time
The distinction between the two paths is not simply a difference in automation. They address different points in the value chain. A Foundry industrializes measurement, aiming to generate data an order of magnitude faster than before through new experimental technologies. The article cites Xaira, NewLimit, Octant, Tahoe, and Endura for next-generation sequencing and multiplexing; Insitro, Eikon, and Noetik for high-throughput microscopy; and Lila and Periodic Labs for physical automation. AI can make this data legible and predictive, but the differentiating asset remains the experimental data itself.
A Navigator invests in the organization’s surplus thinking capacity. It does not require a proprietary model or a massive dataset at the outset. It requires changing how work is conducted: what should be automated, which internal tools are worth building, and which candidates deserve an experiment. A capability that once required software costing six figures may become a one-day internal build. When analysis falls from a week to an hour, iteration is no longer held back by data processing, and the value of the model appears as less waiting and better choices rather than as evidence generated out of thin air.
Research Code Has to Change with the Experiment
This distinction matters especially at the software layer of experimental science. In software engineering, requirements that change every few weeks are usually treated as a planning failure. In research, the purpose is to learn from an experiment, and that learning should change what the next experiment does. The article makes a sharp observation: if an approach has not evolved for six months, it may indicate that nothing new is being discovered. A new protocol can change a dozen times in its first year, and every change propagates into measurement processing, normalization, and interpretation.
Historically, the experimentalist and the analyst were often separate people, creating a seam between them. The experimentalist understood what the measurement meant, while the analyst moved data through a code pipeline that might not keep pace with the evolving protocol. Models and faster code generation lower the cost of crossing that seam, allowing research teams to update processing logic more quickly and keep code closer to the experiment. That does not automatically produce correct results. The faster the analytical workflow changes, the more carefully the relationship between experimental definitions, data processing, and interpretation must be reviewed.
Why Early Companies Become Navigators Faster
Navigator-style change is easiest in early-stage startups, not because they have stronger models, but because they have less institutional history to carry. They often have fewer long-term software contracts, standardized processes, fixed organizational structures, and mature compliance regimes to accommodate. When a better way of working appears, it can become the new default rather than passing through layers of coordination. For teams with limited resources and pressure to move quickly, this change reaches candidate selection, experiment scheduling, analytical tooling, and program decisions.
Several quantitative examples in the material show how the effect compounds. If a team could ordinarily evaluate five disease candidates, it might now choose from 500. If analysis no longer takes a week, the next experimental cycle can begin sooner. If a specialized tool can be built in a day, the organization need not wait to buy and integrate an expensive software product. None of these changes necessarily produces a press release or a standalone product, yet together they can create a gap in research velocity and resource allocation. Navigator advantages are therefore hard to see from outside, even as they spread across more companies.
Build a Foundry or Rewrite the Operating System First?
A Foundry is a genuine strategic bet. It requires capital, years of construction, and a view about a particular measurement technology, along with the risk that the technology may not keep producing high-value data. It is easier to see because the infrastructure has a physical form, and its connection to AI can be packaged as a new model, dataset, or experimental platform. For companies genuinely constrained by experimental throughput and able to invest for the long term, a Foundry may be the way to move the bottleneck itself.
For most technical leaders, however, the first question should not be whether to copy a prominent company’s facility. It should be whether the organization is already using its existing experimental capacity as efficiently as possible. If analysis, tool building, and candidate evaluation are still slower than the experiment, the Navigator path may offer the higher near-term return. Its limits are equally clear: faster code and better decisions cannot replace physical validation, predictions do not become facts, and process automation does not remove the need to examine what a measurement means. The practical choice is to identify the longest waits and most expensive decisions in each experimental cycle, then determine whether the bottleneck is measurement throughput or an organization still handling faster knowledge work in an old way.