First-principles thinking is "decompose until indivisible" — strip an argument down to axioms that can't be derived from anything else, then rebuild reasoning from those axioms. Aristotle called it "the first basis for knowing a thing"; physics calls it axiomatization. Its opposite is analogical thinking — solving new problems with variants of existing solutions. Analogy is fast but only produces tweaks; first principles is slow but can leave the prevailing paradigm entirely.
The non-trivial insight: the most common misuse is fake decomposition — people believe they've hit the floor when in fact they've stopped at "the layer they're already familiar with." "EVs are expensive" stops at "batteries are expensive." Musk kept going: "batteries are nickel, cobalt, aluminum, carbon — buy raw materials at LME prices and the cost is ~$80/kWh." The first stops at the product layer; the second hits the physics layer. The test: does your reasoning cross a discipline boundary? If not, you probably stopped early.
Practice: ① For every assumption, repeatedly ask "what's the basis for this? what's the basis for that basis?" until you hit a physical law, a mathematical axiom, or hard fact; ② Smell-test for analogical thinking — phrases like "industry convention," "everybody does it this way," "historically..." are warning flags; ③ In the AI era, this is a role allocation between you and the LLM — LLMs are brilliant at analogical interpolation; humans are uniquely useful at slicing across disciplines down to axioms. That's the scarcest leverage in human-AI collaboration.
SpaceX: the rocket industry took $65M as the floor launch cost because "that's the industry average." Musk decomposed to raw materials — aluminum, titanium, copper, carbon fiber at market price totaled ~2% of launch cost. The remaining 98% was manufacturing, organization, and conservative convention — all rebuildable. Falcon 9 brought the cost to ~$60M, far lower amortized when reused. The paradigm shift came from one move: refusing to accept "industry price" as a premise.
BigCat is evaluating "should I build my own LLM inference cluster?" Analogical thinking says "the big players use cloud APIs — just follow them." First principles: decompose to token economics — monthly calls × unit price = $X; in-house hardware + power + ops = $Y. One more layer: 90% of his workflow is repeated templates; with prompt caching, real token count is ~1/5. The conclusion may flip: in-house isn't necessarily cheaper, but caching saves 70%. The real leverage point isn't "cloud vs in-house" — it's the deeper layer of token structure.
I'm evaluating [decision/product/tech choice]. Apply first-principles decomposition: (1) list every assumption my current judgment quietly takes for granted, (2) for each assumption, recursively ask "what makes this true?" until you hit physical laws, mathematical facts, or irreducible axioms, (3) rebuild the reasoning from those axioms and contrast it with my original conclusion. Flag exactly which layer I likely substituted analogical thinking for actual decomposition.
First-order thinking asks "what happens next?" Second-order thinking asks "and then what?" Howard Marks turned this into an investing canon: first-order says "buy good companies"; second-order asks "how good is this company, and how much is already priced in? where do I know more than the market?" The first is reflex; the second is reflexive game-play. In any game-theoretic system, first-order alone never beats average — everyone sees the same obvious facts.
The non-trivial insight: the lever isn't "think further into the future" — it's see the reflexivity. When your decision changes the system's state and other players' behavior, linear projection breaks. "Stricter speed limits → fewer accidents" is first-order. Second-order: "how do drivers react? Will trust in the system make them drive faster?" Add a layer — how do insurers and police reallocate? In complex adaptive systems, every intervention is "eaten back" by participants' expectations and feedback.
Practice: ① Train the "and then what?" chain — force yourself to at least the third layer; ② Reverse brainstorming — for every intervention, ask "how will the other side / the system adapt?"; ③ Distinguish two decision classes — reversible and low-impact decisions can survive on first-order (speed of comparison wins); irreversible, systemic decisions must be second-order (deliberation wins). Most failures aren't from lack of thinking; they're from stopping at layer one.
1990s: a U.S. state put a bounty on dead cobras to reduce the snake problem. First-order expectation: fewer snakes. Result: people started farming cobras for the bounty; when the bounty was canceled, they released their stock — the snake population doubled. This is the famous "Cobra Effect." Any incentive imposed on a system triggers participants' second-order response; policymakers who ignore that layer often create a worse problem than the one they started with.
BigCat deploys an AI coding tool, expecting per-engineer output to double (first-order). Second-order: each engineer ships more PRs; code-review queues clog; reviewers rubber-stamp; bug rate rises; juniors lose the "read code to learn" loop AI now does for them, and their growth curve flattens. Third-order: in six months, senior attrition rises and organizational capacity hollows out. The conclusion isn't "don't use AI" — it's that adopting AI requires a parallel redesign of review and mentorship paths. Most teams skip this second-order design.
I'm about to act on [policy/product/career decision]. Run a second/third-order analysis: (1) state the obvious first-order outcome that everyone can see, (2) project how key actors will rationally adapt, game, or hedge — yielding second-order reactions, (3) push to third-order: which "sensible first-order" conclusions get fully reversed by the second-order response, (4) flag the second-order safeguards I must build in upfront to avoid a cobra-effect outcome.
Inversion isn't "argue the opposite side" — it's solve the same problem from the back. To find "how to succeed," first list "how to guarantee failure." To find "how to live long and healthy," first study "what behaviors most reliably kill." Jacobi's formula: "Invert, always invert." Munger ranks it among the most underused tools in the human cognitive toolkit. Its power is an asymmetry: success paths are countless and judgment-heavy; failure paths are few, obvious, and avoidable. Avoiding them is more tractable than chasing success.
The non-trivial insight: inversion's real job isn't "find the answer" — it's bypass cognitive blind spots. Pursuing success directly, we see what we want to see. Listing failure modes, we see the cold causal chain. Neuroscience reading: the loss-aversion circuitry (amygdala-related) is sharper than the reward circuitry — inversion recruits the brain's more precise subsystem. Buddhism's "contemplation of death" exercise is structurally identical — by rehearsing the endpoint, you recalibrate current choices in reverse.
Practice: ① Before any goal, draft the "how to completely fail at this" list as a pre-decision pothole map; ② For every conviction, "prepare the funeral" — assume it failed, then autopsy plausible causes; ③ In team decisions, install a red team whose explicit job is to argue "why this project will fail" — countering groupthink and confirmation bias. Inversion won't give you creativity, but it removes most of the paths on which you'd be killed.
Munger's Harvard commencement speech on "How to Guarantee a Miserable Life": ① be unreliable; ② learn only from your own experience; ③ stay down when you fall; ④ practice envy, resentment, and self-pity. Invert that list and you have a guide to a good life — far more useful than positive advice. "Happiness" is too abstract; specific failure behaviors are identifiable. That's why medicine has contraindications first, finance has unacceptable-risk lists first, and software has "never do this in production" rules first.
BigCat wants to become an AI-powered "super-individual." Forward question: how? The answer scatters — prompts, subscriptions, case studies. Inverted: how do I guarantee failure? ① Use AI as a universal tool, dabbling in every domain, deep in none beyond AI's reach; ② Get addicted to tool shopping — perpetually benchmarking new models instead of producing; ③ Use AI to replace thinking rather than accelerate it, outsourcing key judgment to statistical patterns; ④ Don't accumulate private data/experience — public capability has no moat. Turn those four into a weekly self-check — far more actionable than chasing a "best practices" list.
My goal is [career pivot / project objective / life decision]. Use inversion: (1) Don't tell me how to succeed — list 5-7 concrete behaviors guaranteed to make me fail at this, (2) rank those failure modes by "which one I'm most prone to right now," (3) turn them into a weekly self-audit checklist, (4) point out which steps in my current plan are quietly executing items from the failure list without me realizing it.
Occam's Razor: "entities should not be multiplied beyond necessity" — when explanations have equal predictive power, prefer the one with fewer assumptions. It does not say "simpler is always true"; it says "between two equally good explanations, the more complex one carries more parts that can be wrong." Information-theoretically, a shorter hypothesis has a smaller description length and a higher prior (the core of Solomonoff induction); engineering-wise, every extra assumption is an extra failure point.
The non-trivial insight: the most common abuse is oversimplification — conflating "simple" with "fewer assumptions." Einstein's sharper gloss: "as simple as possible, but not simpler." When the phenomenon itself is complex, jamming it into a simple theory is razor overshoot. Quantum mechanics isn't simple, but "wave-particle duality" is the current razor boundary — adding "superstrings" or "multiverse" without new evidence violates the principle. The criterion isn't "sounds simple" — it's assumption count.
Practice: ① Debug in "fewest-assumption first" order — config error > code bug > compiler bug > hardware fault; ② Stress-test conspiracy theories with "how many people would have to stay silent and coordinated? does the coordination cost exceed the direct motive?"; ③ In product design, defend against feature creep — every new feature must answer "what's the evidence of necessity?" or get razored. The razor is fundamentally a Bayesian prior, not an aesthetic preference.
Medical heuristic: "When you hear hoofbeats, think horses, not zebras." Young patient with headache and fatigue: first consider sleep loss, dehydration, screen-strain; next thyroid or anemia; only last, tumor. Jumping straight to "tumor" is statistically wrong — not because tumors don't exist, but because given identical symptoms, the prior probability of "sleep deficit" is 100× higher. The razor is just the colloquial form of a Bayesian prior.
BigCat's AI workflow suddenly slowed. Complex story: did the new model version regress? Did the API rate-limit silently drop? Is the ISP throttling? Apply the razor — first check local CPU/memory/network (most common); then the most recent config change (the variable you introduced); upstream changes last. 90% of "weird bugs" are something you changed and forgot. Same with a child's recent grade drop: check sleep, screen time, recent interpersonal stress first, before reaching for "learning method" theories. The razor reminds you: common causes vastly outnumber exotic ones.
I'm analyzing this issue/anomaly: [scenario]. Apply Occam's Razor to rebuild the diagnostic order: (1) list 4-6 plausible explanations, ranked from fewest to most assumptions, (2) for each, count the "unsupported premises" it silently requires, (3) propose a Bayesian-style test sequence starting from the lowest-assumption hypothesis, (4) flag any reasoning in my current hypothesis where I'm reaching for an exotic explanation just because it "sounds smarter," when a mundane one would do.