Guide · Prompting
How to learn prompt engineering
Prompt engineering is the practice of getting reliable output from a language model on purpose rather than by luck. It covers choosing the right model, giving it the context it needs, structuring the request so the answer can be checked, and testing whether a change made things better or only different.
How long does it take to learn?
The patterns take an afternoon to read and a week to feel. Evaluation, which is the part that separates a practitioner from someone with a good prompt, takes a month of doing it on real work. The tricks are quick. The judgement is not.
The fastest path, in order
- 01
Learn what the model is doing
Tokens, context windows, temperature, and the fact that it predicts rather than retrieves. Every reliable prompting habit is downstream of understanding this, and every superstition comes from not understanding it.
- 02
Choose the model before you write the prompt
A reasoning model, a fast cheap model and a long-context model fail in different directions. Half of what people call a prompting problem is a model selection problem, and it costs nothing to test three.
- 03
Give context, not adjectives
Examples of the output you want beat any number of instructions to be professional or thorough. Two or three worked examples in the prompt will outperform a paragraph of description almost every time.
- 04
Make the output checkable
Ask for structure you can validate: fields, a schema, a list of a stated length. An answer you can machine-check is an answer you can trust at volume, and it is what turns a prompt into something usable in a product.
- 05
Build a tiny evaluation set
Twenty real inputs with the answer you would accept. Run every prompt change against them. Without this you are not improving anything, you are only changing it and remembering the good runs.
- 06
Learn where prompting stops
Some problems are retrieval problems, some need tools, some need a different model. Recognising the ceiling saves the week people spend rewording their way towards a wall.
Tools worth your time
| Tool | What it is for |
|---|---|
| Anthropic Console | Workbench for testing prompts against Claude models side by side, with variables. |
| OpenAI Playground | Same idea for GPT models: parameters exposed, output compared directly. |
| Google AI Studio | Free surface for testing Gemini models, generous on long-context experiments. |
| promptfoo | Open-source evaluation: run a prompt across cases and models, see what regressed. |
| LangSmith | Tracing and evaluation for prompts running inside an application. |
| A plain spreadsheet | Twenty inputs, expected outputs, one column per prompt version. Unglamorous and sufficient. |
Prompt libraries and template packs are worth about one afternoon of reading and nothing after that. The patterns are public and few. What is not transferable is knowing which one applies to your problem, and that only comes from running your own cases.
Mistakes that cost people weeks
Treating prompts as incantations
Adding you are a world-class expert to the top of everything. Role framing occasionally helps, but it is a rounding error next to giving the model an actual example of the output you want.
Changing three things at once
The answer improved, and you have no idea which edit did it. One change, one run against your cases. This is the single habit that turns prompting from folklore into work.
Judging a prompt by one good answer
Models are variable by design. A prompt that produced something brilliant once and mediocre four times is a worse prompt than one that is consistently good, and you cannot tell them apart without running both several times.