AI Builders · AI for Science, Deep Tech, and Compute Infrastructure (Podcast Digest)

This piece reorganizes 9 podcast episodes by subdomain + cross-domain playbook instead of recapping them one by one. There is only one main thread:moving AI from "text on screens" to "atoms in the physical world", plus the compute foundation that supports all of this. It covers four areas: ① Science automation — "self-driving labs" for materials (Periodic Labs, MIT's Heather Kulik) and biology (Ginkgo); ② Autonomous driving — Waymo pushes "automation" past the wall of flexibility to become "autonomous"; ③ Compute and chips — Cerebras (the company building ultra-large AI chips), Baseten (a cloud specialized in "inference", see §3.1 for terminology); ④ New hardware form factors — Starcloud puts data centers in space, Impulse rebuilds the stovetop using batteries.

When to open this:

You want to understand where exactly "AI for Science / AI for materials / AI for biology" is stuck, and why training another big model isn't enough

You hear about Cerebras / Baseten / inference compute / GPU shortages and want to know the moats and risks of this business

You want to understand why people call Waymo, Ginkgo's automated labs, and others the "Waymo moment of [that industry]"

You build products or invest, and want a framework for judging when "AI applied to the physical world" will actually work

You want a few counterintuitive playbooks for hardware/deep tech startups (rebuilding stovetops with batteries, data centers in space, the "specialist David")

0. One-sentence map: These 9 episodes are all about the same thing

Subdomain	Who (people · companies · shows)	One-sentence thesis
AI for materials	Heather Kulik (MIT chemical engineering professor · Latent Space)	There is no AlphaFold for materials; the bottleneck is data quality, not models
AI for atoms	Liam Fedus (co-founder of Periodic Labs, co-creator of ChatGPT · No Priors)	Giving humans the ability to "rearrange atoms" hinges on model ↔ simulation ↔ real experiment closed loop
AI for biology	Jason Kelly(Ginkgo Bioworks CEO · Training Data)	Biology's "Waymo moment": even if AI is dumber,automated labs can still win
Autonomous driving	Dmitri Dolgov (co-CEO of Waymo · Training Data)	Easy to start, extremely hard to go all the way; "end-to-end" is not enough — you need verifiable intermediate representations
AI chips	Andrew Feldman (founding CEO of Cerebras · No Priors)	Brand-new workloads require brand-new architectures (whole wafers), not modified GPUs
Inference compute	Tuhin Srivastava(Baseten CEO · No Priors)	"Even if we get AGI, everything left is inference" — inference is the final market
Space data centers	Philip Johnston(Starcloud CEO · Training Data)	The marginal cost of building data centers on Earth is rising, while in space it is falling; they will cross eventually
AI smart stove	Sam D'Amico(Impulse Labs CEO · Latent Space)	Stick a battery into the stovetop,decouple user experience from the power grid

Note: The two Ginkgo episodes (biologys-waymo-moment and how-autonomous-labs-will-transform) are two edited cuts of the same Jason Kelly interview; they are merged in this piece and not repeated.

1. Science automation: From "thinking hard in a room" to "automated labs"

1.1 Starting point of consensus: The bottleneck of science is doing experiments, not insufficient thinking

Three science-focused founders (Fedus / Kulik / Kelly) all say the same thing: real science is not sitting in a room ruminating, but engaging with the real world and running experiments iteratively.

"Science ultimately isn't sitting in a room thinking really hard. You have to conduct experiments. You have to learn from them. You have to interface with reality." — Liam Fedus(Periodic Labs · No Priors) Translation: At the end of the day, science is not about thinking really hard indoors. You have to run experiments, learn from them, and grapple with reality.

Jason Kelly (Ginkgo · Training Data) quantifies this:About 95% of science is experimental (not something you can calculate with theory/simulation alone); to learn something new you have to "go poke it" — literally prod the physical world.

Why this is the foundation of the whole chapter: This explains why "AI for Science" is not as simple as "training a smarter model" — no matter how high the intelligence, you still need a system behind it that can actually run experiments hands-on. The three companies below are solving exactly "how to let AI do things hands-on".

1.2 Data, not models, is the scarce resource in the physical world

Language models have the entire internet as data; the physical world does not. Both point out the same data trap:

Kulik (materials): Right now the smartest ML engineers train on low-precision DFT (Density Functional Theory, a computational method for approximating molecular energies) datasets that do not match real experiments.

"All the smartest ML engineers right now are learning on data that is not going to be reflective of experiment." — Heather Kulik(MIT · Latent Space) Translation: The smartest group of ML engineers right now are learning entirely from data that does not match real experiments.

Fedus (atoms): Material property values scraped from papers can span multiple orders of magnitude; training on them only fits a "distribution" and gets you no closer to the ground truth —only experimental data can provide grounding.

Both prescribe the same remedy: closed loop. It is not amassing a static pool of data, but: run experiment → observe anomalies/patterns/consistency with simulation → decide what to run next.

"It's not just a pool of data, it's a very active loop." — Liam Fedus Translation: It is not a pool of data, it is a very active (experimental) closed loop.

Analogy for non-technical readers: Just like running a restaurant is not about memorizing recipes perfectly, but actually stir-frying a dish, serving it to customers → seeing feedback → improving the next dish. AlphaFold succeeded back then precisely because the protein field had CASP as a referee with "real experimental answers"; the materials field exactly lacks this referee (§1.3).

1.3 "There is no AlphaFold for materials" — why you can't just copy it over

Kulik's core judgment:Don't expect the AlphaFold playbook to transfer directly to materials, and the bottleneck is data, not model architecture.

Dimension	Proteins (where AlphaFold works)	Materials (can't be copied over)
Building blocks	~20 natural amino acids, regular structures	Far more types of building blocks, endlessly varied bonding patterns (especially metal-organic bonds)
Referee	CASP has experimental ground truth	Mostly only low-precision DFT, lacks experimental ground truth
Risk	—	"Could fail even more spectacularly than AlphaFold did"

"These models could fail more catastrophically than AlphaFold obviously fails." — Heather Kulik Translation: These (materials) models could fail even more spectacularly and crash harder than AlphaFold.

She has a small test she repeatedly uses to call out big models — the "22-atom ligand challenge":

"The thing I constantly do every time an LLM is updated is I just ask it, please design me a ligand that has 22 atoms. I can never get an answer that has 22 atoms." — Heather Kulik Translation: Every time a new big model comes out, I ask it to "design a ligand with 22 atoms", and I have never gotten an answer that actually has 22 atoms.

Two transferable methodologies (applicable to any "AI for X"):

Don't wait for models to be accurate before you start — in active learning, "searching fast when looking for a needle in a haystack" is more valuable than "being accurate on every prediction"; even if the model is inaccurate, optimizing one more dimension can bring a 100–1000x speedup (when she worked on MOF materials for carbon capture, she optimized 7 objectives simultaneously in one run).
Domain literacy is the judge: LLMs are good at "Wikipedia-level" chemistry common sense, but cannot do real design; you have to understand enough to judge whether the model is right or wrong, and treat it as a tool rather than blindly trusting it from scratch.

"ChatGPT is super good at Wikipedia level chemistry knowledge." — Heather Kulik Translation: ChatGPT is very good at Wikipedia-level chemistry knowledge (— the implication being: it can't go any deeper than that).

Why this section matters: It is the hardest correction to the "AI is omnipotent" narrative. Among the science-focused group, Kulik is more pessimistic than Fedus/Kelly in emphasizing the hurdle of "data ground truth" — looking at all three together gives a healthy internal disagreement within the field.

1.4 Periodic Labs: Language models as the "orchestration layer", specialized networks as tools

Fedus (fresh out of OpenAI, formerly co-creator of ChatGPT and post-training lead) built Periodic Labs, positioned as "the AI foundational lab for atoms". Its architecture is well worth product managers studying:

Language model = orchestration layer / lab director: reads literature, moves across multiple types of experimental data and modalities, decides next steps;
Specialized neural networks = tools to be called: small, fine-tuned, low-latency models built specifically for atomic systems with symmetry constraints, used as tools or reward functions.

Two counterintuitive views on resources:

Periodic spends zero effort on "improving the programming model" — it directly uses off-the-shelf Codex and Claude Code as accelerators, and only invests ML effort where existing frontier models are not yet good enough.
Intelligence is "spiky", not a scalar: You can build a system that is world-class in one mathematical domain, but degrades to a "poor student" as soon as the problem is perturbed.

"One fallacy is thinking about intelligence as a scalar." — Liam Fedus Translation: One fallacy is treating "intelligence" as a single, one-dimensional numerical value.

Business model: Position itself as the "intelligence layer / system of record / control plane" for companies bottlenecked by materials/process engineering; start with a software business, and for individual high-value breakthroughs potentially shift to a biotech-style "collaboration + revenue share / owning the materials themselves" model. Periodic itself is "customer zero" (its own first user).

On robots: They are not required for Periodic to reach "escape velocity", but they are a "huge accelerator". Today, off-the-shelf, commoditized robots + humans + reliable automation components are enough; if dexterous humanoids that can enter unstructured labs and reliably follow instructions become available, they will greatly accelerate opening new labs. (This is in tension with Kelly's view that "there is no future for humanoid robots in labs", see §1.6.)

1.5 Ginkgo: Biology's "Waymo moment" — dumber AI can still win

Kelly's worldview:DNA is code (ATCG instead of 0/1), and cells are like programmable computers, except they "move atoms" rather than information. Ginkgo spent ~15 years working on both the "design" and "test" ends, and in the last two years completely cut "design" and went all-in on the "test/build" end——

Because design is a scientific problem (hitting the right answer feels great, but it is unpredictable), while the lab side is an engineering problem that can be "rendered to dust".

The hardest empirical evidence (collaboration with OpenAI): Pair an inference model with a robotic lab, and have it optimize "cell-free protein synthesis". Each round uses ~100 384-well plates, roughly 30,000 experiments; the model reviews the returned data and designs the next round.After 4 rounds it surpassed the then-best level, and after 6 rounds it exceeded that by another 40%.

Why did it win? Kelly emphasizes repeatedly —not because it was smarter, but because it could "run experiments hands-on":

"What really let it break through wasn't that it was so smart. It was that it could run experiments." — Jason Kelly(Ginkgo · Training Data) Translation: What really made it break through was not how smart it was, but that it could run experiments.

Two "unfair advantages" of automated labs (also the most transferable insight in this piece):

Information sharing: 100 AI scientists each pursue one hypothesis, and every day they sync raw data with each other — even your failed results can help my different hypothesis. In human science you have to wait 1–2 years to read a highly distilled paper, and you never see other people's failures or raw data.
Cost structure: Biopharma spends $60–80 billion on R&D annually,less than 5% is actually spent on reagents, and all the rest is indirect cost (people, facilities, regulation, extremely underutilized equipment). AI + robotic labs can flip this, making ~90% spent on reagents ≈ 10x more data per dollar.

"Less than 5% [of R&D spend] is on the reagents. Everything is on overhead." — Jason Kelly Translation: Less than 5% of R&D spending goes to reagents; all the rest is indirect cost.

Stack the two advantages together:even if AI is dumber than human scientists, automated labs can still win.

1.6 "Waymo moment" = automation × flexibility (the parent framework of this piece)

Kelly proposes a 2×2 framework that can be applied to almost all physical infrastructure (which is also why this chapter places biology and autonomous driving side by side):

	Low flexibility / low mix	High flexibility / high mix
High automation	Subway (fixed routes)	Waymo = autonomy
Low automation	—	Cars (human-driven, most flexible)

"Since the industrial revolution, we've basically been automating everything that is low mix... and we just hit a wall on flexibility — and AI pushes us past it." — Jason Kelly Translation: Since the Industrial Revolution, we have basically automated all "low-mix" work… then we hit the wall of flexibility—and AI pushes us over that wall.

When a system delivers both "automation + flexibility", we no longer call it automation; we invented the word "autonomy". Lab automation is exactly this kind of "high-mix, low-volume" work, which was extremely hard to automate in the past; today 99% of experiments are still "done manually on the bench" (just as 99% of miles are still driven by humans).

But there is a key contrast between labs and autonomous driving(Kelly specifically emphasized):

The hardest part of autonomous driving is the changing physical world(traffic cones, rain, places you have never been);
The lab environment does not change at all; the hard part is the diversity of demands from scientists.

So the two tech stacks are different. Kelly says automated labs only need to crack two things to be "done": ① Integrate roughly 1,000 long-tail third-party benchtop instruments (all with terrible software) into a single software-controllable system; ② Solve liquid handling (pipetting; for viscous liquids, pressure must be adjusted by eye, just like a human does).

"It is f***ing tractable." — Jason Kelly (on automated pipetting + instrument integration) Translation: This thing is f***ing solvable.

Two judgments opposite to Periodic(healthy disagreement):

There is no future for humanoid robots in labs: Scientists' main task is "moving samples"; highly reliable tracks (micron-level precision) + 6-axis robotic arms are far better than bipedal locomotion; biology/chip fabrication are both microscopic disciplines, so humanoids are "completely pointless". (Contrast with §1.4 Fedus treating humanoids as an "accelerator".)
Labs will get smaller, not bigger(opposite of data centers): centralized automated labs eliminate redundant purchases, raise equipment utilization from under 20% to ~70%, and pack equipment more tightly around the tracks.

1.7 A shared "small tool" breakthrough: letting scientists who don't write code use robots too

All three companies mentioned the same detail—Claude Code / Codex lets "scientists who can't program" drive robots. This is a very concrete, reusable product insight:

Scientists hate visual programming (LabVIEW was called "complete trash"), and nobody wants to program;
Ginkgo had two accidents: scientists sent sealed film-covered plates into the pipetting robot, and the robotic arm got stuck on the film (even experts make stupid mistakes; it's the UI's fault);
Solution: scientists only submit written experimental protocols (in natural language), and let Claude Code / Codex generate the code; once the model makes a mistake (for example, sending a sealed plate again), they update the skills file so it never makes that mistake again.

"From now on, the way we're going to interact with writing the code is through Claude Code or Codex... and if the model sends a plate sealed, we will update the skills file." — Jason Kelly Translation: From now on, the way we write code is through Claude Code or Codex… if the model sends a sealed plate, we update the skills file.

Why this matters for PMs: This is a real industrial case of "using skills files to turn past pitfalls into permanent rules"—exactly the same way you manage AI agents. Sam D'Amico's stovetop is the same idea (§4.2); even the stovetop runs Claude as an agent.

2. Autonomous driving: How Waymo gets through the "long tail"

Waymo co-CEO Dolgov (who has worked on autonomous driving for ~21 years, starting from the 2005 DARPA Grand Challenge) presents the farthest-along example in "AI for the physical world":20M+ fully autonomous trips, of which 10 million happened in the most recent 7 months.

2.1 The most anti-hype point: Breakthroughs only rewrite the "front of the curve", not the "long tail"

"It's very easy to get started, but it's very difficult to take it all the way to a real product, full autonomy, and superhuman performance." — Dmitri Dolgov(Waymo · Training Data) Translation: It is very easy to get started, but going all the way to a real product, full autonomy, and superhuman performance is extremely difficult.

Dolgov's view on the hype cycle: A single breakthrough makes the easy early part of a problem improve rapidly and attract investment, but it does not change the long tail. Waymo survived the 2016–17 trough when most competitors gave up by: believing deeply in the importance of the mission + being clear about how hard it is + not chasing "easy wins" and "silver bullets".

"Safety has to be the non negotiable foundation... how you go about the first 90 is a totally different problem from how you go about getting to your next n nines." — Dmitri Dolgov Translation: Safety must be the non-negotiable foundation… getting to the first 90% and achieving the next "few nines" (99.9%, 99.99%…) are two completely different problems.

Why every AI product builder should tape this to their wall: Between an impressive demo and real reliability lies the entire long tail. This does not contradict Kulik's "don't wait for the model to be accurate before you start"—in the research phase you should dare to move fast and rough, but when building a product for real people, those last few nines are where all the difficulty lies.

2.2 "End-to-end" is a false dichotomy

Many people debate whether autonomous driving should be "end-to-end" (sensors directly outputting actions). Dolgov says this is a false proposition:

"There's a massive difference between using end to end versus purely relying on it." — Dmitri Dolgov Translation: There is a huge difference between "using end-to-end" and "relying purely on end-to-end".

Waymo's foundation model is a "multimodal world-action-language model" (it reasons jointly over images/video + LiDAR/radar, has 3D spatial + physical + behavioral understanding, and can also pull common sense from language models for semantics); it indeed is end-to-end; but on top of the learned representations, Waymo also layers "structured intermediate representations" so the car can self-check at runtime, perform closed-loop evaluation/training, and design rewards for reinforcement learning.Pure vanilla end-to-end cannot build a product with "full autonomy + superhuman safety + massive scale".

For non-technical readers: "End-to-end" is like letting an experienced driver drive all the way on intuition alone; Waymo adds several "dashboards and checkpoints" on top of intuition, so problems can be seen, corrected, and verified. This is two sides of the same coin as the "long tail" in §2.1—to get through the long tail, you must give up the pure elegance of "one black box solving everything".

2.3 Scaling is a "phase change", not linear

The first 100 million miles took ~16 years; the next 100 million took only ~6 months;
From the first fully autonomous commercial operation to public passenger service in 4 cities took 8 years; recently,in one day they launched in 4 cities;
Data: 4 million+ autonomous miles per week; 13x safer than humans in serious injury crashes = one fewer serious injury every 8 days.

Strategy also shifted from "deliberately, sequentially defusing mines one by one" to "rapid, parallel global commercialization".This is exactly what Kelly/Feldman repeatedly said about "the art of the possible being widened"—once you believe something is possible, speed itself becomes a huge advantage.

3. Computing foundation: Chips and inference are the power grid for all of this

When AI connects to the physical world, it burns computing power underneath. Two episodes fully explain the business of "selling computing power".

3.1 First, some terminology (must-read for non-technical readers)

Inference: The computation that happens after a model is trained, every time it answers your question. Training is like "going to school", inference is like "going to work"—every time you use ChatGPT you trigger an inference.
GPU: General-purpose AI chips like Nvidia's can do both training and inference.
Wafer-scale chips: Cerebras's bet—while others cut a wafer into many "stamp-sized" chips, Cerebras does not cut it, making a single "dinner-plate-sized" chip (46,000 square millimeters).

3.2 Cerebras: Brand-new workloads require brand-new architectures (not GPU tweaks)

Feldman (on his 5th startup; Cerebras IPO'd at a roughly$63 billion market cap) core argument:To be 15–20x faster, you cannot rely on minor tweaks to GPUs; the architecture must be fundamentally different.

"How big is the market for slow search? It's zero. How big is the market for dial-up internet? Zero. That's how big the market for slow inference will be." — Andrew Feldman(Cerebras · No Priors) Translation: How big is the market for slow search? Zero. How big is the market for dial-up internet? Zero. That is how big the market for slow inference is.

A few extremely useful mindsets for entrepreneurs:

"Being ahead of the market" hurts: They proved wafer-scale was feasible back in 2019, but in 2023–early 2025 "nobody cared"—Gen1 shipped a dozen units, Gen2 around 300 units, Gen3 now tens of thousands of units.Even when you get it right, you still have to wait for the market to grow to the point where it can use AI.
The path across the chasm: First target supercomputing customers (who love speed and tolerate immature software) → Argonne, Lawrence Livermore, Sandia and other national labs → oil & gas, pharma → then use a sovereign anchor customer (G42 placed an order of roughly $1 billion) as a "bridge customer"to reshape the supply chain, build out clusters large enough for real-scale stress testing → be ready by the time OpenAI (a ~$20 billion+ mega-order) and AWS come calling.
"Be the professional David":

"You gotta love being a David. I'm a professional David. This is my fifth startup. I compete against Goliath." — Andrew Feldman Translation: You have to enjoy being David (the little guy fighting Goliath). I am a professional David. This is my fifth startup, specifically built to fight giants.

When to give up: You once listed "what premises need to be true to win", and when all of them come back false, that is the clear signal to quit; rely on a few seasoned former CEOs to help you "stay accountable to your original judgment" and avoid being "boiled like a frog in warm water".
Speed spawns entirely new business models (signature insight): Speed is not about making old businesses "slightly better"; it opens up entirely new businesses.

"Netflix used to deliver DVDs in envelopes... when the internet got fast, they became a movie studio. That's what happens with speed." — Andrew Feldman Translation: Netflix used to stuff DVDs into envelopes and mail them to you… once internet got fast, it became a movie studio. That is the kind of qualitative change speed brings.

3.3 Baseten: "Even if we get AGI, everything left is inference"

Tuhin (Baseten, which in the past year grew 30x, is projected to exceed $1 billion in revenue this year, and has cluster utilization at an "uncomfortably high" 90+%) explains the moats and risks of the inference business most clearly:

Where the moat is: Value lives in the "unique user signals" you can capture.If the signal can be encoded into a model and replicated by big tech companies, the business is in danger; if it is encoded into workflows(for example, Abridge's doctor editing medical records actions that go three steps into the electronic health record), that is a moat out of reach of frontier big tech.
How early the market is: Measured by inference call volume,about 99% of the market has not come online yet; the enterprise adoption sequence is "use AI tools → call closed-source APIs → use custom/post-trained models", and this last stage still lies ahead.
"Selling GPUs" is not sticky; "inference with a software layer" is extremely sticky:

"GPUs as a service is not sticky... Inference with the software layer included is incredibly sticky. None of our top 30 customers have ever churned. We're talking like 400% annual NDR." — Tuhin Srivastava(Baseten · No Priors) Translation: Selling GPUs as a service is not sticky at all… inference with a software layer is extremely sticky. None of our Top 30 customers have ever churned, with annual net revenue retention around 400%.

Brutal industry reality: Supply is tighter than outsiders think, with almost no idle computing power; 1024 B200s (Nvidia's flagship) now require signing 3–5 year contracts + prepaying roughly 20–30% of the total contract value—this turns "low cost of capital" into a key competitive advantage, and also "forces companies to go public earlier".
Jevons paradox holds for inference: The cheaper intelligence gets, the more developers will pack into it, and agents will run longer and do more work.

"Even if there's AGI, all that's left is inference." — Tuhin Srivastava Translation: Even if we actually get AGI, everything left is still inference.

On Chinese open-source models: DeepSeek, Kimi and others are "excellent"; DeepSeek can deliver comparable or even better latency and reliability at roughly 20% of the cost, and losing this intelligence would be a "huge loss" for American innovation; the US needs its own strong open-source models, which is "necessary and inevitable".

Why the two episodes in §3 should be read together: Cerebras from the "chip architecture" side and Baseten from the "inference software layer" side are saying the same thing—inference is the main battlefield for the next decade, and the moat is not in the hardware itself, but in software/workflows/unique signals. This also answers what those automated labs in §1 are actually burning (answer: massive amounts of inference).

4. New hardware form factors: Putting data centers in space, and batteries into stovetops

The last two episodes are two extreme examples of "hardware first principles", sharing the same kind of entrepreneurial mindset.

4.1 Starcloud: Earth's marginal costs are rising, space's are falling, and they will eventually cross

Johnston (Starcloud, formerly at McKinsey serving space agencies) core argument:

"In space the marginal cost goes down for every additional unit... there comes a crossover point where it just makes zero sense to continue building things on Earth." — Philip Johnston(Starcloud · Training Data) Translation: In space, the marginal cost of building each additional unit actually falls… there will always be a crossover point beyond which continuing to build on Earth makes no sense at all.

Why space beats ground-based solar: no land approval required (a 100MW project in North America takes 5–10 years to permit), 24-hour sunlight means no energy storage needed,1 square meter of solar panel in space produces 8 times the output of one on the ground. Break-even is reached when launch costs fall to around $500/kg; below a few hundred dollars per kilogram, "space wins forever."

A few counterintuitive engineering realities (useful for understanding that "the physical world is not that romantic"):

~70% of engineering time is spent on heat dissipation, and only ~30% on chip reliability. Space is cold, but it is a vacuum (an insulator), so the only way to dissipate heat is via infrared radiation, and radiative output grows with the 4th power of temperature — which means radiators should be run as hot as possible.
Chips are more radiation-resistant than people think: the H100 in orbit has had zero restart failures; GPU workloads are stochastic, and an occasional bit flip does not change output quality (if you ask it to "write a poem about space," a flipped bit still yields an equally good poem).
The business model is Equinix, not AWS: they only provide "boxes" with power, cooling, and connectivity, and customers install their own chips — the core IP is cooling plus radiation hardening, rather than rebuilding AWS’s two decades of application layers.

"You can think of us more like Equinix while SpaceX might be more like AWS." — Philip Johnston Translation: You can think of us as Equinix (we only provide data halls/racks), while SpaceX is more like AWS (they build even the application layers themselves).

The bet behind the entire business is extremely straightforward:

"If you don't think the launch costs are going to come down, then we're a terrible business. If you do, then we may be the biggest business ever." — Philip Johnston Translation: If you don’t believe launch costs will fall, we’re a terrible business; if you do, we might be the biggest business in history.

4.2 Impulse: Stick a battery in the stove to decouple user experience from the grid

D’Amico (Impulse Labs; previously worked on Google Glass, Oculus, and Meta Quest Pro controllers) rebuilt the stove from first principles: he put a3 kWh lithium iron phosphate battery inside the stove, adding roughly 15,000 watts on top of wall-outlet power, with a single burner peaking at 10,000 watts (about 3 times that of an ordinary induction cooktop).

"If you slam a battery into it, you've decoupled the energy input from the wall with the device's power outputs. You can decouple the user experience from the grid." — Sam D'Amico(Impulse · Latent Space) Translation: You jam a battery in there, and you decouple "the energy coming from the wall outlet" from "the power the device outputs" — you decouple the user experience from the grid.

A few transferable hardware startup lessons:

"Build stoves the way you build phones": treat it as consumer electronics, not home appliances — explicitly drawing an analogy to Tesla Model S’s end-to-end in-house development, not using a pile of off-the-shelf supplier parts, which is why it is "simply a better car."
Closed-loop temperature control is the killer feature: the development unit can hold 446°F for searing scallops; when cold scallops are dropped in and the temperature drops ~10°, the system immediately adds power, so there is "no smoke, no burning." He calls this a "robot":

"We stopped calling robots robots when they work." — Sam D'Amico Translation: When robots can actually do work, we stop calling them robots.

(Note that this shares the same spirit as Kelly’s "automation → autonomy" and Dolgov’s "superhuman performance" — reliable enough that it is no longer a gimmick.)

No app store needed: "As long as it can cook, you’re fine" — deliberately avoiding money pits like two-sided markets or content subsidies (contrast with Meta Reality Labs’ massive subsidies for Quest content).
Pick low-hanging fruit that big companies won’t touch, don’t build a company that "has to be acquired", using Palmer Luckey/Oculus as a model.
Even the stove runs Claude as an agent: "Set the front-right burner to scallop-searing temperature" → it actually sets it; the recipe agent can search the web for recipes, convert them into structured steps with step-by-step timers, and after confirmation send real commands to the burner (preheat oil to 351°F). Moreover, D’Amico, who has a hardware background, built a fleet telemetry system deployed on AWS from scratch using Claude Code + Sonnet 4.

"If you're a 30 person hardware startup, the CEO better be coding." — Sam D'Amico Translation: If you’re a 30-person hardware startup, the CEO had better be writing code themselves.

5. Cross-domain lessons: What it takes to make "AI for X" actually work in the physical world

Cutting across all 9 episodes, we distill a few of the most useful judgments for product building / investing:

Closed loops > static datasets: the physical world has no ready-made internet; value lives in the living closed loop of "run experiments → learn → redesign" (consensus among Fedus, Kulik, and Kelly). The first question to ask any AI-for-X project is:Where is its experimental loop, and how fast does it turn?
Data ground truth is the invisible ceiling: when there is a real ground-truth judge (CASP for proteins), you get AlphaFold; when there isn’t (e.g., materials), don’t get your hopes up. To judge a scientific AI project, first look at what it uses as ground truth.
Judge maturity by "automation × flexibility": only when you get both at the same time does it deserve to be called "autonomous" (the Waymo moment). Ask: is this work high-mix, low-volume? How do you get past the flexibility wall?
A stunning demo ≠ making it through the long tail: the first 90% and the "next few nines" are two different problems (Dolgov). In the research phase you can move fast and rough (Kulik); when building a product, the last few nines are where all the difficulty lies.
Moats lie in workflows/unique signals, not in models or hardware: things big companies can copy (capabilities inside models) are dangerous; things encoded into workflows are safe (Baseten); selling raw compute/raw GPUs is not sticky, adding a software layer makes it sticky.
Speed creates new businesses, it doesn’t just make old businesses slightly better: Netflix → movie studios; the market for slow inference is zero (Feldman). Don’t ask "how much is a little speed worth," ask "what entirely new modes open up when speed crosses a certain threshold."
AI coding is an invisible lever for physical-world founders: Periodic used Claude Code/Codex directly with zero upfront investment; Ginkgo uses it to let scientists who can’t code drive robots and codify rules in skills files; even the stove CEO does his own vibe coding.Hardware and software teams are both using the same set of agent workflows.
Hardware first principles + disciplined business models: Impulse stuffing in a battery to decouple from the grid, Starcloud only doing the "space version of Equinix" instead of rebuilding AWS, Cerebras "being the specialized David" — what they have in common is picking low-hanging fruit big companies won’t touch + avoiding two-sided markets / structures that force an acquisition.
National security and the China-US variable run through everything: China’s share of new drug discovery rose from <5% to over 40% in 3 years (Kelly), DeepSeek matched closed-source models at 20% of the cost (Tuhin), and the US can only avoid "technology surprise" through AI + automation (Project Genesis / DOE). Deep-tech investing cannot avoid this geopolitical line.

References and further reading

Sources for the 9 episodes (full source paths):

../sources/learning/follow-builders/podcasts/latent-space-the-stove-guy-sam-damico-shows-new-ai-cooking-features-on.md — Sam D'Amico / Impulse Labs / Latent Space(2026-03-31)
../sources/learning/follow-builders/podcasts/latent-space-there-is-no-alphafold-for-materials-ai-for-materials-disc.md — Heather Kulik / MIT / Latent Space(2026-03-24)
../sources/learning/follow-builders/podcasts/no-priors-ai-for-atoms-how-periodic-labs-is-revolutionizing-materials.md — Liam Fedus / Periodic Labs / No Priors(2026-04-03)
../sources/learning/follow-builders/podcasts/no-priors-baseten-ceo-tuhin-srivastava-on-the-ai-inference-crunch-cust.md — Tuhin Srivastava / Baseten / No Priors(2026-05-01)
../sources/learning/follow-builders/podcasts/no-priors-the-story-behind-cerebras-63-billion-ipo-with-founder-and-ce.md — Andrew Feldman / Cerebras / No Priors(2026-05-21)
../sources/learning/follow-builders/podcasts/training-data-biologys-waymo-moment-ginkgo-bioworks-jason-kelly.md — Jason Kelly / Ginkgo Bioworks / Training Data (2026-03-24, edited version A)
../sources/learning/follow-builders/podcasts/training-data-how-autonomous-labs-will-transform-scientific-research-g.md — Jason Kelly / Ginkgo Bioworks / Training Data (2026-03-24, edited version B, same interview as above)
../sources/learning/follow-builders/podcasts/training-data-greetings-earthlings-philip-johnston-of-starcloud-on-dat.md — Philip Johnston / Starcloud / Training Data(2026-03-17)
../sources/learning/follow-builders/podcasts/training-data-waymos-dmitri-dolgov-20-million-rides-and-the-road-to-fu.md — Dmitri Dolgov / Waymo / Training Data(2026-05-04)

Companion wiki:

AI Builders · Frontier Model Research and the Path to AGI (Podcast Digest) — Frontier research (foundation models, world models, superintelligence, etc.), complementary to this piece’s focus on "application to the physical world"

History

2026-06-05 v1.0 created — follow-builders podcast digest, AI for Science / deep tech / computing infrastructure topic bucket, 9 episode sources (two Ginkgo edits merged), topic-driven + bilingual.

2026-09-26 supplement: Working backward from useful work to compute and delivery chains

Evidence scope: locally truncated transcripts of Jensen Huang (feed 2026-06-10), Lip Bu Tan (2026-06-18), and Max Hodak (2026-08-20); this section is partial. Only product and engineering judgments supported by visible fragments are retained; oral statements about medical approvals, valuations, and performance have not been independently verified.

Define the work first, then talk about infrastructure. Jensen chains generated content, inference, and tool operation into a capability progression, with the core value judgment being whether useful work can be delivered. He recommends looking at both downstream industry tasks and upstream compute demand. Framing old computing as pre-storage and retrieval and AI as on-the-fly, context-based generation is an explanatory framework; the visible opening is not sufficient to prove that every enterprise should build its own "AI factory."

“We pay for people who do work.” Translation: We pay people who get work done.

Customers are not buying isolated chip specs, they are buying reliable delivery. Discussing foundry work, Lip Bu Tan emphasized required IP, yield, defect density, and cycle time; some customers need full racks, so software and systems are also required. His argument about CPU importance comes from task mixes such as agent orchestration. CPU:GPU ratios of roughly 1:8 to 1:4 or 1:1 are interview observations and expectations, and cannot substitute for measuring your own workloads.

“It's a service business. It's a trust business.” Translation: This is a service business, and it is also a trust business.

Long-term research and near-term products can advance on two tracks, but milestones must be kept separate. Max Hodak described how Science pairs long-term neural interface research with a near-term vision restoration product, working backward from usable biological pathways to solutions while also considering both in-house development and acquisitions. His oral statements about European approval and first sales in the coming weeks describe different statuses; approval does not equal sales already made, much less validation of scaled efficacy. This paragraph only records route choices and does not constitute medical suitability advice.

A usable checklist for PMs is: what is the task outcome → what hardware, software, and data are needed for it → which reliability or cycle time is the constraint → which technology, approval, first-order, or scale-up milestones have been achieved. Avoid directly translating upstream capability demos into downstream commercial success.

2026-09-26 full-text supplement: After design speeds up, recalculate the critical path for verification and supply chain

Based on Arm CEO Rene Haas’s full local interview 00:00—37:04 (full_scan). Numbers and trends are as stated by the guest; future cycle-time reductions are forecasts.

Delivering chips entails a whole additional set of responsibilities beyond delivering designs. IP licensing is like providing part designs; compute subsystems are like providing assembly blueprints; selling physical chips additionally requires manufacturing allocations, memory, substrates, layout implementation, debug labs, inventory, and after-sales support. Even without building your own fab, you cannot skip these capabilities. Moving downstream also requires maintaining the existing ecosystem of chip and software customers; you cannot look only at new-product revenue.

Near-term AI value may appear first in verification, debugging, and documentation. The guest stated that a typical chip development cycle is 24–36 months, and the largest portion is not necessarily first-pass design; the figure that 80%–90% of engineers use AI daily is an adoption metric and cannot be read as an equivalent productivity gain.Having a design without documentation and tests is both hard to sell to customers and hard to use as reliable training and verification material.

“It's unusable. It's untestable.” Translation: It is unusable, and it is untestable.

Therefore, you cannot simply multiply RTL (code describing digital circuit behavior) generation speedup across the entire time-to-market cycle. For simpler designs, he suggested it may be possible in five-plus years to go from idea to tape-out files; the most advanced designs that are simultaneously faster, more power-efficient, and cheaper cannot be delivered with a single button press today.

Faster design may also shift bottlenecks toward fabs, memory, advanced packaging, and data center construction. Capital, supply-chain relationships, and construction capacity need to be arranged in advance. At the system level you likewise cannot look only at GPUs: CPUs handle scheduling and tool execution, while memory and accelerators jointly determine actual task performance; edge devices such as wearables are also subject to strict power constraints.

“you just can't put a 50 watt GPU on your head.” Translation: You can’t simply wear a 50-watt GPU on your head.

Robotics follows the same evidence discipline: general demos, retrainable hardware, cost declines, business models, and scaled deployment are each validated separately. The guest is bullish on both humanoid and specialized form factors but acknowledges that costs and business models are not fully resolved today. For deep-tech projects, design, verification, manufacturing, integration, and customer adoption should be recorded ring by ring; after shortening one ring, reassess the new critical path, and avoid mistaking demo speed for delivery speed.

2026-09-26 full-text supplement: After chips get faster, you still have to measure end-to-end task time

Cerebras’ Andrew Feldman used memory movement to explain its wafer-scale architecture: choosing faster SRAM with lower per-area capacity requires larger die area and corresponding power delivery, cooling, redundancy, and packaging. The point of this case is system tradeoffs. It does not prove that one architecture is best for all models, contexts, and concurrency levels; performance multiples, deals, and the IPO mentioned in the interview were not independently verified here.

“you've made trade offs.”

Choosing an architecture means accepting its corresponding tradeoffs.

For interactive agents, low latency can reduce multi-turn waiting time and may also leave more room for checking and verification. However, tool calls, CPU work, cross-region networks, and rework can still slow down tasks. When selecting options under the same model and quality requirements, compare first response time, full task completion time, concurrency, failure retries, and cost. Although an API may appear to only require changing the endpoint address, model behavior, contracts, and operational boundaries still need to be verified.

R&D retrospectives should also distinguish technical operability from market adoption. Guests noted that packaging was an unexpected difficulty, and early demand remained weak after the product was built; these stages each require independent milestones. For full qualifications, see Cerebras Digest.

2026-09-26 Full-text addition: Experimental results and infrastructure metrics must retain consistent measurement scopes

The Chai Discovery interview connects molecular design to wet-lab validation, then feeds results back to the model. The most important point for product judgment is to distinguish stages: the cited roughly 15% refers to binding hits in a specific experiment, and by no means represents clinical success or patient benefit; after binding, developability and other properties still need to be assessed. Experimental error may overshadow small model improvements, so repeated validation, cross-target performance, and complete protocols must be examined.

“the lab is an important part to verify that what you're doing is correct.”

The laboratory is an important link for verifying whether a design is correct.

Similar discipline in measurement scope also applies to computing power. Lambda’s Stephen Balaban distinguishes accounting depreciation, physical lifespan, and economic lifespan; long-term wholesale contracts and on-demand services for the same GPU model cannot be directly compared by average price. Dylan Patel emphasizes the tradeoff between total throughput and single-user responsiveness: overnight documents can wait, while interactive tasks may care more about latency. Testing requires fixed models, software versions, loads, and quality, rather than comparing the highest speedup ratios each side cherry-picks.

“you can't have point in time benchmarking.”

Systems are continuously updated, so one-time benchmarks cannot represent real-world performance over the long term.

Applicable timing: When procuring or reviewing model platforms, separately record capacity, utilization, task success rate, completion time, and total cost. Hardware-software co-design can improve efficiency, but may also lock specialized architectures to current model directions; room must be reserved for future migration. All the business and performance figures above are statements from interviews; for qualifications, see Chai Digest, Lambda Digest and Patel Digest.

Full-text addition: Hardware products deliver services, and milestones must be accepted layer by layer (2026-09-26)

Two local interviews with Valar Atomics and Zipline discuss nuclear energy and drones respectively. Their shared lesson for product managers is: a single device operating successfully only completes part of the delivery chain. The following comes from interviewees’ own accounts; performance, safety, regulatory, and business figures have not been independently verified.

Why milestones must be broken down. In the nuclear energy interview, drawings, experimental data, criticality, heat production, power generation, continuous power supply, and commercial scale represent different states of evidence. The interview states, “you need data in order to go to the regulator.” This supports using experiments to reduce unknowns, but does not support treating an experimental permit as a commercial operating license. A short-term power supply case used by an AI demo website also cannot replace acceptance of continuous data center availability.

Case: Turning aircraft into a continuously deliverable service. The Zipline interviewee recalled that even with aircraft in the early days, they did not immediately cover all originally planned hospitals; inventory, orders, maintenance, and local collaboration all had to be connected. “People get sick twenty four seven.” Therefore, requirements should be written as reliable delivery service, not merely flight capability. Correct positioning still does not equal safe delivery; the division of labor between aircraft and last-mile delivery devices must also be jointly assessed for noise, location suitability, cost, and safety.

When it is worth building in-house. Valar advocates building necessary links that hinder scaling in-house, but also discusses purchasing expensive components to avoid delays. The transferable lesson is to first identify delivery bottlenecks, rather than trying to build everything oneself. Funding arrangements are also phased: prove the technology first, then discuss project financing; interviewees’ scale cost predictions do not equal already realized economics.

When to increase fault drills. Zipline says “you need to assume that any part of the system can have a fault.” Redundancy cannot just add a second computer; the mechanism responsible for judging which one is trustworthy must also be checked. As scale grows, rare anomalies become daily tickets; the millions of daily deliveries mentioned in the interview are a future scenario, not current business volume. A company statement of “zero safety incidents” also does not mean zero failures; the original text also reviews early parachute landings. Accident, failure, and recovery measurement scopes should be defined before discussing whether risk has decreased.

Source:Valar Original Digest, Zipline Original Digest.

Full-text addition: Bottlenecks for scientific research models may lie in how data is generated (2026-09-26)

The Biohub interview treats open tools, long-term maintenance, and experimental data as the same piece of infrastructure. According to the local archive dated 2026-06-25, the team believes “the data is actually even more of a constraint.” The lesson for PMs is: before adding computing power, first ask whether the required observations exist, whether data from different experiments can be connected, and whether the tools that generate data can be maintained long-term.

Cases. The interview discusses single-cell methods, annotation tools, and community data, moving on to models of proteins, cells, and the immune system. Cross-level data cannot simply substitute for one another: good performance in protein structure prediction does not mean the human body can already be simulated. AI and wet-lab teams designing sampling and validation together have a better chance of closing the feedback loop than each finishing their part and then stitching results together.

When it is useful. When building scientific research platforms or any product dependent on new data, tool adoption, repeatable experiments, predictions for new contexts, and actual applications can be accepted separately. The interviewee says “Our goal is always to build tools”; this does not mean the mission of curing diseases has already been achieved. The 96-well experiment and binding capacity cases in the original text are also not human therapeutic effects. Guests explicitly reserve the gaps from laboratory to clinic and the generalization of virtual cells, so this page does not describe digital simulation as already able to replace real clinical validation.

Source:Biohub Original Digest.

Sources and related materials

2026-10-09 Addition: Converting peak computing power into actually completed work

An interview with Google infrastructure lead Amin Vahdat provides a perspective for procurement and product review:goodput must subtract wasted work from failures, recovery, and recomputation. It is not equal to chip peak performance, nor is it equal to all tokens produced by the service. In synchronous training systems composed of tens of thousands of components, a local fault may pause the entire task; computation rerun before restoring a checkpoint consumes budget without adding to the final result. Therefore, a cheap per-card price is only meaningful when placed within the context of a complete task.

Compare solutions by delivered results

During evaluation, put four categories of data on the same table: successfully completed tasks, end-to-end time, losses from failures and retries, and total resource cost. Training scenarios focus on how much time and power are consumed per unit of effective training progress; user-facing agents should also add task success rate and result quality. Token count alone cannot substitute for business value, otherwise verbose outputs may be miscalculated as efficiency gains. This translates the interview’s infrastructure framing into an application review method, and is not a unified business metric published by Google.

After optimizing one layer, look for bottlenecks again

Agents quickly move to the next step after obtaining results, without waiting for humans to read. Request parsing, tool scheduling, and context reading may therefore push bottlenecks toward CPU, network, and storage. First measure the waiting time at each stage of a complete task, then decide whether to buy faster inference, shorten data access, or improve recovery mechanisms. Otherwise, even if the model becomes faster, user task completion time may remain unchanged.

Hardware-software co-design should also compare benefits against delivery costs. When research teams propose model changes, they need to confirm whether chip adaptation gains are sufficient to compensate for design changes and delays; near tape-out, minor improvements are usually not enough to overturn existing arrangements. The more specialized a design is, the more clearly it must document the load assumptions it depends on and migration methods after model changes. The separation of training and inference types mentioned in the interview still retains the ability to carry each other’s loads, indicating that specialization and elasticity need to be reviewed together.

Include recovery and power supply in capacity planning

The case of optical path switching to backup racks shows that reliability design is not only about reducing failures, but also about shortening waiting time after failures. When procuring capacity, also ask: how long until detection, how long until switchover, how much work must be recomputed, and whether drills have actually been conducted. Power supply needs to be planned together with the grid and expansion cycles; having old clusters on paper does not mean low-latency service can be immediately provided in the user’s region.

The half-year effective capacity targets, chip arrangements, and infrastructure effects mentioned in the interview are all guest statements. This section adopts their judgment framework and does not treat these numbers as independently verified performance commitments.

Source:Reference articles or interviews for this section.

October 9, 2026 addition: Turn peak compute into useful work completed

Google infrastructure leader Amin Vahdat's interview offers a useful perspective for purchasing and product reviews: goodput excludes work lost to failures, recovery, and repeated computation. It is neither peak chip performance nor the total number of tokens generated. In a synchronized training system with tens of thousands of components, a local failure can pause the entire job. Repeating computation after restoring a checkpoint consumes resources without adding to the final result. A low price per accelerator only becomes meaningful in the context of a complete workload.

Compare delivered outcomes

Put four categories in the same evaluation table: successfully completed work, end-to-end time, losses from failures and retries, and total resource cost. For training, measure the time and power needed to make useful progress. For a user-facing agent, also assess task success and output quality. Token count alone cannot stand in for business value: verbose output could otherwise appear to be an efficiency improvement. This is an editorial adaptation of the interview's infrastructure perspective, not a universal business metric published by Google.

Find the next bottleneck after each improvement

An agent can start its next step immediately after receiving a result, without waiting for a person to read it. Request parsing, tool orchestration, and context retrieval may therefore move the bottleneck to CPUs, networks, or storage. Measure the waiting time at each stage of a complete task before deciding whether to buy faster inference, improve data access, or shorten recovery. Otherwise, a faster model may leave the user's total task time unchanged.

Hardware–software co-design also requires balancing benefits against delivery costs. When researchers propose a model change, teams must determine whether the hardware benefit justifies redesign and delay. Close to tape-out—the point when a chip design is sent for manufacturing—a small gain may not justify changing the plan. More specialized designs should state their workload assumptions and explain how migration would work if models change. The interview's training and inference variants retain the ability to run each other's workloads, illustrating why specialization and flexibility belong in the same review.

Include recovery and electricity in capacity planning

Switching optical connections to a spare rack illustrates that reliability includes shortening the wait after a failure, as well as preventing failures. Capacity reviews should ask how quickly a fault is detected, how quickly service switches over, how much work must be repeated, and whether recovery has actually been rehearsed. Electricity requires coordination with grid and expansion timelines. Owning an older cluster does not automatically provide low-latency capacity where users live.

The interview's six-month capacity goals, chip plans, and infrastructure results are the guest's statements. This section adopts the decision framework without treating those figures as independently verified performance commitments.

Source: Article or interview used for this addition.

2026-10-18 Supplement: Capacity boundaries and manufacturing cycles of high-speed inference

Based on the Chinese collation of the Builders interview with Fractile founder Walter Goodwin on October 3. This round did not reread the full verbatim transcript or reproduce performance; chip roadmaps and cycles are guest statements and are not treated as conclusions of mass production or verification.

This page already discusses memory movement, full task completion time, and migration risks. Here a specific testing boundary is added:How large a model and task state can the high-speed path accommodate, and what happens when that limit is exceeded? Goodwin believes that relying solely on SRAM (high-speed but high-capacity-cost memory) makes it difficult to economically accommodate large models and long contexts, and he introduces a route exploring high-bandwidth DRAM. He also points out that some solutions still need to fall back to GPUs when encountering long contexts; one cannot infer from short-context demos that long tasks will be equally accelerated.

Application suggestions for this repository: keep model and quality requirements consistent, gradually increase context and task length, and record when execution platform switching is needed, how full task completion time changes, and whether data movement and costs increase. Accept “fast at peak” and “one’s own tasks always staying within the high-speed path” separately. Without threshold and fallback measurements, treat this as a selection question pending verification.

Faster design experiments do not automatically shorten physical delivery and recycling cycles. The guest described manufacturing after tape-out as still measured in months and investment payback in years; the specific oral figures of three to five months and three to five years should not be treated as universal industry constants. The value of increasing candidate architecture experiments lies in eliminating unsuitable designs earlier, not in promising mass production of new chips every few weeks. For reviewers, list the constraints of design verification, manufacturing and packaging, customer adaptation, and investment recovery separately, and check whether they remain usable when next-generation models change; the general hardware lock-in risk explanations elsewhere on this page are not repeated.

Addition: Capacity limits and manufacturing cycles in fast inference

This addition is based on the October 3 Builders Chinese account of an interview with Fractile founder Walter Goodwin. The complete transcript was not reread and performance was not reproduced in this review. Chip plans and timelines are the guest's statements, not evidence of volume production or independently verified results.

The existing article discusses memory movement, total task time and migration risks. An additional test asks: How large a model and task state can the fast execution path accommodate, and what happens beyond that limit? Goodwin argues that relying solely on SRAM—fast memory with relatively expensive capacity—makes large models and long contexts difficult to accommodate economically. He describes an exploration of high-bandwidth DRAM. He also says that some systems fall back to GPUs for long contexts. A short-context demonstration therefore does not establish equivalent acceleration for long tasks.

An editorial application is to hold the model and quality requirements constant while increasing context and task length. Record when execution must switch platforms, how total task time changes and whether data movement and costs increase. Evaluate peak speed separately from whether your workload stays on the fast path. Without measured thresholds and fallback behavior, treat this as an open selection question.

Faster design experiments do not automatically shorten physical delivery or investment-recovery cycles. The guest describes manufacturing after foundry submission in months and recovery of investment in years. His specific estimates of three to five months and three to five years are not universal industry constants. More architecture experiments can eliminate unsuitable designs earlier; they do not promise a newly manufactured chip every few weeks. In a review, list constraints for design validation, manufacturing and packaging, customer integration and investment recovery separately. Check whether the system remains useful as models change. This adds specific evaluation questions without repeating the article's general discussion of hardware lock-in.