"Write a product description for our new backpack." Every team that adopts an AI assistant starts with a prompt like this, gets something bland and generic back, and concludes the tool is overrated. The tool is fine. The prompt gave it almost nothing to work with. Prompt engineering sounds like a dark art, but most of it is the same skill as writing a good brief for a freelancer: say who it's for, what good looks like, and what to avoid.
Below are the prompt engineering techniques we actually use day to day, each with a before/after example. None of them depend on magic phrases.
1. Give context, not just a command
The model doesn't know your company, your customers or your constraints. Tell it.
Before:
Write a product description for our new backpack.
After:
We sell outdoor gear to urban cyclists aged 25–40 who commute daily. Write a product description for our new 22-litre waterproof backpack. Key features: roll-top closure, reflective strips, a padded laptop sleeve for up to 16 inches, recycled fabric. Tone: practical and a little dry, no exclamation marks. Length: about 120 words.
The second prompt is longer, and the output will be dramatically better, because the model is no longer guessing at audience, facts and tone. The single biggest improvement most people can make is simply to add the context they already have in their head.
2. Show examples (few-shot prompting)
Describing a style is hard. Showing it is easy. Including two or three examples of the input and the output you want is called few-shot prompting, and it's one of the most reliable techniques there is.
Before:
Classify these customer messages by urgency.
After:
Classify each customer message as HIGH, MEDIUM or LOW urgency.
Message: "The checkout page shows an error and I can't pay." → HIGH Message: "Can I change the delivery address on order 4471?" → MEDIUM Message: "Do you plan to sell this in green?" → LOW
Now classify: Message: "I was charged twice for the same order."
Pick examples that cover the edge cases you care about. If the model keeps getting a certain kind of input wrong, add an example of exactly that kind.
3. Specify the output format
If the output feeds into another system or a spreadsheet, define the format precisely. Ask for a table with named columns, a bulleted list, or JSON with specific keys.
Before:
Summarise this meeting transcript.
After:
Summarise this meeting transcript in three sections:
- Decisions made (bullets, one line each)
- Action items as a table with columns: Owner, Task, Deadline
- Open questions (bullets) If a deadline wasn't stated, write "not set" – don't guess.
That last line matters. Telling the model what to do when information is missing prevents it from filling the gap with something invented.
4. Ask for reasoning before the answer
For tasks involving analysis, comparison or multi-step logic, ask the model to work through the problem before giving its conclusion. This is often called chain-of-thought prompting. Because the model generates text one token at a time, writing out intermediate steps gives it more to work with before it commits to an answer.
Before:
Which of these three supplier quotes is best?
After:
Compare these three supplier quotes. First, list for each: total cost over 12 months, delivery time, payment terms and any conditions in the fine print. Then note the main trade-offs. Only then recommend one, with a two-sentence justification.
Many newer models reason internally before answering, so this technique matters less than it used to for pure logic. It still helps when you want the reasoning visible so a human can check it.
5. Assign a role and an audience
Telling the model who it is and who it's writing for shifts vocabulary, depth and assumptions.
Before:
Explain what an API is.
After:
You're a senior developer explaining things to a new account manager who has no technical background. Explain what an API is in under 150 words, using one everyday analogy. Avoid jargon; if you must use a technical term, define it.
Roles work best when combined with a concrete audience. "You are an expert" on its own does little.
6. Break big tasks into steps
One giant prompt asking for research, outline, draft and edit in one go usually produces a mediocre result at every stage. Chain smaller prompts instead: get an outline, correct it, then ask for a draft of section one, and so on. You catch problems early and keep control of the direction.
7. Give the model permission to say "I don't know"
Models are trained to be helpful, which can push them to answer even when they shouldn't. Explicitly allow uncertainty.
Before:
Based on this contract, what's the notice period?
After:
Based only on the contract text below, what's the notice period? Quote the clause you're relying on. If the contract doesn't specify one, say so – don't infer from typical contracts.
Asking for a quote from the source is a cheap, powerful check: you can verify it in seconds.
A prompt engineering checklist
| Element | Question to ask yourself |
|---|---|
| Context | Does the model know the audience, product and situation? |
| Task | Is the request specific, with a clear definition of done? |
| Examples | Would two or three examples make the target obvious? |
| Format | Have I specified length, structure and style? |
| Constraints | Have I said what to avoid and what to do when info is missing? |
| Source | Have I supplied the facts instead of hoping it knows them? |
Test prompts like you test code
For any prompt you'll reuse – in a product, a workflow or a template your team shares – keep a small set of test inputs and check the outputs whenever you change the wording. A tweak that fixes one case often breaks another. Teams that build AI features into products, which is a good part of what we do at Mraviko, treat prompts as versioned code for exactly this reason.
The takeaway
Good prompt engineering is mostly good briefing: context, examples, a clear format, permission to be uncertain, and the facts supplied up front. Start with those techniques before reaching for clever tricks. If the output is still wrong, the problem is usually missing information, not missing magic words.
