Why teachers are the best prompt engineers

The most underrated skill in working with AI isn't technical. It's pedagogical.

---

There is a moment most people have had with a chatbot and not thought twice about. You ask it to do something. It returns something adjacent to what you wanted, confidently wrong in a way that's almost worse than useless. You sigh, and instead of rewriting the request from scratch, you do something more patient. You show it an example. You break the task into smaller pieces. You say "no, like this," and you point at the part it got right and the part it got wrong. And on the third or fourth pass, it works.

What you did in that moment was not engineering in any traditional sense. You did not optimize a function or tune a parameter. You taught. You diagnosed a misunderstanding, scaffolded the gap, gave feedback, and let the work improve. The reason it worked is the reason this essay exists: prompt engineering, stripped of its jargon, is the act of transferring intent into a mind that cannot read yours. And teaching is the most refined version of that act humans have ever developed.

The people getting the most out of these models right now are not, on average, the best programmers. They are the people who are good at explaining things to someone who doesn't yet understand. That skill has a name, and we have spent a few thousand years building a discipline around it. The discipline is pedagogy, and it turns out to be the closest thing we have to a theory of prompting.

The thesis, stated plainly

A prompt is an attempt to make another system understand what you want well enough to produce it. The obstacles are exactly the obstacles a teacher faces in a classroom. The other party doesn't share your context. It fills ambiguity with whatever is most statistically likely, which is rarely what you meant. It can produce fluent nonsense that mimics understanding. It needs the task shaped, not just stated.

Teachers solve this problem for a living. Not through warmth or patience, though those help, but through a specific toolkit of techniques for moving knowledge across a gap. Almost every technique in that toolkit has a direct twin in prompt engineering, and most prompt-engineering advice is just one of these teaching techniques rediscovered without the citation. Once you see the mapping, you stop memorizing prompting "hacks" and start reasoning from first principles, because you already have the first principles. You learned them, or could have, in any decent education course.

Let me lay the mapping out, because the correspondence is almost embarrassing in how clean it is.

The toolkit transfers, one for one

Diagnose before you teach. The first thing a good teacher does is figure out what the student already knows. You don't explain fractions to someone who doesn't have division yet. In prompting, this is the work of setting context and priors. Most failed prompts fail because the person assumed shared ground that wasn't there. The model doesn't know your company, your audience, your definition of "good," the document three tabs over. The teacher's instinct to never assume prior knowledge is the single most valuable instinct to bring to a blank prompt box.

Work inside the zone of proximal development. Vygotsky's idea, and the most useful one here, is that learning happens in the gap between what someone can do alone and what they can do with guidance. Too far below the gap and you bore them. Too far above and you lose them. The teacher's job is to pitch the task right at the edge of current ability and provide temporary support, scaffolding, that gets removed as competence grows. This is exactly what good prompting does. You don't hand a model a vague, enormous task and hope. You decompose it, you provide structure, you constrain the output, and as you learn what it can reliably do, you remove the supports. Decomposition and least-to-most prompting are scaffolding by another name.

Use worked examples. Cognitive science has a robust finding called the worked-example effect: novices learn a new skill better by studying completed examples than by struggling through problems unaided. Every teacher knows this intuitively, which is why the board fills with solved problems before the homework gets assigned. Few-shot prompting is the worked-example effect, full stop. Showing the model two or three examples of the input-output pattern you want is not a trick. It is the oldest pedagogical move there is, and it works for the same reason it works on people: a demonstrated pattern carries more information than a described one.

Ask for the reasoning, not just the answer. "Show your work" is a teacher's demand for a reason. It surfaces where the thinking went wrong, and it tends to make the thinking better in the first place, because articulating each step forces rigor. Chain-of-thought prompting is this exact move. Asking a model to reason step by step before answering improves accuracy for the same reason it improves a student's: the act of laying out intermediate steps catches errors that a leap to the conclusion hides.

Assess formatively, then re-teach. There are two kinds of assessment. Summative assessment judges the final product. Formative assessment is the ongoing, low-stakes feedback loop a teacher runs constantly: a quick check, a correction, an adjustment, another check. Good teaching is mostly formative. So is good prompting. The iterative loop of reading the output, diagnosing the specific failure, and adjusting one thing is formative assessment applied to a model. The people who are bad at this rewrite the whole prompt in frustration every time, which is the equivalent of a teacher who responds to a wrong answer by starting the entire lesson over.

Write the instruction so it cannot be misread. Anyone who has written an exam question knows the particular horror of watching half the class answer a question you didn't ask, because the wording had a seam you didn't see. Teaching trains you to hunt for ambiguity before it costs you. That is precisely the skill of writing a spec. A prompt is a worksheet question for an extremely literal student, and the discipline of removing every interpretable gap is one teachers build over years of being misunderstood by thirty people at once.

Design backward from the outcome. The best curriculum design, what Wiggins and McTighe called backward design, starts from what you want the learner to be able to do, then defines how you'll know they can do it, and only then plans the instruction. Most people prompt forward: they describe a task and see what comes out. The teacher's move is to define the target first. What does a good answer look like? What is the format, the success criteria, the shape of the output? Specify that, and the prompt almost writes itself, because you've done the hard thinking before the first token.

Differentiate for the learner in front of you. Teachers adjust for who they're teaching. The same content lands differently for different students and needs different delivery. Prompting has its own version: a frontier model and a small fast model are different learners, and so is the same model at a different temperature or with a different system prompt. Knowing which task suits which model, and adjusting your approach accordingly, is differentiation.

Eight techniques, eight clean correspondences. You could keep going. The point is not that the list is exhaustive. The point is that it isn't a coincidence. Both activities are solving the same underlying problem, so they converge on the same solutions.

So who actually graduates?

Here is where the metaphor gets interesting, and where most versions of this argument get lazy.

The romantic version goes like this: you keep teaching the model, giving it more and more, until one day it graduates and starts helping you. It grows up. It learns. The student becomes the colleague.

This is mostly false, and the way it's false is the most useful thing in this essay.

A model in a single conversation does learn, in a real sense. In-context learning is not a metaphor. As you add examples, corrections, and clarifications within a session, the model genuinely gets better at the specific task. That part of the graduation story is true. But it is also ephemeral. Close the tab and the student has total amnesia. Every brilliant lesson you ran, every correction it absorbed, gone. You sit down tomorrow with a stranger who has never met you. If graduation means the model itself permanently rises to a higher level through your teaching, then no, that mostly doesn't happen. You are not raising a child who carries the lessons forward.

So if the student forgets every night, what was the point of teaching it? The answer reframes the whole activity.

The prompt graduates, not the model. The durable thing you build is not an improved model. It is a curriculum. The system prompt, the example bank, the decomposition, the output spec: these are a lesson plan. And a good lesson plan has a remarkable property. It makes any fresh student graduate instantly on load. You are not nurturing one learner over months. You are writing instruction so complete that a brand-new instance, with no memory of you, performs at graduate level the moment it reads it. This is what teachers have always actually produced. The legacy of a great teacher was never one improved kid. It was the reusable thing, the method, the worksheet, the way of explaining, that worked on every kid who came after. Prompt engineering makes that fact literal. Your output is pedagogy you can run again.

And then you graduate. There is a line every teacher knows: you don't really understand something until you have to teach it. Standing in front of a room exposes every soft spot in your own understanding, every place you knew the answer but not the reason. Writing a genuinely good prompt does the same thing, and this is the payoff almost no one talks about. To instruct a model precisely, you are forced to make your own intent explicit. You discover that you didn't actually know what "a good summary" meant until you tried to specify it. You find out your own definition of done was vague. The model's failure is often just a mirror held up to the fuzziness of your own thinking. Prompting it well requires you to think it through, and you come out the other side understanding your own task better than when you started.

So three things can graduate: the model, briefly and forgetfully; the prompt, permanently and reusably; and you, which is the one that compounds. The last one is the reason this skill is worth building even as the models get good enough that the first two start to matter less.

Where the metaphor breaks, and why that matters

A frame this clean invites overuse, and an essay that only sells you the metaphor is doing you a disservice. The honest move is to mark where teaching intuitions stop helping and start actively misleading you, because importing the wrong half of teaching makes you worse at this, not better.

Start with motivation. A student has wants. You can engage curiosity, raise stakes, make someone care. A model has nothing of the kind. When a prompt that says "this is important for my career" seems to produce a better answer, something is happening, but it is not the model trying harder for you. It is a statistical association in the training data being activated, a very different mechanism with very different reliability. Treat it as a tool to test, not a relationship to invest in.

Then there's the question of growth itself. When you teach a person, you are raising a real ceiling. Their actual ability is higher in June than it was in September. A model's capability is fixed the moment it finishes training. You are not raising its ceiling. You are finding the path to a ceiling that already exists. What feels like the model "getting better" as you prompt it is not development. It is better elicitation, you locating a capability that was always there. This distinction sounds academic until it changes your behavior: a teacher waits for a student to grow, but a prompter who waits is wasting time. If it can't do the thing after good prompting, more patience won't grow the ability. You need a different model or a different approach.

And memory, already mentioned, is the asymmetry underneath both. Students consolidate. Sleep on a lesson and it integrates. A stateless model does not, which is why your real artifact has to live outside the model in the curriculum you keep.

Here is the cleanest way to hold all of this. The teacher's rigor transfers completely. The diagnosis, the scaffolding, the worked examples, the formative loop, the relentless hunt for ambiguity: bring all of it. The teacher's warmth mostly doesn't. The patience that waits for a slow learner to bloom, the gentleness that softens an instruction so as not to discourage, the faith that effort will be rewarded with growth: leave those at the door. They were features when the student was a person. They are bugs when the student is a function. Take the discipline of teaching. Leave the tenderness.

The skill that's left when the tricks expire

Most prompt-engineering advice has a short shelf life. The specific incantations, the magic phrases, the format hacks: these decay as models improve, and half of what was true a year ago is now unnecessary. Betting your edge on the tricks is betting on a depreciating asset.

But the teaching skill underneath does not expire, because it is not about the model. It is about the much harder and more permanent problem of knowing a task well enough to hand it off cleanly. Diagnosing what a fresh mind is missing. Pitching work at the edge of ability. Showing rather than telling. Asking for the reasoning. Closing the feedback loop one variable at a time. Defining done before you begin. None of that goes stale, because all of it is really about the clarity of your own intent, and the model is just the latest thing forcing you to get clear.

Which means the most useful thing you can do to get better at AI is not to study prompting. It is to learn to teach. Pick something you understand and explain it to someone who doesn't, and pay attention to what you have to do to make it land. Notice the assumptions you didn't know you were making. Notice how an example does the work ten sentences couldn't. Notice how the act of explaining sharpens your own grip on the thing. Then take that to the blank prompt box and treat the model like what it is: a brilliant, literal, forgetful student who graduates the moment you finally figure out how to teach it, and hands you, on the way out the door, a clearer version of your own understanding than you walked in with.

That last part is the trade. You set out to teach the machine. You end up the one who learned.