A lot of AI pilots stall on the same complaint. The answers sound right, and too many of them are wrong. Before anyone reaches for a bigger model or a fine-tuning project, it's worth looking at the prompt, because that's the cheapest thing in the system to change and the one teams test least.
An effective prompt has three parts. It sets the stage (who the model is acting as, who the answer is for, and what it should work from), it defines the task (the one thing to produce), and it specifies the rules (format, tone, what to include and what to leave out). Prompt engineering is writing those parts precisely and then iterating on what comes back.
That's the short answer. The example below follows it to the letter and still produces a confident answer that's wrong, so we take it apart, rewrite it, and show a simple way to test a prompt change before it ships, the way you'd test any other change to production code.
Updated by the TechFabric editors in October 2026. Leo Oliemans' example prompt is quoted as he wrote it; the analysis around it, the revised prompt and the testing method were added by the editors.
The example prompt
Comparing parts for a low-power IoT project, a prompt that sets the stage, defines the task and specifies the rules might read:
"You are my personal assistant who is an expert in electronic component analysis, and I'm working on a low-power IoT project. Act as if you are a seasoned electronics application engineer providing consultancy.
Create a technical briefing that compares the energy efficiency and computational capabilities of the A12 Bionic microcontroller versus the Snapdragon X20 microcontroller.
Do focus on their power consumption rates, processing power in terms of GFLOPS, and cost per unit for bulk purchases. Don't include any advanced features that are unnecessary for simple IoT devices, like graphics processing capabilities."
And it goes on to define the output:
"Present this in the form of a concise comparative report and include a summary table. The report should be technical but understandable for a non-expert audience, aiming to be informative yet engaging.
Please use a respectful and professional tone appropriate for a business setting. If there are technical terms, briefly explain them."
Mapped onto the three parts:
| Part | What the prompt says |
|---|---|
| Setting the stage | An electronics application engineer advising on a low-power IoT project |
| Defining the task | A technical briefing comparing two parts on energy and compute |
| Specifying rules | Power, GFLOPS and bulk cost in; graphics out; a report with a summary table; professional tone; explain jargon |
Structurally it's a good prompt. The role gives the model a register to write in, the do and don't list narrows what's relevant, and asking for a summary table gets you something you can paste into a design review.
What the prompt gets wrong
Neither part in it is a microcontroller. Apple's A12 Bionic is the system-on-chip from the 2018 iPhone XS, and Apple doesn't sell it to anyone. Qualcomm's Snapdragon X20 is an LTE modem. So there's no bulk unit price to quote for either, and GFLOPS isn't how anyone rates a microcontroller for a battery-powered sensor. Those parts are compared on active current per MHz, sleep current, wake-up time and which radios and peripherals are on the die, with CoreMark as the usual compute benchmark.
A model given this prompt will usually not say any of that. The role told it to act as a seasoned consultant, and the format told it to produce a table, so it fills the table. Some cells will be real figures for the wrong kind of part, and some will be numbers it produced because a cell was there. The answer will look exactly like what was asked for. This is the failure prompt engineering most often misses, because every part of the prompt was followed.
The fixes are small, and each belongs to one of the three parts.
Stage: give the model the source material instead of relying on its memory. Paste the datasheet sections, or attach the files, and say the answer must come from them.
Task: let the model question the premise. One sentence does it: "If either part isn't suited to a low-power IoT device, or the comparison doesn't make sense, say so before writing the briefing."
Rules: give it a way out of the table. "Where the datasheet doesn't state a value, write 'not stated' rather than estimating." And ask for the metrics that fit the job, such as active and sleep current, rather than the ones that sound technical.
A revised prompt, with the two documents wrapped in tags so the model can tell them apart from the instructions:
You're an electronics application engineer advising on a battery-powered
IoT sensor that wakes once a minute, takes a reading and sends it over BLE.
Compare the two parts described in the datasheets below for this use.
If either part is unsuitable for a low-power IoT device, say so first and
explain why.
Use only the datasheets. Where a value isn't stated, write "not stated".
Cover: active current per MHz, deep-sleep current, wake-up time, on-chip
radios, CoreMark score if given, and unit price at 10,000 units if given.
Leave out graphics and display features.
Format: a summary table, then three short paragraphs a non-engineer
could follow. Explain each technical term the first time it appears.
<datasheet name="part_a"> ... </datasheet>
<datasheet name="part_b"> ... </datasheet>
Both Anthropic and OpenAI recommend this kind of structure in their current guidance. OpenAI's prompt engineering guide suggests separating identity, instructions, examples and context into sections, and says XML tags "can help delineate where one piece of content (like a supporting document used for reference) begins and ends". Anthropic's covers the same ground, from clarity and examples to XML structuring and role prompting.
Do's and don'ts in a prompt
Telling a model what to include and what to leave out is one of the cheapest improvements available, and the example does it well. Two refinements make it work better.
State the don'ts as what to do instead where you can. "Don't include graphics features" works, but "cover only power, compute and price" leaves less to interpret.
And give a reason when the rule isn't obvious. "Leave out graphics because these devices have no display" lets the model apply the same thinking to features you didn't list, such as video encoders.
Tone and audience
Naming the reader changes more than the vocabulary. "Understandable for a non-expert audience" in the original prompt will get you shorter sentences and defined terms. Naming the actual reader, such as "the operations director deciding which board to fund", also changes what the model puts first, because it now knows what that person needs to decide.
A short example of the output you want does more than any adjective. If you've written a briefing in the right tone before, paste two paragraphs of it and say "match this style". OpenAI's guide makes the same point about examples generally: show "a diverse range of possible inputs with the desired outputs".
Feedback, and what the model actually learns
Correcting a model mid-conversation works because the correction is now part of the conversation it reads on the next turn. It doesn't train the model. Start a new chat and the correction is gone, unless your tool has a memory feature that saves it.
That has a practical consequence. When a correction fixes something, move it into the prompt itself so it applies every time. A prompt that's used repeatedly, by a team or inside an application, should be a document you keep and version, with the lessons from each bad answer written into it.
Asking the model to help write the prompt is a reasonable start. Describe the goal loosely and ask it to draft a prompt and list what it needs to know. Anthropic publishes a prompt generator for exactly this. Treat what comes back as a first draft.
How to know the prompt works
One good answer proves very little. Model output varies from run to run, and a prompt that handled the part you tried can fail on the next one.
Anthropic's guide assumes you have three things before you start tuning a prompt: "A clear definition of the success criteria for your use case", "Some ways to empirically test against those criteria", and a first draft. OpenAI's recommends "building tests and evaluation suites that measure prompt behavior so you can monitor performance as you iterate". For a prompt like the one above, that can be as plain as this:
- Write down five to ten inputs, including a trap like the original pair, where the right answer is to object.
- Write what a good answer must contain for each, in one or two lines.
- Run every input after each change to the prompt, and read the answers against your lines.
If you call a model from code, pin a specific model version for the same reason. OpenAI's guide gives the example gpt-4.1-2025-04-14. A prompt tuned against one version can behave differently on the next, and your test list is how you find out before your users do.
Prompt engineering is a moving target
The techniques that matter have shifted since 2024. Newer models follow plain instructions more reliably, so elaborate tricks matter less, and giving the model the right documents and a clear way to say "I don't know" matters more. What hasn't changed is the structure: set the stage, define the task, specify the rules, then test what comes back. A well-structured prompt can still rest on a wrong premise, as the A12 and X20 comparison shows, so checking the premise belongs in every review of a prompt.
Frequently asked questions
What if I can't get the datasheets for the parts I'm comparing?
Then the model is back to working from memory, and the answer needs to say so. The revised prompt already gives it a way to do that: write "not stated" where a value is missing. That leaves gaps in the table instead of invented cells, and a gap tells you which datasheet to go and find before the briefing reaches a design review.
Does a prompt that questions the premise slow the answer down or make it less useful?
It adds one check before the briefing, and the briefing is where a wrong premise does its damage. With the A12 Bionic and Snapdragon X20 pair, an answer that says "neither is a microcontroller" is the useful one, and the prompt should reward it. Put a trap like that in your test inputs, so you can see whether a later edit to the prompt lost the objection.
Will the same prompt behave the same way next month?
Not if the model version changes underneath it. A prompt tuned against one version can behave differently on the next. If you call a model from code, pin the version. Keep your five to ten test inputs and rerun them whenever the version or the prompt changes.
Sources
Checked 11 October 2026.