Prompt Engineering Introduction

What prompt engineering is#

Prompt engineering is the practice of deliberately designing the input you give a language model to reliably get the output quality and format you actually want. The same underlying model can produce a vague, generic, borderline-useless answer or a precise, well-structured, directly usable one, depending entirely on how the request is phrased — what context is given, how the task is framed, and what constraints are specified. Prompt engineering is the discipline of closing that gap deliberately, rather than by trial and error every time.

This matters in practice because, unlike a traditional API with a fixed, documented contract, an LLM's "interface" is natural language, and natural language is ambiguous by default. "Summarize this document" can produce a two-sentence summary or a three-page one; "write me a function" can produce code with or without error handling, tests, or comments. A well-engineered prompt narrows that ambiguity down to what you actually need, without requiring any change to the model itself.

The anatomy of a good prompt#

Most effective prompts, especially for non-trivial tasks, include four distinct elements — not necessarily in this order, but all worth considering deliberately rather than leaving implicit:

• Context — the background information the model needs but doesn't already have: relevant facts, prior conversation, a document to work from, or who the audience is. Without it, the model has to guess, and it will often guess wrong.
• Task — a clear, specific statement of what you actually want done. "Help me with this email" is vague; "Rewrite this email to be more concise and professional, keeping the same core request" is a task.
• Format — how you want the output structured: a bulleted list, a JSON object matching a specific schema, a maximum length, a particular tone. Models will happily default to their own idea of "reasonable" formatting unless you specify otherwise.
• Constraints — explicit boundaries: what to avoid, what assumptions not to make, a required length limit, a required reading level, information the answer must or must not include.

Vague prompt:

Write about our return policy.

Prompt with context, task, format, and constraints:

Context: You are writing for an e-commerce FAQ page. Our return policy allows
returns within 30 days of purchase, with a valid receipt, for a full refund.
Opened electronics can only be exchanged, not refunded.

Task: Write a customer-facing explanation of this return policy.

Format: 3-4 short bullet points, plain language, no legal jargon.

Constraints: Do not imply returns are accepted after 30 days under any
circumstances. Keep the total under 80 words.

The second version leaves far less room for the model to guess wrong about tone, length, or content — and it's the difference between a prompt you write once and reuse reliably, and one you have to re-roll every time.

Common mistakes#

• Treating a vague, one-line prompt as a fair test of a model's capability — most quality problems people attribute to "the model isn't good enough" are actually missing context, task, format, or constraints that the model had no way to infer.
• Over-specifying to the point of contradiction (for example, asking for both "a brief summary" and "cover every detail") — contradictory constraints force the model to silently pick one, and you won't know which it picked without checking.
• Assuming a prompt that works well for one task will generalize unchanged to a different task — prompt structure should match the specific task's needs, not be copy-pasted as a one-size-fits-all template.