| name | thinking-dual-process |
| description | Use when an answer arrives too fast on a high-stakes or unfamiliar task. Force one explicit verification pass before committing instead of shipping the first plausible answer. |
Dual-Process Thinking
Overview
A language model produces a first answer by fast pattern-completion: the most statistically likely continuation given the prompt. That fast path is excellent for routine, well-trodden tasks and dangerous for high-stakes or unfamiliar ones, where the most plausible-sounding answer and the correct answer diverge. This skill is the deliberate counterweight: when an answer arrives too easily on a task that matters, force one explicit verification pass before committing.
The framing comes from Kahneman's fast/slow distinction, but the operative idea here is mechanical, not psychological: fast generation (the immediate completion) vs. a deliberate check (re-deriving, testing, or sourcing the answer).
Core Principle: Fluency is not correctness. When the answer came easily and the cost of being wrong is high, that combination is the trigger to slow down and verify — not a signal you're done.
Trigger Card
When an answer arrives instantly on a high-stakes or unfamiliar task, run one verification pass before committing:
- Notice: Did the answer form immediately, with no intermediate steps? High confidence but nothing checked?
- Check triggers: Is the task high-stakes/irreversible OR the domain unfamiliar? If neither, ship the fast answer.
- Verify: Re-state the claim → re-derive or test it a second, independent way → check against ground truth (code, docs, data) → reconcile any disagreement → commit.
The trigger is easy answer + real cost of error. If the answer was hard-won, you already deliberated. If the task is trivial and reversible, don't over-verify.
When to Use
- The task is high-stakes or irreversible (data migration, security, deletion, public commitment) and the answer felt obvious.
- The domain is unfamiliar or the task is novel — no well-worn pattern to rely on.
- The answer requires statistical or quantitative reasoning (where fast completion is reliably miscalibrated).
- You're reviewing work and it "looks fine" on a quick pass.
- A claim is plausible and convenient but you haven't actually checked it against the code/docs/data.
Decision flow:
Answer arrived fast? → High stakes OR unfamiliar? → yes → RUN A VERIFICATION PASS
↘ no → fast answer is fine, ship it
↘ no (had to work for it) → you already deliberated
When NOT to Use
- Routine, reversible, low-stakes tasks. Renaming a variable, a trivial edit, an obvious lookup — re-verifying everything is wasted budget and invites analysis paralysis.
- You already worked through it deliberately. If the answer was hard-won, a second pass is redundant; the trigger is easy answer + high stakes, not every answer.
- The verification pass would cost more than the error it prevents. Match the depth of the check to the cost of being wrong.
- You can just run it. If a test or a quick execution would settle it, do that instead of more reasoning.
The Two Modes
Fast generation (the default)
| Characteristic | Description |
|---|
| Speed | Immediate — the answer is just the first plausible completion |
| Basis | Pattern-matching to similar prompts seen in training |
| Confidence | Often high regardless of correctness — fluency masquerades as certainty |
Fast generation is reliable for:
- Well-trodden, conventional tasks with a clear standard answer
- Reformatting, summarizing, and other low-ambiguity transforms
- Recall of common, stable facts
- Routine code in a familiar language/framework
Fast generation is unreliable for:
- Arithmetic and multi-step quantitative reasoning
- Statistical reasoning and base-rate problems
- Novel or unfamiliar problems with no template to match
- Anything where a plausible-sounding answer can be subtly wrong (APIs, version-specific behavior, edge cases)
Deliberate verification (the override)
| Characteristic | Description |
|---|
| Speed | Slower — re-derive, test, or source the answer |
| Basis | Explicit steps, checks against ground truth |
| Confidence | Earned — tied to what was actually verified |
Deliberate verification is worth its cost when:
- Re-deriving a result a second, independent way
- Running or tracing the code instead of predicting its output
- Checking a claim against the actual file/doc/data rather than memory
- Enumerating edge cases the fast answer glossed over
Its only failure mode is over-use: applying it to trivial, reversible work where the check costs more than the error.
The Process
Step 1: Notice the fast answer
A fast answer announces itself: it's the response forming immediately, before any explicit work. That's normal and usually fine. The thing to notice is how you got it.
- Answer formed immediately, no intermediate steps
- It "obviously" follows from the prompt
- Confidence is high but nothing was actually checked
Example: "Does this regex match leading zeros?"
A confident yes/no forms instantly → fast generation.
Before answering: is this high-stakes or am I sure? If either is shaky, test the regex.
Step 2: Check the two trigger conditions
A verification pass is warranted only when BOTH are true enough:
The answer came easily (Step 1), AND the cost of being wrong is real:
- Stakes are high or the action is irreversible
- The domain is unfamiliar or the problem novel
- It requires arithmetic / statistical reasoning
- A wrong-but-plausible answer would slip through review
If the answer was hard-won, you already deliberated — stop. If stakes are trivial and reversible, the fast answer is fine — stop.
Step 3: Run the verification pass
When both conditions hold, do exactly one disciplined check:
1. RE-STATE - Write the claim/answer explicitly
2. RE-DERIVE - Reach it a second, independent way (or test/run it)
3. CHECK - Against ground truth: the code, the docs, the data, the math
4. RECONCILE - If the two paths disagree, the fast answer was wrong — find out why
5. COMMIT - Ship the verified answer
Watch for these fast-answer red flags specifically:
- It's the most common/canonical answer but the prompt has an unusual twist
- It depends on a version, config, or edge case you didn't actually confirm
- It's the convenient answer that lets you stop early
- It restates the user's assumption back to them without testing it
Step 4: Match effort to stakes
| Situation | Process |
|---|
| Fast answer + low stakes | Ship it; don't manufacture doubt |
| Fast answer + high stakes | Run the verification pass above |
| Already deliberated | Done — no second pass needed |
Fast-Generation Failure Modes
Question substitution
Fast generation answers an easier nearby question instead of the one asked:
Asked: "Is this O(n) or O(n log n)?"
Answered: "Does this look like efficient code?" (vibe, not analysis)
Asked: "Does this migration preserve all rows?"
Answered: "Does this migration look correct?" (plausibility, not verification)
The fix is to re-state the exact question (Step 3) so the substitution becomes visible.
Pattern-matched errors
| Pattern | What it does | When it fails |
|---|
| Canonical-answer pull | Returns the textbook answer | The prompt has a non-standard twist |
| Base-rate neglect | Reasons from the salient detail | Ignores how common the outcome actually is |
| Anchoring | Builds on a number in the prompt | The anchor was arbitrary or wrong |
| Confirmation | Surfaces support for the framing given | Misses evidence the framing is wrong |
| Sycophantic agreement | Echoes the user's stated assumption | The assumption was the bug |
WYSIATI (What You See Is All There Is)
Fast generation builds the most coherent answer from only what's in the prompt, and does not flag what's missing:
Given: "the function returns the user"
Concludes: "so the happy path works"
Missing: the 404 path, the timeout, the null case — none mentioned, so none considered
Coherence of the answer is not coverage of the territory. Explicitly ask "what would I need to look at that isn't in front of me?"
Fluency Is Not Correctness
A smooth, confident, well-formatted answer feels more trustworthy — to the reader and in the generation itself. That fluency signal is independent of whether the answer is right.
| Fluent answer | Verified answer |
|---|
| Reads cleanly, high apparent confidence | Confidence tied to a specific check that passed |
| Risk: accepted without scrutiny | Risk: only over-use on trivial tasks |
The trap: the more polished the fast answer, the less it gets challenged — exactly backwards from what stakes should dictate. On a high-stakes task, treat a too-clean answer as a reason to run the verification pass, not a reason to ship.
Application Examples
Code Review
Fast answer: "This looks fine" (matches familiar-looking code)
Verification pass (high-stakes change):
- Trace the actual logic line by line, don't pattern-match the shape
- Enumerate the edge/error paths the diff doesn't mention
- Check the change against the contract it must uphold (callers, tests)
Reporting a Fact or API Behavior
Fast answer: "Use method X, it takes these args" (canonical recall)
Verification pass (unfamiliar/version-sensitive):
- Confirm the method exists in the version in this repo
- Check the signature in the actual source/docs, not from memory
- If unsure, say so or look it up rather than assert
Architecture / Tech Choice
Fast answer: "Use [the obvious default]" (most-common completion)
Verification pass (high-stakes):
- State the actual requirements, then check the default against them
- Name one alternative and why it loses, so the choice is reasoned not reflexive
Debugging
Fast answer: "It's probably X" (first plausible hypothesis)
Verification pass:
- List the candidate causes, not just the first
- Find the evidence that would distinguish them, and look at it
- Resist committing to X until the logs/repro actually point there
Integration with Other Thinking Skills
With Debiasing
Fast generation is where most bias-shaped errors enter; the verification pass is where you catch them. Run the debiasing checklist as the content of Step 3 on high-stakes calls.
With Bayesian Reasoning
Fast answers neglect base rates; the verification pass restores them:
Fast: "Positive test result = probably has the condition"
Verified: state the base rate first, then update (see thinking-bayesian)
With First Principles
The fast answer reasons by analogy ("everyone does X"); the verification pass asks whether the constraint is real:
Fast: "Competitors do X, so we should too"
Verified: "What's the fundamental requirement? Does X actually meet it?"
With Pre-Mortem
The fast answer is optimistic by default; the verification pass adds the failure view:
Fast: "This plan will work"
Verified: "Assume it failed — what's the most likely reason?"
With OODA Loop
Under genuine time pressure (an incident), act on the fast answer at ~70% confidence and re-observe — don't stall on verification. Reserve the full pass for after, or for the irreversible step within the incident.
When the Fast Answer Is Trustworthy
The fast path is not the enemy — it's correct most of the time, and over-verifying is its own failure. Lean on the fast answer when:
- The task is conventional — a standard transform or a common, stable fact
- The pattern fits cleanly — no unusual twist in the prompt
- It's cheaply reversible — a wrong answer is caught and fixed at near-zero cost
- You can confirm it trivially if challenged — the check is one step away
Fine to ship fast:
- "Convert this JSON to YAML"
- "What HTTP status means 'not found'?"
- A rename or a comment fix
Verify first:
- "Will this SQL touch every shard?"
- "Is this auth check actually enforced on the server?"
- Anything version-, edge-case-, or money-sensitive
Ask: "If this is wrong, how and when do I find out — and how much does it cost?"
Verification Checklist
Key Questions
- "Did this answer come too easily — and does that matter here?"
- "Is this a conventional task or one with an unusual twist?"
- "What would a second, independent derivation show?"
- "Is my confidence tied to an actual check, or just to how clean the answer reads?"
- "What's missing that isn't in front of me (WYSIATI)?"
- "If this is wrong, how and when do I find out?"
The Core Warning
A fluent, confident answer reflects the coherence of the completion, not the quality of the evidence behind it. The most polished answers get challenged the least — which is exactly backwards when the stakes are high. When an answer comes easily on something that matters, that ease is the trigger to verify, not the signal you're done.
