We Built Conversational Machines. Then We Taught People to Write Prompts.

We have spent the last few years learning how to talk to machines. More precisely, we have spent those years learning how to stop talking to them.

Prompt engineering has become an industry of its own. There are frameworks, templates, formulas, cheat sheets and elaborate instruction structures promising to unlock the full potential of large language models. Users are encouraged to construct increasingly precise, comprehensive and carefully formatted prompts before they even begin working with an AI system.

There is something rather peculiar about this development.

We built machines capable of participating in remarkably sophisticated natural-language conversations, trained them on enormous collections of human communication, and then taught people to interact with them as if they were command-line interfaces.

Perhaps we have misunderstood where the actual interface lies.

A prompt is not a conversation

A conventional computer program executes instructions according to explicitly defined logic. Its behaviour is determined by its code, inputs and state. The closer an instruction gets to the expected syntax, the more predictable its execution becomes.

Large language models operate differently. They generate responses through learned statistical representations of language, context and patterns of interaction. Their interpretation of an instruction is not a straightforward execution of predefined commands.

A prompt is still language. It is an input that the model must interpret, contextualise and use to generate a response.

This distinction has practical consequences.

When we write a detailed prompt, we are attempting to anticipate how the model will interpret our intentions. We choose terminology, define constraints, specify output formats and try to eliminate ambiguity.

But we cannot always know which parts of our instructions will receive the most attention, how particular expressions will be interpreted, or whether the model has understood the underlying intention correctly.

A technically impeccable prompt can encode a fundamentally incorrect understanding of the task.

Making it longer does not necessarily make it better.

We don’t think in prompts

Consider how people actually develop ideas.

We rarely begin with a complete specification of what we want. We start with fragments, observations, intuitions and sometimes contradictory requirements. We explore possibilities, reject interpretations, discover constraints and gradually develop a clearer understanding of the intended result.

This is how creative and analytical work often progresses.

We do not usually formulate a complete brief before discovering what the brief should contain.

Conversation accommodates this process naturally.

We can introduce an incomplete idea, see how someone interprets it, correct their assumptions and continue from there. The meaning develops through interaction rather than existing as a fully formed instruction from the beginning.

An LLM can participate in this process.

It can propose interpretations, identify ambiguities, ask for clarification, offer alternatives and incorporate corrections into subsequent responses. The conversation provides context that accumulates across exchanges.

This does not mean that a model understands us in the same way another human does. Its conversational competence emerges from its training and inference mechanisms, not human-like cognition.

But we do not need to assume human cognition to recognise the practical value of conversational interaction.

The model can work with an evolving intention instead of requiring us to translate it into a complete specification upfront.

Conversation as a process of developing shared context

Consider two approaches to creating a complex visual asset.

In the first, the user writes a comprehensive prompt describing composition, materials, lighting, colours, camera perspective, proportions and every relevant detail.

The model interprets the instructions and generates an image.

In the second, the user begins with an idea. The model proposes an interpretation. The user explains what works, what doesn’t and why. They explore alternative compositions, discuss materials, identify unwanted visual conventions and refine the intended direction.

Only when the idea has become sufficiently clear does the model formulate a structured prompt for image generation.

The final prompt may be considerably more precise than anything the user could have written independently at the beginning.

Not because the user has learned to write better prompts, but because the underlying idea has been developed through conversation.

There is an important distinction here: the prompt is no longer the starting point of the process. It is its formalisation.

The model helping to construct the specification has also participated in the discussion that produced it. It has access to the corrections, rejected interpretations and contextual decisions that would otherwise need to be reconstructed in a standalone instruction.

This does not guarantee that the final specification will be correct. Models can introduce assumptions, overlook constraints and confidently formalise misunderstandings. Human evaluation remains essential.

Nevertheless, the workflow changes the nature of the task.

Instead of asking the user to anticipate everything the machine needs to know, it allows the machine to participate in discovering what needs to be specified.

The prompt is an endpoint, not necessarily an interface

This suggests a different way of thinking about prompt engineering.

A prompt is an excellent mechanism for formalising an established intention. It can package decisions into a structured specification, making it useful for execution, automation and repeatable workflows.

But exploring an idea and executing a specification are different activities.

During exploration, ambiguity is not necessarily a problem to eliminate immediately. It is often an essential part of the process. Alternatives need to be considered before decisions can be made.

During execution, ambiguity becomes a liability. The requirements need to be sufficiently precise for the system to produce a predictable result.

Treating these two stages as if they require the same communication method creates unnecessary friction.

Conversation is particularly useful for exploration. Structured prompting becomes particularly useful when the intention is sufficiently established.

The distinction is not between people who know how to prompt and people who don’t. It is between developing an idea and specifying how to execute it.

This applies beyond creative work

The same principle applies to research, analysis, software development and strategic planning.

A researcher may begin with a question that is too broad or based on an incorrect assumption. A conversation can help identify the actual research problem before producing a formal research protocol.

A developer may describe a problem in terms of its visible symptoms. Discussion can expose the underlying architectural issue before generating code.

A business owner may have an intuition about a market opportunity without knowing how to formulate a useful analytical question. Working through the idea conversationally can help establish the relevant variables and constraints.

In each case, the model can help translate an evolving intention into a more formal representation.

This is not an argument against structured instructions. There are situations where they are indispensable: API calls, automated agents, data extraction, structured outputs and repeatable production pipelines all benefit from explicit specifications.

But those are primarily execution problems.

Not every interaction with an LLM is an execution problem.

Stop optimising the instruction. Start developing the understanding.

The growing emphasis on prompt engineering reflects a particular mental model of artificial intelligence: the user has an intention, translates it into instructions, and the machine executes them.

A conversational model offers another possibility.

The user has an intention, communicates it imperfectly, and develops it through interaction. The model contributes interpretations, questions, alternatives and structured formulations. Together, they arrive at a specification that neither side necessarily possessed at the beginning.

The process can be described simply:

Conversation establishes and develops intent.
Discussion exposes ambiguity and competing interpretations.
Iteration refines the shared context.
Formalisation translates the result into explicit requirements.
Execution produces the intended output.
Evaluation determines whether the result actually matches the intention.

This is not the elimination of prompt engineering. It is moving it to the point where it becomes useful.

Perhaps the most important skill in working with large language models is not learning to write increasingly elaborate instructions.

It is learning how to use conversation to discover what needs to be instructed in the first place.

We cannot solve a communication problem simply by making the instruction more complicated.

And perhaps that is the most curious consequence of building conversational machines: we have created systems that can help us think through what we want, only to spend an extraordinary amount of time teaching people to tell them what to do.