Prompt engineering: a practical guide to better LLM results

Prompt engineering means writing the input to a language model so it reliably does what you want. It is less magic and more clear communication: say what you want, give the needed context and define the shape of the answer.

1. Be clear and specific

Vague: "Write about databases."

Better: "Write a 150-word explanation of database indexes for a junior developer. Use one analogy and one SQL example. Do not mention vendor-specific features."

Include:

• The task (what to do).
• The audience and tone.
• The length and format.
• What to avoid.

2. Give context

The model only knows what is in the prompt (and its training). Provide the background it needs: the text to work on, definitions, rules, the user's goal. If a fact must be right, include it rather than hoping the model remembers.

Separate parts clearly with labels or delimiters so instructions are not mixed up with data:

Task: Summarise the article below in 3 bullet points.

Article:
"""
...text here...
"""

3. Show examples (few-shot)

Examples often work better than long descriptions.

Classify the sentiment as positive, negative or neutral.

Text: "Delivery was fast and the box was intact." -> positive
Text: "The app crashes every time I open it." -> negative
Text: "It arrived on Tuesday." -> neutral
Text: "The support team never replied." ->

Use a few varied, correct examples, including edge cases. Keep their format identical to the output you want.

4. Ask for a structured output

When code will read the answer, request a strict format, for example JSON with named fields:

Return only valid JSON with this shape:
{"title": string, "tags": string[], "priority": "low" | "medium" | "high"}

Many APIs offer structured output or JSON-schema modes that enforce this. Still, validate the result in code and handle failures with a retry or fallback.

5. Let the model work step by step

For reasoning, maths or multi-step tasks, ask the model to break the problem down or to plan before answering. Some models have built-in reasoning modes. For simple tasks this only adds cost, so use it where it helps. If you only need the final answer, ask for a clean final answer after the work.

6. Use the system prompt for rules

Many APIs separate a system prompt (stable rules and role) from user messages.

You are a support assistant for Acme.
- Answer only from the provided help articles.
- If the answer is not there, say you do not know and offer to contact a human.
- Keep replies under 120 words.

Put persistent behaviour, tone and constraints there. Remember a system prompt is not a security boundary and should not contain secrets, because users can often coax it out.

7. Tell it what to do when unsure

Give a permitted way out: "If the information is missing, answer 'unknown'." This reduces made-up answers.

8. Iterate and test

Prompting is an experiment loop.

1. Write a first version.
2. Run it on a set of real examples, including hard ones.
3. Look at failures and change one thing at a time.
4. Keep the examples as a test set so you notice regressions when you change the prompt or the model.

Save prompts in version control. A change of model version can change behaviour, so re-run your tests.

Common mistakes

• Packing many unrelated tasks into one prompt.
• Contradictory instructions.
• Hiding the real requirement in a long wall of text.
• Trusting output without checking.
• Putting untrusted user text and instructions together without separation, which allows prompt injection (see the security article in this series).

A reusable template

Role: <who the model is acting as>
Task: <what to do>
Context: <background and data>
Rules: <must and must not>
Examples: <1-3 examples>
Output format: <exact shape>

Takeaway: be specific, give context and examples, define the output format, tell the model what to do when unsure, and treat prompts like code: test them on real cases and improve step by step.

---

AI & LLM series, Part 1 (building with language models): 2 of 5. Previous: How large language models work: tokens, context and sampling.