Loading lesson…
Prompt Engineering / Core Techniques
Getting a model to think before it answers.
Reviewed by Yuvaraj
On a single-step question, a definition, a lookup, a one-line transformation, a capable model answers well in one shot. On a multi-step task, a word problem, a chain of conditions, a plan with dependencies, asking for the answer directly is where accuracy quietly collapses. This lesson covers the family of prompting techniques that give a model room to work before it commits: chain-of-thought, task decomposition, self-consistency, and structured scaffolds. The unifying idea is simple: let the model think in tokens you can see, then read the answer off the end.
A Transformer produces one token at a time, and each token is the output of a fixed number of layers, a bounded amount of computation. A problem that needs more sequential reasoning steps than that fixed depth allows cannot be solved inside a single token, so the model is forced to guess. Chain-of-thought sidesteps the ceiling. Every token the model emits is appended to the context, so intermediate results, a subtotal, an inference, a ruled-out option, become inputs the next token can build on. The generated text is a working memory the architecture does not otherwise have. More tokens buy more serial computation, which is why "show your work" is not a stylistic preference but a way to spend compute.
| Technique | What you ask for | Best for |
|---|---|---|
| Chain-of-thought | Reason step by step, then answer | arithmetic, logic, anything with intermediate results |
| Decomposition (least-to-most) | Split into sub-questions, solve in order, feed answers forward | tasks whose parts depend on each other |
| Self-consistency | Sample several reasoning paths, take the majority answer | high-stakes questions with one correct answer |
| Structured scaffold | Numbered slots: first find X, then use X to find Y | when you already know the shape of the solution |
Ask about this lesson, or about anything in AI. Answers cite the lessons they draw on.
Finished this lesson?
Mark it complete to earn XP, keep your streak, and schedule a review.
For a curious beginner
Answering instantly is like blurting a mental-math guess; working it out on paper lets you catch a wrong turn before you commit. The written steps are that paper.
How it is actually used
Each token the model generates is appended to the context, so the next token is conditioned on the partial solution. The model reads its own subtotals back in and builds on them, instead of holding everything in one activation and guessing.
The underlying mechanism
A Transformer applies a fixed layers per token, bounding the serial computation available for any single token. Emitting intermediate tokens grants up to extra serial steps; formal results show this strictly enlarges the class of problems a fixed-size model can solve.
Here is a genuinely two-stage problem. The direct prompt loses it; the decomposed prompt recovers it.
A train leaves a station at 9:00 AM going 60 km/h. A second train
leaves the same station at 10:30 AM going 90 km/h in the same
direction. What time does the second train catch the first?
Answer with just the time.
Model output: 11:30 AM, wrong. In one pass it divided the 90 km gap by the wrong speed (the second train's own 90 km/h), never writing down the closing speed.
A train leaves a station at 9:00 AM going 60 km/h. A second train
leaves the same station at 10:30 AM going 90 km/h in the same
direction. What time does the second train catch the first?
Work through it step by step, then give the final time on a line
starting with "ANSWER:".
Model output:
1. By 10:30 AM the first train has run 1.5 h × 60 km/h = 90 km.
2. Same direction, so the gap closes at 90 − 60 = 30 km/h.
3. Closing 90 km at 30 km/h takes 90 ÷ 30 = 3 h.
4. 10:30 AM + 3 h = 1:30 PM.
ANSWER: 1:30 PM
Correct: at 1:30 PM both trains have traveled 270 km. Writing the closing speed as its own step is exactly the subtotal the single-pass answer could not reach.
The reasoning text is a plausible-sounding rationalization, not a faithful log of the computation that produced the answer. A model can reach the right result for reasons it never states, or narrate steps it did not actually use, so do not treat the trace as an audit trail. Chain-of-thought also costs latency and tokens, and it is not free reliability.
This guidance is EVOLVING
Whether to hand-write "think step by step" is model-dependent. Modern reasoning models already run extended internal reasoning before they reply; on those, bolting on your own CoT is often redundant or actively worse. Follow the current provider guidance for the specific model, and always separate the final answer, a delimiter, an ANSWER: line, or structured JSON, so downstream code parses the conclusion, not the scratch work.
Common mistakes