Prompt engineering

Be specific about the task, the audience and the format. "Summarise this" invites a guess about length, tone and what matters; "summarise this support thread in five bullets for an engineer who has not read it, leading with the unresolved question" does not. Most disappointing output is an under-specified request rather than a weak model.

Show, do not only tell. Two or three examples of input paired with exactly the output you want will beat several paragraphs describing that output. Where the result feeds other software, ask for a defined schema and validate what comes back rather than parsing prose.

Give the model room to work before it commits. Asking for the reasoning before the answer, rather than after, measurably improves anything involving several steps — the words it generates first become context for the words that follow.

It is the cheapest lever available. A better prompt costs an afternoon; fine-tuning costs a dataset and a training run, and switching to a larger model costs more on every single call from then on. Most teams that believe they need a bigger model need a clearer instruction and a couple of examples.

Collecting magic phrases. Flattery, threats and "you are a world-class expert" are folklore; some of it helped on older models, little of it survives contact with a current one, and none of it substitutes for saying what you want. Test a change against real cases instead of adopting it because it sounded plausible.

The larger shift is that the job is turning from wording into context: deciding which documents, examples, tool results and history belong in the window for this specific request. That is why the work is increasingly called context engineering.