Prompt Basics

Wherever you left it unspecified, the model fills in its own answer. So when output is wrong, the first question is not whether it can do it, but what you failed to say.

This column is about putting AI to work, and it starts with the thing you do most: hand the model a job and get back a result you can use. Most of that outcome is decided before you type a word — a prompt is a requirements document, not an incantation, and wherever you left it unspecified, the model fills in its own answer. So when the output is wrong, the first question is not "can it do this" but "what did I fail to say."

After reading, you should be able to answer:

When the output is off, in what order do you check yourself, and which gap do you close first?
Why does a copied "universal prompt" stop working in your hands — and start working once conditions are added?
Which of the usual magic phrases do nothing, and when is changing the model finally the right move?

When the output is wrong, check yourself first

This is the posture to take away. When output looks wrong, the reflex is "the model can't do it," so you swap models, swap tools, pile on adjectives — all of which push in the wrong direction.

The right first move is one question: where did it decide something on its own, and did I leave that unstated? Nearly every "wrong" in the output maps to a blank in your requirements document. It did not disobey you; it filled in its own answer on the line you left empty.

This posture deserves repeating because it is actionable. Swapping models is a gamble. Checking yourself is a repair.

Work through the check in this order, easiest to miss first:

Context: who it is for, in what situation, with what history. Miss it and the output fits everyone, which means it fits no one.
Requirements: what exactly to produce, in how many steps, along which dimensions. Miss it and it picks the most common interpretation.
Constraints: what not to do, which material it may use, what to do when unsure. Miss it and it improvises, and invents.
Acceptance: how many items, how long, what format, numbered or not. Miss it and the shape changes every run and your code cannot catch it.

Those four are the four parts, which gets its own article. Here you only need the order: check what you left out before you consider replacing anything.

Once you find the gap, there are four moves

If you have an underperforming prompt in hand, fill these in, in order — it beats rewriting from scratch.

Surface your implicit assumptions. When you wrote it you were assuming "obviously for B2B clients," assuming "obviously in Chinese," assuming "obviously no competitor mentions" — and the model reads none of it. Put each one into words.
Add a "don't" list. Positive requirements alone are often not enough; a list of banned territory narrows things faster. Say plainly: no exclamation marks, no marketing voice, no invented data — one prohibition is worth about three positive requests.
Give an example. If you can produce one sample of "this is what right looks like," it beats three paragraphs of adjectives. Examples get their own article.
Define done. Requiring "three items, each under 20 characters, numbered" and writing only "summarize concisely" are worlds apart in effect.

Of the four, the first two usually pay back the most — because your default assumptions and your banned territory are exactly the two blanks you are least able to see yourself.

Each condition you add removes a stretch of possibility

Back to the mechanism that guesses the next token: every step asks which word is most likely to come next. Note that "most likely" is always relative to something — namely everything it has in front of it right now.

So handing it "write some copy" opens the possibilities as wide as they go — who is the audience? what is being sold? how long? what tone? All blank. But it cannot stop there; it has to keep writing, so it picks whatever phrasing is most common in its training corpus. What you get back is therefore smooth and inoffensive, and it moves nobody.

The more conditions you supply, the fewer places it has to land. Add "for users who joined three months ago" and every new-user framing is ruled out; add "under a hundred words, no exclamation marks" and what is left is roughly what you wanted. The narrowing is visible: the more specific the request, the smaller the gap between two runs. Both vendors' official prompting guides are really saying this one thing — be specific, be testable, spell the conditions out. openai-prompt anthropic-prompt

The inverse also holds: a sentence that narrows nothing has zero effect. "Think carefully" and "this is very important" bring no new information at all, so the model has no reason to change its output because of them. What works is concrete conditions: write the format out, paste an example, list the words that must not appear.

Put another way, prompt engineering is not a search for a magic phrasing — it is saying everything that matters clearly. Which is also why someone else's "universal prompt" fails in your hands: that text narrowed their range, not yours.

Treat it like a sharp new colleague

A useful comparison: treat the model as a new hire who is strong at the job but knows nothing about your company.

They are smart, they learn fast, and they can hold their own in any field. But they do not know what your product is called, who your users are, why the last proposal was rejected, or what voice you write in. Every piece of background you skip when briefing them, they have to guess — and they will not come back to double-check.

So how would you brief a person like that? You would make four things clear: who the work is for, what result you need, where the red lines are, and what counts as finished. Those four are exactly what a prompt has to carry.

This comparison also settles a common puzzle: why someone else's shared "universal prompt" stops working in your hands. That text is loaded with their business context and constraints, which do not match yours. You can copy the structure; the content does not travel.

Three misconceptions with one root

All three rest on the same assumption: that it will fill your blanks correctly for you.

One, there is a magic phrase. Most "prompt hacks" online take this form. A simple test: delete the sentence and see if the output changes. If it does not, the sentence was doing nothing. The one near-exception is asking it to reason before answering — that helps, but not because it is a spell. It is because writing more is computing more.

Two, longer is better. No. What carries weight is information density; the word count itself is worth nothing — hoping bulk will cover what you left unsaid is the same shortcut as hoping for a magic phrase: the blank stays blank either way. The more irrelevant background you pile on, the more the key instruction gets washed out, and the cost climbs too. Worse, once the text runs long the crucial line easily sinks into the middle — and the middle is exactly where attention goes slack.

Three, it understood me. There is no "understanding" happening; it performs a statistical continuation. The difference is invisible when things go well and glaring the moment they go wrong: a person would stop and ask when the brief is ambiguous; it will not. It picks one reading and carries on with total confidence. So the loss from ambiguity lands entirely on your side of the ledger — which is precisely where the opening posture, "check yourself first," comes from.

The part a model swap cannot fix

Everything above comes down to one habit: for every spot in the output you dislike, go find the matching blank in the requirements document first. Most verdicts of "the model can't do this" dissolve after the four moves earlier.

What is left is not solved by adding more words, but by changing with a ruler — one thing at a time, comparing against the same sample set to see whether it actually improves. How to iterate on a prompt lays out that method.

Deciding when to change models, add retrieval, or fine-tune is a separate judgement. When all four parts are filled in and samples have run a few rounds, yet failures still cluster on the same kind of input, the problem is no longer in how you asked. Before that point, changing the model usually just swaps one phrasing of the same error for another.