Before the Answer
Why the most important AI skill may be knowing when not to ask for a solution just yet
There is a question that regularly appears online as a test of whether large language models can reason:
“The car wash is only 500 metres down the road. Should I walk or drive?”
Occasionally the model recommends walking. The result is then shared as evidence that the machine has somehow missed something obvious. If the purpose of the journey is to wash the car, walking is not particularly useful.
But there is something wonderfully ironic about the example. The model is being criticised for jumping to an answer when the person asking the question has already jumped past the problem.
“Should I walk or drive?” sounds like the question. It isn’t. The underlying question is closer to:
What am I trying to accomplish, and what does that imply about how I should get there?
The absurd answer is partly a failure of reasoning, but it is also a failure of framing. And that distinction is becoming increasingly important.
AI makes answers cheap. That makes the thinking that happens before the answer more valuable, not less.
We were doing this long before AI
Anyone who has spent time around product, engineering or transformation work will recognise the pattern. “We need a dashboard.” “Can we add a notification?” “We should build an app.” “We need an AI assistant.”
The conversation begins with what sounds like a problem but is actually a proposed solution.
One team I worked with spent several rounds designing a reporting dashboard. They had gathered a long list of metrics from people inside the organisation and used AI to help lay them out visually. Different versions were generated. Charts moved around. Information was grouped, regrouped and refined.
The work looked productive. But no one had asked three more basic, and foundational, questions:
- How does the user see the world?
- What are they actually trying to do with this data?
- What are their goals, motivations and decisions?
The team had started with a list of available information and jumped directly to the interface. AI made that jump easier because it could turn a collection of metrics into something that looked like a dashboard almost instantly.
But it could not compensate for the question the team had skipped.
The real problem was not how to arrange the data. It was understanding what information would help a particular person make a particular decision in a particular context. Once that became clear, much of the original dashboard was unnecessary.
We had asked AI how to organise the information before we had asked what the information was for.
This is not a new failure mode. AI simply makes it easier to reach the wrong end of the conversation faster.
Why solutions feel so good
Part of the reason teams jump to solutions is simple: solutions feel like progress.
A problem is ambiguous. It creates uncertainty, exposes disagreement and often makes it difficult to know what to do next. A proposed solution changes the emotional texture of the conversation because suddenly there is something to build, estimate, assign, approve or present.
Action creates relief.
That taps into a familiar human bias toward doing rather than waiting, especially when uncertainty is uncomfortable. But organisations amplify the effect through their own incentives. Most organisations visibly reward movement: shipping, launching, delivering, deciding, closing actions, producing artefacts. They are much less practiced at recognising the value of someone saying, “I don’t think we understand the problem yet.”
That can look like hesitation when everyone else is trying to create momentum. So solution bias is not simply a cognitive quirk. It is often reinforced by the operating environment.
The product team that commits to a feature has something to put on the roadmap. The executive who declares a direction appears decisive. The consultant who brings an answer looks useful. The engineer who starts building creates visible progress. The person who asks whether the underlying problem has been framed correctly may appear to be slowing everyone down.
Uncertainty is psychologically uncomfortable for most people. In many organisations, it can also be professionally inconvenient.
That creates a powerful combination: action bias inside people, and implicit incentives around them.
AI fits almost perfectly into that system because it can transform uncertainty into something that looks like action almost instantly. It does not merely offer an answer; it offers the feeling that the work has moved.
And that distinction matters.
A generated strategy, prototype or requirements document can create the emotional reward of progress before the underlying problem has become any clearer.
AI can turn uncertainty into the appearance of progress faster than we can turn uncertainty into understanding.
AI reduces the cost of premature certainty
Before generative AI, moving from an underdeveloped thought to a polished artefact usually created some friction. Someone had to conduct research, write the document, visualise the idea or build the prototype. Other people became involved along the way, and those interactions sometimes exposed weaknesses in the original framing.
That friction was often inefficient, but some of it was cognitively useful.
AI can collapse much of it. A vague idea can become a compelling strategy in minutes. A loosely framed requirement can become a detailed specification. A proposed feature can become a working prototype before the team has properly established whether the underlying problem exists.
This is an extraordinary capability. It also creates a new risk:
AI reduces the cost of being pre-maturely certain.
A poorly framed problem can now become a beautifully executed solution before anyone notices that the framing was wrong. The danger is not simply that the machine might give us the wrong answer. It is that fluency can make an inadequately framed question feel sufficiently answered.
Every prompt contains a theory of the problem
We tend to talk about prompts as instructions: “Summarise this.” “Write that.” “Compare these.” “Tell me whether I should do A or B.”
But a prompt does more than instruct a model. It defines a world.
It contains assumptions about what matters, which choices are available, what success looks like, what context is relevant and sometimes even what kind of answer is legitimate. “Should I walk or drive?” assumes the decision is fundamentally about transport. “We need a dashboard” assumes visibility is the problem. “Design an AI assistant for our sales team” assumes an assistant is the intervention. “Should we build feature A or feature B?” assumes one of those features should be built.
Every prompt therefore contains a compressed theory of the situation. Sometimes that theory is good enough. But, sometimes it is the most important thing to challenge.
This is why prompting cannot simply become a new form of command-line literacy: learning increasingly sophisticated ways of extracting a desired output from a model. The more consequential use of AI may be learning how to use it before the problem has hardened into a request.
The answer creates gravity
Something changes once an idea has been rendered into a convincing artefact. It gains weight.
A rough thought is easy to question; a polished strategy is harder. A vague product idea can be abandoned over coffee. A clickable prototype shown to executives has already begun acquiring stakeholders.
The answer creates what we might call framing gravity: the tendency for subsequent thinking to be pulled toward the assumptions embedded in the original request.
Once the model has produced an articulate recommendation, the conversation often shifts from:
“Have we understood this correctly?”
to:
“Is this answer right?”
That is a much narrower question. The team starts adjusting the solution rather than reopening the frame. The original assumptions disappear into the background while the generated artefact becomes the new object of attention.
I saw this in an AI-generated user research report. At first glance, it looked convincing. The themes were clear, the findings sounded plausible and the recommendations were neatly expressed. Product decisions began to form around it.
But at a surface level, something fundamental had never been resolved: the target users and buyers had not been clearly defined.
At a deeper level, the polished report created an even bigger problem. It gave the team enough confidence to delay talking to actual customers.
The artefact did not merely contain assumptions. It made those assumptions feel settled. So instead of using the report as a hypothesis to test, the organisation began treating it as evidence.
That false-positive confidence created an additional barrier to discovery. The team already appeared to “know” what customers wanted, so conversations with real customers felt less urgent. The first meaningful learning only arrived later, when the product met the market. By then, the cost of being wrong was much higher.
The problem was not simply hallucination or poor research quality. It was that apparent completeness arrived before genuine understanding.
The report did not replace customer research.
It replaced the team’s felt need for customer research.
That is a more dangerous failure mode than an obviously bad answer, because a plausible answer can close inquiry. And once inquiry closes, the organisation starts learning from its own artefacts rather than from reality.
Vibe coding may be the extreme case
Vibe coding makes this dynamic particularly visible.
For most of software history, building something created a natural delay between an idea and its manifestation. Requirements had to be translated, architecture had to be considered, code had to be written and people had to collaborate. There were many inefficiencies in that process, but there were also moments in which the idea encountered resistance.
Someone might ask what the user was actually trying to accomplish. An engineer might expose an assumption. A designer might discover that the proposed interaction made little sense. The cost of building created an incentive, however imperfect, to think before making.
Vibe coding radically lowers that cost. You can begin with an intuition and have something apparently functional before you have properly articulated the problem.
That is an extraordinary democratisation of making. It is also an extraordinary acceleration of premature solutioning.
The danger is not that people without traditional coding skills can now build software. That is potentially enormously valuable. The danger is that the existence of the artefact can start standing in for evidence that the artefact should exist.
A prototype appears. People react to it. Features are added. Edge cases are fixed. The interface improves. Very quickly, the organisation is answering increasingly sophisticated questions about a solution whose original premise remains strangely under-examined.
In a pre-AI world, the cost of implementation created pressure to understand the problem first. As implementation approaches zero cost, that pressure disappears.
That changes the economics of thinking. When making was expensive, the organisation worried about building the wrong thing because the waste was visible. When making becomes almost free, building the wrong thing can feel harmless.
But the cost has not disappeared. It has moved.
It appears in attention, maintenance, complexity, security, duplicated tools, fragmented workflows and the opportunity cost of people adopting something that should perhaps never have progressed beyond an idea.
The paradox of vibe coding may therefore be: The cheaper it becomes to build, the more expensive it becomes not to think.
Get @dalladay’s stories in your inbox
Join Medium for free to get updates from this writer.
There is another important distinction here. Cheap making does not have to accelerate commitment; it could expand exploration.
A disposable prototype used to learn something is very different from a prototype that quietly becomes production because it happens to work. The same artefact can serve either purpose. The cognitive frame matters.
Build quickly, but remain slow to conclude what the thing means.
Used well, vibe coding could make solution spaces cheap enough to explore without forcing attachment to the first plausible answer. The capability is not merely to build the answer faster. It is to build enough possible answers that we become better at understanding the question.
Ask what would need to be true
One of the most useful changes I have seen is surprisingly small.
A team I worked with was targeting a particular exit valuation. The ambition was clear, but the reasoning behind it was not.
Different people held different assumptions about what the business would need to look like to justify that valuation: growth rate, margins, market position, customer concentration, defensibility, management depth, recurring revenue quality. Everyone had part of the picture, but there was no shared model.
The obvious AI interaction would have been for one person to ask:
“How do we achieve a 10x revenue multiple?”
That would probably have produced a convincing report full of benchmarks, recommendations, actions and perhaps even a roadmap.
Instead, we sat together and asked a different question:
“Please explain what conditions would need to be true for a business in our industry to achieve a 10x revenue multiple, and the reasons why?”
The difference was subtle, but important. We were no longer asking the AI to solve the problem for us. We were asking it to help us construct the problem space.
It produced a long set of conditions that we could then work through together. Some exposed gaps. Others revealed strengths the team had been underestimating. Several surfaced assumptions that different people had been carrying without realising they were not shared.
The value was not the list itself. The value was that the list became a shared object for thinking, and aligning on what needed to change.
Instead of one person disappearing to produce “the answer”, the team used AI to make its assumptions visible, compare interpretations and build a common view of what would actually have to be true.
That changed the conversation from:
“How do we get to 10x?”
to:
“What would have to be true for 10x to be justified?”
The first question invites a plan. The second invites understanding.
Only once the team had a clearer picture of the conditions could it sensibly discuss which actions might move them toward them.
Sometimes the better prompt is not “How do we achieve this?” but “What would need to be true for this to make sense?”
Better prompting should begin by widening the problem
The standard interaction with an AI system often looks something like:
Ask → Answer → Act
For simple and well-understood tasks, that may be perfectly appropriate. For ambiguous or consequential problems, it is often too compressed.
A more useful sequence might be:
Explore → Frame → Challenge → Solve
Before asking AI for an answer, we can ask it to help construct a better question:
- What assumptions are embedded in how I have described this problem?
- What important context appears to be missing?
- What alternative explanations should we consider?
- What information would materially change our understanding?
- What would have to be true for the proposed solution to make sense?
This is not simply better prompting. It is a different cognitive relationship with the model.
The AI moves from being a machine that responds to framed problems to something that can participate in framing itself.
The most useful answer may be another question
Imagine the car-wash example again.
“The car wash is only 500 metres down the road. Should I walk or drive?”
A useful model could answer:
“What are you going there to do?”
That may be a better response than either walking or driving because the system has noticed that the choice cannot be separated from the purpose.
This seems trivial in the car-wash example. Inside organisations, it is not.
A leader asks, “Which of these markets should we enter?” The useful response might be, “What strategic outcome are you optimising for?”
A product team asks, “What should we build to improve retention?” The useful response might be, “What evidence suggests product capability is the cause of churn?”
An organisation asks, “How should we automate this process?” The useful response might be, “Why does this process exist in its current form?”
The intelligence of the system is not demonstrated only by producing an answer. Sometimes it is demonstrated by challenging the frame.
We need framing hygiene, not just prompting hygiene
Much of current AI literacy focuses on getting better outputs: provide more context, specify a role, give examples, define the format, iterate.
These techniques can improve the answer. But they can also make a bad question produce an even better-looking answer.
There is therefore another capability we need before prompt engineering: framing hygiene.
Before asking “How should I prompt the model?”, ask “What cognitive task should be happening at this moment?”
Are we exploring, sense-making, framing, testing evidence, challenging assumptions, choosing, generating, deciding or executing?
The answer determines the appropriate role of AI.
A system designed to generate when the team should still be framing is not merely being used badly. It has been assigned the wrong cognitive responsibility.
That matters because AI can be much more than an answer machine. It can surface assumptions, separate evidence from inference, generate competing framings, expose contradictions, ask what information is missing, represent perspectives absent from the room and help teams understand what would have to be true before they decide what to do.
That is a much richer role than producing the answer faster.
This is another form of cognitive infrastructure
The wider organisational system still matters.
If an organisation habitually rewards immediate answers, AI will make immediate answers easier to produce. If meetings are structured around proposals rather than problems, AI will create better proposals. If teams are rewarded for delivery rather than discovery, AI will accelerate delivery.
The model enters a pre-existing theory of how work should happen.
So good framing cannot be delegated entirely to the individual writing the prompt. Do teams have time to explore ambiguity? Are leaders comfortable hearing, “we do not yet understand the problem”? Are requirements allowed to remain provisional? Do people distinguish evidence from inference? Can AI challenge the premise of a request rather than merely satisfy it? Does the organisation reward the person who reframes the problem, or the person who produces the solution fastest?
These are cultural and organisational design questions, not prompt-engineering questions.
The same Cognitive Infrastructure that helps an organisation convert intelligence into outcomes must also shape what happens before intelligence is generated at all.
Because if the frame is wrong, better downstream execution simply makes the mistake more efficient.
Before the answer
AI makes answers cheap. That makes the quality of the question, and the thinking that happens before it, more valuable, not less.
The danger is not simply that AI solves the wrong problem. It is that it can solve the wrong problem so quickly, convincingly and completely that we stop noticing it was the wrong problem in the first place.
The new discipline is therefore not to avoid answers. It is to earn them.
Before asking the AI what to do, we may need to ask what is happening. Before asking for the solution, we may need to examine the frame. Before asking which option is best, we may need to understand what outcome matters.
And before asking whether we should walk or drive, it may be worth remembering why we are going to the car wash at all.
The most important AI skill may not be knowing how to get the model to answer. It may be knowing when not to ask for the answer yet.
This is the forth article in The Last Mile of AI series.
Previous article: “Does AI need an Andon Cord? What Toyota understood about scaling judgement, before intelligence became abundant”
Next article: “Intelonomics — Why the cheapest intelligence can end up being extraordinarily expensive”
Are you a leader not seeing the expected value from AI? Book a Last Mile Diagnosis call with us.
Craig Wright and I explore this territory through UN/DO, a strategic futures studio focused on the cognitive infrastructure that helps organisations turn intelligence into meaningful outcomes.
Some anecdotes and examples in this article have been anonymised or combined to protect confidentiality.
