A good prompt is not luck or a magic phrase: it is a method. Most poor results come from vague instructions, not from the model itself.
Be specific and provide context
The model cannot guess what is in your head. “Write about marketing” produces a generic answer because the request is generic. Say who will read it, what the goal is, what tone to use, and what constraints apply. Compare “summarize this text” with “summarize it in 3 bullet points for a busy manager, focusing on decisions and avoiding jargon”: the second produces something useful because you did the thinking before asking. Context matters more than polished wording—paste the relevant material, say what has already been tried, and point out what you do not want.
Show examples (few-shot)
Describing the desired result helps; showing an example helps more. If you want to classify tickets as “urgent / normal / spam,” provide two or three cases that have already been labeled before presenting the real one. The model picks up the pattern—format, level of detail, and criteria—much better from examples than from adjectives. One or two well-chosen examples are often worth more than a paragraph of instructions. Just make sure they are representative: if they are all easy, the model will stumble on edge cases.
Ask for a format
If you are going to consume the response in code, paste it into a spreadsheet, or review it quickly, specify the format explicitly: JSON with these keys, a table with these columns, a numbered list, no more than X words. Without this, each round comes back differently and you waste time cleaning it up. A “respond with JSON only, with no surrounding text” instruction prevents the “Sure! Here it is:” that breaks your parser. An explicit format is also the cheapest way to make the output testable.
Break difficult tasks into parts
Asking “analyze this contract, find the risks, rewrite the clauses, and generate an executive summary” in a single prompt often produces a lukewarm mixture of everything. Separate the steps: first extract the clauses, then assess the risk of each one, and then rewrite them. Each step becomes easier to verify and correct. For reasoning tasks, asking the model to “think step by step” before answering can help with logic problems—not by magic, but because it forces the model not to jump straight to a guess. Large and vague tasks are where errors hide.
Iterate and evaluate
The first prompt is rarely the best. Treat it like code: run it, see where it failed, change one thing, and run it again. A common mistake is changing five things at once and then not knowing what worked. If you use the same prompt frequently, create a test set—inputs with expected answers—and run the prompt against them whenever you change it. “Does this look better?” does not scale; a handful of examples with answer keys does.
Know the limits
The model can make things up with confidence. It fills gaps with what sounds plausible—names, numbers, citations, and APIs that do not exist. Politely asking it not to hallucinate does not solve the problem. What helps is providing the source in the prompt itself (grounding), asking it to say when it does not know, and verifying anything factual or sensitive before using it. A knowledge cutoff date, bias in training data, and lack of access to your private context are real limitations, not matters of opinion. Use it like a fast, tireless intern: excellent for drafting, terrible for signing off on anything without review.
In the end, prompt engineering is less about tricks and more about clarity: the better you define the problem, the less the model has to guess. The tool is useful—just do not outsource your thinking.
