Prompt Engineering Basics for Developers

What Prompt Engineering Is

Prompt engineering is the practice of designing the input you give a large language model (LLM) so it produces the output you actually need. The model does not read your mind — it predicts a response based on the words, structure, and context you provide. Small changes to the prompt can produce dramatically different results.

Think of it less like searching and more like delegating to a fast, capable, but very literal junior teammate. The clearer your brief, the better the work that comes back. You do not need a special syntax or magic words — just clear communication plus a handful of reliable techniques.

The Anatomy of a Good Prompt

Most effective prompts are built from the same components. You will not always need all of them, but knowing the parts helps you diagnose a weak prompt.

• Task / instruction — what you want done, stated as a clear action.
• Context — background the model needs: audience, constraints, source material.
• Examples — one or more samples of the input/output you expect.
• Role / persona — the perspective the model should write from.
• Output format — the shape of the answer (list, table, JSON, length).

Here is a weak prompt versus the same request rebuilt with these parts:

// Weak
Write about caching.

// Strong
You are a senior backend engineer.
Explain HTTP caching to a junior developer who knows
basic web concepts but has never set cache headers.
Cover: what it solves, Cache-Control, ETag, and one
common mistake. Use under 200 words and a short example.

Be Specific & Give Context

Vague prompts produce generic answers. Specificity narrows the model toward what you want. Replace abstract requests with concrete details: audience, length, tone, scope, and what to leave out.

Make the implicit explicit

The model cannot see your project, your codebase, or your intent. State the things that are obvious in your head.

// Vague
Make this function better.

// Specific
Refactor this JavaScript function for readability.
Keep the behavior identical, add early returns to
reduce nesting, and add a one-line comment above
each block. Do not change the function signature.

[paste code here]

Few-Shot Examples

One of the most reliable techniques is to show the model what you want instead of only describing it. Providing a few input/output pairs is called few-shot prompting (zero examples is "zero-shot", one is "one-shot").

Classify each support message as: bug, billing, or question.

Message: "I was charged twice this month."
Label: billing

Message: "The export button does nothing when I click it."
Label: bug

Message: "Do you have a dark mode?"
Label: question

Message: "My dashboard shows last week's data."
Label:

The examples teach the model the exact labels, format, and style you expect. This is especially powerful for classification, formatting, and matching a particular writing voice.

Assign a Role

Telling the model who it should act as sets the tone, depth, and vocabulary of the response. A role acts as shorthand for a whole bundle of expectations.

You are an accessibility specialist reviewing HTML.
Point out WCAG issues in the markup below, ordered by
severity, and suggest the minimal fix for each.

[paste markup here]

Roles like "senior code reviewer", "patient tutor for a 12-year-old", or "technical editor" shift the response without you spelling out every preference. Pair the role with a clear task for best results.

Constrain the Output Format

If you need the answer in a particular shape, ask for it directly. This is essential when the output feeds into code, a spreadsheet, or another tool.

Return ONLY valid JSON, no prose, in this shape:

{
  "title": string,
  "tags": string[],
  "difficulty": "easy" | "medium" | "hard"
}

Summarize the article below into that structure.

Common format constraints worth knowing:

• "Answer in a markdown table with columns X, Y, Z."
• "Reply in at most 3 bullet points."
• "Output valid JSON only — no explanation."
• "Limit the response to 100 words."

Chain-of-Thought / Step by Step

For reasoning, math, debugging, or multi-step tasks, asking the model to work through the problem step by step often improves accuracy. This is called chain-of-thought prompting.

A train leaves at 2:15 PM and arrives at 4:50 PM.
It stopped for 20 minutes en route.
How long was it actually moving?

Think step by step, then give the final answer
on its own line as: Answer: <value>

Encouraging intermediate reasoning helps the model avoid jumping to a wrong conclusion. When you only want the result, ask it to reason first and then print the final answer on a separate, clearly labeled line — so you can parse or skim it easily.

Iterate & Refine

Your first prompt is a draft, not a final answer. Treat prompting as a short feedback loop: send, read the output, and adjust the part that fell short.

• Output too long? Add a length limit.
• Wrong tone? Add a role or example.
• Missed a requirement? State it explicitly and put it first.
• Inconsistent format? Add a sample of the exact format you want.

You can also refine in conversation: "Good, but make it more concise and add a code example for step 2." Each round teaches you which words move the result in the right direction.

Common Mistakes

A few habits quietly sabotage otherwise good prompts:

• Being too vague — "improve this" without saying what "better" means.
• Burying the instruction — the key ask hidden in the middle of a wall of text.
• Asking for too much at once — five goals in one prompt, none done well.
• No format guidance — then being surprised the output is hard to parse.
• Assuming hidden context — expecting the model to know your stack or files.
• Trusting blindly — not verifying facts, code, or citations the model produces.

A Reusable Prompt Checklist

Before you send an important prompt, run through this quick table. You rarely need every row, but each one is a lever you can pull when results disappoint.