My original LinkedIn post shared Amit Shekhar’s accessible explanation of chain-of-thought prompting. Shekhar deserves credit for making the basic mechanism and its common variants approachable. My short summary repeated the popular formulation—ask a model to reason step by step, let it “show its work,” and accuracy improves—but compressed two different claims into one.
The evidence supports the narrower claim that eliciting intermediate steps can improve measured performance for some models, tasks, prompts, and decoding strategies. It does not establish that a visible rationale is a faithful record of the process that produced the answer. Nor does a fluent sequence of steps certify that the conclusion is correct.
That distinction matters anywhere an AI answer is expected to survive verification rather than merely look convincing.
What the original results showed
Wei et al. demonstrated few-shot chain-of-thought prompting: a prompt contains worked examples with intermediate reasoning, and the model continues that pattern for a new problem. They reported substantial gains on selected arithmetic, commonsense, and symbolic reasoning benchmarks, especially with sufficiently large models.
Kojima et al. studied a different method. Their zero-shot approach appended an instruction such as “Let’s think step by step” without providing worked examples. It also improved results on several reasoning benchmarks used in that study.
These are important empirical results, but neither paper supports the universal rule “more visible reasoning means a more accurate answer.” Performance depends on the task, model, prompt, and evaluation. A technique that helps on a multi-step arithmetic benchmark may add latency or failure opportunities to a simple classification or retrieval task.
Several techniques share the same label
The term chain of thought now covers practices with materially different mechanisms and evidence.
| Technique | What changes | What it does not guarantee |
|---|---|---|
| Few-shot CoT | Worked reasoning examples are included in the prompt | That the examples induce the right method |
| Zero-shot CoT | A short instruction elicits an intermediate explanation | That the instruction improves every task |
| Self-consistency | Several reasoning paths are sampled and aggregated | That a majority answer is correct or independent |
| Reasoning models | Additional inference is performed before the final reply | That the public explanation is an internal trace |
Self-consistency is particularly revealing. Instead of trusting one greedy reasoning path, it samples multiple paths and selects the most consistent answer. Its gains show that decoding and aggregation matter, not only whether the model emits a step-by-step explanation. Agreement can still be wrong, but the technique changes the evidence from one plausible story to a distribution of attempted solutions.
A plausible explanation is not evidence
The temptation is to read generated reasoning as an audit log. That interpretation is unsafe.
Turpin et al. showed that biasing features could affect model predictions while the generated explanations systematically failed to mention those influences. When a bias pushed a model toward an incorrect answer, the model could produce a coherent rationale for that answer after the fact.
Later work by Arcuschin et al. found unfaithful reasoning on naturally worded prompts as well, including cases where models constructed superficially coherent arguments for contradictory answers. The rates and behaviours vary by model and setup, but the engineering conclusion is stable: verbalized reasoning is not a complete account of the process that generated the result.
A chain of thought may expose a useful intermediate claim. It may also rationalize a prior answer, omit a decisive influence, contain a subtle inconsistency, or arrive at the correct result through invalid steps. Fluency makes those cases harder—not easier—to distinguish by inspection alone.
Verification changes the question
The operational question should not be “Did the model explain itself step by step?” It should be “Which claims can be checked independently?”
The appropriate checks depend on the domain:
- Mathematics: recompute the result, use symbolic or numerical checks, test constraints, and search for counterexamples.
- Software: compile the code, run example-based and property-based tests, apply static analysis, and isolate execution.
- Factual work: cite primary sources, preserve retrieval provenance, and cross-check claims against independent evidence.
- Agent actions: enforce permissions, separate planning from execution, use dry runs, log effects, and require approval for consequential writes.
In each case, the verifier should be at least partly independent of the prose being evaluated. Asking the same model to declare its own reasoning correct is additional testimony, not independent evidence.
A practical prompting and testing pattern
For high-consequence work, a more defensible workflow is:
- Ask for the result, assumptions, and a concise decomposition into checkable claims.
- Request multiple candidate solutions when the problem admits meaningfully different approaches.
- Send calculations, code, citations, or proposed actions to an external verifier.
- Preserve verifier output and observed effects as evidence.
- Test boundary cases and actively try to falsify the answer.
- Report remaining uncertainty instead of filling it with a longer rationale.
This pattern still benefits from decomposition. It simply refuses to confuse the decomposition with proof. The generated steps become hypotheses and test targets rather than privileged access to the model’s internal process.
When chain of thought is useful
Chain-of-thought prompting remains useful when decomposition helps a model solve a multi-step task, when intermediate claims guide debugging, or when those claims can be checked with tools. It is less attractive for simple tasks, for settings where verbose output increases cost or leaks sensitive context, and for problems with a cheap authoritative verifier that can evaluate the answer directly.
The corrected conclusion is therefore narrower than my original LinkedIn post, but more useful: chain of thought is an inference technique and a diagnostic interface. It can improve answers under particular conditions and expose material worth testing. It is not a correctness certificate, a proof, or a guaranteed faithful transcript of how a model arrived at its answer.