The Conversation Isn’t Real

14 prompting techniques that work because AI chats aren’t what you think.

14 prompting techniques that work because AI chats aren’t what you think.
prompting
Author

Lon Riesberg

Published

July 3, 2026

Most people interact with AI like they’re having a conversation. They ask a question, the AI responds, they respond back, and so on. It’s a natural flow for people that feels like a conversation, but that’s an illusion. Understanding why will supercharge how you use AI.

Behind the scenes, every message you send and every reply is a big, evolving transcript. People respond to the latest interaction, but AI doesn’t have any awareness of an ongoing discussion. There isn’t a sentient being on the other side that remembers what was just said. The model re-reads the entire transcript everytime you click send, and then reponds to the entire transcript.

Understanding that is key. You can do things with a transcript that you can’t do with a conversation. For instance, you can hand a transcript to a different model. You can fork a transcript. You can delete bad ideas. And then watch the AI reason through the transcript as if the edits never existed.

In this post, I’ll walk through three tiers of working with LLMs and show you specific ways to get more from your prompts. The first tier shows how to get more from a single chat. This tier feels like a conversation and is where most people work. The second tier breaks out of conversations and shows how to use multiple AIs together. The third tier is where you’ll notice that what you’re doing in tier 2 is actually a pipeline. And pipelines can be built.

You don’t need to be an engineer for any of this. Tiers 1 and 2 are just copy-paste. Tier 3 is a way of thinking that happens to point towards code.

Tier 1: Talk to One Model Better

LLMs do two things that limit the quality of every response: 1) they guess your context and, 2) they defer to you more than they should. Every strategy in Tier 1 fixes one of those two things.

1. Get interviewed first

One of the biggest failure modes with current LLMs is that the model guesses your context. So, stop it from guessing:

Please draft a job description for a senior analyst on my team. Before writing anything, ask me the 5 questions whose answers would most change the draft.

This will get the model to ask about things like team size, stakeholder mix, whether your culture is SQL-first or Python-first, etc. You know these things intuitively but don’t think to include them in a question.

2. Force a choice

If you ask an LLM a “this-or-that” question, it will essentially respond with, “It depends.” This is better:

Postgres or BigQuery for a 50GB analytics workload, 3-person team. Pick one and include one sentence of justification.

“Pick one” forces the model to make a choice and you can dig into details from there.

Telling it to rank choices is even better. “Rank these five KPI candidates from most to least useful for a subscription business. No ties allowed.” Not allowing ties forces it choose.

3. Run a pre-mortem

If you ask an LLM, “Do you see any issues with this plan?” you’ll get a list of generic risks. Ask for a “pre-mortem” instead:

We're launching a self-serve analytics tool for non-technical PMs. Imagine it's 8 months later and no one's using it. Write an internal post-mortem, including the warning signs everyone ignored.

Phrases like “internal post-mortem” and “warning signs everyone ignored” produce specific failure modes instead of a checklist of risks.

It works on artifacts too. Take a marketing email you’re about to send: “imagine no one responded and tell me why” is much better than “how can I improve this email?”, which will mostly get you tone tweaks.

4. Roleplay your audience

Giving an LLM a role to play is a good way to get different perspectives. I like this approach for charts:

You’re a CFO seeing this in a board deck and you have 10 seconds of attention. What do you take away? Now, what did the author intend you to take away?

On their own, the perspectives are useful and, in this case, the gap between those perspectives offers a worthwhile critique.

5. Ask what you should have asked

Say you just got some suggestions from an LLM about a database migration. Before moving on, ask one more question:

What should I have asked you that I didn't?"

That question will reveal any deal-breakers. For instance, “You never asked about your downtime tolerance.” The model didn’t volunteer that because you didn’t seem to want it.

This one’s even better: “What’s the one question that, if I answered it, would most change your recommendation?” That one gets the model to tell you about its assumptions.

6. Demand calibration flags

Models sound confident about everything, which is a real danger. So make confidence explicit:

Summarize the changes in pandas 3.0. Tag every claim [confident] or [verify] and be stingy with [confident].

The “be stingy” clause is important because without it, everything gets rated as “confident.”

Tier 2: Escape the Context

Everything up to this point works within a single chat. But since that “conversation” is just a transcript that’s re-read from scratch with every new message, nothing binds you to that one chat. The chat is completely portable. You can change it and give the transcript to a new instance of the model you’re already working with. Or you can give it to a completely different model. The models don’t care.

Every technique in Tier 2 exploits that loophole.

7. Switch models mid-stream

Pitting the models against each other is my favorite LLM strategy.

Ask Claude to architect your data pipeline. Then paste the entire chat into ChatGPT or Gemini, starting with something like this:

A consultant proposed this architecture. Where would you push back?

A new model will often have a different perspective than the first. It may also have different strengths and capabilities and will find issues that the first model would have defended.

8. Make them argue

ChatGPT says I should normalize this table into 3NF. What do you think?

Models defer to you, but not so much to each other. By attributing a position to another AI, you’re more likely to get a constructive response.

You can take that a step further and give a third model both answers: “Two AIs disagree about whether I should use embeddings or fine-tuning here. Here are both arguments. Judge them and declare a winner.”

That’s a debate-and-judge evaluation, which is a real technique from the research literature.

9. The colleague gambit

Ask “can you review my SQL query?” and the model might say something nice like, “Great approach! One small suggestion…”

Now try: “A junior analyst submitted this query for review. Give the feedback you’d put in the PR.”

It’s the same question but dramatically more useful.

10. Never let the author grade its own work

The chat that wrote your essay will defend every paragraph of it, so don’t ask that chat. Open a fresh one instead:

I found this essay online. Is it worth my time? Be honest about where it loses you.

The fresh chat may tell you the intro is 200 words too long but the chat that wrote it would defend it because the back-and-forth process that created it is baked into the transcript.

11. Branch, don’t scroll

The edit button on your earlier messages isn’t for fixing typos. It forks the chat.

For example, say you’re 20 rounds into planning a project and you wonder about a different approach. If you ask “what if we did it the other way?” at the bottom, the model anchors on everything already decided. Instead, edit the message where you made the choice and let the branch develop independently. Then compare endpoints.

This also makes it easy to A/B test your prompts. Edit your initial request and watch how far downstream the changes propagate. People A/B test their landing pages all the time but never think about testing their prompts. The edit button makes it a two-click experiment.

Tier 3: Notice the Pipeline

At this point, you’re running the same prompt against multiple models. You’re spinning up fresh chats to evaluate outputs. You’re generating variations and picking winners.

Essentially, you’ve stopped having conversations and have started running experiments.

It’s the beginning of a pipeline. It’s a slow one, with you copy-pasting into different windows, but the real dividing line between casual users and people who build with AI isn’t technical skill. It’s noticing which of your manual workflows are actually scripts waiting to be written.

12. Invert the prompt

Take three pieces of your own writing that you’re proud of:

Write the prompt that would make an AI produce output in exactly this style, capturing the rules I'm following unconsciously.

This gives you a portable style guide that you can drop into any future chat. It’s your voice and editorial instincts, externalized.

Push it one step further and drop in placeholders:

Here's a report format that works for my team. Reverse-engineer the prompt that would produce it, parameterized with {dataset} and {time_period} slots.

With the placeholders, you now have a template that you can drop into a script for automated reporting.

13. Generate diverse, then judge

In an interview from the 90s, a National Geographic photographer said they typically had two or three good shots in a roll of 36. Having lots to choose from was key for getting the great ones.

It’s the same with LLMs.

Ask for options and be specific:

Give me three launch-announcement drafts: one safe, one contrarian, and one that takes a genuine risk.

Even better, ask it to give you multiple versions of each draft. Then, in a fresh chat, have a model judge them: “Which of these would you actually keep reading past the first paragraph? Why?”

This is a hand-run version of two patterns the research world has names for: best-of-N sampling (generate several candidates, keep the winner) and LLM-as-judge (use a model to do the picking).

It works on analysis too: “Interpret this churn data three ways: the optimistic perspective, the alarming perspective, and the boring-but-most-likely perspective.” Then let another chat pick the most likely interpretation.

14. Create a Rubric

“Is this a good README?” gets you “Yes, but it could use some examples.”

A better approach is to create a rubric first:

Write a 6-criterion rubric for a great open-source README, with what 1/5 and 5/5 look like for each criterion.

Once you have a set of rules you like, then have it read the document:

“Score my README against this rubric, with one line of cited evidence per score.” 

Now you have a rubric that you can use with future drafts. That gives you a persistent, reusable evaluation component.

That’s the Tier 3 mindset in one artifact. And once you have a few of these (a style prompt, a parameterized template, or a rubric), wiring them together in code is a smaller step than you might think.

Where This Goes

The advice in Tier 1 is about getting more out of a single chat.

Tier 2 is about escaping that frame: fresh chats, rival models, and forked timelines.

Tier 3 is where the frame dissolves. If you’ve been copy-pasting between chats, running the same prompt through three models, and keeping a rubric in a notes file, you’re already building a pipeline. You’re just running it slowly.

Making it fast and automated is what code is for. More on that in another post.