Prompting with Questions

Learning to prompt can be both easy and hard at the same time. Prompts are written in natural language, but writing good prompts still takes practice. In this post, I want to explore a method I’ve increasingly used to improve prompts: asking questions.

By doing so I hope to introduce context engineering to beginners and to form discussion with those who also have thoughts about this new field over on X.

Context

To understand prompting, it helps to understand context.

All LLM’s (Large Language Model) like gpt-5.4 or opus-4.6 are stateless by default. Every call starts fresh unless you explicity provide previous messages.

So if you ask a model:

How are you?

The context might look something like this:

After the model replies:

When you ask the same question again, the context looks the same. Remember, the model is stateless.

In ChatGPT, the model doesn’t seem stateless because the app reconstructs the conversation for you. It prepends prior messages so that you can continue where you left off.

That might look something like this:

Why does this matter?

Because the model’s response is shaped by the context it receives.

Tokens (kind of like words) are generated based on the context by predicting what token to give you next.

In other words: what you have told the model dictates what it will reply with. It is not living and all-knowing, and if it appears to be then that’s some clever engineering.

Questions

The cool aspect of questions in prompting is that they let you shape the model’s attention without immediately specifying the final answer.

A question lets you say:

Look over here. Think about this. Help me understand this part before we decide what to do.

This is useful for many reasons:

• You want the model to understand your thinking
• You want to think alongside the model
• You don’t want to lose understanding
• And of course, you may not know the answer

This becomes especially valuable when you are using an agent, which is just a model in a loop with access to tools.

I will focus on my favourite use case: thinking alongside the model.

Thinking alongside the model

Let’s say you are writing code with an agent like Codex with gpt-5.5.

Codex is capable enough that it can be tempting to type something like:

Make a new command that does X.

Often this works. Your code now does X.

But if you are like me you care about how the code does X, what decisions Codex made, and whether those decisions fit the rest of the codebase.

One way to deal with this is to let Codex implement the feature, read through all the changes afterwards, then ask follow-up questions.

That can work, but it has a downside: you are reacting after the model has already gone down a path.

An alternative is to start with a question.

For example:

How does our existing CLI handle errors in similar commands?

This does a few things at once.

It points Codex toward relevant code. It highlights an important concern: error handling. It also asks the model to explore before implementing.

From there, you might continue:

That does not look quite right. The existing command retries too aggressively. I like how it validates input before making the request, though. Can you scaffold what this would look like for the new command without implementing the full feature yet?

Now the context looks something like this:

Notice that we have not simply said:

Build X.

Instead, we have explored the surrounding code, identified patterns we like, rejected patterns we do not like, and made a few decisions together.

The model has contributed, but so have we.

Better Outputs

The model’s response is shaped by its context, so if we want better outputs, we should improve the context before asking for the output.

Questions are one of the easiest ways to do that.

By asking intentional questions, we choose what gets added to the conversation. The model’s answers then become part of the working context for the final task.

Instead of starting with:

Build X.

We might build up to it:

How does this part of the codebase work? Where is error handling already implemented? Which existing command is most similar? What tradeoffs do you see? What would a minimal implementation look like? Now implement it using that approach.

By the time we ask the model to act, it has much more useful context.

It understands the relevant code. It has seen our preferences. It has explored the problem. It has already reasoned about tradeoffs.

This also helps us intercept bad paths earlier.

If the model is going to misunderstand something, I would rather find that out while it is answering a small question than after it has rewritten half the codebase.

Questions let you catch misalignment before it becomes expensive.

Agent-Human Sustainability

There is another reason I like this approach: it feels more sustainable.

I do not want to write a perfect 400-word prompt every time I use an agent. I also do not want to disappear from the process, let the agent run for a while, and then spend all my energy catching up afterwards.

Questions keep me in the loop.

They let me steer without micromanaging. They let the agent do useful exploration while I still make the important decisions. They turn prompting from a one-shot instruction into a conversation.

That makes using agents feel more like collaboration.

Conclusion

A lot of people focus on writing the perfect prompt.

But often, the better approach is not to write one huge instruction upfront. It is to ask the right questions first.

Questions help you shape the context. Context shapes the output.

So if you want better results from models and agents, ask more questions before you ask them to act.