Home › Claude Ecosystem Guides

Prompt Engineering with Claude: The Levers That Actually Move the Model

Prompt engineering is the practice of shaping the text you send so the model produces the output you want — and for most tasks it is the fastest, cheapest improvement you can make before reaching for anything heavier.

Last reviewed: 2026-09-04 · Українською

Why start here, before fine-tuning

When a model's answers miss, the instinct is often to reach for training data and fine-tuning. That is usually the wrong first move. Rewriting the prompt costs minutes and a handful of tokens; fine-tuning costs a dataset, a pipeline, and a maintenance burden that follows you into every future model change. Exhaust prompt engineering first, and escalate only when a well-built prompt genuinely cannot carry the task.

It pays off with Claude because the model responds strongly to explicit structure and instruction. Most disappointing outputs are not a capability gap — they are an underspecified request. The techniques below are ordered roughly by leverage: how much better the answer gets per minute you invest.

Be clear, direct and specific

The single highest-return habit is to say exactly what you want, for whom, and in what form. Vague requests force the model to guess your intent, and a guess that is 80% right still reads as wrong. Name the task, the audience, the constraints, and the shape of the output. "Summarize this" invites a paragraph; "Give me three bullet points, each under twenty words, aimed at a non-technical manager" leaves almost nothing to interpret.

A useful discipline is to describe the desired output before the input, and to prefer positive instructions over prohibitions — telling the model what to do beats a list of things not to do. If a human colleague could misread the request, so can the model.

Show examples instead of only describing

A couple of worked examples — the multishot approach — often teach the model more than a paragraph of description. Instead of explaining a tone, a labelling scheme, or an edge case, show one or two input→output pairs and let the pattern speak. This is especially powerful for classification, extraction, and any task where the format is finicky but hard to articulate in words.

Choose examples that are representative, not just easy: include the tricky case you actually care about getting right. If your data has an awkward category, put an example of it in the prompt. A common mistake is giving three near-identical examples — they teach the model the narrow shape and nothing about the boundaries.

Structure the prompt with tags and a system role

Claude has a particular strength: it reads XML-style tags well. Wrapping each part of a long prompt in named tags — the source material in one, the instructions in another, examples in a third — lets the model tell them apart instead of blurring a document into the request. This alone removes a whole class of errors on multi-part prompts, and it makes the output easier to parse when you tag the response too.

• Put the reference material inside a tag like a document block, so the model never mistakes it for an instruction.
• Use a system prompt to set a durable role and the rules that hold for every turn — tone, scope, what to refuse, the persona to adopt.
• Keep the moving parts (the user's actual question) clearly separated from the fixed scaffolding.

The system prompt is where enduring behavior belongs; the user turn is where the specific request goes. Mixing the two is a frequent source of drift.

Give the model room to reason, then reuse what works

For anything involving analysis, math, or multi-step judgment, let the model think before it commits to an answer. Asking it to reason step by step — chain-of-thought, or the deeper extended-thinking mode — raises accuracy on hard problems because a first-token answer skips the working. If you need only the final result, have it reason and then present the conclusion clearly separated from the scratch work.

Once a prompt performs well, stop rewriting it from scratch each time. Turn the stable parts into a template with variables — slots you fill per request — so the wording that you tested is reused verbatim and only the input changes. Templates make prompts testable, version-controllable, and consistent across a team, which matters far more than a clever one-off phrasing you cannot reproduce.

A pitfall to avoid: do not rely on prefilling

An older technique put words in the assistant's mouth — starting its reply for it to force a format. On current Claude models this assistant-message prefilling is not supported, and building a prompt around it will fail or behave unpredictably. If you find a tutorial recommending it, treat that as a sign the material is out of date.

The right way to control format is to ask for it plainly, show an example of the exact shape, and set the rule in the system prompt or use a structured-output feature. That combination is more robust than a trick anyway, because it survives model changes. As a general habit, keep prompts free of anything tied to a specific model version or a magic phrase you cannot explain — durable prompts describe the task, not the machinery.

Frequently asked

How do I make Claude return output in an exact format?

State the format explicitly, show one or two examples of the exact shape you want, and pin it with a system prompt or a structured-output feature. Do not rely on prefilling the assistant's reply — that is not supported on current models.

Is prompt engineering better than fine-tuning?

For most tasks, yes — it is faster, cheaper, and survives model upgrades. Fine-tuning makes sense only after a carefully built prompt has clearly hit its ceiling on your specific task.

Why should I use XML-style tags in prompts?

Tags let Claude tell your parts apart — which text is the document, which is the instruction, which is an example. This removes mix-ups on long or multi-part prompts and makes the output easier to parse reliably.

Continue in this track