Prompting on TurboVision

The Myth of Prompting as Conversation

Mon, 13 Apr 2026 00:00:00 +0000

The phrase “just talk to the model” is one of the most successful half-truths in the current AI boom. It is good onboarding and bad description: useful for getting people in the door, and deeply misleading the moment anything expensive, fragile, or embarassingly public depends on the answer.

TL;DR

Prompting is conversational only at the surface. Under real workloads it behaves much more like specification-writing for a probabilistic component inside a larger system, except the specification keeps pretending to be a chat.

The Question

Have you ever wondered why everyone says prompting is basically conversation, yet good prompting looks less like chatting and more like writing instructions for a very literal, very strange coworker with infinite patience and inconsistent memory?

The Long Answer

Because “conversation” describes the feeling of the exchange, not the job the exchange is actually doing.

The Surface Still Feels Like Conversation

If I ask a friend, “Can you take a look at this and tell me what seems wrong?” the friend brings a whole life into the exchange. Shared background. Common sense. Tone-reading. Social repair mechanisms. Tacit norms. A strong instinct for what I probably meant even if I said it badly. Human conversation is robust because it rides on an absurd amount of shared context that usually never gets written down.

A language model has none of that in the human sense. It has pattern competence, not lived context. It can imitate tone, infer intent surprisingly well, and reconstruct missing links much better than older software ever could, but it still needs something people keep trying to smuggle past it: framing discipline.

This is why casual prompting and serious prompting diverge so sharply.

Casual prompting thrives on vague intention:

Give me some ideas for this title.

Serious prompting, by contrast, starts growing scaffolding almost immediately:

what the task is
what the task is not
what inputs are authoritative
what constraints matter
what output shape is required
when uncertainty must be stated
when tools may be used
what to do when evidence conflicts

Notice what happened there. The “conversation” did not disappear, but it got demoted. It became the friendly outer layer wrapped around a stricter interaction frame. That frame is the real unit of control.

Hidden Assumptions Become Explicit Scaffolding

This is easiest to see in agentic systems. A normal chatbot can get away with charm, improvisation, and soft interpretation because the downside of a slightly odd answer is usually low. An agent that edits files, runs commands, manages tickets, or handles real work cannot survive on charm. It needs boundaries. It needs tool policies. It needs escalation rules. It needs failure handling. It needs a memory model. It needs a way to distinguish plan from action and action from reflection.

In other words, it needs architecture.

That is why the romantic phrase “prompting is conversation” becomes increasingly false as the stakes rise. Conversation does not vanish. It becomes the user-facing veneer over a stricter operational core.

The better analogy is not a chat with a friend. It is a briefing.

A good briefing can sound relaxed, but its job is exact:

establish objective
define environment
state constraints
clarify resources
identify known unknowns
specify expected deliverable

That is much closer to good prompting than ordinary small talk, even if the software keeps trying to flatter us with the aesthetics of conversation.

You can feel this most clearly when a model fails. Humans in conversation usually repair failure socially. We say, “No, that is not what I meant.” Or: “I was talking about the earlier file, not the second one.” Or: “I was asking for strategy, not code.” We do not usually treat that as a protocol error. We treat it as normal conversational life.

With a model, the same repair process often reveals something uglier: the original request was under-specified. The failure was not just a misunderstanding. It was an interface defect dressed up as a conversational wobble.

That shift is intellectually valuable. It forces us to admit how much human communication usually gets away with by relying on context that never needed to be written down.

Once we notice that, prompting becomes a mirror. It shows us that many tasks we thought were simple were only simple because other humans were doing heroic amounts of implicit reconstruction for us.

Take a mundane instruction like:

Review this code.

To a human reviewer in your team, that may already imply:

prioritize correctness over style
look for regressions
mention missing tests
keep summary brief
cite specific files
avoid re-explaining obvious code

To a model, unless those expectations are already anchored in some persistent context layer, each one is only probabilistically present. So the prompt expands. Not because models are stupid, but because hidden expectations are expensive and ambiguity gets more expensive the moment automation touches it.

This is why I resist the lazy claim that prompt engineering is “just learning how to ask nicely.” No. At its best it is the craft of dragging latent expectations into the light before they become failures.

Conversation and Interface Pull in Different Directions

And once you put it that way, the social and technical layers snap together.

Conversation is optimized for flexibility and repair. Interfaces are optimized for repeatability and transfer.

Prompting sits awkwardly between them.

That awkwardness explains most of the current confusion in the field. Some people approach prompting like rhetoric: persuasion, tone, phrasing, psychological nudging, vibes. Others approach it like systems design: schemas, role separation, state management, tool boundaries, evaluation. Both camps touch something real, but the second camp is much closer to the long-term truth for serious systems.

The conversational framing remains useful because it lowers fear. It invites non-programmers in. It gives people permission to start without mastering syntax. That is not trivial. It is a genuine democratization of access, and I would not sneer at that.

But the price of that democratization is conceptual slippage. People start believing that because the interface feels human, the control problem must also be human. It is not.

A human conversation can survive ambiguity because the humans co-own the recovery process. A machine interaction only survives ambiguity when the system around it has already anticipated the ambiguity and constrained the damage.

That is why good prompt design increasingly looks like this:

separate stable system instructions from task-local instructions
define tool contracts precisely
provide authoritative context sources
demand visible uncertainty when evidence is weak
specify output schema where downstream code depends on it
keep room for natural-language flexibility only where flexibility is actually useful

This is not anti-conversational. It is simply honest about where conversation helps and where it starts lying to us.

There is also a deeper cultural issue. Calling prompting “conversation” flatters us. It makes us feel that we are still in purely human territory: language, personality, persuasion, style. Calling it “interface design for stochastic systems” is much less glamorous. It sounds bureaucratic, technical, slightly cold, and therefore much closer to the parts people would rather not look at.

But reality does not care which description feels nicer. If the model is part of a system, then the system properties win. Reliability, clarity, observability, reversibility, testability, and control start mattering more than the aesthetic pleasure of a natural exchange.

The Human Metaphor Helps, Then Misleads

This does not kill the human side. In fact, it makes it more interesting.

The authorial voice still matters. Examples still matter. Rhetorical framing still matters. The order of instructions still matters.

But they matter inside a designed interface, not instead of one.

So the phrase I prefer is this:

Prompting is not conversation.
Prompting borrows the surface grammar of conversation to program a probabilistic collaborator.

That sounds harsher, but it explains the world better and wastes less time.

It explains why short prompts can work brilliantly in low-stakes settings and fail spectacularly in long-horizon work. It explains why agent systems keep growing invisible scaffolding. It explains why reusable prompts slowly mutate into templates, then policies, then skills, then full orchestration layers.

If you want an ugly little scene, here is one. A team starts with “just chat with the model.” Two weeks later they have a hidden system prompt, a saved output format, a retrieval layer, a style guide, three evaluation scripts, a fallback tool policy, and an internal wiki page titled something like “Recommended Prompting Patterns v3.” At that point we are no longer talking about conversation. We are talking about infrastructure pretending to be conversation.

And it explains why newcomers and experts often seem to be talking about different technologies when they both say “AI.”

The newcomer sees the conversation. The expert sees the interface hidden inside it.

Both are real. Only one is enough for production.

Summary

Prompting feels conversational because natural language is the visible surface. But once the task carries real consequences, the exchange stops behaving like ordinary conversation and starts behaving like interface design. Hidden assumptions have to be written down, constraints have to be made explicit, and recovery can no longer rely on human social repair alone.

So the central mistake is not using conversational language. The central mistake is believing conversation itself is the control model. It is only the skin of the thing, and sometimes not even a very honest skin.

If prompting only borrows the surface grammar of conversation, what other “human” metaphors around AI are flattering us more than they are explaining the system?

Freedom Creates Protocol

Mon, 06 Apr 2026 00:00:00 +0000

Natural-language AI was supposed to free us from syntax, ceremony, and the old priesthood of formal languages. Instead, the moment it became useful, we did what humans nearly always do: we rebuilt hierarchy, templates, rules, little rituals of correctness, and a fresh layer of people telling other people what the proper way is.

TL;DR

Natural language did not abolish formalism in computing. It merely shoved it upstairs, from syntax into protocol: prompt templates, role definitions, tool contracts, context layouts, reusable skills, and the usual folklore that grows around every medium once people start depending on it.

The Question

You may ask: if LLMs finally let us speak freely to machines, why are we already inventing new rules, formats, and best practices for talking to them? Did we escape formalism only to rebuild it one floor higher?

The Long Answer

Yes. And no, that is not a failure. It is what happens when a medium stops being a toy and starts carrying consequences.

Freedom Feels Loose at First

When people first encounter an LLM, the experience feels a little indecent. You type something vague, lazy, half-formed, maybe even badly phrased, and the machine still gives you back something that looks intelligent. No parser revolt. No complaint about a missing bracket. No long initiation rite through syntax manuals. Compared to a compiler, a shell, or a query language, this feels like liberation.

That feeling is real. It is also the beginning of the misunderstanding.

Because the first successful answer encourages people to blur together two things that should not be blurred:

expressive freedom
operational reliability

Those are related, but they are not the same thing.

If you want one answer, once, for yourself, free language is often enough. If you want a result that is repeatable, auditable, safe to automate, shareable with a team, and still sane three months later, then free language starts to feel mushy. That is the moment protocol walks back into the room.

You can watch the progression happen almost mechanically.

At 09:12 someone writes a cheerful little prompt:

Summarize this file and suggest improvements.

At 09:17 the answer is interesting but erratic, so the prompt grows teeth:

Summarize this file, keep the tone technical, do not propose speculative changes, and separate bugs from style feedback.

At 09:34 the task suddenly matters because now it is being copied into a team workflow, or wrapped around an agent that can actually do things, or handed to a colleague who expects the same behavior tomorrow. So examples get added. Output format gets fixed. Constraints get named. Edge cases get spelled out. Tool usage gets bounded. Failure behavior gets specified. And with that, the prompt stops being “just a prompt.” It becomes a contract wearing friendly clothes.

The Prompt Becomes a Contract

At that point it starts acquiring all the familiar properties of engineering:

assumptions
invariants
failure modes
version drift
style rules
compatibility concerns

That is why “prompt engineering” so quickly mutated into “context engineering.” People noticed that the useful unit is not the single sentence but the whole frame around the task: role, memory, retrieved documents, allowed tools, desired output shape, refusal boundaries, escalation behavior, evaluation criteria. In other words, not a line of text, but an environment.

That is also why “skills” emerged so quickly. I do not find this mysterious at all, despite the dramatic naming. A skill file is simply what happens when a behavior becomes too valuable, too repetitive, or too annoying to restate every time. It says, in effect: “When this kind of task appears, adopt this stance, gather this context, follow these rules, and return this shape of answer.” That is not magic. It is protocol becoming portable.

There is a faintly comic irony in all of this. We escape the old priesthood of formal syntax and immediately grow a new priesthood of prompt templates, system roles, and context strategies. Different robes, same instinct.

You could object here: if we are writing rules again, what exactly did we gain?

Quite a lot.

The old formal layers required the human to descend all the way into machine-legible syntax before anything useful happened. The new model lets the human stay much closer to intention for much longer. That is a major shift. You no longer need to be fluent in shell syntax, parser behavior, or API schemas to start interacting productively. You can begin from goals, not grammar.

But goals are high-entropy things. They arrive soaked in ambiguity, omitted assumptions, social shorthand, wishful thinking, and the usual human habit of assuming other minds will fill in the missing parts. Machines can sometimes tolerate that. Systems cannot tolerate unlimited amounts of it once money, time, correctness, or safety are attached.

This is where a lot of current AI talk becomes mildly irritating. People love saying, “you can just talk to the machine now,” as if that settles anything. You can also “just talk” to a lawyer, a surgeon, or an operations engineer. That does not mean freeform speech is enough when the stakes rise. The sentence becomes serious long before the sentence stops being natural language.

So the new pattern is not:

free language replaces formal language

It is:

free language captures intent
protocol stabilizes intent
tooling operationalizes protocol

That is the more honest model. Less romantic, more true.

Why Humans Keep Rebuilding Structure

The deeper reason is that structure is not the opposite of freedom. Structure is what freedom turns into, or curdles into, depending on your mood, once scale arrives.

Human beings romanticize freedom in abstract form, but in practice we keep generating conventions because conventions reduce coordination cost. Even ordinary conversation works this way. Speech feels free, yet every serious domain develops jargon, shorthand, ritual phrasing, and unstated rules. Lawyers do it. Operators do it. Mechanics do it. Programmers certainly do it. The more a group shares context, the more compressed and rule-like its communication becomes.

There is also a more intimate reason for this, and I think it matters. Human minds are greedy for pattern. We abstract, label, sort, compress, and build little frameworks because raw complexity is expensive to carry around naked. We want handles. We want boxes. We want categories with names on them. We want a map, even when the map is smug and the territory is still on fire. That habit is not just intellectual vanity. It is one of the main ways we make memory, judgment, and navigation tractable.

That is why, when a new medium appears to offer radical freedom, we do not stay in pure openness for long. We start sorting. We separate kinds of prompts, kinds of contexts, kinds of failures, kinds of agent behaviors. We name patterns. We collect best practices. We define anti-patterns. We build checklists, templates, taxonomies, and eventually frameworks. In other words, we do to LLM interaction what we do to almost everything else: we turn a blur into a structure we can reason about.

Sometimes that instinct is useful. Sometimes it is cargo-cult theater. Both are real. Some prompt frameworks genuinely clarify recurring problems. Others are just one lucky anecdote inflated into doctrine and laminated into a slide deck.

LLM work is following the same path, only faster because the medium is software and software records its habits with ruthless speed. A verbal superstition can become a team standard by next Tuesday.

From Expression to Governance

There is a second irony here. We often speak as if prompting were the end of programming, but much of what is happening is actually the return of software architecture in softer clothes. A serious agent setup already contains the familiar layers:

input validation
API contracts
middleware rules
orchestration logic
error handling
logging and evaluation

The difference is that the central compute engine is now probabilistic and language-shaped, which means the surrounding discipline matters even more, not less.

This is why ad hoc prompting feels creative while production prompting feels bureaucratic. And let us be honest: once a company depends on these systems, bureaucracy is not a side effect. It is the bill. You want repeatability, compliance, delegation, and reduced blast radius? Fine. Someone will write rules. Someone will freeze templates. Someone will decide which prompt shape counts as “correct.” Someone will eventually win an argument by saying, “That is not how we do it here.”

The historical pattern is old enough that we should stop acting surprised by it. When literacy spreads, spelling gets standardized. When communication networks open, protocols appear. When institutions grow, forms multiply. When natural-language computing opens access, prompt scaffolds, schemas, and skills proliferate.

Freedom expands participation. Participation creates variation. Variation creates friction. Friction creates standards.

That cycle is almost boring in its reliability.

The most interesting question, then, is not whether this protocol layer will emerge. It already has. The real question is who gets to define it before everyone else is told that it is merely “the natural way” to use the system.

Will it be model vendors through hidden system prompts and product defaults? Teams through internal conventions? Open communities through shared practices? Or individual power users through private prompt libraries? Each one of those choices creates a different politics of machine interaction.

And that is where the topic stops being merely technical. The prompt is not only a command. It is also a social form. It decides what kinds of instructions feel legitimate, what kinds of behaviors are treated as compliant, and what kinds of ambiguity are tolerated. Once prompting becomes institutional, it becomes governance.

That sounds heavier than the cheerful “just talk to the machine” sales pitch, but it is closer to the truth. Natural language lowered the entry threshold. It did not suspend the need for discipline. It redistributed discipline.

So if you feel the contradiction, you are seeing the system clearly.

We did not fight for freedom and then somehow betray ourselves by inventing rules again. We discovered, once again, that free interaction and formal coordination belong to different layers of the same stack. The first gives us reach. The second gives us stability.

And in practice, every medium that survives at scale learns that lesson the same way: first by pretending it can live without structure, then by building structure exactly where reality starts hurting.

Summary

Natural language did not end formal structure. It delayed the moment when structure became visible. We gained a far more humane entry point into computing, but the moment that freedom had to support repetition, collaboration, and accountability, protocol came roaring back. That is not hypocrisy. It is how human coordination works, and probably how human thought works too: we reach for abstraction, labels, and frameworks whenever openness becomes too costly, too vague, or too exhausting to carry around unshaped.

So the interesting question is not whether rules return. They always do. The interesting question is who writes the new rules, who benefits from them, which ones are genuinely useful, and which ones are just fashionable superstition with a polished UI.

If natural-language computing inevitably creates new protocol layers, who should be allowed to write them?