Prompting Without Magic — Six Principles That Survive Model Changes

Applied AI Practice

Prompting without magic. Specifications that travel.

A durable prompt does not depend on a secret phrase. It names the outcome, supplies the missing context, defines the boundaries, and makes success observable. Those habits still matter when the model, interface, or provider changes.

↓ Build the specification ↘ Test the result

Ali Reza Rashidi 8 min read Updated Aug 30, 2026

Treat the model like a capable collaborator entering a task with none of your private assumptions.

In this piece

Prompting as specification
Context and output contracts
Examples and boundaries
Reason, test, refine
Sources

01— Specification

Replace wishes with decisions.#

When a prompt fails, the model is often blamed for a decision the prompt never made. “Handle this ticket” leaves the audience, action, tone, evidence, and stopping point undefined. A useful prompt closes the choices that matter and leaves the rest open.

Imagine a support ticket: a customer says invoice INV-2047 contains the same €89 charge twice. “Answer the customer” sounds clear because you know the business. The model does not know whether it should apologize, authorize a refund, request evidence, or escalate the case.

Start with the observable result: draft a reply that acknowledges the customer’s duplicate-charge concern, explains the next verification step, does not confirm duplication, fraud, or refund status before review, and ends with one action for the customer. Official provider guides consistently put clear instructions and relevant details ahead of elaborate tricks.[1][2][3]

Topic-shaped request

“Reply to this billing complaint.” The model must invent the purpose, policy boundary, level of detail, and next step.

Decision-shaped request

“Draft a 120-word reply that acknowledges the customer’s concern, requests the receipt, and does not confirm duplication, fraud, or a refund before review.”

Useful objective = action + audience + acceptance criteria

Specific does not mean long.It means the important choices are visible.

02— Context

Give the model what the task assumes.#

Instructions say what to do. Context explains the world in which the instruction must work. An output contract then turns the desired response into a shape that a person—or another system—can inspect.

For INV-2047, useful context is concrete: the payment processor shows two settled charges; the company verifies receipts before refunding; support may apologize but may not confirm fraud; the customer is in the EU and prefers English. Each fact changes the correct reply.

Explain the reason behind an unusual constraint when that reason helps generalization. “Do not promise a refund because the payment record is still under review” gives the model a principle it can apply when wording the whole response. Still, provide only task-relevant context. Extra documents create more places for conflicts, stale facts, and malicious instructions to hide.

Context is not autobiography.Every included fact should change a decision in the output.

An output contract prevents a response from being “correct” yet unusable. For a human reply, you might require a subject line and two short paragraphs. For software, you might require a schema with summary, risk, and next_action. Structured Outputs can enforce a JSON schema when the API and model support it; plain prompting alone cannot guarantee machine-valid data.[4]

The five decisions inside a useful prompt

How to read this: the prompt becomes more reliable as it moves from a broad intention to a response contract. The format card is highlighted because that is where an otherwise good answer becomes inspectable.

03— Patterns

Show the pattern. Mark the boundary.#

Examples teach the mapping you want. Delimiters tell the model which text plays which role. Both reduce ambiguity, but neither should be treated as a security control.

Few-shot examples can steer classification labels, response shape, and style by showing completed input-output pairs.[5] One representative example may be enough for a simple pattern; a difficult boundary may need several diverse examples. There is no universal best count. Add examples because a measured failure calls for them, not because a checklist demands a fixed number.

For INV-2047, a useful example would show a different duplicate-charge case in which the reply acknowledges the problem, names the verification step, and avoids an unsupported promise. Keep the example close to the real task but not so narrow that the model merely copies names or amounts.

Memorization-shaped example

Same customer, amount, phrasing, and resolution. The model may imitate surface details instead of learning the decision pattern.

Pattern-shaped example

Different case details, same policy boundary and response structure. The reusable relationship becomes visible.

Markdown headings, XML tags, or other consistent separators make a multi-part prompt easier to parse. Anthropic explicitly recommends XML tags for separating prompt components, while Google and OpenAI show structured sections and clear boundaries in their guidance.[2][1][3]

A bounded prompt for INV-2047

<objective>
Draft a calm customer-support reply.
</objective>

<policy>
Do not promise a refund before payment review.
</policy>

<ticket>
Invoice: INV-2047
Customer report: two €89 charges
Processor status: both charges settled
</ticket>

<output>
Subject line, then two paragraphs, maximum 120 words.
</output>

Delimiters improve communication; they do not make untrusted content safe. A document inside <ticket> can still contain an instruction designed to redirect the model. Keep trusted instructions outside untrusted data, restrict available tools, validate outputs, and enforce authorization in code. Prompt formatting is one layer—not the boundary itself.[7]

04— Evaluation

Reason through the task. Test the system.#

A prompt is a hypothesis about behavior. You do not validate it with one attractive answer. You validate it against representative cases, failure modes, and an acceptance rule that existed before you saw the output.

Build a small evaluation set before polishing wording: an obvious duplicate charge, a pending charge that should not be called a duplicate, a missing receipt, an angry customer, and a ticket containing irrelevant or hostile instructions. Score the behaviors you actually need: policy compliance, factual grounding, action clarity, and format validity.

Provider guidance treats prompt development as iterative, and OpenAI recommends pinning model snapshots and building evaluations as applications move toward production.[9] Model behavior is nondeterministic and can change across versions, so preserve the cases, rubric, prompt version, model snapshot, and results together.[1]

The evidence loop for INV-2047

How to read this: work moves clockwise, but every stage writes back to the shared evidence record. A revision earns its place only when the same evaluation set shows an improvement without creating a new failure.

For complex work, asking for intermediate artifacts can improve reliability: extract the relevant policy, list missing facts, propose a decision, then draft the reply. That is task decomposition. It is different from demanding a hidden reasoning transcript. Reasoning models are designed to reason internally, and OpenAI’s guidance recommends simple, direct prompts rather than “think step by step” instructions for those models.[8]

Role labels Useful for voice or perspective; not a substitute for facts, criteria, or tools.[10]

Long prompts Sometimes necessary, never automatically better. Remove text that changes no decision.

Negative rules Can express boundaries, but pair them with the behavior you want instead.

Magic phrases A benchmark result on one model is not a universal law. Test the actual task.

The production unit is not the prompt alone.It is the prompt, model snapshot, tools, context, evaluation set, and acceptance rule.

05— Sources

Read the primary guidance.#

Prompt advice ages quickly when it is detached from a model, task, and evaluation. These sources provide the provider guidance and research foundations used in this article.

Prompt engineering. OpenAI API documentation. Read the guide
Prompting best practices. Anthropic documentation. Read the guide
Prompt design strategies. Google AI for Developers. Read the guide
Structured Outputs. OpenAI API documentation. Read the guide
Language Models are Few-Shot Learners. Brown et al., NeurIPS 2020. Read the paper
Understanding prompt injections. OpenAI. Read the security guidance
Reasoning best practices. OpenAI API documentation. Read the guide
Evaluation best practices. OpenAI API documentation. Read the guide
When “A Helpful Assistant” Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models. Zheng et al., 2023. Read the paper

Ali Reza Rashidi

Ali Reza Rashidi, a Senior Data Scientist-Gen Al | Al Architect | MLOps with over ten years of experience, He is the author of three books that delve into the world of data and management.

Prompting

Five DeepEval Metrics That Turn RAG Scores into Engineering Decisions

Prompting without magic. Specifications that travel.