Prompt Engineering

Prompt engineering is the practice of designing the text you send an LLM so it reliably produces the output you want. Because models are instruction-followers that generate the likely continuation of your prompt, how you ask determines what you get — a vague prompt yields vague, inconsistent results; a clear, well-structured one is often the difference between a demo and a dependable feature.

It's less "magic words" than careful communication: state the task and constraints explicitly, show examples of what good looks like, give the model room to reason on hard problems, and specify the output format. Then iterate against real cases.

TL;DR

Quick Example

A specific, structured prompt beats a vague one:

Core Techniques

Clear, specific instructions

Tell the model the task, the audience, the constraints, and what to avoid. Replace "write about X" with "write a 200-word intro for beginners, no jargon, end with one actionable tip."

System prompts & roles

Most APIs separate a system prompt (persistent role, rules, persona) from the user turn. Put durable instructions there: "You are a careful financial assistant. Cite sources. If unsure, say so."

Delimiters & structure

Wrap inputs in clear delimiters (XML-style tags, fences, headings) so the model knows where data ends and instructions begin — and so you avoid prompt-injection ambiguity:

Few-shot examples

Show 1–5 examples of input → desired output. This is the most reliable way to pin down a format or a subtle behavior the instructions alone don't capture.

Let the model reason

For multi-step problems, ask it to work through the reasoning (or use a model's built-in reasoning/"thinking" mode). Frontier models like Claude can be told to think before answering, which improves accuracy on hard tasks.

Best Practices

Common Mistakes

Vague instructions

Over-aggressive instructions on modern models

FAQ

Is prompt engineering still necessary as models get better?

Yes — better models reduce the amount of prompting needed but raise the value of clear specification. Capable models follow instructions more literally, so precise, well-structured prompts matter more, not less: ambiguity now produces confidently wrong results rather than obvious nonsense. The skills shift from coaxing tricks toward clear communication, output specification, and evaluation.

What's the difference between a system prompt and a user prompt?

The system prompt sets persistent context — the model's role, rules, tone, and constraints that apply across the whole conversation. The user prompt is the specific request for this turn. Put durable behavior ("you are a concise technical writer; cite sources") in the system prompt and the actual task/data in the user turn. Separating them also keeps a stable, cacheable prefix and isolates untrusted input.

When should I use few-shot examples?

When instructions alone don't reliably produce the format or behavior you want — structured extraction, a specific tone, edge-case handling, or classification with subtle categories. A few input→output examples pin down expectations far better than prose. For simple, well-specified tasks, zero-shot (instructions only) is often enough and cheaper. Add examples when you see inconsistency.

How do I stop the model from ignoring my instructions or being hijacked by the input?

Use clear structure and delimiters: keep instructions in the system prompt, wrap untrusted data in explicit tags, and tell the model to treat that content as data, not commands. This mitigates prompt injection (where input text tries to override your instructions). Combine with output validation and, for high-stakes actions, human confirmation. No prompt is fully injection-proof, so don't rely on prompting alone for security. See AI APIs & Tool Use.

Related Topics

References