Instruct AI like a person, not a search query

You don't need to be good at prompting; rather ask for what you want and correct the AI when it doesn't get your intentions, since instructing these systems is more like managing than chatting


Ethan Mollick, a Wharton professor who writes widely about working with AI, has a piece of advice that runs against most of the prompt-engineering discourse: stop trying to be good at prompting.

Plus, as the models have gotten better, instructing AIs has become more like instructing people. You don't need to be good at prompting, but rather at asking for what you want and correcting the AI when it doesn't get your intentions.

The claim underneath that sentence is a shift in what the skill even is. Early chatbots rewarded people who learned tricks — magic phrases, role assignments, elaborate formatting instructions — and a small industry grew up selling those tricks. Mollick's point is that the models have changed faster than the advice. Current systems are good enough at interpreting ordinary language that the bottleneck is no longer how you phrase the request. It's whether you know what you actually want, and whether you notice when the result misses it.

The useful analogy is managing, not searching. A search query is a single shot: you type words, you get results, and if they're wrong you rephrase the words. Managing a person is a loop: you describe the outcome, you look at what comes back, you say that's not quite it — keep the first section, but the tone is too formal and it needs to be half as long. Mollick's argument is that modern AI assistants respond to the second approach far better than the first. The correction is not a failure of your prompt; it is the mechanism by which the work gets done.

This matters most for a specific reader: anyone who has tried an AI assistant, gotten mediocre output, and concluded the problem was them — that they lacked some technical knack for "talking to AI." The implication of Mollick's framing is that there is no knack to lack. The skills that transfer are the same ones used with a new colleague or a contractor: be specific about the deliverable, give context about what it's for, and treat the first draft as a draft. If you find yourself accepting output that isn't what you wanted because rewriting the request feels like too much effort, that's the habit to break — the correction is where the value is.

It's worth being honest about the limits. This is not a technique or a product; it's a posture, and Mollick's claim is an observation about how the models behave, not a measured result. He does not define how much correction is reasonable, and the managing analogy has a real edge: a person you correct three times learns something permanent, while most AI assistants forget everything once the conversation ends. If you give the same correction every session, nothing is accumulating. The analogy also flatters the systems in one way — they will often produce confident, plausible output that is quietly wrong, which is a failure mode a competent human colleague signals more honestly.

There is also nothing to buy or install here. The behavior Mollick describes — asking plainly and iterating — works in the assistants people already have, and it applies to the current generation of models, not a future release. What he is offering is permission to stop preparing: you do not need a course in prompting before your requests count. You need a clear idea of what you want, and the willingness to say so again when the first answer isn't it.

accuracyefficiency