For a long time, good prompting meant teaching the model how to think.
We told models to think step by step.
We asked them to break problems down.
We gave examples.
We described the order in which they should evaluate conditions before giving an answer.
That made sense.
Many earlier prompting techniques were useful because they stopped the model from jumping too quickly to a conclusion.
But reasoning models change the relationship a little.
A reasoning model is not just a chat model that writes longer answers.
It is designed to spend more effort on harder problems, compare conditions, explore possible paths, and hold the problem longer before producing an answer.
So when we keep using the same old prompts, we may accidentally get in the way.
Sometimes the problem is not that we gave the model too little direction.
Sometimes the problem is that we gave it too much.
The old habit: control the thinking process
With general chat models, instructions like this often helped:
Think step by step.
First analyze the problem.
Then compare the options.
Then explain your reasoning.
Finally give the answer.
````
This kind of prompt creates a path.
It tells the model not to rush.
It forces intermediate steps.
It makes the answer feel more deliberate.
For many tasks, that was useful.
But with reasoning models, the same habit can become friction.
If the model is already built to reason through a problem internally, forcing it into your exact thinking sequence can narrow its search space.
You may think you are helping it reason.
But you might actually be telling it to ignore a better path.
---
## Examples can also become a cage
Examples are powerful.
A good example shows the model what kind of answer you want.
It can define tone, structure, format, and level of detail.
But examples can also overfit the response.
If your example is too specific, the model may follow the shape of the example instead of finding the best solution for the actual problem.
This is especially important with reasoning tasks.
Sometimes the model needs freedom to compare options, reject a path, or find a simpler solution than the one implied by your example.
So the problem is not that examples are bad.
The problem is using examples to control the method when you only needed to define the standard.
---
## A better prompt defines the target
For reasoning models, I try to give less process and more criteria.
Instead of this:
```txt
Break this problem into three steps.
First check A.
Then compare B.
Then decide based on C.
I prefer something like this:
Solve this problem.
Goals:
- Find the most likely causes
- Separate confirmed evidence from assumptions
- Prefer the smallest safe change first
- Point out remaining uncertainty
Output:
1. Most likely cause
2. Evidence to verify
3. Minimum fix
4. Risks or unknowns
The second prompt does not teach the model exactly how to think.
It tells the model what a good answer must satisfy.
That difference matters.
You are not designing the reasoning path.
You are defining the destination, the constraints, and the output shape.
Then you step back.
This does not mean reasoning models are better for everything.
For simple tasks, they can be overkill.
If you need:
- a short summary
- a quick translation
- a tone adjustment
- a simple list of ideas
- a small rewrite
a normal chat model may be faster and good enough.
Reasoning models become useful when the problem has many conditions, possible paths, and a high cost of being wrong.
For example:
- debugging a complex code issue
- comparing architecture decisions
- planning under many constraints
- reviewing the logic of an argument
- analyzing trade-offs
- solving math or logic problems
- choosing between contradictory options
In those cases, the model’s value is not that it writes more.
Its value is that it can stay with the problem longer.
The user’s job changes
When the tool changes, the prompt should change too.
With a general chat model, you may need to guide the model more explicitly.
With a reasoning model, the better move is often to clarify:
- the goal
- the context
- the constraints
- the success criteria
- the output format
- what should remain uncertain
That is usually more useful than telling the model how to reason.
The prompt becomes less like a script.
It becomes more like a problem brief.
Don’t teach the model how to think
This is the main shift for me.
When using a reasoning model, I do not want to over-direct the middle of the process.
I want to define the problem clearly.
I want to say what matters.
I want to say what should be avoided.
I want to say what the answer should contain.
I want to say how uncertainty should be handled.
But I do not need to micromanage every step of the reasoning path.
A reasoning model is already built to think.
Our job is not to teach it how to think.
Our job is to give it a problem worth thinking about.