thinking-in-limits — quality + safety report

---
name: thinking-in-limits
description: Stress-test any design, plan, or architecture by scaling a variable to extreme values (a million units, one user, zero cost, infinite scale) and asking what breaks, what stays expensive, and what the platonic-ideal version would look like. Use during architecture debates, scaling questions, capacity planning, performance budgeting, cost analysis, design exploration, "would this still be a problem at scale?", "is this overengineered?", "why is this so expensive?", "what's the theoretical floor?", or any moment someone says something is "impossible" or "too expensive" without quantifying the limit. Especially powerful when a team has anchored on incremental improvements over today's baseline instead of working backward from physical or theoretical limits. Trigger eagerly even when the user does not name Musk or the framework.
stacks_with:
  - magic-wand-number
  - idiot-index
  - cost-floor-thinking
---

# Thinking in Limits

> "Impossible is a strong word. It's just a strong word. I approach things from a physics standpoint, and the word impossible is more or less banned in physics."
> — Elon Musk, *The Book of Elon* (Chapter: Thinking in Limits)

## What this skill captures

Take any variable in the system — cost, latency, volume, headcount, lines of code, tunnel diameter, energy per unit, RPS — and imagine it at an extreme: a million units, one user, zero, infinity. Two questions follow:

1. **"Would this still be expensive/slow/painful at the limit?"** If yes, the problem isn't volume or scale — it's the design itself.
2. **"What does the platonic ideal of the perfect product look like?"** Now work backward from there, not forward from today's tools.

And when someone declares something impossible, replace the word with the question: **"What would it take?"**

## When to use this skill

- Architecture debates where someone says "this won't scale" or "this is fine at our scale"
- Cost/perf reviews where the team is incrementally optimizing the status quo
- Capacity planning, performance budgeting, infra sizing
- "Why is X so expensive?" — is it volume, or is the design wrong?
- Design exploration when the team is anchored on existing tools/parts/methods
- Anyone says "impossible," "can't be done," "that's just how it is"
- Roadmap critiques: incremental 10% gains vs. 10x rethinks

## The how-to

### Step 1. Name the variable and push it to the extreme

Pick the load-bearing number in the design. Push it down to 1 or 0, up to a million or infinity. Ask what changes.

> "Take a particular idea and imagine scaling it to a very large or very small number. How do things change?"
> — *The Book of Elon* (Thinking in Limits)

### Step 2. Distinguish "expensive because of volume" from "expensive because of design"

This is the canonical question. Run it on any cost, latency, or complexity claim.

> "Ask, 'If our volume was a million units per year, would it still be expensive?' If it's still expensive at a million units a year, then volume is not the reason why your part is expensive. Maybe something's wrong with the design."
> — *The Book of Elon*

If the answer is "still expensive at a million" — stop optimizing volume and redesign the part.

### Step 3. Identify the theoretical floor (raw materials + IP)

The asymptote of cost is the raw inputs plus licensed IP. Anything above that is solvable.

> "If you are really good at manufacturing and producing at a high volume, you can make anything for a cost that asymptotically approaches the raw material value of the components, plus any intellectual property you need to license."
> — *The Book of Elon*

For software: the asymptote is the irreducible computation + data. Above that floor is solvable engineering, not destiny.

### Step 4. Stack the order-of-magnitude levers (Boring Company pattern)

The Boring Company hit ~10x tunneling cost reduction by stacking three independent levers:
- **Shrink the diameter** — area scales quadratically, so 28ft → 12ft gave ~4–5x
- **Continuous tunneling + reinforcing** — eliminate the 50% idle time, gave 2x
- **Run the machine at its actual power/thermal limits** — another 2–5x

Generalize: find 2–3 independent multiplicative levers, push each to its physical limit, multiply.

### Step 5. Design from the platonic ideal, not from existing tools

> "People often start designing with the tools, parts, and methods they are familiar with... That will lead to a product that can be made with those tools and methods, but it is unlikely to be the perfect product."
> — *The Book of Elon*

> "Imagine the platonic ideal of the perfect product or technology. What is the perfect arrangement of atoms that would be the best possible product? Now try to figure out how to get the atoms in that shape."
> — *The Book of Elon*

Think in both directions: what's buildable today, AND what would the theoretically perfect version look like. The gap between them is your real roadmap.

### Step 6. Ban "impossible" — ask "what would it take?"

> "If my team says something is impossible, I try to open their minds to new potential solutions by asking, 'What would it take?'"
> — *The Book of Elon*

Force the cost of the impossible into concrete terms: what physics, what budget, what time. Often the answer is "expensive but not impossible" — which changes the conversation entirely.

## Common failure modes

- **Pushing the wrong variable.** Scaling RPS when the real limit is per-request memory. Pick the variable that actually binds.
- **Stopping at one lever.** Real 10x comes from stacking 2–3 independent multipliers, not finding one magic optimization.
- **Confusing "expensive at low volume" with "expensive by design."** The whole point of step 2 is to separate these. Don't skip it.
- **Treating the platonic ideal as a deliverable.** It's a direction, not a spec. The definition shifts as you learn.
- **Using "what would it take?" to bully a team into commitments.** It's a tool to expand the option space, not to extract promises.
- **Skipping the math.** Limits-thinking without numbers is just vibes. Put units on it.

## When NOT to use this skill

- The decision is reversible and cheap — just ship and measure.
- You're deep in execution of an already-validated design; limits-thinking is for the design phase, not the build phase.
- The bottleneck is organizational/political, not physical — different toolset.
- You don't yet understand the system well enough to know which variable is load-bearing. Learn first, then apply limits.

## Source

The Book of Elon by Eric Jorgenson (2026, Scribe Media). Chapter: "Thinking in Limits" (in "Think Like a Physicist"). Primary source pages 63–67.