Lesson 3.1: Step-by-step reasoning, and when it helps

Learn when asking a model to show its steps improves answers, how to prompt for reasoning, how voting across runs helps, and what it costs.

By the end of this lesson you will be able to tell which tasks gain from asking a model to work step by step and which do not, write prompts that ask for reasoning in a form you can check, use a decision matrix and a worked calculation as reasoning templates, and understand how asking for several answers and taking the majority can raise reliability, along with what each of these costs in time and money. You should have read Module 2, especially Lesson 2.4 on checking output, since showing the steps is partly a way to make errors visible. No technical background is needed, and the arithmetic uses simple percentages and powers.

Some questions can be answered in one glance: "What is the capital of France?" Others need a chain of small moves: "A loan of ₹2,40,000 at 12 per cent simple interest for 18 months is repaid in equal monthly instalments of principal plus interest. How much is each instalment?" A person asked the second question out loud with no pen would probably slip. Writing the steps down makes the slip less likely. Models behave in a similar way, and that observation is the basis of one of the best-known prompting techniques.

The idea: let the model write its working

A model produces its answer one piece at a time, each piece conditioned on everything before it. If you ask for a final answer immediately, the model has to commit to it in a single move, with no space to work anything out. If you ask it to write intermediate steps first, those steps become part of the text it reads while producing the answer, and each step can build on the last. Researchers found that prompting for such a chain of thought improved accuracy on many multi-step problems, such as arithmetic word problems, logic puzzles and planning questions.

The simplest version is a single added sentence: "Work through this step by step, then give the final answer." A stronger version shows a worked example of the steps you want, in the style of the few-shot prompts from Lesson 2.1. A third version supplies a structure: "First list the facts given. Then state the formula. Then calculate. Then check the result. Then give the answer."

Predict first: you ask an assistant the loan question above and request only the final instalment. What is the most likely mistake? Decide before reading on.

The usual slips are using 18 as the number of years in the interest formula, which gives an interest charge twelve times too large, or forgetting to add the interest to the principal before dividing. Written out, the correct steps are these. The term is 18 months, which is 1.5 years. The simple interest is 2,40,000 × 0.12 × 1.5 = ₹43,200. The total to repay is 2,40,000 + 43,200 = ₹2,83,200. Divided into 18 equal instalments, each is 2,83,200 ÷ 18 = ₹15,733. Each line is easy, and the risk lies in skipping one in a single leap. When the model writes the lines, you can see them, and a wrong line is visible at a glance.

A moving target: reasoning models

A note about the tools. Many assistants now include modes or models that reason internally before they answer: they generate a long hidden or partly visible chain of thought on their own, whether or not you ask. With such models, adding "think step by step" often changes little, and long reasoning instructions can sometimes interfere with how they work. The advice that follows therefore comes with a rule that applies throughout this course: test on the tool you use. Run the same task with and without a request for steps, on a handful of cases where you know the answer, and keep whichever works. The underlying lesson does not date: hard problems benefit from intermediate work, and you should be able to see that work if the answer matters.

When step-by-step helps, and when it does not Helps · Does little or hurtsMulti-step arithmetic and word problems · Looking up a simple fact Logic puzzles and constraint problems · Creative writing, where a rigid process stifles voice Comparing options against several criteria · Rewriting text for tone or grammar Planning and scheduling · Short classification, where the label is the whole answer Debugging and tracing why something failed · Questions with a single obvious answer Any task where you need to audit the logic · Very tight length limits There are three costs. First, time and tokens: reasoning text is extra output, which takes longer and costs more. Second, false confidence: a tidy chain of steps looks authoritative even when one step is wrong, so a reader is lulled into trusting the conclusion. Third, explanations that do not match the cause: the written steps are the model's account of its working, and research suggests they do not always reflect what actually determined the answer. Treat the steps as a check you can read, not as proof.

Prompting for reasoning that you can check

A few patterns make the steps useful, not decorative.

Ask for the structure. "List the given facts, state what is being asked, show the calculation line by line with units, then give the answer." This gives you something to scan.

Separate the working from the answer. "Show your working under the heading Working, then write Final answer: followed by one line." This makes it easy to copy only the answer, and to check the working separately.

Ask for a check. "After the answer, check it by working backwards, for example by multiplying the instalment by 18, and say whether it matches." A simple check catches many slips.

Ask for assumptions. "List any assumptions you made about the interest method or the term." Many reasoning errors are hidden assumptions, and surfacing them shows you where to correct the prompt.

Give the method when you know it. If your company calculates a figure in a particular way, state the formula. Do not leave the model to guess which of several valid methods you intend.

text Work out the monthly instalment for the loan below.

Loan: Rs 2,40,000, simple interest at 12% per year, term 18 months, repaid in equal monthly instalments of principal plus interest.

Show your working under the heading Working, one line per step, with units. Then check the result by multiplying the instalment by the number of months. Finish with "Final answer:" and the instalment to the nearest rupee. List any assumption you made.

A reasoning template for decisions

Reasoning is not only for arithmetic. A common business task is choosing among options, and the right structure is a decision matrix: list the options, agree the criteria, give each criterion a weight, score each option and combine. Asking the model to produce this makes the logic visible, and it lets you disagree with any single number.

Suppose you are choosing between three vendors. The criteria and weights are cost at 40 per cent, reliability at 35 per cent and support at 25 per cent. The scores out of 10 are Vendor A: 8, 6, 7, Vendor B: 6, 9, 8 and Vendor C: 9, 5, 5. The weighted scores are A: 0.40 × 8 + 0.35 × 6 + 0.25 × 7 = 3.2 + 2.1 + 1.75 = 7.05. B: 0.40 × 6 + 0.35 × 9 + 0.25 × 8 = 2.4 + 3.15 + 2.0 = 7.55. C: 0.40 × 9 + 0.35 × 5 + 0.25 × 5 = 3.6 + 1.75 + 1.25 = 6.6.

The matrix does not make the decision for you. It makes the reasoning inspectable. If a colleague thinks cost should carry 60 per cent, you can change the weight and rerun. A prompt that asks for the matrix, with your criteria and weights, and asks the model to explain any score where it made an assumption, gives you a reviewable record. Be aware that the scores themselves are judgements, and a model that scores vendors from general knowledge will invent them. Supply the facts you have, and mark which scores you provided and which the model estimated.

Reading the working: a checklist

When a reply includes steps, do not skim them. A short routine catches most problems.

1. Is every given fact used correctly? Compare the first lines with your own numbers. A wrong starting value spoils everything after it. 2. Does each line follow from the one before? Look for a leap, where a number appears from nowhere. 3. Are the units consistent? Months against years, lakh against crore, per cent against decimals. 4. Does the check really check? A check that repeats the same calculation proves nothing. A good check works backwards or uses a different route. 5. Is the answer plausible? A monthly instalment larger than the loan is wrong whatever the steps say.

The routine takes a minute for a short calculation, and it is the main reason to ask for working in the first place. A model that shows steps you never read has given you a more expensive way to get the same unchecked answer.

Reasoning about arguments and trade-offs

Not every reasoning task is numeric. When you ask a model to weigh a decision, such as whether to open a new branch, a straight request for a recommendation tends to produce a balanced-sounding paragraph that sits on the fence. A structure forces substance. Ask for the strongest case for each option in turn, the evidence that each case depends on, the single assumption that would change the conclusion, and then a recommendation with a stated level of confidence. Because each part is separate, you can challenge the evidence for one side without rereading everything.

Two further moves help. Ask for the opposite. After a recommendation, ask "What is the best argument against this, and how would you answer it?" This counters the model's tendency to agree with the direction of your question, which Lesson 1.2 described. And ask what you would need to know: "List three facts that, if true, would make you change your recommendation." The list tells you where to spend effort checking before you commit. These prompts do not make the model wiser. They make its reasoning visible enough for you to apply your own judgement, which is the point.

Voting: ask several times and take the majority

A model's answers vary from run to run, so a second technique is to ask the same question several times and take the answer that comes up most often. If errors are somewhat random, the majority is more reliable than any single run. The effect can be calculated. Suppose each run is right 70 per cent of the time and the runs are independent. The chance that the majority of three is right is 3 × 0.7² × 0.3 + 0.7³ = 0.441 + 0.343 = 0.784, or 78 per cent. For five runs it is 10 × 0.7³ × 0.3² + 5 × 0.7⁴ × 0.3 + 0.7⁵ = 0.309 + 0.360 + 0.168 = 0.837, or 84 per cent. For seven runs it is about 87 per cent.

The simulator shows a limit worth remembering: voting only helps when a single run is right more often than not. If it is right 40 per cent of the time, a majority vote is worse than a single run. Voting is also only practical when answers can be compared, such as a number, a label or a yes or no. For a free-text essay there is no majority.

What reasoning costs

Reasoning is extra text, and extra text costs time and money. Suppose a direct reply is about 150 tokens and a reply with working is about 650 tokens. If a team makes 5,000 such calls a day at an example output price of ₹800 per million tokens, the direct replies cost 150 × 5,000 ÷ 1,000,000 × 800 = ₹600 a day and the replies with working cost ₹2,600. That is more than four times as much, and the replies take about four times as long to appear, since a model writes at a roughly steady pace.

So the decision is a trade. Where a wrong answer is expensive, such as a figure that goes into a client proposal, working is cheap insurance. Where a wrong answer is harmless or easily spotted, such as a quick classification, skip it. A sensible pattern is to use reasoning for the hard cases only: handle routine requests directly, and send the ones that are flagged as complex or important to a reasoning prompt.

Worked examples

Example 1: a calculation. The loan problem above. Asked for the answer alone, an assistant might return ₹18,000 by using 18 as years or ₹13,333 by forgetting the interest. Asked for working with a check, it returns the 1.5-year conversion, the interest of ₹43,200, the total of ₹2,83,200 and the instalment of ₹15,733, and the check 15,733 × 18 ≈ 2,83,194 shows a rounding difference of a few rupees. The reader can see and verify each step in a minute.

Example 2: a scheduling puzzle. A team of four needs a one-hour meeting. Asha is free only after 2 pm, Ben cannot do Tuesdays, Chitra leaves at 4 pm on Mondays and Wednesdays, and Dev is available only from Monday to Wednesday. Asked directly, a model may confidently suggest Tuesday at 3 pm, which quietly breaks Ben's constraint. Asked to list each person's constraints and test each day against them, it works through the week: Tuesday fails on Ben, Thursday and Friday fail on Dev, and Monday and Wednesday survive, with a window from 2 pm, when Asha is free, to 4 pm, when Chitra leaves. The answer is Monday or Wednesday between 2 and 4 pm. The elimination is easy to read and to check, and had the constraints truly clashed, the working would have shown exactly where.

Example 3: a recommendation. A manager must choose between two software tools. The prompt gives the facts, asks the model to list the criteria, weight them using the manager's priorities, score each tool with a one-line reason and compute totals, then to identify which assumption would flip the ranking. The last request is especially useful: it shows how fragile the recommendation is, and where to gather more facts before deciding.

Common mistakes

Asking for steps on every task. It costs time and tokens and can stiffen creative writing. Use it where the task has several steps. Treating a neat chain as proof. A fluent chain can contain a wrong step. Check the key lines. Not telling the model the method. If your company uses a formula, state it. Mixing the working into the answer. Separate them, so the answer can be copied cleanly. Voting on questions with no definite answer. Majority needs comparable answers. Voting with a weak single-run accuracy. If one run is right less than half the time, fix the prompt before voting. Forgetting to test the tool. Reasoning models may not need the nudge. Compare with and without. Letting the model invent scores. In a decision matrix, supply the facts and mark estimates.

Key takeaways

Asking a model to write intermediate steps often improves accuracy on multi-step problems, because each step becomes context for the next and an error becomes visible. It helps with calculations, logic, comparisons, planning and debugging, and does little for lookups, rewriting and creative work. Reasoning models may do this internally, so test with and without. Make the steps useful: ask for structure, separate working from the answer, ask for a check and for assumptions, and give the method if you know it. A decision matrix makes judgement inspectable: criteria, weights, scores and totals. Supply the facts, and mark the scores the model estimated. Voting across several runs helps when a single run is right more than half the time and errors are not identical. At 70 per cent per run, a majority of five is right about 84 per cent of the time. Reasoning costs time and money, so use it for the hard or important cases, and let routine ones go direct.

Check yourself

1. Why does writing steps first often improve a multi-step answer? Each step becomes part of the text the model reads next, so later steps build on earlier ones, and a mistake is visible. 2. Name two kinds of task where step-by-step reasoning does little. Simple fact lookups and tone rewrites, or creative writing and short classification. 3. In the vendor example, what happens to the ranking if cost carries 60 per cent and the other two split the rest equally at 20 per cent each? A: 0.6×8+0.2×6+0.2×7 = 7.4. B: 0.6×6+0.2×9+0.2×8 = 7.0. C: 0.6×9+0.2×5+0.2×5 = 7.4. A and C tie ahead of B. 4. If a single run is right 60 per cent of the time, roughly how right is a majority of three? 3 × 0.36 × 0.4 + 0.216 = 0.432 + 0.216 = 0.648, about 65 per cent. 5. A direct reply is 200 tokens and one with working is 800. What is the cost multiple? 800 ÷ 200 = 4 times.

Try this

You need an assistant and about forty-five minutes.

1. Collect eight multi-step questions with known answers: percentages, instalments, scheduling or small logic puzzles from your own work. 2. Ask each question twice in fresh chats: once asking only for the final answer, once with the structure from this lesson (working, check, final answer, assumptions). Record whether each is correct. 3. Note which kind of question gained from the working and which did not. 4. For one question you got wrong, read the working and find the step that failed. Was it a hidden assumption you can fix in the prompt? 5. Run one answerable question five times and take the majority. Compare the majority with the single-run accuracy you saw. 6. Build a decision matrix for a real choice you face, with your own criteria and weights, and ask the model to compute it. Change one weight and see whether the ranking flips. 7. Use the cost simulator with your own volumes to decide where reasoning is worth it. Check · Direct · With workingCorrect out of 8 · · Errors you could find by reading · · Extra time per answer · · Eight questions are too few to prove anything, as Lesson 2.1 showed, so treat the result as a hint and repeat on more. A good result is a note on which of your tasks benefit from reasoning, a saved reasoning template and one decision matrix you can reuse. In the next lesson we go one step further: breaking a large task into a chain of smaller prompts.

Tags: Prompt Engineering Reasoning Chain of thought Decision making Intermediate