You’ve probably heard someone say “it’s all about the prompt.” They’re mostly right. Prompt engineering is the practice of crafting inputs to AI models so they produce the output you actually want — not a vague summary, not a hallucinated answer, not a wall of irrelevant text.
It’s not magic. It’s a skill, and it’s one of the highest-leverage things a developer can learn right now.
Why prompt engineering matters more than model choice
Here’s a counterintuitive truth: a well-prompted mid-tier model will outperform a poorly-prompted frontier model on most practical tasks. Switching from GPT-4o to Claude 3.5 Sonnet won’t fix a bad prompt. Rewriting your prompt almost always will.
If you’re spending time debating which model to use, you might get more value from spending that time on your prompts instead. (That said, model differences do matter — see our AI model comparison for when they come into play.)
Prompt engineering is also the foundation of a broader discipline called context engineering, which deals with everything the model sees — not just your prompt, but retrieved documents, tool outputs, and conversation history. Understanding prompts is step one.
The core techniques
1. Zero-shot prompting
You give the model a task with no examples. This works well for straightforward requests where the model’s training data covers the domain.
Classify the following customer message as "billing", "technical", or "general":
"I can't log in to my account after resetting my password."The model returns technical. No examples needed.
Zero-shot works when the task is unambiguous. When it doesn’t, you move to few-shot.
2. Few-shot prompting
You provide examples of the input-output pattern you want. This is one of the most reliable techniques for getting consistent, formatted results.
Classify these customer messages:
Message: "When is my next invoice?"
Category: billing
Message: "The app crashes when I open settings."
Category: technical
Message: "Do you have a referral program?"
Category: general
Message: "My payment was charged twice."
Category:The model returns billing. The examples taught it your classification scheme, your format, and your tone — all without explicit instructions.
Few-shot is especially powerful for tasks with domain-specific labels, edge cases, or non-obvious formatting requirements.
3. Chain-of-thought (CoT) prompting
You ask the model to reason step by step before giving a final answer. This dramatically improves accuracy on math, logic, and multi-step problems.
A store sells notebooks for $4 each. If you buy 5 or more, you get a 20% discount.
How much do 7 notebooks cost?
Think step by step before answering.The model responds:
- Base price: 7 × $4 = $28
- Since 7 ≥ 5, the 20% discount applies
- Discount: $28 × 0.20 = $5.60
- Final price: $28 − $5.60 = $22.40
Without “think step by step,” models frequently skip the discount or miscalculate. CoT forces the model to show its work, and showing work improves the work.
4. System prompts
System prompts set the model’s behavior, personality, and constraints before the user ever says anything. They’re the foundation of any production AI application.
System: You are a senior code reviewer. Review code for bugs, security
issues, and readability. Be direct. Use bullet points. If the code is
fine, say so in one sentence — don't invent problems.
User: Review this Python function:
def get_user(id):
query = f"SELECT * FROM users WHERE id = {id}"
return db.execute(query)The model flags the SQL injection vulnerability, suggests parameterized queries, and keeps it concise — because the system prompt told it to.
System prompts are where you define guardrails, output format, and persona. Tools like Claude’s system prompt editor and OpenAI Playground make it easy to iterate on these.
5. Role prompting
You assign the model a specific role or expertise. This narrows the response style and knowledge domain.
You are an experienced database administrator with 15 years of
PostgreSQL experience. A junior developer asks you:
"Should I add an index to a column that's used in WHERE clauses
but only has 3 distinct values?"The model explains selectivity, when low-cardinality indexes hurt performance, and suggests partial indexes — because it’s “thinking” as a DBA, not a generalist.
Role prompting works because it activates relevant patterns in the model’s training data. A “senior security engineer” gives different advice than a “helpful assistant.”
6. Structured output prompting
You tell the model exactly what format to return. This is critical for any pipeline where another system consumes the output.
Extract the following fields from this job posting and return valid JSON:
- title (string)
- company (string)
- salary_min (number or null)
- salary_max (number or null)
- remote (boolean)
Job posting: "Acme Corp is hiring a Senior Backend Engineer.
$150k-$190k. Fully remote. Apply now."The model returns:
{
"title": "Senior Backend Engineer",
"company": "Acme Corp",
"salary_min": 150000,
"salary_max": 190000,
"remote": true
}For production use, combine this with JSON mode (available in most APIs) to guarantee valid JSON output. Always specify types and handle nulls explicitly.
Combining techniques
The real power comes from stacking these together. Here’s a production-grade prompt that uses role prompting, system instructions, few-shot examples, and structured output:
System: You are a content moderation classifier. Classify user messages
into exactly one category. Return only valid JSON.
Categories: safe, spam, harassment, off_topic
Examples:
Input: "Great article, thanks for sharing!"
Output: {"category": "safe", "confidence": 0.95}
Input: "BUY CHEAP WATCHES click here now!!!"
Output: {"category": "spam", "confidence": 0.98}
Input: "You're an idiot and nobody likes you"
Output: {"category": "harassment", "confidence": 0.92}
Now classify:
Input: "Can someone help me with my React build error?"This prompt is unambiguous, well-structured, and easy to test. That’s the goal.
Common mistakes
Being too vague. “Write something about databases” gives you a generic essay. “Write a 200-word explanation of database indexing for a developer who knows SQL but hasn’t used indexes” gives you something useful.
Overloading a single prompt. If you need the model to analyze data, generate a summary, AND create action items, split it into separate calls. Multi-task prompts produce mediocre results on each task.
Not specifying format. If you need bullet points, say so. If you need JSON, say so and show the schema. Models default to prose paragraphs unless told otherwise.
Ignoring the system prompt. Putting everything in the user message works for quick tests, but production apps should separate instructions (system) from data (user). This improves consistency and makes prompt injection harder.
Prompt stuffing. Adding “be very very careful and think really hard” doesn’t help. Specific instructions do. Instead of “be careful with dates,” say “dates must be in ISO 8601 format (YYYY-MM-DD).”
Tools for prompt engineering
Claude’s system prompt editor — lets you set and iterate on system prompts directly in the console. Pair it with Claude Code for testing prompts against real codebases.
OpenAI Playground — provides a side-by-side view of system, user, and assistant messages. Great for testing few-shot patterns and comparing model behavior across temperature settings.
LangSmith / Braintrust / Promptfoo — prompt evaluation platforms that let you run test suites against your prompts. Essential once you move past prototyping.
For most developers, the console or playground is enough to start. The evaluation tools matter when you’re shipping prompts to production.
When prompt engineering isn’t enough
Prompt engineering has limits. If you hit them, you have two main options:
Retrieval-Augmented Generation (RAG) — when the model needs access to your specific data (docs, codebases, knowledge bases) that isn’t in its training set. Instead of cramming everything into the prompt, you retrieve relevant chunks and inject them as context. Our guide on building a local RAG pipeline with Ollama walks through this step by step.
Fine-tuning — when you need the model to consistently behave in a way that’s hard to express through prompts alone. Custom tone, domain-specific jargon, or specialized classification tasks are good candidates. See our beginner’s guide to fine-tuning local LLMs for a practical starting point.
The decision tree is simple: try prompt engineering first. If you need external knowledge, add RAG. If you need behavioral changes that prompts can’t capture, fine-tune.
For a deeper look at how prompt engineering fits into the bigger picture — including how it differs from the emerging practice of context engineering — read our comparison: Prompt Engineering vs. Context Engineering.
Start here
Pick a task you do regularly — code review, writing docs, data extraction, classification — and write a prompt for it. Test it. Refine it. Add examples. Constrain the output format.
That loop — write, test, refine — is prompt engineering. The techniques above give you a framework, but the skill comes from repetition. The good news: every iteration takes seconds, not hours.
FAQ
Is prompt engineering still relevant now that models are smarter?
Yes — even the most capable models produce significantly better output with well-structured prompts. Smarter models are better at following complex instructions, which actually increases the value of good prompting. The techniques evolve, but the skill remains essential.
What’s the fastest way to improve my prompts?
Add specificity: define the output format, provide 2-3 examples of what you want, and state constraints explicitly. Most bad prompts fail because they’re vague, not because the model is incapable. Going from “write a function” to “write a TypeScript function that returns a Promise<string[]>” is often all it takes.
Should I use prompt engineering or fine-tuning for my project?
Start with prompt engineering — it’s faster, cheaper, and easier to iterate on. Only consider fine-tuning when you need consistent behavioral changes that prompts can’t reliably produce, like matching a specific writing style across thousands of outputs or handling highly specialized domain terminology.
The models are powerful. Your prompts decide whether that power is useful.