What Is Prompt Engineering? Techniques, Examples and Common Mistakes

Two people can ask the same AI model for the same thing and get answers of very different quality. The difference is often the prompt. Prompt engineering is the skill of closing that gap, and you do not need a machine learning background to learn it.

This guide explains the techniques that matter most, with prompts you can adapt. The examples work as patterns with most large language models (LLMs), though each model behaves differently, so try them on the one you use. Output described here is illustrative and not a guarantee of what a model will produce.

What is prompt engineering?

A prompt is the input you give to a generative AI model. Prompt engineering is the process of designing and refining that input so the output is accurate, relevant and in a form you can use. It covers the wording of your request, the background you supply, the examples you include and the way you break work into steps.

A helpful way to think about it: imagine briefing a very capable new colleague who knows a great deal in general but nothing about your project, your audience or your standards. If you say “write something about our release”, you will get something generic. If you give them the audience, the facts and the length, you will get something much closer to what you need.

Why prompts matter

An LLM generates text by predicting what is likely to come next, based on patterns learned from training data and whatever you provide. It does not read your mind, and it will usually fill any gap in your request with a plausible assumption. Vague prompts therefore do not fail loudly. They produce something that looks fine but may be wrong for your situation.

This matters more when AI is built into a product. In a chat, you can simply ask again. In an application, a prompt runs thousands of times without anyone watching, so small weaknesses become repeated errors.

Anatomy of a good prompt

Most strong prompts contain some combination of these parts. You rarely need all of them, but it helps to check for each.

Before and after

Here is a weak prompt:

Write test cases for login.

It leaves everything open: which login, what rules, how many cases and what format. Here is the same request with those gaps filled:

You are a senior QA engineer.

Write test cases for the login form described below.

Requirements:
- Email and password are both required.
- The account locks after 5 failed attempts within 15 minutes.
- "Forgot password" sends a reset link.

Output a table with the columns: ID, Scenario, Steps, Expected result.
Cover positive, negative and boundary cases, with at most 10 rows.
If a requirement is unclear, list your question below the table
instead of guessing.

The second version is longer, but it needs fewer retries. Asking the model to raise questions rather than guess is especially useful, since it surfaces missing information. If you want to judge the result, our guide on how to write test cases explains what good ones look like.

Core prompt engineering techniques

Zero-shot prompting

You give an instruction with no examples. This is the simplest method and is fine for common tasks such as summarising or translating. Start here, and add more only if the results fall short.

Few-shot prompting

You show a few examples of the input and output you want, and the model follows the pattern. This is often the quickest way to get a consistent format or tone, because showing is clearer than describing.

Classify the sentiment of each review as positive, negative or mixed.

Review: "Fast delivery and great quality."
Sentiment: positive

Review: "It broke after two days."
Sentiment: negative

Review: "Lovely design, but the battery is poor."
Sentiment: mixed

Review: "Setup was painful, though support fixed it quickly."
Sentiment:

Choose examples that cover tricky cases rather than only easy ones, and vary them so that the model does not copy an accidental pattern.

Asking for step-by-step reasoning

Known as chain-of-thought prompting, this asks the model to work through a problem before giving its final answer. It tends to help with maths, logic and multi-step decisions.

A plan costs 800 per month, or 8,000 per year paid upfront.
A customer expects to stay for 11 months. Which is cheaper?
Work through the calculation first, then give the answer
on a final line starting with "Answer:".

The reasoning also gives you something to check, but do not treat it as a perfect record of how the model reached its answer. Verify important results independently.

Role prompting

Assigning a role, such as “You are a technical editor”, can shift tone, vocabulary and focus. It does not give the model knowledge it lacks, so a role is no substitute for supplying the facts.

Providing context

If an answer depends on your documents or data, paste them in and tell the model to rely on them. Systems that do this automatically, by retrieving relevant documents before each request, are known as retrieval-augmented generation (RAG). A good instruction is: “Answer using only the text below. If the answer is not there, say you do not know.” This reduces made-up answers, although it does not remove the risk.

Specifying the format

State exactly what structure you want. If your code will read the result, ask for JSON and show the shape:

Extract the details from this email. Return only JSON:
{"name": string, "order_id": string, "issue": string}
Use null for anything that is missing.

Email: """
{email_text}
"""

Using delimiters such as triple quotes separates your instructions from the data. Many APIs also offer structured output modes that enforce a schema, and these are more reliable than asking in words alone. Always validate the output in your code anyway.

Prompt chaining

Instead of one giant prompt, break the work into steps, feeding each output into the next. For example, to answer a long customer complaint: first extract the facts, then classify the issue, then draft a reply using those results. Each step is simpler, easier to test and easier to fix when something goes wrong.

Iteration

Your first prompt is a draft. Read the output, work out what is wrong and change one thing at a time. If the answer is too long, set a limit. If it misses a case, add an example. Changing one thing at a time tells you what actually helped.

Prompts for developers

Coding assistants respond well to the same principles. Share the error, the relevant code, your language and version, and what you have already tried.

This Python 3.13 function should return orders from the last 7 days,
but it also returns older ones.

[paste function and one failing example]

First explain the cause in two sentences.
Then show the smallest fix. Do not refactor anything else.

Review generated code just as you would a colleague’s. Run it, read it and add tests. Our guide to unit vs integration testing is a good reference, and a clear description of the problem, as in a good bug report, improves AI answers as much as human ones.

How to test a prompt

One impressive answer does not mean a prompt works. Models can vary between runs, and a prompt tuned on one input can fail on the next. Treat prompts more like code: collect real examples, define what a correct answer is, and measure.

Here is a minimal evaluation script. You supply call_model, a function that sends text to whichever model you use and returns its reply.

PROMPT = """Classify this support ticket as billing, technical or other.
Reply with one word only.

Ticket: {ticket}"""

CASES = [
    ("I was charged twice this month", "billing"),
    ("The app crashes when I log in", "technical"),
    ("Do you have an office in Pune?", "other"),
]

def evaluate(call_model):
    passed = 0
    for ticket, expected in CASES:
        answer = call_model(PROMPT.format(ticket=ticket)).strip().lower()
        ok = answer == expected
        passed += ok
        print("PASS" if ok else "FAIL", "|", ticket, "->", answer)
    print(f"{passed}/{len(CASES)} passed")

We checked this script with a fake model that always gets the third case wrong, and it reported 2/3 passed, so failures show up clearly. In real use, add many more cases, including awkward ones, and run the set several times. Rerun it whenever you change the prompt or upgrade the model. For free-form answers where exact matching is impossible, score with a checklist or human review.

Prompt injection and limits

If your application passes user text or web content to a model, that text may contain instructions such as “ignore your previous rules”. This is called prompt injection, and no prompt wording fully prevents it. Treat model output as untrusted, give the model only the permissions it needs, and require human approval for sensitive actions such as sending money or deleting data.

Also keep in mind that models can state false information with confidence, and their knowledge may be out of date. Check facts, figures and citations, and do not paste confidential data into a tool unless your organisation has approved it.

Common mistakes

• Being vague. “Make it better” gives the model nothing to aim for. Say what better means.
• Overloading one prompt. Five tasks at once lead to uneven results. Chain them instead.
• Trusting without checking. The more an answer matters, the more you need to verify it.
• Never measuring. Without test cases, you cannot tell if a change helped or just looked better once.

Final thoughts

Prompt engineering is mostly clear communication plus a habit of testing. Take one task you repeat every week and write a proper prompt for it, covering the task, context, format and constraints. Add two or three examples, try it on several real inputs and keep what works. A small library of tested prompts will serve you better than any list of tricks.

Frequently asked questions

Keep learning