Prompt Engineering 101: Moving Beyond "Make Me a Website"
The difference between a generic answer and a production-grade solution is often just a few extra sentences. Here is the framework for perfect prompts.
We've all done it. We open ChatGPT or Claude and type something like: "Write a function to validate emails."
And the AI gives us a decent function. But it's in Python, and you wanted JavaScript. It uses a regex that doesn't validate real domains. It doesn't handle the case where input is null. It returns a boolean, but you needed an error message string.
This is the "garbage in, garbage out" principle of AI. Prompt engineering is not about tricking the model or memorising magic words. It is about providing the context you already have in your head but forgot to type. LLMs cannot read your mind — every assumption you leave unstated is a coin flip they will get wrong half the time.
This guide covers the five core techniques that consistently produce better, more predictable results — whether you are writing code, drafting emails, analysing data, or generating documentation.
The Anatomy of a Well-Structured Prompt
Before the techniques, it helps to see a high-quality prompt as a five-slot template:
- Role — Who is answering? (the persona)
- Task — What exactly needs to be done?
- Context — What does the model need to know about your situation?
- Constraints — What must it avoid, use, or stay within?
- Format — How should the output be structured?
Not every prompt needs all five, but the more slots you fill in, the less the model has to guess. Here is what that looks like applied to a real task:
// Weak prompt
"Write a function to parse dates."
// Strong prompt
"Act as a Senior JavaScript developer. Write a TypeScript function that parses
date strings in ISO 8601 format (YYYY-MM-DD) and returns a Date object.
Handle invalid input by throwing a descriptive Error. Do not use any external
libraries. Include JSDoc comments."
The second prompt takes 20 extra seconds to write and saves you 5 minutes editing the result.
1. The Persona (Who)
LLMs are trained on the entire internet — Reddit threads, academic papers, YouTube transcripts, Stack Overflow answers, and comment sections. When you ask a generic question, the model aims for the statistical average of all those sources, which tends to produce competent but unremarkable output.
Assigning a persona narrows the probability distribution toward high-quality, domain-specific responses. You are steering the model toward the subset of its training most relevant to your problem.
| Without Persona | With Persona |
|---|---|
| "Explain how to center a div." | "Act as a Senior CSS Developer. Explain how to center a div using modern Grid and Flexbox, avoiding legacy float hacks." |
| "Review my code." | "Act as a security-focused code reviewer. Review this endpoint for SQL injection, IDOR, and missing input validation." |
| "Write an email to my client." | "Act as a professional consultant. Write a concise email to a non-technical client explaining a two-week delay due to scope creep, without assigning blame." |
2. Context & Constraints (What & How)
Context tells the model about your situation. Constraints tell it what to avoid. Both are necessary — and constraints are often more powerful than positive instructions, because they eliminate the default behaviours that waste your time.
Context examples:
- "This is a React 18 app using Zustand for state management."
- "The codebase uses ESLint with the Airbnb style guide."
- "My audience is non-technical marketing managers."
Constraint examples:
- "Use TypeScript, not vanilla JS."
- "No external libraries — only the Node.js standard library."
- "Keep the response under 200 words."
- "Do not explain what the code does — just write it."
- "Format the output as valid JSON, no prose."
Constraints save the most time on formatting. If you want a JSON response, say so explicitly. If you want bullet points instead of paragraphs, specify it. The model defaults to whichever format is statistically most common for that task type — which is often not what you need.
3. Chain of Thought (The Reasoning)
For complex logic, LLMs often hallucinate because they try to predict the final answer in a single pass. The model sees the question, predicts a plausible-sounding answer, and skips the intermediate reasoning. Asking them to reason step-by-step forces the generation of intermediate "thinking" tokens, which measurably increases accuracy. This was demonstrated in Google's 2022 paper "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models."
The trigger phrase is simple: "Think step by step" or "Work through this carefully before giving your final answer."
// Without Chain of Thought
"Is this SQL query safe from injection?"
// With Chain of Thought
"Is this SQL query safe from SQL injection?
SELECT * FROM users WHERE id = " + userId
Think step by step. First, check whether user input is concatenated directly
into the query string. Then determine if any sanitisation is applied. Finally,
provide a concrete attack payload that would exploit the vulnerability.
Chain of Thought is most valuable for: security analysis, debugging, algorithm design, mathematical reasoning, and any task where a wrong intermediate step invalidates the final answer.
4. Few-Shot Prompting (Show, Don't Tell)
The best way to specify an output format is to demonstrate it. When you provide one or two examples of input paired with expected output, you communicate the pattern far more precisely than any written description. This is called "few-shot prompting."
Task: Convert movie titles to URL slugs.
Example 1:
Input: "Star Wars: A New Hope"
Output: "star-wars-a-new-hope"
Example 2:
Input: "The Matrix Reloaded"
Output: "the-matrix-reloaded"
Now convert:
Input: "Indiana Jones and the Temple of Doom"
Output:
The model will output "indiana-jones-and-the-temple-of-doom" because you showed it
the pattern rather than described it. This works especially well for data transformation,
classification, formatting, and any task where "correct" means matching a specific structure.
5. Negative Prompting (What Not to Do)
Borrowed from image generation, negative prompting tells the model explicitly what to exclude. It is often more reliable than the positive version of the same constraint:
- Instead of: "Be concise." → Try: "Do not include introductory paragraphs or closing summaries. No filler sentences."
- Instead of: "Write modern JavaScript." → Try: "Do
not use
var, callbacks, or jQuery." - Instead of: "Keep it professional." → Try: "Do not use slang, bullet points, or passive voice."
Combine negative and positive constraints in the same prompt for maximum precision.
Common Mistakes That Kill Output Quality
- Vague verbs: "Fix," "improve," and "make better" mean nothing. Be specific: "Reduce cyclomatic complexity," "Add null checks," "Rewrite for readability."
- Missing language: The model defaults to Python for code tasks if you do not specify. Always state the language and version.
- No output format: If you want JSON, say "respond only with valid JSON, no prose." The model will write paragraphs when you needed structured data.
- Asking too many things at once: "Write tests, refactor, and document this function" in one prompt produces mediocre results for all three. Break complex tasks into sequential prompts.
Frequently Asked Questions
Does prompt engineering work on all LLMs?
The core techniques — persona, context, constraints, chain of thought, few-shot — work across all major models (GPT-4, Claude, Gemini, Llama). The degree of impact varies. Smaller models benefit more from explicit structure because they have less capacity to infer intent from vague inputs. Larger models are more forgiving but still produce measurably better output with well-structured prompts. Chain of Thought in particular has been tested across model families with consistent improvements to reasoning accuracy.
How long should a prompt be?
As long as it needs to be — no longer. A well-structured 80-word prompt outperforms a rambling 400-word one. A useful heuristic: if you can remove a sentence without losing information the model needs, remove it. If a sentence eliminates a decision the model would otherwise guess at, keep it.
Should I reuse prompts or write new ones each time?
Build a personal library of prompt templates for tasks you repeat — code reviews, email drafts, data transformations, commit message generation. Treat them like functions: keep the structure stable and parameterise the parts that change. This is exactly what system prompts in the OpenAI and Anthropic APIs are designed for.
Automating the Perfect Prompt
Remembering all five techniques — Persona, Context, Constraints, Chain of Thought, Format — every time you need a quick answer is tedious. The overhead can feel like it outweighs the benefit for simple tasks.
That is why we built the Prompt Optimizer. Paste your rough idea and it automatically expands it into a structured, engineer-grade prompt using these exact principles. No account required, no data sent to a server — it runs entirely in your browser.