ExpertsFMWhat will computer chips look like in 2045?
Dwarkesh Podcast · October 22, 2026
5 Selected Lessons:
heuristic · 2 reasoning_pattern · 1 framework · 1 priority · 1
Scale and fungibility matter more than winning on raw transistor metrics
Source
Dwarkesh Podcast — What will computer chips look like in 2045? (October 22, 2026) · at 52:06 ▸ · at 55:15 ▸ · at 57:33 ▸
When this applies
when competing in a capital-intensive, scale-driven industry where small technical deltas matter far less than production scale and execution reliability
The takeaway
In extreme fixed-cost, scale-driven businesses, prioritize scale and on-time, high-yield execution over chasing marginal technical superiority once you're roughly at parity with competitors.
Why it works
Because fixed costs dominate (~80% of cost structure), every incremental percentage point of utilization or yield translates into outsized revenue gains, meaning the real competitive battleground is scale and execution reliability, not marginal performance specs, once competitors are within a 'few percent' of parity on technology.
One level up
Rank competitive priorities by which lever actually moves the P&L the most in your specific cost structure, not by which lever is most visible or prestigious.
Where it stops holding
This stops working when the technical gap is a full generation or more (not just a few percent), in which case the technical gap itself becomes the dominant driver of output and functionality.
Detail
hierarchy:
- Being on time / predictable execution with very high yields to support large rapid ramps
- Being generally 'in the right ballpark' technically (within a few percent on density/performance/power)
- Catching up specifically on raw transistor density or performance metrics
rationale: Benchmarking one foundry ahead/behind only matters when the gap is a full generation or two; at a few percent difference it's 'splitting hairs,' and fixed-cost economics make utilization/yield improvements nonlinearly valuable, explaining industry consolidation down to three advanced-node foundries.
Hot Topics meeting risk-based prioritization
Source
Dwarkesh Podcast — What will computer chips look like in 2045? (October 22, 2026) · at 21:48 ▸ · at 26:38 ▸
When this applies
when allocating scarce engineering/experimental resources across many open problems under time pressure and incomplete data
The takeaway
Appoint someone with full visibility into the stakes to make risk-calibrated go/no-go calls under incomplete information, rather than waiting for complete data or letting individual contributors self-limit at the first obstacle.
Why it works
Waiting for complete data before deciding is itself a decision that costs time you don't have; a decision-maker who understands the business stakes can accept calculated risk faster than individual engineers who lack visibility into the broader urgency.
One level up
In time-critical, resource-constrained environments, the cost of decision latency often exceeds the cost of deciding with imperfect information.
Where it stops holding
This stops working when the stakes of being wrong are catastrophic and irreversible, in which case gathering more data before committing resources is worth the delay.
Detail
procedure:
- Engineers bring experiments/issues with partial data.
- The meeting owner (Kevin) decides how much risk to take on a given decision given incomplete data.
- Resources are aligned to the primary problems identified as most urgent.
- A tiered 'hot box' fast-track system expedites priority lots through the factory at the cost of overall factory efficiency.
benchmarks: {"data_completeness":"never complete — 'if you want to wait for a complete data set, you've waited too long'"}
rationale: Average engineers lack visibility into business-level urgency and will self-limit at the first blocked request; someone must own urgency and risk-taking explicitly.
In their words
One thing you learn in this industry is that you will never have a complete data set. If you want to wait for a complete data set, you've waited too long. It's already too late.
Sequence innovations by what's ready, not by ideal order
Source
Dwarkesh Podcast — What will computer chips look like in 2045? (October 22, 2026) · at 9:37 ▸
When this applies
when a team has a backlog of known future improvements and must decide which to tackle now versus defer
The takeaway
Don't solve the hardest version of a problem before you have to — extract value from incremental solutions first, and escalate to the harder solution only once incremental options are exhausted.
Why it works
Tackling the 'ultimate' or most ambitious solution too early means absorbing maximal integration risk before simpler wins have been banked; sequencing lets you extract performance from easier technologies first while deferring the hardest problems until they are truly necessary.
One level up
Match the aggressiveness of your technical bet to necessity, not to theoretical elegance — use the simplest sufficient solution at each point in time.
Where it stops holding
This stops working when competitive pressure forces you to leapfrog directly to the hardest solution because incremental options no longer provide enough differentiation.
Detail
approach: When several future technologies are known conceptually, use simpler/already-understood performance levers first (strained silicon, high-k metal gate, FinFETs) and only escalate to the most radical option (gate-all-around) once those are exhausted.
signals:
- other known levers still have headroom
- the 'ultimate' solution requires solving multiple hard material/tool problems simultaneously
rationale: You don't want to tackle the hardest, most integration-heavy idea before you have to, because other options can still drive performance with less risk.
In their words
Well, you don't want to tackle something before you have to. And so if you have these other things that can drive performance, would go and do that.
Limit innovation per node to protect schedule
Source
Dwarkesh Podcast — What will computer chips look like in 2045? (October 22, 2026) · at 0:00 ▸ · at 3:22 ▸
When this applies
when deciding how many new, unproven elements to bundle into any single product release or project milestone
The takeaway
Deliberately cap the number of untested changes introduced in a single release cycle so you can hit a predictable schedule, deferring extra innovation to the next cycle.
Why it works
Each added innovation multiplies integration complexity and interaction risk, so stacking many unproven changes at once makes the overall schedule unpredictable even if each piece individually could work.
One level up
Predictability is itself a deliverable that must be managed as deliberately as the innovation itself.
Where it stops holding
This stops working when competitors are moving so fast that deferring any given innovation costs you the market window, making schedule less important than being first with the full feature set.
Detail
rule: Don't do too much innovation in one node; figure out how much innovation you can include while still meeting the customer's required timeline.
threshold: Enough new elements to improve the process, but not so many that integration becomes unmanageable within the schedule.
rationale: The more innovation packed into one node, the more complex and unpredictable the schedule becomes, which ultimately harms the customer relationship more than slightly lower performance would.
In their words
I think what we've learned is that you don't want to do too much innovation in one node. Because the more innovation that you did, the more complex it becomes.
Shared tool-supply bottleneck caps industry-wide scaling regardless of capital
Source
Dwarkesh Podcast — What will computer chips look like in 2045? (October 22, 2026) · at 47:03 ▸ · at 49:39 ▸
When this applies
when a whole industry's growth depends on a small number of shared, slow-to-scale upstream suppliers, regardless of how much capital any single player deploys
The takeaway
When growth depends on a shared, concentrated supplier base with long lead times, capital alone cannot bypass the bottleneck; near-term output is capped at roughly the increment the whole supply chain (not just your own spending) can support.
Why it works
Once a process is locked into a specific tool, substitutability disappears, and because all industry players draw from the same limited supplier base, no amount of capital from one firm expands the total pool of available tools in the near term — capacity expansion is gated by the slowest-growing upstream link in the entire supply chain.
One level up
Identify whether your bottleneck is capital-constrained or supply-chain-constrained — these demand entirely different strategies (spend more vs. coordinate or wait on upstream suppliers).
Where it stops holding
This stops working when alternative tool suppliers, tool-sharing fungibility across nodes, or increased supplier output genuinely expand total available capacity faster than currently projected.
Detail
rule: Even with infinite CapEx, output from a given leading-edge process is capped at roughly 2x current levels given existing tool-supply constraints, not 10x.
threshold: ASML produces under 100 EUV tools/year, shared across Intel, TSMC, Samsung, and memory makers like SK Hynix; yield improvements beyond already-high yields are 'extremely hard' marginal gains.
rationale: Once you lock into a process flow, you're locked into a specific tool and supplier; the AI industry's historical 3x/year compute growth cannot continue unless the entire supply chain — equipment makers, their suppliers, their sub-suppliers — collectively ramps output.
In their words
Are there enough tools in the world so you get 10x the amount of wafers you're producing at the leading edge? Not 10x, but probably like 2x, yes.