# Critical Thinking & Fallacies

> A fallacy is an argument that feels convincing but is logically broken. Learning to name the common ones - and the habits of clear thinking that beat them - is the most practical self-defense there is against being misled.


---

# Critical Thinking & Fallacies

Everything in the Logic track so far has been about what makes reasoning *valid*. This guide is about
the opposite - and arguably more useful - skill: recognizing reasoning that is *broken* but doesn't feel
broken. Because that's the dangerous kind. A bad argument that sounds bad fools no one. A bad argument
that sounds great is how people get talked out of their savings, their vote, and their better judgment.

A **fallacy** is exactly that: an argument that's persuasive on the surface but logically unsound
underneath. They're not rare or exotic - they're the everyday machinery of advertising, politics, and
internet fights, and they work because they exploit feelings and mental shortcuts rather than logic.
This guide gives you a name for each common one, an example so you'll recognize it in the wild, and a
practical toolkit of clear-thinking habits. Naming a manipulation is the first step to being immune to
it - and a person who can't be easily fooled can't be easily steered.

## How to read this
- **Want the catalog?** [Phase 2](02-the-fallacies-youll-meet-most.md) is the field guide to the common
  fallacies.
- **Want it to stick?** Read in order - Phase 1 explains *why* fallacies work, Phase 3 is the toolkit
  that beats them.

## The phases
1. **[What a Fallacy Is (and Why They Work)](01-what-a-fallacy-is.md)** - broken-but-convincing
   reasoning, and the psychology it exploits.
2. **[The Fallacies You'll Meet Most](02-the-fallacies-youll-meet-most.md)** - a field guide: ad
   hominem, straw man, false dilemma, slippery slope, post hoc, and more.
3. **[Thinking Clearly: A Practical Toolkit](03-thinking-clearly-a-practical-toolkit.md)** - steelmanning,
   separating claim from evidence, cognitive biases, and verifying in the age of fluent AI.

> This caps the Logic foundations. It draws on validity from
> [What Logic Actually Is](/guides/what-logic-actually-is) and the conditional errors from
> [Implication & Conditionals](/guides/implication-and-conditionals).


---

# What a Fallacy Is (and Why They Work)

## Start where logic left off

In [What Logic Actually Is](/guides/what-logic-actually-is) you met two words that look similar
but do different jobs. An argument is **valid** when its conclusion follows from its premises -
if the premises are true, the conclusion has to be true. An argument is **sound** when it's valid
*and* the premises are actually true. Validity is about shape; soundness is shape plus facts.

Neither word covers a third thing that runs the world: how convincing an argument *feels*.
Feeling convincing isn't the same as being valid or true - they come apart constantly. A
**fallacy** lives in that gap: an argument that's invalid or unsound, broken on the inside, yet
still feels like it should work. A clumsy mistake isn't dangerous; you'll catch it. The dangerous
one slides past because it *feels* right - this guide is about learning to feel that "wait, that
doesn't actually follow" click before the conclusion settles in.

## Two ways an argument can break

Logicians sort fallacies into two families that fail for different reasons and need different
instincts to catch.

A **formal fallacy** is broken in its *structure* - the shape is bad, so the argument fails no
matter what you plug into it. You don't even need to know what the words mean. An **informal
fallacy** has a fine structure but cheats in its *content*: it leans on something irrelevant,
applies emotional pressure, plays with ambiguous words, or yanks your attention elsewhere.

Think of a bridge. A formal fallacy is a bridge with a flawed design - it collapses under any
load. An informal fallacy is a well-designed bridge built out of cardboard: the blueprint is
fine, the materials are a lie.

## Formal: when the shape itself is wrong

The cleanest example, worth memorizing, is **affirming the consequent**. Recall from
[Implication and Conditionals](/guides/implication-and-conditionals) that "if P then Q" only
promises one direction: P guarantees Q, and says nothing about going backward from Q to P. The
fallacy ignores that:

```text
If it rained, the street is wet.   (If P then Q)
The street is wet.                 (Q is true)
Therefore, it rained.              (Therefore P)
```

Feel how natural that sounds? But the street could be wet because a truck spilled water, or
someone washed their car, or a pipe burst. The conditional never promised that *only* rain wets
the street. That's the signature of a formal fallacy: the error is in the wiring. Swap rain and
wet streets for any other P and Q, and the same broken pattern produces the same broken
conclusion - which is why you can spot these without knowing a single fact about the topic.

## Informal: when the content cheats

Here the shape is usually fine - what fails is relevance, fairness, or clarity. A few flavors, to
show the range:

- **Irrelevance.** The argument brings in something that has nothing to do with whether the claim
  is true. "You can't trust her budget plan; she got divorced last year." The divorce has no
  bearing on the math.
- **Emotional pressure.** Instead of giving reasons, the argument makes you feel something - fear,
  pity, belonging - and lets the feeling stand in for the reason.
- **Ambiguity.** A word quietly changes meaning partway through. "Only man is rational; no woman
  is a man; therefore no woman is rational." "Man" flips from "human" to "male" mid-argument, and
  the whole thing rides on you not noticing.
- **Distraction.** The argument changes the subject to something easier to attack, then declares
  victory on the wrong question.

You'll meet each by name in [Phase 2](02-the-fallacies-youll-meet-most.md). For now, absorb the
pattern behind the patterns: an informal fallacy gives you something that *looks* like a reason
but isn't connected to the truth of the claim.

## Why fallacies work on us

Fallacies aren't rare glitches that fool careless people - they work on careful people too,
because they exploit how every human brain is built. Reasoning carefully is slow and effortful,
so your mind runs on shortcuts most of the time, and those shortcuts are usually *fine*. A
fallacy is just a shortcut pointed in the wrong direction. A few of the levers it pulls:

- **Heuristics.** Your brain prefers fast rules of thumb - "sounds right, moving on." A fallacy
  hands you something that *sounds* right and counts on you not slowing down.
- **Emotion.** A claim wrapped in fear, anger, or warmth feels more true than the same claim
  stated flatly. The feeling is real; the extra truth is imaginary.
- **Authority and the crowd.** "An expert said so" and "everyone believes it" are decent first
  guesses - but they're guesses, not proof, and a fallacy dresses a guess up as a verdict.
- **Effort avoidance.** Checking an argument is work, and a clean, confident conclusion lets you
  skip it. We take the offer.

None of these are stupidity - they're features that mostly serve you well. A fallacy is what
happens when someone, by accident or on purpose, aims one of those features at a false
conclusion. **Persuasiveness and truth are different properties, and the gap between them is the
entire vulnerability.** When you can *name* a manipulation, it stops working on you: the moment
you can say "that's affirming the consequent" or "that's an appeal to fear," the spell breaks and
you're examining instead of reacting. A person who can't be easily fooled can't be easily steered.

## For builders

The everyday fallacy in software is the **confident, fluent, wrong answer.** It shows up when a
teammate explains a bug's cause smoothly and completely, and is completely mistaken; it shows up
when documentation reads beautifully and describes behavior the code doesn't have; and it shows up
constantly in AI output, where a model produces a polished, authoritative answer that is false -
the polish is doing the persuading, not the correctness. Fluency reads as competence, but fluency
is a property of the wording, and correctness is a property of reality. The fix is boring and
reliable: run the code, check the source, reproduce the claim. Trust the test, not the tone.

## Recap

- A **fallacy** is an argument that's invalid or unsound but still feels convincing - and the
  convincing-but-broken kind is the one that actually fools people.
- **Formal fallacies** break in their structure (like affirming the consequent); the wiring is
  bad regardless of content.
- **Informal fallacies** keep a fine structure but cheat in their content - irrelevance,
  emotion, ambiguity, or distraction.
- They work because human brains run on shortcuts, respond to feeling, defer to authority and
  the crowd, and avoid effort. **Persuasive is not the same as valid, and neither is the same as
  true.**
- Naming a manipulation is the first step to being immune to it - and "fluent and confident"
  (from a person or an AI) is not evidence of "correct."

## Open-ended exercise

Read this argument carefully:

> "We should adopt framework X. The top three companies in our industry use it, and
> their engineering blogs all say it's transformed their deployment speed."

Name at least two different moves happening in this short paragraph. For each one,
say whether it's a good reason to adopt the framework, a fallacy, or something in
between - and what additional evidence would turn it from persuasion into a sound
argument.

Quick gut-check before you move on:

```quiz
[
  {
    "q": "Which best describes what a logical fallacy is?",
    "choices": [
      "Any argument you personally disagree with",
      "An argument that is invalid or unsound yet still feels convincing",
      "An argument whose conclusion is false",
      "An argument that uses big or technical words"
    ],
    "answer": 1,
    "explain": "A fallacy is about the reasoning being broken - invalid or unsound - while still feeling persuasive. The conclusion of a fallacious argument can even happen to be true; what's broken is how you got there."
  },
  {
    "q": "What's the difference between a formal and an informal fallacy?",
    "choices": [
      "Formal fallacies are written down; informal ones are spoken",
      "Formal fallacies are easy to spot; informal ones are impossible to spot",
      "A formal fallacy breaks the argument's structure; an informal one keeps the structure but cheats in its content",
      "There is no real difference; the terms are interchangeable"
    ],
    "answer": 2,
    "explain": "Formal fallacies fail in their shape, no matter the content (like affirming the consequent). Informal fallacies have an okay shape but lean on irrelevance, emotion, ambiguity, or distraction."
  },
  {
    "q": "A friend gives a smooth, confident explanation for why a bug happened, and it sounds completely right. What does this phase say you should conclude?",
    "choices": [
      "It's persuasive, so it's almost certainly correct",
      "Persuasiveness isn't evidence of truth - fluency can be wrong, so verify it",
      "Confident people are usually trying to manipulate you",
      "Only AI answers need checking; people's explanations don't"
    ],
    "answer": 1,
    "explain": "Persuasiveness and truth are different properties. A fluent, confident answer - from a person or an AI - can still be false, so the move is to check it (run the code, reproduce the claim), not trust the tone."
  }
]
```


---

# The Fallacies You'll Meet Most

Phase 1 covered what a fallacy is and why a broken argument can still feel convincing. Now the
field guide: the moves you'll run into again and again, in comment threads, meetings, headlines,
and your own head at 2 a.m. You don't need the Latin names memorized - the goal is recognition.
For each one: the name, a one-line definition, and a concrete example. Read for the pattern.

One thing up front: spotting a fallacy means the argument failed to *prove* its point, not that
the conclusion is false. A person can defend a true claim with a terrible argument. So "that's a
fallacy" is a reason to ask for a better argument, not a victory dance - see
[What Logic Actually Is](/guides/what-logic-actually-is) for that distinction in full.

## Attacks on the person, not the point

### Ad hominem
**Attacking the person instead of their argument.**

```text
"You think we should rewrite the billing service? You've only been
here three months. Sit down."
```

Notice what's missing: any response to whether the billing service should be rewritten. Maybe the
newcomer is wrong - but their tenure isn't the reason. Watch for this when an argument turns into
a referendum on the speaker's credentials, motives, or character.

### Straw man
**Distorting someone's position into a weaker one, then knocking that down.**

```text
Alex: "I think we should add more tests before the next release."
Sam:  "So you want us to stop shipping features forever? Great plan."
```

Alex never said "forever." Sam built a scarecrow and toppled it. The tell is a phrase like "so
what you're really saying is…" followed by something the person would never agree to. The straight
move is the opposite: restate their view in a form *they'd* accept, then respond to that.

## Forcing the shape of the choice

### False dilemma (false dichotomy)
**Presenting only two options when more exist.**

```text
"Either we ship tonight or the whole quarter is a failure."
```

Ship tonight, ship tomorrow, ship a smaller version, cut one feature - the real menu has more than
two items. False dilemmas thrive under pressure, because a fake either/or feels decisive. The
counter is one quiet question: "Are those really the only options?"

### Slippery slope
**Claiming one small step inevitably leads to disaster, with no justification for the chain.**

```text
"If we let one person work from home, soon nobody comes to the
office, and the company collapses."
```

Each arrow in that chain is a separate claim that needs support, and none is given. Slippery
slopes aren't always wrong - sometimes a step really does set off a chain - but the burden is on
whoever's claiming it to show *why* each link follows.

## Borrowed weight: authority, emotion, the crowd

### Appeal to authority
**"X said so" - when X is not a relevant authority, or is wrong.**

```text
"A famous physicist tweeted that this diet works, so it must."
```

Brilliant physics says nothing about nutrition. Even a relevant expert can be mistaken - authority
is a reason to take a claim seriously, not a substitute for the evidence behind it.

### Appeal to emotion
**Using fear, pity, or anger in place of reasons.**

```text
"Think of how stressed the team is. We can't possibly do a code
review on this one."
```

Stress is worth caring about, but it isn't an argument that this particular change is safe to
merge without review. When a claim makes you feel something strongly and gives you nothing to
check, slow down and ask: what's the actual reason here?

### Bandwagon
**"Everyone believes it, so it's true."**

```text
"Every startup is rewriting in this framework, so it must be the
right choice for us."
```

Popularity gets smuggled in as proof, but lots of people can be wrong together. What everyone's
doing tells you about trends - it doesn't tell you whether the thing is correct *for your
situation*.

## Conclusions that outrun the evidence

### Hasty generalization
**A sweeping conclusion drawn from too few cases.**

```text
"Two users complained about the new layout, so everybody hates it."
```

Two complaints are data, but they're not "everybody." Maybe the loudest two percent are unhappy
while the quiet majority is fine - ask whether the sample is big and representative enough to
carry the conclusion.

### Circular reasoning / begging the question
**The conclusion is assumed in the premises.**

```text
"This API is the most reliable because it never fails - and it
never fails because it's so reliable."
```

Strip it down and "reliable" is being proved by "reliable." Nothing outside the claim was ever
brought in - the tell is a vague feeling that you went around in a loop and ended where you
started.

### Post hoc / correlation isn't causation
**A happened, then B happened, therefore A caused B.** This is the big one - it costs people the most.

```text
"Ice cream sales and drowning both rise in summer, so ice cream
causes drowning."
```

Both are driven by a third thing: hot weather. The pattern is real; the causal story is invented.
Coincidence, reverse causation, or a hidden common cause are always on the table - before
accepting "A caused B," ask what *else* could produce the same pattern.

This has a formal cousin worth knowing: "If the deploy was bad, the site would be slow; the site
is slow, therefore the deploy was bad" is **affirming the consequent** - the site could be slow
for a dozen other reasons. [Implication & Conditionals](/guides/implication-and-conditionals)
walks through why that direction doesn't hold.

## A couple more you'll recognize

### Whataboutism
**Deflecting criticism by pointing at someone else's fault instead of answering.**

```text
"Our deploy process is a mess." - "Yeah? What about *their* deploy
process, it's way worse."
```

Their mess, even if real, says nothing about whether yours needs fixing. The original point still
stands, unanswered.

### No true Scotsman
**Redefining a term mid-argument to dodge a counterexample.**

```text
"A real engineer would never push to main." - "I push to main and
I'm an engineer." - "Well, no *real* engineer would."
```

The definition keeps shifting to protect the claim from any evidence against it - and a claim
that can never be wrong isn't telling you anything.

## The catalog at a glance

| Fallacy | The move | Example |
|---|---|---|
| Ad hominem | Attack the person, not the point | "You're too junior to have an opinion on this." |
| Straw man | Distort the view, then defeat the distortion | "So you want to ship nothing ever?" |
| False dilemma | Only two options when more exist | "Ship tonight or the quarter is ruined." |
| Slippery slope | One step → disaster, no chain shown | "Remote one day, company collapses." |
| Appeal to authority | "X said so" (irrelevant or wrong X) | "A physicist endorsed this diet." |
| Appeal to emotion | Feeling offered as a reason | "The team's stressed, so skip review." |
| Bandwagon | Popular, therefore true | "Everyone uses it, so it's right." |
| Hasty generalization | Big conclusion, tiny sample | "Two complaints, so everyone hates it." |
| Circular reasoning | Conclusion hidden in the premise | "Reliable because it never fails." |
| Post hoc | After, therefore because of | "Ice cream sales rise with drownings." |

## For builders

You'll meet post hoc more than any other fallacy in your work, wearing a specific costume:
**"it broke right after my deploy, so my deploy caused it."** Sometimes that's true; often it
isn't - a deploy is one event in a noisy system, and a dependency, a config flag, a traffic spike,
or a slow-burning bug crossing a threshold could all produce the same timing. "After" is a hint
about where to look, not a verdict. Before you write "deploy caused outage" in the incident
channel, check the evidence: timestamps, what *else* changed in that window, whether the symptom
matches your diff, whether reverting actually fixes it. Treat the deploy as a suspect to
investigate, not a confession to record - the same goes for "latency dropped after we added the
cache, so the cache fixed it." Correlation points your flashlight; it doesn't close the case.

## Practice: find the fallacy

Read each short argument and name the move. The goal is to feel the shape before you
reach for the label.

```text
1. "We shouldn't listen to her proposal - she's from a competing team."
2. "If we add this feature, users will ask for more, and soon we'll have no
   deadlines left. It's a slippery slope to chaos."
3. "Every engineer I know uses Vim, so it must be the best editor."
4. "The new deploy went out at 2pm and the site went down at 2:05pm. The deploy
   caused the outage."
5. "You want more tests? So you want us to miss every deadline from now on?"
```

<details>
<summary>Answers</summary>

1. **Ad hominem** - attacks the person's affiliation instead of engaging with the
   proposal.
2. **Slippery slope** - asserts an unstoppable cascade without showing why each link
   follows.
3. **Bandwagon** - popularity is offered as proof of quality.
4. **Post hoc** - temporal overlap is treated as causation without checking other
   explanations.
5. **Straw man** - distorts "more tests" into "miss every deadline" and defeats the
   distortion.

</details>

## Recap

- A fallacy means the argument failed, not that the conclusion is false - ask for a better argument, don't celebrate.
- **Ad hominem** and **straw man** dodge the real point: one attacks the person, the other attacks a distorted version of their view.
- **False dilemma** and **slippery slope** rig the shape of the choice - too few options, or an unjustified chain to disaster.
- **Appeal to authority/emotion** and **bandwagon** borrow weight from a source, a feeling, or the crowd instead of giving reasons.
- **Hasty generalization** stretches a tiny sample; **circular reasoning** hides the conclusion in its own premises.
- **Post hoc** is the one that'll bite you most: "after" doesn't mean "because." Always ask what else could explain the pattern.

Quick check before you move on:

```quiz
[
  {
    "q": "In a debate about a proposed budget cut, someone responds: 'She only supports the cut - she's never managed a team in her life.' What fallacy is this?",
    "choices": ["Straw man", "Ad hominem", "False dilemma", "Post hoc"],
    "answer": 1,
    "explain": "The reply ignores the argument for the budget cut and attacks the person's experience instead. Attacking the speaker rather than their reasoning is ad hominem."
  },
  {
    "q": "Your manager says: 'We either adopt this tool company-wide today or we fall hopelessly behind our competitors.' What's the flaw?",
    "choices": ["False dilemma - there are more than two options", "Appeal to emotion", "Circular reasoning", "Bandwagon"],
    "answer": 0,
    "explain": "Only two outcomes are offered - adopt now, or fall behind - when a pilot, partial rollout, or waiting are all real options. Presenting two choices as the whole menu is a false dilemma."
  },
  {
    "q": "A teammate notes: 'Sign-ups went up the same week we changed the logo, so the new logo is driving growth.' What's the problem?",
    "choices": ["The conclusion is assumed in the premise", "Two events overlapping in time doesn't prove one caused the other", "It attacks the logo designer", "It relies on what's popular"],
    "answer": 1,
    "explain": "Sign-ups rising after the logo change is correlation, not proof of causation. A marketing push, seasonality, or coincidence could explain it - that's the post hoc fallacy."
  }
]
```

Next we'll turn defense into offense: a practical toolkit for thinking clearly and pressure-testing arguments before they fool you.


---

# Thinking Clearly: A Practical Toolkit

You now know what an argument is, how implication works, and which fallacies show up most.
That's the diagnostic layer - you can spot a bad move when it happens. This phase is the
everyday layer: habits practiced quietly that make you harder to fool. Including by yourself.

Fallacies are mistakes other people make in front of you. Bias is the mistake you make on your
own, in the privacy of your own head, where nobody is around to call it out. A toolkit for clear
thinking has to cover both - so this isn't a list of clever rebuttals, it's a list of moves you
run *before* you've decided what you think.

## The toolkit

Each of these is a question or habit you can apply to any claim - yours, a friend's, a
headline's, a chatbot's. None require being smart, only being willing to slow down for ten
seconds.

**Steelman, don't strawman.** You met the strawman fallacy in Phase 2: attacking a weak,
distorted version of someone's position. The steelman is its opposite. Before you respond to an
argument, restate it in the strongest, most charitable form you can - strong enough that the
person who made it would say "yes, that's exactly what I mean." *Then* engage with that version.
This feels backwards, but if you can only beat the weak version, you haven't won anything - you've
dodged. Building the steelman often reveals the other side has a real point you'd missed.

**Separate claim from evidence from conclusion.** Most confusing arguments are confusing because
three things are mashed together:

- **The claim** - what's being asserted. ("This framework is faster.")
- **The evidence** - what's offered to support it. ("My app loaded quicker after I switched.")
- **The conclusion** - what you're being asked to do or believe. ("So you should switch too.")

Pulled apart, the gaps become visible. Is the evidence actually about the claim? (One app on one
machine isn't really about the framework being faster.) Does the conclusion follow even if the
claim is true? (Faster for them might not mean faster for you.) You can't evaluate a tangle - you
can evaluate three labeled pieces.

**Ask "what would change my mind?"** The single most useful question in the toolkit, asked about
your *own* beliefs. Pick something you believe. Now ask: what specific thing, if I saw it, would
make me give this up? If you can name it - "if a careful study showed the opposite" - your belief
is connected to reality; evidence could move it. If the real answer is *nothing would change my
mind*, then whatever you're holding, you didn't arrive at it by reasoning, and reasoning won't get
you out of it either. That's an attachment wearing a belief's clothes - there's nothing wrong with
having those, but it's worth knowing which is which.

> **Try it on a small thing.** Next time you're sure about something low-stakes - a tool, a
> technique, a take - pause and finish the sentence "I'd change my mind if ___." If the blank
> stays empty, that's information about the belief, not about the world.

**Check the source and the incentive.** A claim doesn't arrive from nowhere - someone is saying
it, and they usually have a reason. Two quick questions: *Where did this come from?* (A primary
source, an expert, a random post, a generated summary?) And *who benefits if I believe it?* That
second one isn't cynicism, it's context. A company's blog explaining why its own product is best
isn't necessarily lying, but it isn't a neutral referee either. Incentive doesn't make a claim
false - it tells you how hard to check before you trust it.

**Extraordinary claims need extraordinary evidence.** The bigger the claim, the more it should
take to convince you. "It rained in Seattle" needs almost nothing - it fits everything you already
know. "I have a sorting algorithm that beats the theoretical limit" needs a great deal, because it
would overturn things that are well established. This isn't closed-mindedness, it's calibration:
the strength of your belief should track the strength of the evidence. A surprising claim with
thin support gets a "maybe, show me more," not a yes and not a flat no.

**Correlation is not causation (recap).** Two things moving together doesn't mean one causes the
other. Ice cream sales and drowning both rise in summer - heat drives both; the ice cream is
innocent. Before accepting "X causes Y" because they happen together, ask whether something else
might cause both, or whether it's coincidence. (You'll meet this properly in the Mathematics
track.)

## We fool ourselves too: a few biases

Fallacies are about arguments; biases are about the wiring - predictable ways your own mind tilts
before you've consciously decided anything. You can't delete them, but you can learn to notice
their fingerprints.

- **Confirmation bias.** You notice, remember, and seek out evidence that agrees with what you
  already think, and quietly skip the rest - which is why "I did my research" can mean "I found
  the articles that told me I was right." The counter is "what would change my mind?" - it forces
  you to look for disagreeing evidence on purpose.
- **Anchoring.** The first number you hear sticks, and everything after is judged relative to it.
  A "was $200, now $80" tag makes $80 feel like a steal, because $200 anchored you - whether or
  not anything ever sold for $200. When a number frames a decision, ask where it came from.
- **Availability.** Whatever comes to mind easily feels more common or likely than it is. Vivid,
  recent, scary events are easy to recall, so they get overweighted - one dramatic story can feel
  heavier than a pile of dull statistics that describe reality better.

Naming these isn't about feeling clever - it's so that when you catch yourself doing one, you have
a word for it, and a word is a handle you can grab.

## The AI-era angle

Modern AI chatbots produce text that is fluent, confident, well-organized, and grammatically
clean - and it can be completely wrong. The technical term is *hallucination*: the system
generates a plausible-sounding answer with no basis in fact. It will cite a paper that doesn't
exist, describe an API method that was never built, or state a date with total confidence and
total inaccuracy - in exactly the same calm tone it uses when it's right.

The trap is a built-in human shortcut: we treat fluency as a signal of truth. That heuristic is
roughly okay for humans, who at least usually feel uncertain when they're guessing. It fails badly
for a system with no such feeling, fluent by design whether or not it's correct.

So the move is nothing new - it's the toolkit you already have. Treat an AI's claim like any other
unverified claim: check the source, ask what would change your mind, verify load-bearing facts
against something independent. This is applied skepticism, not cynicism - you're not assuming the
answer is wrong, and you're not refusing to use the tool. You're refusing to let *confident* stand
in for *checked*. Fluent isn't true. It never was; now the gap is easier to fall into.

## For builders

If you write code, you already do critical thinking for a living.

- **Code review is steelmanning.** Before you reject a change, understand what it's actually
  trying to do, in its strongest form. The best review comments engage with the real intent.
- **Debugging is "what would change my mind?"** A bug means reality disagrees with your belief
  about the code. Name the belief - "this function gets called with a valid ID" - and hunt for the
  case that breaks it. You're trying to falsify your assumption; the counterexample *is* the bug.
- **Assume nothing, verify.** "It works on my machine" is a claim with one data point. "This
  config is loaded in production" is a claim until you've checked the running system.
- **An AI suggestion is a claim.** A confident, fluent code snippet is not the same as a correct
  one. Read it, understand it, test it - treat shipping it unverified the way you'd treat merging
  a stranger's PR you never read.

## Closing the toolkit - and the foundations

Phase 1 gave you the anatomy of an argument. Phase 2 gave you the catalog of bad moves so you can
name them on sight. This phase gave you the proactive habits: steelman the other side, separate
claim from evidence from conclusion, ask what would change your mind, check the source and the
incentive, demand evidence sized to the claim, and never mistake correlation for cause - while
staying clear-eyed that your own biases are working the whole time.

That toolkit zooms all the way out. The Logic foundations - [what logic actually
is](/guides/what-logic-actually-is), [implication and conditionals](/guides/implication-and-conditionals),
and [predicate logic and quantifiers](/guides/predicate-logic-and-quantifiers), now capped by
critical thinking - were never really about syllogisms. They were about one skill: holding a
thought up to the light and checking whether it holds. That's the foundation; everything else
builds on it.

From here, clear thinking turns numerical the moment real stakes appear: how big is the effect,
how likely is it, how much does the evidence actually move the needle? "Extraordinary claims need
extraordinary evidence" and "correlation isn't causation" are doorways into probability and
statistics - the Mathematics track, and the natural continuation of what you started here. You've
learned to think clearly in words. Next you learn to think clearly in quantities.

## Open-ended exercise

Read this product claim: "Our new feature increased user engagement by 40%." Apply the
toolkit from this phase: (1) steelman the claim - what's the strongest version of it?
(2) separate the claim from the evidence - what would you need to see to verify it?
(3) name at least one cognitive bias that could make the claim feel true before you've
checked it. The goal is to turn a persuasive sentence into a checklist you can act on.

Here's a quick check on the habits worth keeping.

```quiz
[
  {
    "q": "What does it mean to 'steelman' an argument?",
    "choices": [
      "Restate the opposing position in its strongest, most charitable form before engaging with it",
      "Attack the weakest version of the opposing position so it's easier to beat",
      "Refuse to engage with arguments you disagree with",
      "Repeat your own argument more forcefully until the other person gives up"
    ],
    "answer": 0,
    "explain": "Steelmanning is the opposite of strawmanning. You engage the strongest version of the other side - partly to win fairly, partly because building it often reveals a real point you'd missed."
  },
  {
    "q": "Why is asking 'what would change my mind?' such a useful habit?",
    "choices": [
      "It guarantees you'll never be wrong about anything",
      "It's a polite way to end an argument quickly",
      "If nothing could change your mind, the belief isn't actually held for reasons evidence can reach",
      "It lets you avoid having to check any sources"
    ],
    "answer": 2,
    "explain": "If you can name what would change your mind, your belief is connected to reality. If the real answer is 'nothing,' you didn't arrive at it by reasoning - and it's worth knowing the difference."
  },
  {
    "q": "Which of these best describes confirmation bias?",
    "choices": [
      "Letting the first number you hear set the scale for everything after",
      "Treating fluent, confident text as if it must be true",
      "Overweighting vivid events because they come to mind easily",
      "Noticing and seeking evidence that agrees with you, while skipping evidence that disagrees"
    ],
    "answer": 3,
    "explain": "Confirmation bias is the tilt toward agreeing evidence - which is why 'I did my research' can quietly mean 'I found what told me I was right.' (The other options describe anchoring, the fluency trap, and availability.)"
  }
]
```