What Is Prompt Engineering: A Getting-Started Guide for Developers
An introduction to prompt design, examples, output constraints, generation settings, and evaluation for LLM applications.
A prompt defines the task, relevant context, and expected output for a language model. Developing it well means testing those instructions against representative inputs, including cases where the model should express uncertainty or return no result.
Why the Same Model Produces Different Results
A language model generates tokens conditioned on its input and previous output. Instructions, examples, model version, and sampling settings can all affect the result.
Compare “summarize this document” with “extract three key points and list them in order of importance.” The second gives a clearer output target, though it still needs evaluation.
The Basic Anatomy of a Prompt
Most production prompts have two parts:
System prompt: Higher-level instructions for behavior and output. The API determines which instruction roles are available and how conversation state is carried between requests.
User message: The specific input for this request — the document to process, the question to answer, the data to extract.
Keeping these two parts cleanly separated makes your prompts easier to maintain, version, and debug. When something goes wrong, you can identify which part of the prompt is responsible.
Core Prompt Engineering Techniques
Be specific about the output format
Specify the fields and types you need. For example: “Return an object with name (string), email (string or null), and action_items (array of strings).”
Where the model API supports schema-constrained output, use it and validate the result in application code. A prompt alone does not guarantee valid structure or correct values.
Use a role to set behavioral framing
Starting the system prompt with a clear role — "You are a senior technical writer who creates concise, accurate documentation" — sets the model's frame of reference for all subsequent instructions. This is not decoration. It affects tone, vocabulary choices, and how the model interprets ambiguous instructions.
Keep roles specific. "You are a helpful assistant" tells the model almost nothing. "You are a data extraction assistant that processes customer support tickets and outputs structured JSON" gives the model a specific behavioral context.
Provide worked examples
Examples communicate patterns that are difficult to describe in prose. Include representative inputs and the outputs you expect.
Choose the number of examples through evaluation. Include meaningful variations, such as missing fields and ambiguous inputs, without crowding out the task data.
Separate instructions from content
When your prompt includes both instructions and the content to process, mark the boundary clearly. A common approach:
Instructions: [your instructions here]
Document to process:
[document content here]
Clear boundaries help the model distinguish instructions from task data. They do not guarantee protection against prompt injection; the application still needs appropriate tool permissions and input handling.
Zero-Shot, Few-Shot, and Chain-of-Thought: What These Mean
Zero-shot prompting: Giving instructions with no examples. Works for clear, simple tasks. Degrades on complex or ambiguous tasks.
Few-shot prompting: Including example input-output pairs before the actual input. Improves consistency significantly on pattern-following tasks without requiring model fine-tuning.
Chain-of-thought prompting: Asking the model to reason through a problem before producing its final answer. Either explicitly ("Reason through this step by step before giving your answer") or by providing examples that show a reasoning step before the conclusion. This improves accuracy on tasks that require multi-step reasoning.
These are composable. A prompt can use few-shot examples that themselves demonstrate chain-of-thought reasoning.
The Role of Temperature
Temperature adjusts the sampling distribution on models that expose it. Lower values generally reduce variation, but do not guarantee identical or correct outputs. Some reasoning models restrict or do not expose this setting.
Test supported settings against your evaluation set. Extraction and classification need factual and schema checks; brainstorming may place more weight on varied, useful suggestions.
Record the model version and supported generation settings with each prompt version so results can be compared.
How to Know If Your Prompt Is Working
Write a small set of test cases with known correct outputs before you are satisfied with a prompt. Include at least one case where the input is clean, one where data is absent, and one where the input is ambiguous or unusual. Run your prompt against all of them.
For a failed case, identify whether the problem comes from instructions, missing context, model capability, or validation. Revise and rerun the full evaluation set to check for regressions.