A How to Guide: Prompt Engineering for Reasoning Models

 on prompt engineering, we covered the basics of prompt engineering, the difference between reasoning and non-reasoning (traditional) models, and how to prompt traditional models. Today we’re going to focus on reasoning models like 

When using traditional models, the anatomy of a good prompt looks something like this: 1) Goal - the task you want to achieve; 2) Detail - Specifics of how you want it done; 3) Role - the role you want the model to adopt, e.g. “you are a senior software developer who writes clean code”; 4) Format - how you want your output presented, e.g. bullet points, JSON etc.; 5) Examples of input/output; 6) Tone - Conversational tone to adopt when providing the output (professional vs casual etc.); and 7) Context - considerations and supplementary information to take into account, e.g. input documents or codebase to work with.

Reasoning models operate somewhat differently, so the tips and tricks for working with them is slightly different.

Some of the basic rules still apply though:

Before we get into the details of prompting, let’s take a deeper look at reasoning models.

Reasoning models differ from traditional models in that they break down tasks into a series of subtasks executed sequentially. This “chain-of-thought” reasoning is key to how they function, and makes them more performant - albeit more computationally expensive to use. It also means that reasoning models are capable of “showing their work”, that is to say, showing the intermediate steps used to arrive at an output.

 for its GPT models vs o1/o3-mini as an example, we see a stark difference in the price per million tokens - by roughly a factor of six. They will generally take longer to produce an output too.

 tasks - you’re still better off using traditional models. Reasoning models can also ‘ovethink’ on simple tasks, and may produce errors by trying to add reasoning steps where none are needed.

But Reasoning models excel at certain types of complex tasks.

Let’s look at an example of how reasoning models work on the front-end, I used the following prompt with DeepSeek-R1 with the “DeepThink” option checked.:

if jason has seventy-two apples, gives eight of them to sara, is given four more by jules,
eats fifteen apples himself then loses another ten while being rushed to hospital for 
food poisoning, how many apples does he have?

We get very long response explaining the steps taken:

And the result is recapped in the output prompt:

Now that we’ve had a look at how reasoning models work, let’s look at how to prompt them and how those prompts differ from traditional models. Like in our previous article, we’re going to look at a few components that make up the anatomy of a good prompt.

When dealing with reasoning models, it’s better to think of your prompts as ‘briefs’,  detailed step-by-step instructions with as much context as you can provide. Think something like spec documents for building software.

Same as with a traditional model, you want to give the reasoning model a clear and detailed goal from the very start. Describe exactly what you want up front, rather than how you want it - this means that unlike traditional model, you don’t really want to assign a role (e.g. “you are a senior software developer” but rather have the focus very much on the outcome you want. The point of chain-of-thought reasoning is to figure out the “how”.

Similar to traditional models, we want to specify the output format. This ties in to what we said about goals, particularly that we want to focus on 

 We can specify specific structures, like JSON, XML, CSV, or text formatting guidelines (bullet points, tables etc.) The important thing is to know exactly what we want as a response.

Here you can pre-empt possible errors in the chain of reasoning. This can include cautions like “make sure the name of XYZ is correct”, “make sure the code is executable”, “make sure each entry matches the schema” etc.

You want to give as much context as you possibly can - this can include the intended audience and details of your company if you’re generating a report, your database schema and other architectural notes if you’re producing code, steps you’ve tried to solve your problem that didn’t work. The more context you give the better.

Since reasoning models are good at complex tasks, let’s give it a tricky coding problem to solve. Let’s say I want to write a Python program for my son to play around with - he’s a big Pokémon fan, so let’s get our model to make a program where he can input the name of a Pokémon and get some data and a fun fact about them. To make it a little more complicated, we’re also going to ask the model to provide some unit tests

We’re going to follow the format we used above.

#Goal
Write a Python program thhat takes the name of a Pokémon as an input, then prints some 
fun facts about that pokémon on the screen 

I also want you to write some unit tests

#Format
The python program should be called "whos_that_pokemon" and be written with Pep8 style
guidelines in mind. I should be able to run this code right away. For each input, please 
make sure you include he most recent pokédex entry and what type(s) it is

#Warnings
Make sure that the code produces the JSON object in the correct format. Also make sure
that we check that the input is a valid pokémon name

#Context
I want this code for my son to play around with, he is ten years old, loves pokémon and
wants to learn a bit about coding. So I want this code to be really easy to use and 
to understand

Note that using headings like we did in the prompt above helps to structure the information for the model to use. Now let’s try out our prompt with DeepSeek-R1:

First, we get a LOT of insight to its reasoning steps - I won’t paste the whole thing since it’s quite long, but let’s get some highlights.

First, the model affirms the goal and starts reasoning about the “how” once it’s clear on the “what”, and then delves into considerations it needs to take into account. For example which API to use, how to handle the string input, which Pokédex entry is the ‘latest’ (for context - each new Pokémon game usually comes with new entries for every Pokémon and sometimes multiple games release at once with different entries) - we can see that this problem gives DeepSeek some pause.

Here we can see the model iterating on the format and context, taking into account our warnings - it intuits correctly that 1) Pokémon can have more than one type, and 2) That JSON is probably not the most child-friendly format for a child (importance of context!).

Skipping ahead to when the model tries to generate code, we can see it iterating on its solutions, and we can see exactly how the different components of our prompt affect it’s reasoning process - here it corrects an error message to be more child friendly based on the output we gave it.

Seeing these intermediate steps really helps us understand how reasoning models structure their problem solving and how they respond to the context we give in prompts. Studying these from time to time will help you get better at prompting, and help you debug issues in the output.

This was the final code generated by the model

# whos_that_pokemon.py
import requests
import json

def get_pokemon_info(name):
    """Fetches Pokémon data from the PokeAPI."""
    try:
        # Get species data
        species_url = f"https://pokeapi.co/api/v2/pokemon-species/{name.lower().strip()}/"
        species_response = requests.get(species_url)
        if species_response.status_code == 404:
            return None
        species_response.raise_for_status()
        species_data = species_response.json()

        # Get latest English Pokédex entry
        english_entries = [
            e for e in species_data['flavor_text_entries'] 
            if e['language']['name'] == 'en'
        ]
        latest_entry = english_entries[-1]['flavor_text'] if english_entries else "No entry available"
        latest_entry = latest_entry.replace('\n', ' ').replace('\f', ' ')

        # Get type data from Pokémon endpoint
        pokemon_url = species_data['varieties'][0]['pokemon']['url']
        pokemon_response = requests.get(pokemon_url)
        pokemon_response.raise_for_status()
        pokemon_data = pokemon_response.json()
        
        types = sorted(
            [t['type']['name'] for t in pokemon_data['types']],
            key=lambda x: pokemon_data['types'][0]['slot']
        )

        return {
            "name": species_data['name'].capitalize(),
            "types": types,
            "pokedex_entry": latest_entry
        }

    except requests.exceptions.RequestException:
        return None

def main():
    """Main program loop"""
    print("Who's That Pokémon?")
    name = input("Enter a Pokémon name: ").strip()
    
    if not name:
        print("Please enter a Pokémon name!")
        return

    pokemon_info = get_pokemon_info(name)
    
    if pokemon_info:
        print("\nHere's your Pokémon info!")
        print(json.dumps(pokemon_info, indent=2))
    else:
        print(f"\nOops! Couldn't find {name}. Check the spelling and try again!")

if __name__ == "__main__":
    main()

# test_whos_that_pokemon.py
import pytest
import requests
from whos_that_pokemon import get_pokemon_info

def test_valid_pokemon(requests_mock):
    # Mock Pikachu data
    species_data = {
        "name": "pikachu",
        "flavor_text_entries": [{
            "flavor_text": "Electric mouse Pokémon",
            "language": {"name": "en"},
            "version_group": {"name": "sword"}
        }],
        "varieties": [{"pokemon": {"url": "https://pokeapi.co/api/v2/pokemon/25"}}]
    }
    requests_mock.get("https://pokeapi.co/api/v2/pokemon-species/pikachu/", json=species_data)
    
    pokemon_data = {
        "types": [{"slot": 1, "type": {"name": "electric"}}]
    }
    requests_mock.get("https://pokeapi.co/api/v2/pokemon/25", json=pokemon_data)
    
    result = get_pokemon_info("Pikachu")
    assert result == {
        "name": "Pikachu",
        "types": ["electric"],
        "pokedex_entry": "Electric mouse Pokémon"
    }

def test_invalid_pokemon(requests_mock):
    requests_mock.get("https://pokeapi.co/api/v2/pokemon-species/unknown/", status_code=404)
    assert get_pokemon_info("unknown") is None

def test_connection_error(requests_mock):
    requests_mock.get("https://pokeapi.co/api/v2/pokemon-species/pikachu/", exc=requests.exceptions.ConnectionError)
    assert get_pokemon_info("pikachu") is None

The model helpfully reminded me to pip install requests and pytest. I ran the program in my IDE and it worked straight off the bat - just like we specified in the prompt.

Could we have done anything better with the prompt? 

Yes - for example giving the prompt a JSON schema would have allowed us to better guide what the output looks like, the model did come up with a consistent and correct schema, but only included the items we specifically requested it include (type, latest pokedex entry) - this is why I kept saying you need to know exactly what you want when prompting a reasoning model!

We could have also been more specific about our unit testing - for example requesting it check for Pokémon with more than one type (it thought of this issue in its chain of thought, but did not include it in the unit tests - again, the importance of specifying our output).

Well, there you have it - now you hopefully know a bit more about how reasoning models work, when to use them, how to prompt them effectively, and get the output you want.  It’s important to know how they break up problems step by step, and to focus on exactly what you want the model to achieve.

If you’re curious about how to prompt traditional models and haven’t read our previous article - 

As before, we’ll leave links to a couple of useful resources for prompt engineers below. 

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

A How to Guide: Prompt Engineering for Reasoning Models

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript