What prompt engineering is and why developers care
Prompt engineering means designing text that steers a language model to a desired, repeatable result. For a developer it has two uses: talking to a coding assistant day to day, and writing prompts that run inside a product, for example in an LLM-based chatbot.
The right mindset is to treat the model as a very fast colleague with no context. It does not know what is obvious to you: the framework version, your team conventions, or that the output will be parsed by a function. Spell each one out.
The anatomy of a strong prompt
Most weak prompts are missing one or more of the parts below. You do not always need all four, but when the result is poor, first check which one is missing.
| Part | Purpose | Example |
|---|---|---|
| Role | Sets expertise level and tone | "You are a senior TypeScript reviewer" |
| Context | Information the model lacks | "The project uses React 18 and Vite" |
| Task | One concrete, checkable job | "Find only async-related bugs" |
| Output format | Exact shape of the answer | "A JSON list with line and issue fields" |
Compare. A vague prompt: "improve this function". A precise one:
You are a senior Node.js reviewer.
Context: Node 20, ESM modules, no external dependencies allowed.
Task: Refactor the function below for readability. Do not change its behaviour or its signature.
Output: 1) the refactored code in one code block, 2) a bullet list of at most 3 changes you made.
<code>
{{FUNCTION_SOURCE}}
</code>Separating data from instructions with delimiters such as <code> improves readability and lowers the risk of the model obeying instructions hidden inside the text.
Structured output you can parse in code
When model output flows into your program, free text is trouble. Request the format explicitly, show an example and always validate before use; the model sometimes adds a preamble or drops a key.
const prompt = [
"Classify the support ticket. Reply with JSON only, no prose:",
'{"category": "billing|bug|feature|other", "urgent": true|false}',
"Ticket: " + ticketText
].join("\n");
function parseTicket(text) {
const start = text.indexOf("{"), end = text.lastIndexOf("}");
const data = JSON.parse(text.slice(start, end + 1));
const ok = ["billing", "bug", "feature", "other"].includes(data.category)
&& typeof data.urgent === "boolean";
if (!ok) throw new Error("Invalid model output");
return data;
}Patterns that actually work
Few-shot examples
Two or three input and output pairs convey style and format better than several paragraphs of explanation. Choose varied examples and include one edge case so the model does not copy a single pattern.
Think first, answer second
For multi-step problems (debugging, calculation, design) ask the model to list steps or hypotheses first and then give the result. If you only need the final answer, request two separate sections and hide the reasoning part.
Break big jobs apart
One giant prompt such as "write the whole payments module" usually gives poor results. Build a chain of small steps instead: design, interfaces, implementation, tests. Check each step's output before feeding it to the next.
Feeding errors back
When generated code fails, send the full error message and test output along with the code and ask for a fix to that part only. "It doesn't work" carries no information.
Common mistakes and how to fix them
| Mistake | Symptom | Fix |
|---|---|---|
| Vague request | Generic, padded answer | State a concrete task and a done-criterion |
| Missing context | Wrong API or version | Provide versions, relevant files and constraints |
| Conflicting instructions | Sometimes one, sometimes the other | State a priority or drop one |
| Heavy use of negatives | The very thing you banned appears | Say what to do instead of what not to do |
| No validation | Occasional production failures | Parse and check the output |
A common myth: "a longer prompt is always better". Aimless length muddles the instructions; precision matters, not word count.
Maintain prompts like code
Prompts that run in a product are part of the application logic. Keep them in the repository with an explicit version id and in files separate from code, and check every change against a fixed test set.
// prompts/classify-ticket.v3.js
export const classifyTicket = {
version: "v3",
system: "Classify support tickets. Reply with JSON only.",
examples: [
{ in: "I was charged twice", out: '{"category":"billing","urgent":true}' },
{ in: "Dark mode please", out: '{"category":"feature","urgent":false}' }
]
};To build the test set and measure results, the evaluation method in the chatbot guide applies directly. If your prompts run inside business workflows, also see automation with AI.
A checklist before you hit send
- The task is one clear, checkable sentence.
- Needed context (version, files, constraints) is included.
- The output format and, when useful, an example are specified.
- Data and instructions are separated with delimiters.
- Machine-read output has validation and an error path.
- It was tried on several real inputs, not just one.
To bring these habits into a whole team's process, AI in software development suggests practical policies. Providers' official docs are the best source for per-model details; for working with JSON in code, see the JavaScript docs on MDN.
Frequently asked questions
What makes a good prompt for coding?
It has a specific task, technical context (language, version, relevant files), constraints and a clear output format, plus an input and output example when helpful. The goal is to leave nothing for the model to guess.
What is few-shot prompting and when should I use it?
It means placing a few input and output examples in the prompt. When you want a specific format or style, such as classification or data extraction, it is usually more effective than long written explanations.
How do I make sure the model returns valid JSON?
Request the format explicitly, use the provider's structured-output mode where available, and always parse and validate the result. On failure, retry once with the error message included.
Does one prompt work the same on every model?
No. Models differ in instruction following, response length and format sensitivity. When you switch models, rerun your prompts against the fixed test set and adjust if needed.
Comments
No comments yet. Be the first to share your thoughts.