SUN, OCTOBER 04, 2026
Independent · In‑Depth · Practitioner‑Tested
Claude Productivity

Six Prompts to Tell a Search Problem From an Insight Problem

Meta published six mathematics papers with Muse Spark today, and two of the results are disproofs by counterexample - which is a search task. Define the space, generate candidates, test them, keep going. The model was strongest exactly there and weakest where the work was constructing an argument that holds for every case. That distinction is not about mathematics. Most of what you hand a model is one shape or the other, and knowing which before you start is the difference between a useful afternoon and a confident wrong answer. These six prompts sort your work.

⌨️ 6 prompts 🕐 Updated Oct 4, 2026
💡 How to use these prompts: Replace everything in [BRACKETS] with your specific details before sending. Click Copy to copy any prompt to your clipboard instantly.
1
Sort the Task Before You Start It
Ask this first, every time. A model that sounds equally confident on both shapes is not equally reliable on both.
Here is what I am trying to do: [describe the task].<br/><br/>Tell me which of these it actually is:<br/>1. SEARCH - there exists a thing, and the work is finding it among many candidates. A counterexample, a bug, a precedent, a supplier, a phrasing that works.<br/>2. INSIGHT - the work is constructing something that holds across all cases. A proof, an architecture, a strategy, an explanation of why.<br/>3. BOTH, in sequence - and if so, say where the handover is.<br/><br/>Then tell me honestly where you are likely to be useful and where I should expect you to produce something fluent and wrong.
2
Define the Space Before Searching It
A search with a fuzzy success condition returns whatever the model thinks you want. The definition is the work.
I want to search for: [what you are looking for].<br/><br/>Before generating anything, help me define the space properly:<br/>- what counts as a candidate and what does not<br/>- what the boundaries are, and which ones are real constraints versus assumptions I have carried in<br/>- what a hit looks like, precisely enough that we would both agree when we see one<br/>- roughly how large the space is, and whether exhaustive search is feasible or we need to sample<br/><br/>If my definition of a hit is vague, say so and make me fix it before we start.
3
Generate Candidates Without Grading Them
Models self-censor toward plausible answers, which is the opposite of what a search needs. Separate generation from judgement.
Generate [number] candidates for: [the search target].<br/><br/>Rules: do not evaluate them as you go, do not stop at the ones that look promising, and do not cluster around the obvious region of the space. I want coverage, including the ugly and the unlikely.<br/><br/>After the list, tell me which regions of the space you did NOT cover and why - that gap is more useful to me than another ten candidates from the middle.
4
Make It Prove the Hit
Finding a candidate is the cheap half. A search result nobody verified is a guess with extra steps.
Here is a candidate that looks like it solves my problem: [paste].<br/><br/>Do not tell me whether it is good. Tell me how to VERIFY it, concretely - what I run, what I check, what result would confirm it and what result would kill it.<br/><br/>Then try to kill it yourself. Find the case where it fails, the assumption it depends on, the reason it might only look right.<br/><br/>If you cannot break it, say what you tried, so I know what the verification actually covered.
5
Handle the Insight Half Differently
On insight work, the useful output is a map of the territory. Treat a confident conclusion as a warning sign.
This part of my problem is an insight problem, not a search: [describe it].<br/><br/>Do not give me an answer. Instead:<br/>- lay out the possible approaches and what each one would require to be true<br/>- tell me which parts you can check and which parts need my judgement<br/>- flag anywhere you would be pattern-matching to something that looks similar rather than reasoning about my specific case<br/><br/>I want the structure of the problem, not a confident conclusion.
6
Audit Where You Have Been Using It Wrong
The failures that hurt are the ones that produce a fluent answer nobody checks. Find those before they compound.
Here is a list of things I regularly use AI for: [list them].<br/><br/>Sort each into search, insight, or both. Then tell me:<br/>- which ones I am probably getting good results on and should do more of<br/>- which ones are insight work that I have been treating as search, where the output looks fine and may not be<br/>- which ones I have not tried that are clearly search-shaped and would benefit<br/><br/>Be specific about the second group. That is the one that costs me without showing it.