Getting better answers from language models

Most people’s first instinct with a language model is to treat it like a search engine. Type a few words, see what comes back. The results are usually mediocre, and a fair number of people stop there, concluding the tools are overrated.

The conclusion is wrong, but the experiment was too. A language model isn’t looking anything up. It is continuing a piece of text in the most plausible way it can, based on everything you’ve given it. Give it three vague words and it has almost nothing to work with, so you get the most average possible answer. Give it real context and constraints and the output changes character entirely.

Writing that context well has picked up a grand name, prompt engineering, but the practice itself is mostly ordinary clarity. A few habits account for the bulk of the improvement.

Say what you actually want

Compare two requests. “Write about AI benefits” gives the model nothing: no audience, no purpose, no format, no length. Now try telling it that it’s advising a retail CEO, that you need three benefits of using AI in customer service, that the focus is cost and customer satisfaction, and that the answer should read as a one-page memo.

The second request will produce something usable on the first try far more often. Nothing about it is clever. It is the same information you would give a freelancer on day one, which is a decent rule of thumb for prompting in general: if a capable human stranger couldn’t do the job from your instructions, the model probably can’t either.

Give it a role and a reader

Telling the model who it is supposed to be (“you are an experienced financial analyst”) and who it is writing for (“a board that has limited patience for jargon”) shapes tone, vocabulary, and depth all at once. It sounds like a parlor trick. It works because the model has seen millions of examples of how analysts write for boards, and you’ve just pointed it at the right shelf.

Show an example or two

When format matters, the single best instruction is a sample. One or two examples of the input and output you want will beat several paragraphs of description. People who use models heavily lean on this constantly, and newcomers almost never do.

Make it think before it answers

For anything with real reasoning in it, ask the model to work through the problem step by step before giving its conclusion. For long inputs, separate the instructions from the material with clear markers so the two don’t blur together. Both habits cost nothing and measurably cut down on confident nonsense.

Expect to iterate

Even a good prompt rarely lands perfectly the first time. Read the output critically, notice where it drifted, and tighten the instruction. Add a constraint. Supply a better example. Two or three rounds of this almost always converge, and the refined prompt becomes a small reusable asset. Teams that save and share their working prompts stop solving the same problem over and over.

Why this is worth a team’s time

None of these habits require technical background, which is exactly why they’re worth teaching broadly rather than leaving to a few enthusiasts. The gap between an untrained and a trained prompter shows up directly in the quality of drafts, analyses, and summaries that flow through a business every day. In our training sessions, this gap is usually visible within an hour, on the participants’ own work.

There is a caveat worth keeping in view. Better prompting raises the quality of output. It does not make output trustworthy on its own. A well-prompted model still gets things wrong, still states errors with confidence, and still needs a human check before its work carries your name. Knowing how to ask is half the skill. Knowing how to verify is the other half, and the two are best learned together.