Page 84 - CyberSecurityEssentialsEnglish

instruction to think step by step adds length and cost. State the problem, the data, the
constraints, and what a finished answer looks like.

+ For the advanced reader: there is no single recipe for every model

Some models are designed to spend more internal reasoning effort. Current guidance
encourages a direct, clear request that states the constraints and what completion
means, rather than filling the prompt with repeated commands of the “think step by
step” kind. Test the result, and ask for brief justifications that can be inspected [10].

The instruction “think step by step” has a real research basis. Chain-of-thought prompting
was shown to improve performance on multi-step reasoning tasks in earlier and smaller
models, both when examples of reasoning were supplied and when the instruction alone

was added [16][17]. The recommendation has shifted for a specific reason: models built for
reasoning already perform that work internally, so repeating the instruction adds length and
cost without necessarily adding accuracy. The technique is not wrong; it is being absorbed

into the model.

When using a reasoning model, begin with the complete problem, the data, the constraints,
and the shape of the answer. Define the end point: is one solution required, or a comparison,
or the detection of a contradiction, or a verification plan? Do not make the goal simply “think

deeply.” Depth is not an output, and it can consume time without changing the decision.
Do not treat the disclosure of an internal chain of thought as a guarantee of correctness. You

can ask for a summary of the justifications, the assumptions, the auditable steps, and the
visible sources or calculations. But real verification comes from testing the result, using an
appropriate tool, or consulting an expert, not from the length of the narration about how
the thinking was done.

In computational or programming tasks, ask for a tool or code to be used where one is
available, and ask for the result, the assumptions, and the verification tests to be shown. In
open tasks, ask for alternatives, criteria, and trade-offs. In every case, make the prompt

specific enough that we know when the task is finished and what must be checked.
It also helps to set an effort budget when the tool supports one. Does the task deserve
extended reasoning, or a fast answer? Do not use the highest effort for every request; that

may increase time and cost without adding value. Tie the effort to the complexity of the task
and the impact of an error, and test whether the increase actually improves the measure
you care about.

In multi-part problems, ask for a short plan of the outputs or a list of sub-questions, but do

not assume that writing a plan means executing it correctly. You can specify: “Check that all
items are complete before finishing the answer, then give a summary of the justifications

83