Prompt Engineering: The Complete Guide to Writing Better AI Prompts

Short answer: prompt engineering is the practice of writing structured, context-rich instructions so an AI model produces the output you actually need instead of something vaguely related to your question. Most of it is not clever phrasing. It is specification — saying who the model is, who the output is for, what it must contain, and what shape it should come back in.

I write a lot of prompts. Not in a chat window for fun, but inside systems I ship: bots that answer customers in Persian, scripts that generate schema for client pages, pipelines that draft and then criticise their own output. The gap between a prompt that works in a demo and one that survives a thousand real messages is where I learned most of what follows.

The single biggest lesson: almost every disappointing AI output I have produced was my fault, and the fix was almost never a cleverer sentence. It was information I had not given the model.

What prompt engineering actually is

Prompt engineering is writing instructions for an AI model so the result is consistently usable: accurate, on-brand, in the right format, and needing minimal editing before it goes anywhere.

The name is unfortunate, honestly. "Engineering" suggests a deep technical discipline with secret incantations, and that is not what this is. It is closer to writing a good brief for a very fast, very well-read freelancer who has never met you, has no access to your files, will not ask clarifying questions unless you invite them, and will confidently guess at anything you leave out.

Once you hold that picture in your head, most of the advice becomes obvious. You would not send a freelancer the message "write about marketing" and expect something usable. You would tell them who it is for, how long it should be, what angle you want and what to avoid. That is the whole discipline.

Where it stops being obvious is at scale. Writing one good prompt is easy. Writing a prompt that works on the two-hundredth input you have not seen yet — that is the part that takes real work, and it is why the production section below matters more than the tips.

Why the wording changes the output at all

You do not need to understand transformers to be good at this, but a rough mental model helps you predict what will work instead of guessing.

A language model continues text. Given what came before, it produces what most plausibly comes next, shaped by everything it learned in training. So "write about website speed" is consistent with tens of thousands of plausible continuations — beginner blog posts, marketing fluff, academic papers — and what you get back is effectively the average of them. Bland, because the average of everything is bland.

Every specific thing you add cuts that space down. Say "you are a performance engineer," and the academic register and the beginner blog post both drop away. Say "for a shop owner who does not know what a millisecond costs them," and the jargon-heavy continuations drop away too. Add "300 words, three paragraphs, end with one concrete action," and you have narrowed thousands of possible answers to a small family of good ones.

This also explains why the model happily invents things. Filling a gap with something plausible is exactly what it is built to do; it has no separate sense of "I do not actually know this." That is why the fix for invented facts is not a sterner tone, it is giving it the material or explicitly permitting it to say nothing.

The seven parts of a professional prompt

This is the checklist I run through when something is not working. You will rarely need all seven, but a prompt producing weak output is usually missing three or four.

1. Role

Open with who the model is supposed to be. "You are a senior content strategist working with B2B SaaS companies" points at a different body of language than no role at all. Be specific about the field and the seniority; "you are an expert" is close to useless because everything is expert-adjacent.

2. Goal

Name the deliverable, not the topic. Not "write about hiring" but "write a 150-word LinkedIn post about the most common mistake founders make when hiring their first marketer." A topic invites an essay. A deliverable invites the thing you wanted.

3. Audience

Say who reads it, what they already know, and what they are trying to decide. The same subject written for a backend developer and for a café owner are two different pieces of work, and the model cannot infer which one you meant.

4. Context

This is the part people skip and then blame the model for. Paste the background it cannot possibly have: the product, the market, the constraint, the code, the exact error message, the previous version of the text. Context is the difference between a generic answer and yours.

5. Constraints

Length, tone, format, things to avoid, claims that need hedging. Negative constraints deserve a special mention because they are underused: "no bullet points," "do not name competitors," "skip the general background and start with the specific answer." Each one removes a failure mode you would otherwise fix by hand.

6. Examples

One good example beats a paragraph of adjectives. If you want a certain voice, paste two hundred words written in it. This is the highest-leverage item on the list and the least used — probably because it takes thirty seconds of copying instead of thirty seconds of typing. Be careful what you show it, though: the model copies the flaws in your examples just as faithfully as the strengths.

7. Output format

State the exact shape you want back: a table with these columns, JSON with these keys, three sections with these headings, the body text only with no preamble. If the output feeds a script, specify it strictly and tell the model to return nothing else. "Output only the JSON object, no explanation, no code fences" has saved me more parsing bugs than any library.

A template you can copy

This is close to the skeleton I actually reuse. Delete whatever does not apply, keep the order — it front-loads the framing before the detail, which is how these models read best.

ROLE
You are a [specific role] with [experience] in [domain].

GOAL
Write [exact deliverable] of about [length] about [precise subject].

AUDIENCE
[Who they are], who already know [X] and want to decide [Y].

CONTEXT
- [Fact the model cannot guess]
- [Fact the model cannot guess]
- [Source material, pasted in full below if it exists]

CONSTRAINTS
- Tone: [tone]. Language: [language].
- Do NOT: [failure mode 1], [failure mode 2].
- If you are unsure of a fact, say so instead of guessing.

EXAMPLE OF GOOD
"""
[Two hundred words in the voice you want]
"""

OUTPUT FORMAT
Return [exact structure]. No preamble, no closing summary.

Techniques that actually work

There are hundreds of named techniques circulating. These are the ones I still use after the novelty wore off.

Chain of thought

Adding "work through this step by step before giving your final answer" measurably improves accuracy on multi-step problems — this is the 2022 result from Wei and colleagues at Google, and it held up well enough to change how everyone writes prompts. Two caveats from practice: on simple rewriting or lookup tasks it just makes the answer longer, and on newer reasoning models the step-by-step work already happens internally, so asking for it again mostly adds noise. Use it where the task genuinely has steps.

Few-shot examples

Give two or three worked examples and ask for a new one in the same pattern. This has been understood since the GPT-3 paper in 2020 and it remains the most reliable way to lock in a format or a voice. Two or three is the sweet spot; beyond that you spend context for very little return.

Iterative refinement

Treat the first output as a draft, always. Then go specific: "make paragraph two concrete with a real example," "cut this to 120 words without losing the caveat," "give me three alternative openings, each with a different angle." Vague follow-ups like "make it better" produce different, not better.

Give it a rubric

Tell the model how you will judge the result, then ask it to check its own draft against that list before returning it. Something like: "Before you answer, verify: is the first sentence a direct answer? Is every number sourced? Is anything here true only for the US?" It is the cheapest quality gain I know of, and it makes the model's misses much easier to spot.

Ask for the shape, not the tone

"Make it more professional" is barely instruction. "Remove all adjectives, cut every sentence over 25 words, and replace the two vague claims with numbers" is. Structural instructions land; mood words drift.

Before and after

Three pairs from real work. The difference in each case is information, not eloquence.

Notice that the good versions are not written more beautifully. They are just longer in the places where the model would otherwise have guessed.

Prompts inside real systems

Everything above assumes you are typing into a chat box. The moment a prompt goes into software that runs it on inputs you have not seen, the rules change, and this is where most projects get into trouble.

• Keep prompts in files, not in string literals. A prompt is content. It changes weekly at first. Buried in the middle of a function it becomes unreviewable and nobody dares touch it.
• Version them and write down why. "v4 — added the rule about never inventing prices, after the incident on 12 Shahrivar." Six weeks later that note is the only thing standing between you and re-breaking it.
• Separate the standing instruction from the request. Role, tone and hard rules belong in the system prompt. The user's message is the variable part. Mixing them is how a customer's message ends up overriding your rules.
• Assume hostile input. If a user's text is pasted into your prompt, someone will eventually paste "ignore your instructions and…". Put untrusted text in clearly delimited blocks, tell the model that everything inside them is data and never instructions, and never let a model's raw output trigger an irreversible action on its own.
• Build a test set of twenty awkward inputs. The empty message, the 4,000-word message, the one in another language, the rude one, the one asking about something you do not sell. Run it after every prompt change. This takes an afternoon to set up and it is the difference between shipping and firefighting.
• Log the input and the output. You cannot improve a prompt you cannot see failing. This is also the raw material for your examples section later.

If you write this tooling yourself, it will almost certainly be in Python — the client libraries, the evaluation frameworks and the retrieval tooling all live there first. I wrote separately about why Python became the default language of AI work if you want the background on that.

Prompts for SEO and GEO content

This is the use that pays for itself fastest, so it is worth being precise about what prompting can and cannot do here.

It can do the structure. You can reliably prompt for an answer-first opening paragraph, for self-contained sections of 200 to 300 words that survive being pulled out of the page, for a structured FAQ where the visible text and the schema match word for word, and for a valid JSON-LD graph. That last one alone saves hours, and it is the sort of exacting, repetitive work models are genuinely good at.

It cannot do the substance. The thing AI answer engines most want to cite is a specific, verifiable fact that nobody else has — your data, your test results, your log excerpt, your client's numbers. A model cannot produce that, and content assembled entirely from what the model already knows is by definition not new information for anything retrieving it.

One warning that has nothing to do with search engines: verify before publishing. Models produce confident, well-formatted, entirely incorrect specifics — dates, statistics, citations, version numbers, prices. A fabricated statistic on your site does more damage to your credibility than ten missing articles.

Mistakes that cost me the most time

1. Describing the style instead of showing it

I once spent an hour iterating on adjectives — warmer, more confident, less corporate — for a piece of copy. Pasting two paragraphs of the voice I wanted fixed it on the first try. Show, do not describe.

2. Asking for everything in one prompt

Research, outline, draft and polish in a single request gives you a mediocre version of all four. Split it: outline first, approve it, then draft section by section. Each step is cheaper to correct.

3. Accepting the first output

The first response is a starting point, not a deliverable. The gap between usable and good is almost always two or three specific follow-ups.

4. Trusting specifics

Names, numbers, dates, citations, API parameters and version details are exactly where models fail most convincingly. Verify all of them. Every time.

5. Not saving the prompts that work

For two years I rewrote the same prompts from memory, slightly worse each time. Keep a file per use case with the prompt and one line on why it is shaped that way. It compounds, and it is the cheapest institutional knowledge a small team can build.

6. Blaming the model

When the output is wrong, my first question now is what I failed to specify. It is the right answer often enough that starting anywhere else wastes time.

When prompting stops being enough

There is a ceiling here, and it is worth knowing where it sits.

A prompt is one instruction producing one output. That is the right tool for drafting, rewriting, summarising, converting and explaining. It is the wrong tool the moment the task needs several passes, outside information, real tools or a quality check that has to happen before anyone sees the result.

At that point you stop writing prompts and start building a loop: generate, evaluate against criteria, fix what failed, repeat, stop at a defined condition. The prompt becomes one component inside a system rather than the system itself. That shift is what loop engineering is about, and it is where most of the interesting work has moved.

My honest view on the future of this skill: the tricks are dying and the specification is not. Every model generation needs less coaxing than the last, and the prompt libraries full of magic phrases are aging badly. But no model, however capable, can guess your audience, your constraints, your data or your house style. Saying clearly what you want is not a 2023 technique. It is just communication, and it will outlive every trick on every list.

Written by Soroush Moghaddami

Software engineer since 2012, working in Python, Java and Oracle, and head of the database department at a national mobile operator. He founded Filtori, where he builds bots, websites and AI automation for businesses. The prompts in this article come from systems currently running in production.

All articles by Soroush Moghaddami · LinkedIn