The first time a model confidently told me something false, I recognized the tone immediately. I had used it in meetings for years.
It was the tone of the sharp young analyst who has read the deck, grasped ninety percent of the situation, and decided that the missing ten percent can be filled in with poise. No hedging. No "I'm not sure." Just a clean, fluent, completely wrong answer delivered with the cadence of someone who has never been wrong in his life. What gave it away wasn't the content — the content was smooth. It was the confidence sitting one notch too high for the question, the absence of the small verbal flinch a person makes when they're guessing and know it. I had learned to hear that pitch in meetings. I learned, that afternoon, that a model has the same tell, and never the flinch.
People around me kept describing this as a technical problem. The model "hallucinates." The context window is "too small." We need better "prompt engineering." All of that is true in the way that "the engine has a thermal management issue" is true when your car is on fire. It describes the mechanism and misses the experience. The experience is older than computing. You are working with someone gifted and green, and your job is to get the best out of them without getting burned.
The intern who forgets
Here is the frame that has served me better than any prompt-engineering guide. Treat the model as a gifted intern with no memory of yesterday.
Gifted, because it genuinely is. Hand it a tangle of legal boilerplate and it will summarize the obligations faster than any associate. Ask it to draft six variations of an email and it will, without sighing, without checking its phone, without the faint resentment a person rightly feels when asked to do the same task six times. The raw capability is not in question. I have watched it do, in nine seconds, work I used to budget an afternoon for.
No memory of yesterday, because that is the part people refuse to internalize. Every conversation starts cold. The brilliant thing you explained on Tuesday is gone on Wednesday. The intern shows up each morning having read the entire library and forgotten where he sat. If you have ever managed someone with that exact profile — enormous range, zero continuity — you already know the playbook. You write things down. You restate the goal. You stop assuming context that lives only in your own head.
This is why the people who manage humans well tend to manage models well, often without any technical background at all. They have already absorbed the hard lesson: the quality of the output is mostly a function of the quality of the brief. A vague request to a capable person yields confident, off-target work. A vague prompt to a capable model yields exactly the same thing. The failure was upstream, in the asking.
The overconfidence is a feature you have to staff around
The hallucination problem is real, and I don't want to wave it away. But notice that we have a word for the human version of it, and the word is not "broken." It's "junior."
A junior person tells you what they think you want to hear, fills gaps with plausible invention, and resists saying "I don't know" because they think not-knowing is a fireable offense. You don't fix that by firing them. You fix it by changing the conditions. You ask for sources and then you check them. You separate the task of generating ideas from the task of verifying them, because the same person is unreliable at the second even when they are dazzling at the first. You build a review step into the workflow and stop pretending the review step is optional.
Everything I learned the hard way about delegating to people turns out to port directly. Don't delegate a decision you can't evaluate. Don't ask for a conclusion when what you need is the reasoning. Give the work back when it's wrong, specifically, with the part that's wrong named out loud — "the third claim is unsupported, find the source or cut it" — instead of a wounded "this isn't quite right." The model, like the intern, cannot read the disappointment on your face. It can only read what you actually wrote.
Models that pause to think
Something is shifting, though, and it's worth naming before it becomes obvious. The newest models have started to pause before they answer — to reason through a problem in steps rather than blurting the first fluent thing. It is a small change with a large implication. We have spent two years learning to manage the intern who speaks before thinking. We are about to be handed the intern who thinks first, and the management problem changes shape.
Some of the overconfidence will drain out. Some of the brilliance will get slower and more expensive, which is its own kind of trade you'll have to manage. The deeper point is that the interface to these systems is converging on something that looks less like programming and more like leadership. You set the objective. You define what "good" means. You decide how much to trust and where to verify. None of that is code. All of it is judgment about how to get useful work out of a capable mind that is not your own.
I find this clarifying rather than alarming. For thirty years the people who could code held a kind of monopoly on getting machines to do their bidding. That monopoly is ending — not because coding stops mattering, but because the new lever is a skill that good operators, good editors, good managers, good teachers already have. The person who knows how to brief a talented stranger, set the bar, and catch the plausible-sounding mistake has been training for this their whole career and didn't know it.
So the real preparation isn't a prompt library. It's the thing you already do, or already need to learn, to get the best out of people. Be specific about the goal. Assume nothing carries over. Trust the brilliance and verify the confidence. Treat the machine the way you'd treat a gifted colleague who forgets every night and never tells you when he's guessing.
Read it the way you read people. It turns out you already can.