ExpertsFMEpisode 16 - Building AI for Life Sciences
OpenAI Podcast · April 16, 2026
5 Selected Lessons:
case · 2 framework · 2 reasoning_pattern · 1
Two-axis compute scaling (model scale vs. test-time compute)
Source
OpenAI Podcast — Episode 16 - Building AI for Life Sciences (April 16, 2026) · at 20:15 ▸
When this applies
when planning capacity/investment for a system whose performance depends both on built-in scale and on how long it's allowed to 'think' at inference time
The takeaway
When scaling any intelligent system's capability, consider both the size/scale of the base system and the amount of 'thinking time' you allow it per task, as independent dials.
Why it works
Model-scale increases unlock emergent capabilities at training time, while test-time compute scaling allows variable, extended reasoning duration at inference depending on task difficulty, and the two are separate, complementary levers.
One level up
Infrastructure investment decisions should be justified by future use cases (e.g., long-horizon complex reasoning), not just current observed usage patterns.
Where it stops holding
This stops working when a task's difficulty doesn't scale with additional thinking time (diminishing/no returns), making test-time compute scaling ineffective for that class of problem.
Detail
procedure:
- Axis 1: increase model parameter scale for emergent capability gains (e.g., GPT-2 to GPT-3)
- Axis 2: increase test-time/inference compute to allow variable-length reasoning depending on task difficulty
- Combine both axes to reach new levels of discovery difficulty
benchmarks: {"example":"GPT-2 to GPT-3 size increase produced new emergent properties"}
rationale: Data centers and infrastructure like Stargate are being built not just for current conversational use but to support long-horizon complex reasoning processes.
In their words
Yeah, I think there's two different axes we can think about how we are scaling compute. The one that I think everyone's familiar with is just getting bigger models.
Three-tier biology eval methodology
Source
OpenAI Podcast — Episode 16 - Building AI for Life Sciences (April 16, 2026) · at 27:04 ▸
When this applies
when evaluating a model/system in a domain that lacks a single verifiable ground truth and requires multiple complementary validation methods
The takeaway
Combine replay-of-known-outcomes evals, deliberately-flawed synthetic stress tests, and real-world validation as three complementary layers when no single clean ground truth exists.
Why it works
Experimental-data evals test prediction on known outcomes; synthetic data with embedded 'foot guns' tests robustness to realistic messiness; wet-lab/real-world trials are the final ground truth that neither proxy can fully replace.
One level up
In domains without verifiable correctness, build a staged confidence pipeline rather than relying on a single evaluation method.
Where it stops holding
This stops working when real-world validation is too slow/expensive to run at the pace of model iteration, forcing heavier reliance on proxy evals despite their limits.
Detail
procedure:
- Use existing experimental data to test if the model can predict unseen outcomes (e.g., single-cell RNA-seq perturbations)
- Generate synthetic data with embedded realistic pitfalls (bias, QC issues, needed statistical corrections) to test if the model catches them like a computational biologist would
- Recreate an existing experiment as a baseline before pushing to novel, unvalidated predictions (e.g., antibody binding for a new viral variant)
- Treat wet-lab experimental validation as the final real-world test of correctness
rationale: Nothing in biology is really real until you can prove it in the real world, so proxy evals are necessary but insufficient.
In their words
But that being said, I think Ylab is still kind of the final like real evaluation of the model, right? And as you like to say, nothing in biology is really real until you can prove it in the real world.
Shifting the bottleneck from human to compute
Source
OpenAI Podcast — Episode 16 - Building AI for Life Sciences (April 16, 2026) · at 6:43 ▸
When this applies
when any workflow's throughput is capped by human processing speed rather than by the availability of resources
The takeaway
Identify whether your process's true constraint is human throughput or resource throughput, then re-architect with parallel automation to convert a human bottleneck into a resource bottleneck.
Why it works
Deploying many parallel sub-agents to divide and conquer tasks moves the limiting constraint from human attention/speed to compute availability, freeing humans to focus on higher-value judgment work.
One level up
The highest-leverage automation targets whichever constraint is currently the scarcest and most human-bound.
Where it stops holding
This stops working when the task fundamentally requires human judgment that can't be parallelized or delegated to agents, or when compute itself becomes prohibitively expensive.
Detail
approach: Recognize human bottleneck in data ingestion/task execution; replace with parallel orchestrated sub-agents; redirect human time to insight interpretation.
signals:
- compute-intensive high-throughput data
- researcher time spent on rote tasks rather than analysis
rationale: Freeing humans from execution lets them focus on interpretation, which is the scarcer, higher-value skill.
In their words
I think the future that me and Joy see is that it's no longer human bottlenecks but rather maybe compute bottlenecks and we're really able to like deploy mini sub agents doing parallel orchestration to divide and counter all these tasks and the researcher can now spend their time on like really analyzing, interpreting like the most meaningful insights coming out of that.
GPT-5 + Ginkgo Bioworks first wet-lab experiment
Source
OpenAI Podcast — Episode 16 - Building AI for Life Sciences (April 16, 2026) · at 3:46 ▸
When this applies
when you don't know if a general-purpose system can do a specialized task because the task's data was scarce in training, and the field lacks verifiable ground truth the way math/code does
The takeaway
When a domain lacks easily verifiable correctness, test capability claims by connecting the model to a real, physically falsifiable feedback loop rather than relying on benchmark proxies.
Why it works
Running a real-world, physically verifiable experiment (design -> lab execution -> measurable product) is the only way to validate capability in a domain without clean verifiable solutions like code or math.
One level up
Trust in a new capability should be earned through a real-world outcome test, not assumed from adjacent benchmark performance.
Where it stops holding
This stops working when running the real-world test is prohibitively expensive, slow, or risky, making proxy evaluation the only practical option.
Detail
situation: GPT-5 had just finished training with little biology data (mostly math/code, which have verifiable solutions); unclear if it could do biology at all.
decision: Partnered with Ginkgo Bioworks' robotic lab to have GPT-5 design real experiments and test if they produced the intended reactant/protein.
outcome: The first set of GPT-5-designed experiments produced a non-zero amount of the target protein, surprising the team and proving basic biological design capability.
lesson: Real wet-lab validation, not benchmarks, was what converted uncertainty into confidence that models could accelerate science.
In their words
So it was actually quite surprising, I think when GPT-five designed the first set of experiments with Ginkgo and the results came back where, oh, we made a non zero amount of protein that was actually quite surprising.
Safe-but-useless vs. oracle-but-dangerous tradeoff framing (Zhao's view)
Source
OpenAI Podcast — Episode 16 - Building AI for Life Sciences (April 16, 2026) · at 12:10 ▸
When this applies
when any capability sits on a spectrum where maximum safety means minimum usefulness and maximum usefulness means maximum risk
The takeaway
In Joy Zhao's framing, safety design should be understood as a spectrum between two useless extremes (zero capability = safe but useless; unrestricted capability = useful but dangerous), with the operating point located deliberately rather than defaulting to either extreme.
Why it works
As she describes it, capability and usefulness tend to rise together, and so does misuse potential, so she suggests simply maximizing or minimizing capability is generally not the right answer; the design problem is finding where on that line to draw an access line.
Where it stops holding
This stops working when the harm from misuse is catastrophic and irreversible even at low probability, in which case the 'useless but safe' extreme may be the only acceptable choice regardless of lost value.
Detail
situation: A biology model that is highly capable could help cure disease, but could also be asked to design a novel pandemic pathogen.
decision: She frames the problem as locating a point between 'no capability' and 'oracle-level capability' rather than picking an extreme.
outcome: This framing led to the differentiated access framework rather than blanket capability caps.
lesson: Naming the two useless extremes explicitly can help force a deliberate middle design rather than defaulting to either pole.
In their words
And I think the safest model here will be a model just had no capability, right? And you- It's not very good. Yeah, it's not very good, but it's very safe. And on the other hand, if you had a model that is basically an Oracle of the physical world, basically knows everything about every experiment, that model could fall into the wrong hands and do potentially very bad things