The practices that matter for training AI models with prompts all start from one fact about what a prompt does. It changes the input to a model whose weights are already fixed. Everything you gain comes from the text you put in front of it, in one pass, with no memory of the last attempt.
Six practices survive contact with production:
- State the effect you want along with the reason for it.
- Show three to five examples of the output you expect.
- Replace prohibitions with the behaviour you want to see.
- Structure long prompts with tags, so instructions and data stay separable.
- Score every prompt edit against fixed test cases.
- Keep the prompts that work in one versioned place.
Prompting steers a model that is already trained
Training a model means running data through it and adjusting billions of numerical weights until its predictions improve. It takes a GPU cluster, weeks of wall-clock time, and a budget somebody signs.
Prompting happens after all of that, at inference time, meaning the moment you send the request. The weights sit frozen. Your prompt lands in the context window, meaning the span of text a model holds in mind for one request, and shapes the output for that request alone.
Researchers call the effect in-context learning, and the word learning is doing a lot of work there. The model picks up a pattern from the prompt, applies it, then loses it when the context clears. Every session is a first day on the job with a colleague who skimmed the handbook once.
That tells you where to spend effort. A behaviour that must hold for every user belongs in a prompt you control and version. Once that prompt needs its own table of contents, fine-tuning starts to compete. Our piece on when to build an LLM and when to skip it works through the trade, and LLM Systems Engineering covers what training costs.
Cause and effect AI prompts give the model a reason
A vague instruction gets a vague result. Ask for "a summary" and you get whatever summary means in the average of the training data, which is a paragraph of medium length in a register nobody chose.
The less intuitive part is that explaining the reason behind an instruction beats tightening the instruction. Anthropic's prompting best practices illustrate this with a formatting rule. A flat prohibition on ellipses performs worse than the same rule with its reason attached, explaining that the text will be read aloud by an engine that cannot pronounce them. The model then generalises to the punctuation you forgot to list.
That is a cause and effect AI prompt: an instruction paired with the consequence that motivates it. "Keep it under 200 words" is a rule. "Keep it under 200 words because it goes into a notification that truncates" is a rule the model can reason around when your data surprises you.
The same guidance offers a test worth stealing. Hand your prompt to a colleague who knows nothing about the task and ask them to follow it. Their confusion is the model's confusion, except that they will tell you about it. Claude AI for Beginners builds the habit from a standing start.
AI prompt examples carry more than descriptions do
If you want a particular output shape, showing it works better than describing it. A few worked examples pin down formatting and tone that a paragraph of adjectives never quite fixes. The technique goes by few-shot or multishot prompting, and Anthropic's documentation puts the useful range at three to five examples.
Three properties decide whether examples help at all:
| Property | What it means in practice |
|---|---|
| Relevant | Drawn from your real inputs, including the messy ones |
| Diverse | Varied enough that the model cannot latch onto an accident |
| Structured | Wrapped in their own tags, so they read as samples and not as instructions |
Diversity is the property teams get wrong. Give a model five examples that all open with a date and it will open with a date forever, including for the input that has none. It found the pattern you accidentally taught it, which describes most prompt bugs.
Tags matter more as prompts get longer. When a prompt carries your instructions and the user's material in one block of text, the boundary between them is a guess. Naming each part removes the guess:
<instructions>
Summarise the support ticket below for an engineer on call.
Lead with the customer impact.
</instructions>
<ticket>
{ ticket_text }
</ticket>Tagging is also defensive, since user text inside a marked tag is harder to mistake for an instruction you wrote. It is not a security boundary on its own, and should never be the only thing between a user's input and a tool call.
What is a negative prompt in AI, and when it backfires
A negative prompt describes what you want kept out of the output. In image generation the term is literal, since many tools expose a dedicated field for artefacts to suppress such as watermarks or distorted hands. Text models have no separate field, so a negative prompt is any instruction built on avoid or never.
These work up to a point. A prohibition defines a space by its edges and leaves the middle unspecified. Tell a model to avoid marketing language and it drops the phrases it most associates with marketing, then reaches for the tier below, which is often worse.
The reliable move converts the negative into a positive with a reason attached, which is the cause and effect pattern again. "Do not be verbose" becomes "answer in under 80 words, because this renders inside a chat bubble."
How to prompt AI to write like a human
This is the negative prompt problem in its most common form. "Make it sound human" fails because a model has no reliable internal label for its own register. Supplying the target works better. Paste two pieces of writing you consider human, ask for that voice, then name the tells you want gone. A ban on a phrase is enforceable in a way that a ban on a vibe is not.
The uncomfortable part is that the strongest tells are structural. Sentences of uniform length, and a closing paragraph restating what the reader has already read. Fixing those takes an editing pass with its own brief, which means a second prompt.
Score prompts against a fixed test set
Every practice above is a hypothesis until you measure it. The difference between prompts that hold up and prompts that quietly rot is whether anyone can tell when an edit made things worse.
The method is unglamorous. Assemble real inputs with known-good outputs, score the results the same way every time, then change one thing and re-run.
Anthropic's guidance on defining success criteria and building evaluations tells teams to prioritise volume over quality. A hundred cases graded automatically beat a dozen graded by hand, because the automated set runs on every change and the hand-graded set runs once, in a burst of enthusiasm, then never again.
Scoring can be crude and still be useful:
- Exact string match, for anything with a fixed set of correct answers.
- Cosine similarity, meaning how close two pieces of text sit in meaning, for consistency across runs.
- A second model grading against a written rubric, for anything subjective. You now have two prompts to maintain, which is the honest price of this one.
Include the inputs that embarrass you: the empty field, and the message three times longer than anything you designed for. Nobody writes those down, and they are where a prompt breaks.
How to organize AI prompts into a library
Prompts accumulate. Six months in, the good ones are spread across code comments and somebody's notes app, and whoever wrote the best one has changed teams.
A prompt library is the fix, and it can start as one directory of text files under version control. What earns it the name is a few habits:
- One file per prompt, with the task it serves named at the top.
- The test cases beside the prompt, so a change and its evidence travel together.
- A note on which model produced the scores, because a prompt tuned on one model is a draft on another.
That last habit catches teams out. A model upgrade is the one change nobody treats as a prompt change, right up until the release where the phrasing that used to help stops helping.
System prompts and models of AI tools
Organisation also means deciding which layer an instruction belongs in. The system prompt holds what is true for every request, such as the role and the standing constraints. The user turn holds what varies. An API exposes a system parameter for this, while a chat product may call it custom instructions. Agent frameworks assemble it from a template you never see, worth checking before you debug somebody else's default for a week.
The field is larger than it looks. The Prompt Report catalogues 58 text-based prompting techniques and had to define a 33-term vocabulary, because the literature could not agree on what anything was called. Most teams need a handful. AI Prompt Engineering covers building prompts into maintained systems, and Agentic AI Engineering takes system prompt design into agent territory.
One thing to carry out of this. The prompt is the part of the system you can change today, so treat it like the code it functionally is. Version it and score it, then roll it back the moment it gets worse.
The weights will keep improving without you. The instructions will not.