The XY Problem Got Worse With AI. Here's the Prompt Habit That Fixes It.
LLMs answer the step you asked about, not the goal behind it. Why they rarely push back, and a four-line template that makes them.

Here's a question that has been asked on programming forums thousands of times, in one form or another:
How do I get the last three characters of a filename?
The answer is easy:
ext = filename[-3:]
It works on report.txt. Then someone uploads report.json and you get son.
The person never wanted three characters. They wanted the file extension, and they'd already decided "last three characters" was how to get it. The question they asked was their guess, not their goal. The fix for the real goal is different code:
import os
ext = os.path.splitext(filename)[1] # ".json", ".md", ".yaml", ".txt"
That's the XY problem, named and explained on xyproblem.info: you want X, you decide Y is the route, you get stuck on Y, and you ask about Y. Nobody hears about X.
On a forum, a good human usually catches it. They reply "what are you actually trying to do?" An AI assistant, by default, mostly doesn't. It answers Y, correctly and politely, and you leave with working code for the wrong problem.
Why LLMs answer the step instead of the goal
The intuitive explanation is that the model can't see past your framing. The research suggests something more useful: it often can, it just doesn't unless the prompt asks it to.
A 2025 paper, Don't Take the Premise for Granted (arXiv 2505.23715), gave 15 models math word problems containing a planted flaw (a contradiction, a broken solution step, an irrelevant question) and measured how often each model flagged the flaw unprompted versus when told to check the premises first.
| Model | Flagged on its own | Flagged when told to check |
|---|---|---|
| GPT-4o | 11.0% | 57.4% |
| GPT-4.1 | 28.2% | 73.2% |
| o4-mini | 4.0% | 74.2% |

The authors' conclusion: many models don't engage critically unless explicitly prompted. Detection also dropped as problems got harder.
Two related results:
- FalseQA (Hu et al., ACL 2023): fine-tuning on a modest set of examples, around 256, was enough for models to learn to recognize false-premise questions. A small nudge, a large shift, which suggests the knowledge was already there.
- CLAMBER (ACL 2024, ~12,000 ambiguous queries): models were weak at noticing ambiguity and asking useful clarifying questions. Chain-of-thought and few-shot prompting helped only marginally and could increase overconfidence.
The ability to question your premise exists. The habit doesn't. Your prompt decides which one shows up.
Caveat worth stating: those are math problems with planted errors, not your codebase. Exact rates will differ. The gap is the point.
Why this is worse than a wrong answer
A wrong answer fails loudly. A right answer to the wrong question passes: the step works, the test is green, the ticket closes, and the real problem resurfaces later with no link back to the conversation that caused it.
You can verify the step, so the answer feels verified. (Related: Why AI Feels Smarter About Topics You Don't Know.)
Common symptom fixes an assistant will happily write, because you asked for exactly that:
| You ask | The goal it hides | What often actually helps |
|---|---|---|
| Raise the HTTP timeout to 60s | Page loads fast | Fix the query that got slower as data grew |
| Add a retry around this call | Call succeeds | Find why it fails; retries can amplify load |
| Wrap this in try/except | Stop the crash | Understand what the exception was protecting |
| Add an index on this column | Query is fast | Check whether the planner will use it (why it often won't) |
| Increase the connection pool size | Requests stop queueing | Find what holds connections too long (pool exhaustion) |
| Disable SSL verification | Request succeeds | Fix the certificate chain |
Four shapes of a hidden guess
| Shape | Sounds like | The tell | Rewrite |
|---|---|---|---|
| Method question | "How do I make X do Y?" | A mechanism is already in the question | "I'm trying to [goal]. My plan was [Y]. Is that the right approach?" |
| Narrowed choice | "Redis or Memcached?" | Two options, both yours | "Here's the problem. I'm considering these two; tell me if neither fits." |
| Fix request | "Make this error go away." | The error is the subject | "Explain what this error is telling me first, then fix the cause." |
| Loaded premise | "Why is A faster than B?" | States an unchecked fact | "Is A faster than B? If so, why?" |
The fix request deserves extra suspicion with coding tools. The fastest way to make an error disappear is to stop it from being raised, and models know that too.
The Goal Line: a prompt template

Before any request that already contains a method, add four lines:
Goal: <what you're actually trying to achieve, and what "done" looks like>
Guess: <the step you were about to ask for — labeled as a guess>
Permission: If there's a better route to the goal, say so before answering the step.
One question: If one question would change your answer, ask it first. Just one.
Applied to a real request:
BEFORE
How do I raise the HTTP timeout on this request to 60 seconds?
AFTER
Goal: The recent-orders page should load in under 2 seconds,
including for customers with long order histories.
Guess: I was going to raise the request timeout to 60s,
because it currently fails at 30s.
Permission: If there's a better route to the goal, say so
before answering the step.
One question: If one question would change your answer,
ask it first. Just one.
Why each line exists:
- Goal gives the model a success condition. That's what lets it notice the step can't reach it: a 60-second timeout never yields a 2-second page.
- Guess turns your method from a constraint into a hypothesis. This is the line people skip and the one that matters most.
- Permission is the explicit "check the premise" instruction the research says most models need. "Before answering the step" means you still get the step when it was right.
- One question caps clarification. Unlimited permission becomes an interrogation; one forces the highest-leverage question.

Make it a standing instruction
Paste this into custom instructions, a project rules file, or your coding agent's rules file:
When my request names a specific method or tool, treat it as
my guess, not a requirement. If a different approach would
better serve the goal I've stated (or the obvious goal behind
the request), say so in one or two sentences before answering.
If my request rests on a premise that looks wrong, point that
out first. Ask at most one clarifying question, and only if
the answer would change your response.
It can't invent a goal you never typed, but it flips the default from "finish the step" to "check the step, then finish it."
Coding agents: write tickets as outcomes, not steps
With agents, the guess usually lives in the ticket. Tickets written as steps get executed as steps.
STEP TICKET (agent will do exactly this)
Add a retry to the payment webhook handler.
OUTCOME TICKET (agent can choose the route)
Webhook deliveries from the payment provider must not be lost
when our handler is slow, and must never be processed twice.
Current idea: add a retry. Push back if a queue or a faster
handler is the better fix.
The Zoom-Out Test (for answers you already have)
Before merging an AI-assisted change, ask:
If this works perfectly, is my actual problem gone, or just the symptom I described?
If it's the symptom, you solved Y. Go back and ask about X.
When not to use it
- The step is already decided (compliance, convention, a migration in flight). Keep the goal, revoke permission:
Constraint: we're staying on X. Don't suggest alternatives. - The step is the goal. "Which
grepflag ignores case?" has no hidden X. - The model starts second-guessing everything. That's the price of permission. Add the constraint and move on.
Use it when the question contains a mechanism you picked under pressure.
Key Takeaways
- Most "how do I" questions contain your guess at a solution with the goal deleted. That's the XY problem.
- LLMs can often question a flawed premise but rarely do unprompted; in one 2025 benchmark, an explicit "check the premises" instruction raised detection for three popular models from 4–28% to 57–74%.
- A correct answer to the wrong question is more dangerous than a wrong answer, because it passes every check you'd run.
- Watch for four shapes: method questions, narrowed choices, fix requests, loaded premises.
- Use the Goal Line (Goal, Guess, Permission, One question) or set it as a standing instruction.
- For agents, write tickets as outcomes with constraints, not steps.
FAQ
What is the XY problem?
The XY problem is when someone asks about their attempted solution (Y) instead of their actual goal (X). Helpers end up solving Y, which may be a poor route to X. The classic example is asking for the last three characters of a filename when you want the file extension.
Why doesn't ChatGPT or Claude ask clarifying questions more often?
Assistants default to answering the request as written. Research such as the CLAMBER benchmark (ACL 2024) found current LLMs weak at identifying ambiguity and asking useful clarifying questions, with chain-of-thought and few-shot prompting helping only marginally.
Can AI detect a false premise in my question?
Often, yes, if asked. In a 2025 study (Don't Take the Premise for Granted), GPT-4.1 flagged flawed premises in math problems 28.2% of the time unprompted and 73.2% when told to check the premises first. The capability is there; the default behavior isn't.
How do I get AI to challenge my approach instead of just following it?
State your goal and success condition, label your planned step as a guess, and explicitly give permission to suggest a better route before answering. Limit it to one clarifying question so it doesn't stall.
Does this apply to AI coding agents?
Especially. Agents execute tickets literally, so a ticket written as a step ("add a retry") becomes that step. Write tickets as outcomes plus constraints and say your current idea is open to pushback.
When should I not use goal-first prompting?
When the step genuinely is the goal (simple syntax or flag lookups), or when the approach is fixed by constraints the model can't see. In the second case, state the goal but add an explicit constraint against alternatives.
Related reading
- Why Your AI Answers Are Mediocre (And the 7 Prompt Fixes That Change Everything)
- Your AI Is Answering a Version of You That Doesn't Exist — AI memory keeps your questions and loses your reasons
- You're Using AI Like a Search Bar. That's Why It's Disappointing You.
- Why AI Feels Smarter About Topics You Don't Know
The bottom line
The most useful thing a senior engineer ever says is "wait, what are you actually trying to do?" AI can ask it. It mostly won't unless you invite it, so put the goal on the page before anyone has to ask.
AI will finish your step every time. Whether it's the right step stays your job, until you hand it the goal.
New here? Start Here: A Plain-English Map to Understanding AI · Get one of these in your inbox each week: subscribe on Substack
Adam Jaber is a software engineer who writes Simply Explained: complex topics, made simple. No jargon, no hype.
About the author
- I'm a software engineer who spends most days building systems that solve real problems. When I'm not shipping code, I'm either untangling a tricky problem or writing about what I learned doing it. Currently exploring AI on the side.
Comments
Join the discussionNo comments yet. Be the first to comment.




