thinking-dual-process

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:

1. Notice: Did the answer form immediately, with no intermediate steps? High confidence but nothing checked?
2. Check triggers: Is the task high-stakes/irreversible OR the domain unfamiliar? If neither, ship the fast answer.
3. 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)

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)

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

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

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.

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:

1. The task is conventional — a standard transform or a common, stable fact
2. The pattern fits cleanly — no unusual twist in the prompt
3. It's cheaply reversible — a wrong answer is caught and fixed at near-zero cost
4. 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

• Noticed whether the answer arrived fast or was worked through
• Checked BOTH triggers: easy answer AND real cost of error
• If both true, ran one disciplined verification pass against ground truth
• Re-derived or tested the result a second, independent way
• Did NOT over-verify a trivial, reversible task
• Confirmed version/edge-case-sensitive claims rather than asserting from memory
• Matched the depth of the check to the cost of being wrong

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.