Designing the Physical World with AI

In one sentence

The core thesis is that accelerating the physical world requires moving beyond "better plans" toward an "everything is code" paradigm, where engineering is reframed into ontological models that allow for parametric iteration and automated manufacturing.

Why read this (and who it's for)

This material addresses the fundamental friction between the speed of software ("bits") and the sluggishness of construction and hardware ("atoms"). It is for founders, engineers, and infrastructure builders who want to move past fragmented workflows and "snowflake" projects. After reading this, you will be able to identify where "tacit knowledge" can be codified into models and how to structure a business around vertical integration rather than just selling software tools.

The big idea

The disparity between bits and atoms is widening: while software has achieved a near-zero idea-to-output loop, physical construction remains slow because of fragmented workflows, fixed incentives, and systems that resist change. Currently, most projects are "snowflakes"—unique, output-focused efforts that lack robust underlying models, making it impossible to iterate quickly without starting over.

To solve this, we must treat the physical world as code. By embodying relationships into an ontological model (a simple representation of a complex system), engineers gain a parametric relationship to the design. This means that six months into a project, changing a design becomes a matter of updating a variable rather than restarting the work. We must move from "deliverables-focused" engineering to "model-led" engineering, where AI is used to explore tens of thousands of permutations to optimize for CapEx and Total Cost of Ownership (TCO).

Key ideas

Everything is Code

What it is — The belief that if a physical system can be represented in a language models already understand, engineering becomes significantly easier. Why it matters — It shifts the bottleneck from human manual labor to model accuracy; once a system is "coded," AI can iterate on permutations at scale. In the book — The author argues that we should reframe circuit board design using "code" (high training data availability) by building a compiler that makes designing feel like writing a Python program.

Ontological Models vs. Snowflake Projects

What it is — A move away from "snowflake" projects (unique, manual outputs) toward ontological models (simple representations of complex systems). Why it matters — It allows for parametric relationships; you can change a variable in a model to update a design without rebuilding the entire framework. In the book — The author notes that current industry problems stem from everything being a "snowflake," which slows the rate of building because there is no underlying model to reference.

Simulation as Training-Time Tool

What it is — Using simulation not just as a "calculator" for final verification, but as a tool during the training phase to ground physics. Why it matters — It allows the model to develop "taste" (intuition) regarding fluid dynamics, mass flow rates, and other physical constraints before it ever reaches inference-time. In the book — The author argues that while simulation is not fast enough for real-time usage, it is essential for grounding physics during training.

Constrained Design for Manufacturing (DFM)

What it is — Using AI/LLMs to painstakingly check and change design artifacts until they are "manufacturable." Why it matters — It solves the "Ivory Tower" problem where designers in one location don't feel the manufacturing pain of a factory elsewhere. In the book — The author points out that Chinese engineers often design boards to be "easy to make" (e.g., avoiding double passes) because of their visceral connection to the manufacturer.

Codifying Tacit Knowledge

What it is — Converting the lived experience and skills of aging experts (electricians, civil engineers) into codified models. Why it matters — Skilled labor is retiring quickly; we cannot rely on "tacit knowledge" being passed down manually in a shrinking labor market. In the book — The author highlights how Microsoft reportedly employed one-third of the electricians in Georgia to build a single data center, illustrating the desperate need for automated expertise.

Vertical Integration as Value Proposition

What it is — Owning enough of the process to provide a clean interface to the industry rather than just selling software tools. Why it matters — Engineering is a small percentage of total cost; the real value lies in compressing the schedule (e.g., reducing build time by 3–6 months) to improve Internal Rate of Return (IRR). In the book — "You want to build the infrastructure for the models to be able to go and do these things... You don't want to convince people to buy your software. You want to convince people to buy the end product."

Frameworks & tools

The Code-First Hardware Approach

1. Identify Data Gaps: Recognize where lack of digitized data prevents training (e.g., circuit boards).
2. Reframe as Code: Use a compiler to translate hardware requirements into a language models understand (like Python).
3. Build Validated Blocks: Create a library of validated blocks.
4. Bootstrap Data: Use these validated blocks as the training data for the next generation of models.

Parametric Design Iteration

1. Build Ontological Model: Define the relationships of the system (e.g., how mass flow relates to enclosure size).
2. Define Variables: Identify which parts of the design are variable (cost, material, dimensions).
3. Iterate via Update: When a change is needed 6 months into a project, update the variable in the model rather than redesignning from scratch.

The "Rails" Strategy

1. Offer Incentives: Provide incentives for manufacturing in the US at costs competitive with Asia.
2. Collect Volume: Use this volume to generate the data required to "skyrocket" model accuracy.
3. Become Infrastructure: Become the "rails" that others design on for free, ensuring you own the primary data loop.

Memorable examples & stories

The Georgia Electrician Shortage: Microsoft reportedly employed one-third of the electricians in the state of Georgia to build a single big data center. Lesson: The labor gap is so severe that we must codify "tacit knowledge" into models.

Chinese Manufacturing Muscle: Chinese engineers often design boards to be "easy to make" (e.g., avoiding double passes on SMT lines) because they have a visceral connection between the designer and manufacturer. Lesson: AI must bridge this gap by checking designs until they are "manufacturable."

The CubeSat Empowerment: The goal is to enable American engineers and teenagers to build physical things (like putting a CubeSat in orbit) with the ease of spinning up boards for manufacture the next day. Lesson: Software-like ease of use is the ultimate goal for physical builds.

The 50-Year Decline: U.S. construction metrics (labor productivity and adjusted capex) have been declining for 50 years. Lesson: We are losing the "muscle" of knowing how to build large ambitious projects; AI must provide a stepwise improvement to reverse this trend.

Key quotes

"Everything is code." Why it matters: This is the fundamental shift required to move from manual engineering to automated design.

"What happens when intelligence gets cheap, but the physical world stays slow?" Why it matters: This identifies the core problem the book seeks to solve: closing the gap between bits and atoms.

"The question is whether that translates into faster builds or just better plans." Why it matters: It warns against the trap of thinking AI only improves the blueprint without actually accelerating the construction.

"Transform every software engineer into an electrical engineer." Why it matters: This describes the goal of making hardware design as accessible and structured as writing code.

"You want to build the infrastructure for the models to be able to go and do these things... You don't want to convince people to buy your software. You want to convince people to buy the end product." Why it matters: This defines the winning business strategy: vertical integration over tool sales.

How to apply it

This week

• Identify one "snowflake" process in your current workflow (a task that is manual and unique every time).
• Audit the "tacit knowledge" required for that process—what does a veteran know that isn't written down?
• Look for one area where you can reframe a physical requirement as a "code" problem.

Ongoing

• Shift from "deliverables-focused" to "model-led." Every new project should start with an ontological model of relationships before any specific output is designed.
• Prioritize "manufacturability" in the design phase; use AI to check for manufacturing friction early and often.
• Focus on vertical integration: look for ways to own the end product/infrastructure rather than just the software tool.

Common pitfalls

• The "Better Plans" Trap: Assuming that better AI designs will automatically lead to faster builds. The material argues that without changing incentive structures and manufacturing workflows, you only get a better plan, not a faster build.
• Ignoring Incentive Structures: Construction is stage-gated for risk removal to secure funding. If your innovation doesn't provide an "upside" within those fixed budgets/incentives, adoption will be stifled.
• The 90% Gap: Thinking that the last 10% of automation (getting from 90% to 100%) is just a matter of more data; it may require a fundamental ML breakthrough or a better understanding of well-structured building blocks for Monte Carlo tree search.

Connects to

• Scaling Laws: The idea that the efficiency of mass manufacturing a single design outweighs nuanced custom efficiency.
• Reinforcement Learning / Monte Carlo Tree Search: Used as the structural way to "tickle" existing building blocks to reach 100% automation.
• Vertical Integration: A classic business strategy applied here to the physical world to capture the value of compressed schedules.

If you remember only three things

• Everything is Code: Physical systems must be reframed as ontological models to allow for parametric iteration.
• Simulation at Training-Time: Use simulation to ground physics and give AI "taste," not just as a final calculator.
• Sell the End Product: Value lies in compressing the schedule (reducing build time) to improve IRR, not in selling software tools.

Internalize it

• Reflection questions

  • Where in my current projects is the "muscle of knowing how to build" being lost because we don't have a codified model?
  • If I reframed my most complex physical design as "code," what would be the primary compiler or library of validated blocks?
  • Am I currently building "snowflakes"? How would my project change if I were forced to update it via variables instead of redesignning it?

• Flashcards Q: What is the difference between a "snowflake" project and an ontological model? A: A snowflake is a unique, output-focused manual effort; an ontological model is a representation of relationships that allows for parametric iteration.

Q: Why should simulation be used at "training time"? A: To ground physics and allow the model to develop "taste" (intuition) before inference.

Q: What is the core business strategy for winning in physical AI? A: Vertical integration—selling the end product/infrastructure rather than just software tools.

Q: What does "Everything is Code" mean for hardware design? A: Reframing circuit board design as a code problem using a compiler and validated blocks to allow SWEs to act like electrical engineers.

Q: Why is "tacit knowledge" a problem for the physical world? A: Because skilled labor is aging/retiring quickly, and that knowledge is hard to derive from first principles without codifying it into models.

Q: What is the primary value proposition of automating construction design? A: Compressing the schedule (e.g., 3–6 months) to improve the Internal Rate of Return (IRR).

Fidelity note

Confidence: High. This summary is strictly grounded in the provided notes. I am certain about the distinction between "bits vs atoms," the "Everything is Code" philosophy, and the specific strategies for Macro (Construction) and Micro (Electronics) scales. The material does not provide specific technical details on the "diffusion" architecture other than stating it is bullish on it for physics-based problems.