Questions to Ask AI
The general set: twenty questions to type into an AI assistant when you want work you can rely on rather than text that reads well. They run from getting the request right at the start, through pressure testing the answer you were given, to working out what the tool in front of you can and cannot reach. For anyone using a chatbot for research, writing or decisions. If you use the same assistant every day, Questions to Ask Your AI deals with memory, saved instructions and knowing when to start fresh.
The questions
Open any question for the note
What do you need from me to answer this well?
Why ask it
Turns a guess into a brief. Assistants fill gaps silently when context is missing, so asking first surfaces the details that were going to be invented: audience, length, format, constraints. If the reply is that nothing else is needed on a genuinely underspecified task, expect a generic answer.
What was ambiguous in what I just asked?
Why ask it
Most disappointing output traces back to a prompt that could be read two ways. The answer shows you which reading was chosen, which is usually more useful than the answer itself, and it costs one line to fix rather than several rounds of correction.
What are you assuming about what I want here?
Why ask it
Assumptions get baked in without ever being stated: a country, a skill level, a legal system, a tone. Seeing them listed lets you correct the one that is wrong. Watch for assumptions presented as facts about your situation, which is where confident irrelevance comes from.
Can you show your reasoning step by step so I can check it?
Why ask it
Written out steps are checkable in a way that a conclusion is not, and errors usually sit in one identifiable step. Be aware that the explanation is generated alongside the answer rather than being a transcript of how it was produced, so treat it as an argument to audit, not a confession.
Where are you least confident in that answer?
Why ask it
Often produces the most valuable line in the whole exchange, because it points you at the part to verify first. A reply that claims uniform confidence across a complicated answer is itself the warning sign, particularly on anything involving numbers, dates or law.
What did you leave out?
Why ask it
Answers are shaped toward being tidy, and inconvenient exceptions, edge cases and caveats are what get trimmed. Asking directly tends to recover them. This is worth doing on any answer you are about to act on rather than just read.
Which of these claims can I verify, and how?
Why ask it
Forces a split between things with a checkable source and things that are the model's own synthesis. The second group is where errors live. If everything comes back as verifiable but no specific source is named, treat that as a no.
If this answer turns out to be wrong, which part will it be?
Why ask it
A sharper version of asking about confidence, because it demands a specific candidate rather than a hedge. Good answers name the step that rests on an assumption, an old figure or a detail about your situation that was never supplied.
What is the strongest argument against what you just told me?
Why ask it
Tests whether you were handed a considered position or the most commonly repeated one. A weak strawman in reply tells you the original answer was probably the consensus view restated, and that you should look for the real disagreement elsewhere.
How would somebody who disagrees with this put it?
Why ask it
Asking for the other side in its own words gets past the flattening tendency to present all views as roughly equivalent. Useful when you need to anticipate objections from a colleague, a client or a reviewer rather than decide who is right.
Give me three options with the trade-offs instead of one recommendation.
Why ask it
Single recommendations arrive with the reasoning already collapsed. Options make the criteria visible, which is what you actually need to choose. If the three come back with one obviously padded to make another look good, ask what the second best option is and why.
Rewrite that at half the length, and tell me what you cut.
Why ask it
The cut list tells you what the assistant treated as expendable, which is a fast way to find filler in your own writing too. It also exposes an answer whose length came from repetition rather than content, since a genuinely dense passage cannot halve without losing something you notice.
Explain the same thing again as if I have never worked in this area.
Why ask it
A second pass at a lower level catches the term you nodded along to. It also reveals whether the first answer was actually understood or assembled from jargon, because vague explanations tend to stay vague when the vocabulary is taken away.
What would you ask an expert if one were sitting here?
Why ask it
Produces the open questions rather than the settled ones, which is a good map of where your problem is genuinely uncertain. Often the list points at the thing you should be researching instead of the thing you asked about.
What question should I have asked instead of the one I did?
Why ask it
Useful when you suspect you are working from the wrong frame. The reply may be a reframing that saves you the next three prompts, or it may be flattery about your excellent question, which tells you the assistant is agreeing rather than thinking.
Is any of this likely to be out of date, and what should I check?
Why ask it
Prices, laws, software versions, product names and organisational details go stale first. What you want is a list of items to re-check and where, not a general disclaimer. Anything about the last year or two deserves independent confirmation regardless of the answer.
What do you not have access to in this conversation?
Why ask it
Files you have not attached, pages behind logins, your calendar, the current date, anything on your own machine. Getting this stated stops you from asking for work that will be filled in with invention instead of refused.
Do you carry anything over from earlier conversations with me?
Why ask it
The answer varies by product and by setting, and getting it wrong cuts both ways: repeating context that was already stored, or assuming it remembers a preference it has never seen. Check the product's memory settings as well, since the assistant may not describe them accurately.
What happens to what I type here?
Why ask it
Ask, but treat the reply as a starting point rather than an authority. A model describing its own data handling is generating a plausible answer, and the binding facts are in the provider's terms and your account settings. Confident reassurance that nothing is retained is the answer to trust least.
Which parts of this task are you good at, and which should I do myself?
Why ask it
A closing question worth asking on any substantial piece of work. Drafting, restructuring, summarising and generating options tend to be strong. Anything hinging on current facts, exact numbers, judgement about people or accountability for the outcome is yours, and a reply that claims all of it is a reason to check more carefully.
Getting work you can rely on
Practical guidance for the conversation itself
Self-description is generated, not introspected
When you ask an assistant how it works, why it answered as it did, or what it can remember, the reply is produced the same way as any other answer: as plausible text. Some of it will be accurate because it was written into the system by the people who built it, and some will be reasonable inference. None of it is a readout of internal state. Ask anyway, since the answers are often useful, but check anything consequential against documentation or your own testing.
Front load the context
- 1Say who the output is for and what happens to it next. Audience and destination change the answer more than any instruction about tone.
- 2Give the constraints as numbers: length, budget, deadline, reading level, format.
- 3Paste the real material rather than describing it. A sample of your own writing, the actual error message or the genuine data beats a summary of them.
- 4Show one example of what a good answer looks like when you can. One example moves output further than a paragraph of adjectives.
- 5Say what you have already ruled out, so you do not get it back as a suggestion.
Pressure test before you use it
- Ask for the weakest part of the answer, then check that part yourself first.
- Push back once on something you know is right, and see whether the assistant holds its position or folds. That tells you how much its agreement is worth.
- For anything factual, ask where each claim comes from, then confirm the source exists and says what was claimed.
- Ask the same question in a fresh conversation and compare. Answers that vary on substance rather than wording mark an area of low reliability.
- For numbers, ask it to compute a second way, or check them yourself. Arithmetic done in prose is where quiet errors hide.
Common pitfalls
Reading fluency as accuracy
Clear, well organised prose is produced regardless of whether the content is right. Confidence and polish carry no information about correctness, and this is the single most expensive habit to unlearn.
Accepting the first draft because it is close
Output that is nearly right is where most of the wasted effort goes, because the remaining problems are the subtle ones. One round of asking what was left out and what is weakest usually costs less than editing around the gaps.
Asking for a decision instead of the inputs to one
An assistant has no stake in the outcome and no knowledge of what you can live with. Asking for options and trade-offs keeps the judgement where it belongs.
Pasting things you cannot get back
Client data, medical details, credentials and anything covered by an agreement deserve a check of the settings and terms before they go into a text box, whatever the assistant tells you about its own handling.
Letting a long conversation drift
Constraints set early quietly stop being applied as a thread grows. If accuracy matters, restate the important requirements or start again with a clean summary of where you are.