Prompt Engineering

A prompt is just the text you send a model, but how you structure that text largely determines the quality of what comes back. Prompt engineering is the craft of structuring it well, and it is one of the few AI-engineering skills you can practice with zero setup: everything here works in a chat window, no code required. That is why it comes before the API work. Get a feel for it now, and your first real calls will already be sending good prompts.

This guide covers the parts you will use daily: the elements that make up a prompt, the difference between zero-shot and few-shot, how system prompts set the rules, a short look at chain-of-thought, and a handful of practical tips.

The Elements of a Prompt

Most prompts are built from some combination of four parts. You do not need all four; the right mix depends on the task. But knowing them gives you a checklist for when a response is not what you wanted.

• Instruction: the specific task you want the model to perform
• Context: external information that steers the model toward a better answer
• Input data: the input or question you want a response for
• Output indicator: the type or format of the output you expect

Here is a simple sentiment-classification prompt that uses three of them:

The instruction is "Classify the text into neutral, negative, or positive." The input data is "I think the food was okay." The output indicator is "Sentiment:", which signals the shape of the answer you want. This version skips context, but you could add some, for example a couple of labeled examples, to steer the model further.

When a response disappoints, it is usually because one of these is missing or vague. No clear instruction and the model guesses the task. No output indicator and you get a paragraph when you wanted a one-word label. Adding the missing element is often the whole fix.

Zero-shot and Few-shot

The simplest prompt is zero-shot: an instruction with no examples. Modern models are instruction-tuned, so they handle a lot this way. The sentiment classifier from the last section is zero-shot, and the instruction plus the input is all it needs to return "Neutral".

But on harder or more specific tasks, or when you need a particular output format, zero-shot alone stalls. That is when you reach for few-shot: you put a few worked examples into the prompt, and the model picks up the pattern from them. The examples act as conditioning, so the model is learning the task from the prompt itself, with no retraining. This is called in-context learning.

The model continues the pattern and answers "Positive". One example is 1-shot; for tougher tasks you add more (3-shot, 5-shot, and up). A few things make the examples work better than beginners expect:

• Format matters most. Keep every example in the same shape. The consistent pattern does much of the work, so much that examples with even randomly assigned labels, kept in a consistent format, still beat giving no examples at all.
• Cover the range. Make sure your examples span the labels or outputs you actually want, and roughly reflect how often each one shows up.

Few-shot has a ceiling, though. It teaches the model to imitate a pattern, but it does not make it reason. For a multi-step problem, say "do the odd numbers in this list add up to an even number?", examples alone often produce a confident wrong answer. That is the cue to reach for the next technique.

System Prompting

So far the prompt has carried everything at once: the instruction, the examples, the input. A system prompt pulls the standing rules out of that and sets them once, before the conversation starts. It is where you tell the model who it is, how to behave, and what limits to respect, and it stays in force for every message that follows.

Most LLM APIs split a request into two roles:

• System: the persistent setup, the role, tone, rules, and output format. You write it once.
• User: the actual message or question, which changes every turn.

The same user question can produce very different answers depending on the system prompt. Switch it below and watch the response change:

A good system prompt usually covers three things:

• Role: who the model should act as, for example a senior Python tutor or a support agent for your app.
• Behavior: the tone and the rules, how it should respond and what to avoid.
• Constraints: hard limits like length, output format, or staying on topic.

Why not just put all of this in the user message? Two reasons. It keeps your per-message prompts clean, since you do not repeat the rules every time, and models give the system prompt extra weight, so behavior stays consistent across a long conversation.

Chain-of-Thought

Few-shot, which we met earlier, has a ceiling: it teaches the model to copy a pattern, but not to reason. Here is the fix. Instead of showing the model only the answer, show it the reasoning. Chain-of-thought (CoT) prompting gets the model to work through intermediate steps before it commits to an answer, and that alone unlocks tasks plain few-shot cannot.

There are two ways to use it: put the reasoning into your examples (few-shot CoT), or simply ask the model to reason with no examples at all (zero-shot CoT). Start with the first. In few-shot CoT, your examples spell out the reasoning, not just the final answer. Take a task that trips up plain few-shot, deciding whether the odd numbers in a list add up to an even number. Show the arithmetic in your example, and even one is often enough:

The odd numbers in this group add up to an even number: 4, 8, 9, 15, 12, 2, 1.
A: Adding all the odd numbers (9, 15, 1) gives 25. The answer is False.

The odd numbers in this group add up to an even number: 15, 32, 5, 13, 82, 7, 1.
A:

Adding all the odd numbers (15, 5, 13, 7, 1) gives 41. The answer is False.

The model now copies the habit of reasoning, not just the answer format, and gets it right. The second way, zero-shot CoT, is even simpler: when you have no examples to give, just add one line, "Let's think step by step." Try it below.

Why does this work? The extra reasoning gives the model room to compute the answer one step at a time instead of betting everything on a single guess. Writing the steps out is doing real work, not just narrating it.

Practical Tips

A handful of habits separate prompts that mostly work from prompts you can rely on. None are complicated, they just take a little practice.

• Lead with the instruction. Put the task first, in plain command form: Write, Classify, Summarize, Extract, Translate. When a prompt mixes the instruction with the content, a clear separator (like ###) helps the model tell them apart.
• Be specific. The more clearly you describe the task and the format you want, the better the result. Vague prompts get vague answers, and showing an example of the output you expect is one of the most effective moves there is.
• Be direct, not clever. It is easy to over-engineer a prompt into something fuzzy. Plain and precise beats elaborate, the same way clear writing beats flowery writing.
• Say what to do, not what not to do. Negative instructions often backfire. "Do not ask the user for personal info" tends to make the model do exactly that; "recommend from the trending list, and if nothing fits, say so" works far better.
• Start simple, then iterate. Begin with the smallest prompt that might work, look at the result, and add only what is missing. For a big task, break it into smaller steps instead of writing one giant prompt.

The "be specific" habit is the one that pays off most often. Watch what tightening a single instruction does:

Going Deeper