Chain-of-Thought Prompting

This cover sets the tone for the failure manual: most broken CoT prompts fail not because the idea is flawed but because of small, avoidable mistakes. That reframing is important — it tells the reader the fixes are within reach, not a matter of abandoning the technique.

Post five completes the series by cataloging the six mistakes that most often degrade CoT in practice: wrong task, misplaced trust, truncation, bad parsing, tiny models, and ignored cost. Each one is common, each one is fixable, and each one quietly costs accuracy or money.

The first mistake is using CoT where it doesn't help. CoT is built for multi-step reasoning — math, logic, planning, decomposition. On a single-fact lookup, a sentiment label, or a format conversion, the extra reasoning adds tokens and latency, and it gives the model room to talk itself into a wrong answer it would have gotten right with a direct prompt.

The fix is simple discipline: if the task is one step, ask directly. CoT is a tool with a cost, and applying it reflexively to everything makes cheap tasks slow and occasionally less accurate. Match the technique to genuinely multi-step problems.

The comparison slide draws the line between tasks where CoT helps and where it hurts or merely wastes. On the help side: multi-step math, logic puzzles, planning and decomposition, word problems — anything where the answer is composed of several dependent steps. On the hurt-or-waste side: single-fact lookups, sentiment labels, format conversions — anything resolvable in one step.

Keeping this map in mind is the fastest way to avoid the first mistake. When you're about to add 'think step by step,' ask which column the task falls in. If it's the right column, the reasoning genuinely earns its tokens.

The second mistake is treating the chain as truth. The reasoning a model writes is a generated artifact that empirically improves answers — it is not a faithful log of the model's internal computation. A model can produce a flawless-looking chain and still reach a wrong answer, or land on the right answer through reasoning it didn't actually rely on.

The consequence is that you should never cite the steps as proof of correctness. When the answer matters, verify it independently — recompute it, cross-check it, or validate against ground truth. The chain is a useful debugging aid and an accuracy booster, but it is not evidence in the way a formal proof would be.

The third mistake is starving the chain of tokens. Because the answer always comes after the reasoning, a low max-tokens cap truncates the chain and leaves you with a half-finished thought and no conclusion. This is the single most common reason a previously working CoT prompt suddenly returns nothing usable.

The fix is to budget tokens for the full chain plus the answer line. If your reasoning typically runs a few hundred tokens, a 50-token cap guarantees failure. When in doubt, set the cap generously and rely on a stop sequence after the answer to avoid paying for trailing text. Truncation is entirely avoidable once you account for where the answer sits in the stream.

This code slide shows the truncation trap concretely. The bad version sets max_tokens to 50 on a problem whose chain needs roughly 300, so the model gets cut off mid-reasoning and the answer never arrives. The good version, noted in the comment, budgets 512 tokens for the whole chain plus the conclusion.

The contrast is deliberately stark because the bug is so easy to introduce and so confusing to debug — the prompt looks correct, the model 'works,' and yet the output is empty or truncated. Seeing the exact parameter that causes it makes the fix obvious.

The fourth mistake is parsing the wrong number. A naive extractor that grabs the first or last number breaks constantly because intermediate reasoning steps are full of numbers. In '20 x 17 = 340, 3 x 17 = 51,' there are three numbers before the real answer of 391.

The fix is to force a delimited answer — an 'Answer:' line or a JSON field — and extract precisely that. Don't make your parser guess which number is final; make the model mark it, then read the mark. This single change eliminates a whole category of silent, hard-to-spot extraction bugs.

This code slide contrasts brittle and robust extraction on the same text. The brittle approach grabs the first number it finds and returns '20' — an intermediate value, completely wrong. The robust approach searches for the 'Answer:' delimiter and returns '391', the actual answer.

The lesson generalizes: any parsing strategy that doesn't rely on a delimiter you explicitly requested is gambling on the text layout. Pairing a prompt that demands an 'Answer:' line with a regex that reads exactly that line is the simple, durable pattern that survives contact with real model outputs.

The fifth mistake is pairing CoT with tiny models. Because CoT is an emergent ability, below a scale threshold it barely helps and can actively degrade output — a small model's extra reasoning steps are often confident nonsense that derails an answer it might have gotten right directly.

The fix is to test rather than assume. If you're running a small or heavily quantized model, A/B the CoT prompt against a direct prompt on your own evaluation set. Don't import the assumption that 'CoT always helps' from results obtained on large models; at small scale that assumption frequently doesn't hold.

The compare diagram pairs each mistake with its fix as a quick-reference table: CoT on a one-step task maps to 'ask directly'; trusting the chain maps to 'verify the answer'; max_tokens too low maps to 'budget for the full chain'; grabbing the first or last number maps to 'parse the Answer: line'; and CoT on a tiny model maps to 'A/B against a direct prompt.'

This is the post in one glance. Each row is a mistake from the preceding slides paired with the concrete remedy, so a reader can scan it as a pre-flight checklist before shipping a CoT prompt.

The tips slide condenses the whole failure manual into a five-line checklist: match CoT to genuinely multi-step tasks, treat the chain as a tool rather than a proof, give generous max-tokens, force and parse a delimited answer, and stay mindful of the token, latency, and money cost.

These five lines are the practical residue of the entire series. A reader who internalizes them will avoid the great majority of CoT failures and will deploy the technique deliberately, where it pays off, rather than by reflex everywhere.

The sixth mistake is ignoring the cost. Every reasoning token is billed and adds latency, and self-consistency multiplies that cost by k. On a high-volume endpoint, reflexive CoT can quietly multiply your bill while delivering no accuracy gain on tasks that didn't need it.

The fix is to measure. If direct prompting matches CoT on your evaluation set, ship the cheaper option. Reasoning is a resource you should spend deliberately, with evidence that it's buying accuracy you actually need. Treating compute as free is how CoT goes from a smart technique to an expensive habit.

The CTA closes the series and hands off to the next day's topic, framing the five posts as a contribution to the reader's growing prompt-engineering toolkit. It signals continuity — the series keeps building practical, in-depth technique — without naming the next subject, since each day brings something new.