Imagine solving a puzzle, working out a discount, or planning a trip with several stops. Most of us would break the problem into smaller parts before deciding on an answer.

Chain-of-thought prompting, often shortened to CoT, applies a similar idea to a large language model. Instead of asking only for an answer, we provide examples with intermediate steps or ask for a structured solution.

I find this useful because it shifts attention from a confident answer to something we can check. But there is an important difference: an AI-generated explanation is not a direct view into the model’s internal process. It can sound sensible and still be wrong.

The basic idea

A standard prompt might ask, “What is the final price?” A chain-of-thought example shows how to calculate the discount and then subtract it. This gives the model a pattern for approaching the task.

Research has shown improvements on several arithmetic, commonsense, and symbolic reasoning tasks. Those results are useful evidence, not a promise that the method will improve every answer. The model, the task, and the prompt all matter.

A longer explanation is not automatically a better answer. The useful part is whether we can check the result.

Three ways to use it

1. Ask for a structured solution

The familiar instruction “Let’s think step by step” is one way to try this with a general-purpose language model. For a practical task, I prefer being specific about what I want to see.

Prompt: “A shirt costs $20 and is on sale for 25% off. Calculate the discount and the final price. Show the calculation briefly.”

  • Discount: 25% of $20 = $5.
  • Final price: $20 - $5 = $15.

This is enough to check the arithmetic. There is no need for a long explanation of a simple discount.

2. Provide a worked example

For an unfamiliar task, show the model the format you expect. This is called few-shot prompting when you provide a few examples. When those examples include intermediate steps, they also demonstrate a chain-of-thought pattern.

“Sarah has 8 cookies and eats 3. She has 8 - 3 = 5 left.
Tom has 12 cookies and eats 4. He has 12 - 4 = 8 left.
Lisa has 10 cookies and eats 2. How many are left?”

Answer: Lisa has 10 - 2 = 8 cookies left.

These are deliberately simple examples. For a real business task, the examples should reflect the rules, exceptions, and output format that matter in that business.

3. Show the method through the example

You do not always need to use the words “step by step.” A worked example can make the method clear on its own.

“A car travels at 60 miles per hour for 3 hours. Distance = speed × time = 60 × 3 = 180 miles.
At a constant speed of 50 miles per hour, how far will a car travel in 4 hours?”

Answer: 50 × 4 = 200 miles.

This is closely related to the previous approach. The example carries the instruction, so an extra instruction may not be necessary.

Where it helps

  • Problems with several connected steps. A calculation may need one result before it can produce the next. Making that structure explicit can help.
  • Tasks with constraints. A plan has to satisfy the rules, not just look reasonable. Listing the constraints makes them easier to check.
  • Review and learning. A short explanation, calculation, or set of assumptions can help a person find a mistake.
  • Experimenting without retraining. You can change the prompt and examples without changing the model’s weights.

For me, the main benefit is not that the answer looks more intelligent. It is that the work becomes easier to inspect.

Where to be careful

The model still matters

There is no universal rule that a model needs 100 billion parameters to benefit from this approach. Early research found strong benefits in sufficiently large models, but parameter count alone is not a reliable selection rule. Test the model on the tasks you actually need it to perform.

More output can mean more time and cost

Generating extra text can increase latency and token cost. For a simple question, it may add nothing useful. Match the level of explanation to the task.

A convincing explanation can hide a mistake

A model may build a neat explanation around an incorrect answer. Research on explanation faithfulness shows why we should not treat the written explanation as proof of how the model reached its conclusion.

For important calculations, use a calculator or code. For factual claims, check the sources. For decisions with real consequences, use domain review and clear acceptance criteria.

Reasoning models need a different approach

Some models are trained to reason internally. They may not benefit from an instruction to explain every step. Start with a clear goal, relevant context, and constraints. Ask for a concise explanation, assumptions, or evidence when those help you review the answer.

Good prompting is not about finding one phrase that works everywhere. It is about understanding what the task needs and testing what works.

Two simple examples

Example 1: Keeping track of apples

Prompt: “John has 10 apples. He gives away 4 and receives 5 more. How many does he have? Show the calculation.”

  1. Start with 10 apples.
  2. Give away 4: 10 - 4 = 6.
  3. Receive 5: 6 + 5 = 11.

Answer: John has 11 apples.

The value here is simple: we can check each change instead of accepting the final number on trust.

Example 2: Seating three guests

Prompt: “Alice, Bob, and Charlie need to sit in a row of three seats. Alice cannot sit next to Bob. Find all valid arrangements and briefly explain why they work.”

With three seats in a row, Alice and Bob must occupy opposite ends. Charlie has to sit between them.

  • Alice, Charlie, Bob (ACB)
  • Bob, Charlie, Alice (BCA)

Those are the only two valid arrangements. CAB does not work because Alice and Bob sit next to each other. A small check catches an error that a confident explanation could easily overlook.

Putting it into practice

I would start with one task you already understand well. Give the model a clear question, add the relevant constraints, and ask for the answer in a format you can verify.

  1. Try a direct prompt first.
  2. If needed, add a worked example or ask for a structured solution.
  3. Compare correctness, time, cost, and ease of review across several cases.
  4. Keep the approach that improves the outcome, not the one that produces the most text.

In a project plan, for example, I would ask for dependencies, assumptions, and schedule checks. I would not assume that a detailed timeline is realistic simply because the model explains it well.

My takeaway

Chain-of-thought prompting is a useful technique, not magic. It can help with multi-step tasks and make some answers easier to review. It cannot guarantee accuracy or replace verification.

My advice is straightforward: break down the problem when that helps, ask for the information you need to check the answer, and keep your own judgment involved.

A clear explanation is a starting point for trust. Checking the result is what earns it.

Further reading

  1. Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
  2. Kojima et al., Large Language Models are Zero-Shot Reasoners
  3. Turpin et al., Language Models Don’t Always Say What They Think
  4. OpenAI, Reasoning best practices