Season 3 · Part 1
Your First Conversation with the Model
This Part
The last two chapters showed what the model is and where it slips. From here on, we stop talking about it and start working with it. And the first piece of work is exactly that: a real conversation that actually helps you.
You may have already tried it and come away disappointed. You asked a question and got back something that reads like it was copied from a generic textbook — correct, but useless. Or maybe you haven't even started yet, and that empty chat box with its blinking cursor was enough to make you give up. Both have the same root, and this chapter starts right there.
Say you type: “Explain the treatment of periodontitis.” What you get back is a tidy, generic block of text — a definition, the stages, a few lines about scaling and flap surgery. Everything in it is correct, and none of it is useful for what you actually need today. Because that's the answer to a generic question, and a generic question is what you asked.
Now change it to this: “I'm a general dentist. I have a 52-year-old diabetic patient with moderate periodontitis, and I want to explain the treatment options to her in plain language, in a way that won't scare her off and will keep her on board. Help me figure out how to walk through this conversation.” The answer to this is no longer a textbook entry. It's actually answering your real problem. The difference between the two isn't just the length of the question — it's that the second one told the model who you are, who you're dealing with, and exactly what you want.
Here's something we need to make explicit, because everything else depends on it: the model doesn't know you. When you ask a colleague a question, they already know half the story themselves — they know you're a dentist, they know what kind of patients your practice sees, they're up to date on how things are going for you. The model has none of that. Every conversation starts from zero for it, with a stranger.
So you have to put that hidden half on the table yourself. Usually four things are enough: who you are, what you want, why, and at what depth. This still isn't prompt engineering — there's no formula or rule at work here; you're simply making explicit, for the model, what's obvious to a colleague.
And this is exactly what changes things for each of your three most common tasks. If you're handing over an article and want it opened up for you, say what angle you want it from: “As a clinician, I want to know whether this result actually generalizes to a real patient” gets a completely different answer than “summarize this.” If you want to understand a concept, say where exactly it's unclear to you and how much background you have; the model will then start right where you're stuck, not from the alphabet. And if you're preparing something for a patient, say who that patient is and what they understand.
Now, the most important habit — and, as it happens, the exact habit most people get wrong: they ask once, get one answer, and consider the job done. That's not where the model's real value is. Its real value is where you take that answer and push on it.
Take that same periodontitis explanation for the patient. The first answer comes back, but it's too technical for your patient. You say: “Simplify this, as if you're talking to someone with no medical background at all.” Then you notice it states something with too much certainty where it shouldn't: “Say this part more cautiously, because the outcome depends on her glycemic control.” Then: “Assume the patient is afraid of surgery — frame the tone so she doesn't run from it.” Each time, the answer gets closer to your actual problem. This back-and-forth is the work itself; that first message was only the starting point.
And this is exactly where the badly habituated user got stuck. They'd see that first, generic answer and conclude the model was useless. The problem was never the model — it was that they ended the conversation right there.
But there's one thing you must never set aside throughout all this back-and-forth, and it comes straight from the previous chapter. Whenever the model's answer contains a checkable claim — a dose, a figure, a success rate, a reference — verify it right there in the middle of the conversation, not later, and not never. If, in the middle of that very explanation, the model hands you an antibiotic dose or a healing timeframe, pause right there. Its tone is confident, but the previous chapter showed that its tone is no guarantee of anything.
In other words, a conversation with the model runs on two layers at once: one is moving the work forward, the other is staying watchful over what it's actually saying. A beginner usually sees only the first layer and hands over full trust to the answer; an experienced user holds on to both at the same time.
If you do this much, you've had a real, useful conversation: you framed it, you went back and forth, and you stayed watchful. But you did all of this by hand and by instinct — figuring out what to say fresh, every single time. That's a great way to start, but it isn't repeatable. The next chapter turns these same instinctive moves into something deliberate and repeatable — the thing actually called prompt engineering.
You may have already tried it and come away disappointed. You asked a question and got back something that reads like it was copied from a generic textbook — correct, but useless. Or maybe you haven't even started yet, and that empty chat box with its blinking cursor was enough to make you give up. Both have the same root, and this chapter starts right there.
Say you type: “Explain the treatment of periodontitis.” What you get back is a tidy, generic block of text — a definition, the stages, a few lines about scaling and flap surgery. Everything in it is correct, and none of it is useful for what you actually need today. Because that's the answer to a generic question, and a generic question is what you asked.
Now change it to this: “I'm a general dentist. I have a 52-year-old diabetic patient with moderate periodontitis, and I want to explain the treatment options to her in plain language, in a way that won't scare her off and will keep her on board. Help me figure out how to walk through this conversation.” The answer to this is no longer a textbook entry. It's actually answering your real problem. The difference between the two isn't just the length of the question — it's that the second one told the model who you are, who you're dealing with, and exactly what you want.
Here's something we need to make explicit, because everything else depends on it: the model doesn't know you. When you ask a colleague a question, they already know half the story themselves — they know you're a dentist, they know what kind of patients your practice sees, they're up to date on how things are going for you. The model has none of that. Every conversation starts from zero for it, with a stranger.
So you have to put that hidden half on the table yourself. Usually four things are enough: who you are, what you want, why, and at what depth. This still isn't prompt engineering — there's no formula or rule at work here; you're simply making explicit, for the model, what's obvious to a colleague.
And this is exactly what changes things for each of your three most common tasks. If you're handing over an article and want it opened up for you, say what angle you want it from: “As a clinician, I want to know whether this result actually generalizes to a real patient” gets a completely different answer than “summarize this.” If you want to understand a concept, say where exactly it's unclear to you and how much background you have; the model will then start right where you're stuck, not from the alphabet. And if you're preparing something for a patient, say who that patient is and what they understand.
Now, the most important habit — and, as it happens, the exact habit most people get wrong: they ask once, get one answer, and consider the job done. That's not where the model's real value is. Its real value is where you take that answer and push on it.
Take that same periodontitis explanation for the patient. The first answer comes back, but it's too technical for your patient. You say: “Simplify this, as if you're talking to someone with no medical background at all.” Then you notice it states something with too much certainty where it shouldn't: “Say this part more cautiously, because the outcome depends on her glycemic control.” Then: “Assume the patient is afraid of surgery — frame the tone so she doesn't run from it.” Each time, the answer gets closer to your actual problem. This back-and-forth is the work itself; that first message was only the starting point.
And this is exactly where the badly habituated user got stuck. They'd see that first, generic answer and conclude the model was useless. The problem was never the model — it was that they ended the conversation right there.
But there's one thing you must never set aside throughout all this back-and-forth, and it comes straight from the previous chapter. Whenever the model's answer contains a checkable claim — a dose, a figure, a success rate, a reference — verify it right there in the middle of the conversation, not later, and not never. If, in the middle of that very explanation, the model hands you an antibiotic dose or a healing timeframe, pause right there. Its tone is confident, but the previous chapter showed that its tone is no guarantee of anything.
In other words, a conversation with the model runs on two layers at once: one is moving the work forward, the other is staying watchful over what it's actually saying. A beginner usually sees only the first layer and hands over full trust to the answer; an experienced user holds on to both at the same time.
If you do this much, you've had a real, useful conversation: you framed it, you went back and forth, and you stayed watchful. But you did all of this by hand and by instinct — figuring out what to say fresh, every single time. That's a great way to start, but it isn't repeatable. The next chapter turns these same instinctive moves into something deliberate and repeatable — the thing actually called prompt engineering.
Keywords
Prompt Framing (Who You Are / What You Want)
Context-Driven Prompt Engineering
Iterative Back-and-Forth With the Model
Verifying Checkable Claims
Large Language Model (LLM)
ChatGPT
Real-Time Monitoring of Model Output
Trust in AI
AI Literacy
Tags
← Previous Part
Next Part →