Prompt engineering is the practice of writing, testing and refining the instructions you give an AI model so that it produces the output you need, reliably. It covers what you put in a prompt (the task, the context, examples, the input) and how you arrange it (order, format, separators). The term sounds technical, but most of it is careful writing plus checking the results.
This page is the index of Coddy's prompt engineering guide. It explains why the practice works, maps the core techniques to the pages that teach them, and shows the difference between a casual prompt and an engineered one.
Why prompt engineering works
A language model generates text by predicting what comes next, one small piece at a time, based on everything in front of it. It has no access to your intentions, your project or your previous chats unless that text is in its input. So the prompt is not a request to a mind that already understands you; it is the entire situation the model is responding to.
That has a direct consequence. Every question the prompt leaves open, the model tends to settle with the most typical choice: the most common language, the most common length, the most common audience. Sometimes the typical choice is what you wanted. When it is not, the fix is to close the question in the prompt. A good prompt narrows the range of plausible replies until most of what remains is useful.
Two more facts shape the craft. Replies are sampled, so the same prompt can produce different answers on different runs; a prompt is only good if it works most of the time, not once. And the model treats all text in the prompt as potentially meaningful, so a pasted email or a stray sentence can be read as an instruction unless you mark it clearly as material.
A casual prompt versus an engineered one
Both tabs ask for the same thing: sort customer reviews into positive and negative. Compare what each one gets back.
Here's a breakdown:
- Mixed. The user likes the speed but is frustrated about being logged out.
- Positive. The app meets their needs for tracking runs.
- Negative. The user is unhappy that support didn't respond.
Overall, the feedback is mixed, with one positive, one negative and one mixed review.
The casual reply is a sensible answer for a person to read, but a program cannot use it: the labels are mixed in with explanations, a third category appeared that the question did not offer, and a summary was added at the end. The engineered prompt defines every label, fixes the output shape with an example, and wraps the reviews in tags so they are less likely to be confused with instructions. Run on a thousand reviews, it gives output a program can parse far more consistently, and when you need a guarantee, the API's structured output features and a validation step in your code close the rest of the gap.
The core techniques
Each technique below closes a different kind of gap between what you meant and what the model received. Most real prompts combine several.
| Technique | What it does | Reach for it when |
|---|---|---|
| Zero-shot prompting | Gives an instruction with no examples | The task is common and clearly described |
| Few-shot prompting | Shows a few input and output examples | The format or judgment is easier to show than to describe |
| Chain-of-thought prompting | Asks for the reasoning before the answer | The problem has several steps, like math or logic |
| Role prompting | Sets whose voice and standards to use | Audience and level matter |
| Structured output | Fixes the answer to JSON, a table or a template | A program or a spreadsheet reads the result |
| Delimiters and XML tags | Separates instructions from pasted material | The prompt contains documents, code or user text |
| Prompt templates | Turns a good prompt into one with blanks | You repeat the same kind of request |
| Prompt chaining | Splits a job into steps that feed each other | One prompt tries to do too much |
| Self-consistency | Samples several answers and takes the majority | A single reasoning path is unreliable |
| Tree of thought | Explores and scores several lines of reasoning | The problem needs planning or search |
| ReAct | Alternates reasoning with tool calls | The model must look things up or take actions |
| Meta prompting | Has the model write or improve a prompt | You are stuck on how to phrase a prompt |
| Context engineering | Designs everything the model sees, not only the instruction | You are building an app or agent around a model |
If you are new, start with the parts of a single prompt in how to write a prompt, then few-shot prompting and structured output. Those three cover most everyday problems.
A prompt built for a program
Prompts written into software get run thousands of times on inputs nobody has seen yet, so they spell out more than a chat message would. The one below writes commit messages from a code diff. Switch parts off to see what each one protects against: without the examples the style drifts, and without the constraints the model may use types your team does not, such as perf or style.
function validatePassword(password) {
- if (password.length > 8) {
+ if (password.length >= 8) {
return null;
}
return 'Password must be at least 8 characters';
}fix(auth): accept passwords of exactly 8 characters
- The check used > 8, so an 8-character password was rejected
- The rule now matches the error message, which says "at least 8"
How to learn prompt engineering
You learn it by running prompts and looking hard at what comes back. A practical route:
- Learn the parts of a prompt. Task, context, input, format and constraints. Most failures trace back to one of them missing.
- Pick a real task you repeat, such as summarizing tickets, explaining errors or drafting emails, and write a prompt for it.
- Collect five to ten test inputs, including awkward ones: an empty input, a very long one, one in another language.
- Change one thing at a time and rerun all the inputs. If you change three things and the output improves, you will not know which change helped. Iterating on prompts covers this loop in detail.
- Add techniques when a specific failure calls for them. Examples when the format drifts, step-by-step reasoning when multi-step answers are wrong, delimiters when pasted text leaks into the instructions.
The major model providers also publish prompting guides for their own models, and they are worth reading, since each one describes what that model family responds to best.
Is prompt engineering a job?
Some companies have hired for the title "prompt engineer", especially when chat models first became widely available. More often the skill is part of another job. Developers write prompts for the AI features they build, support teams write them for assistants that answer customers, and analysts and writers use them daily.
In teams that build AI products, the work has broadened. Choosing what goes into the model's input (retrieved documents, tool results, conversation history, memory) matters as much as the wording of the instruction, and that wider job is often called context engineering. Measuring whether a prompt works across many inputs, usually called evaluation, is the other half.
What changes with newer models
Early prompt engineering relied on tricks: magic phrases, elaborate personas, repeating an instruction several times. Current models follow plain instructions much better, and reasoning models already work through a problem internally before answering, so asking them to think step by step adds less than it used to.
What has not changed is the part that was never a trick. The model still cannot know your audience, your data, your constraints or what a good result looks like unless you say so. Clear specification is the durable skill, and it is the one this guide spends most of its pages on.
Frequently Asked Questions
What is prompt engineering in simple words?
Prompt engineering is writing the instructions for an AI model carefully enough that it gives you the answer you need, then testing and adjusting them until it does so reliably. It covers what you tell the model (the task, context and examples) and how you arrange it (order, format and separators).
Can I learn prompt engineering without coding?
Yes. The core skills, stating a task clearly, supplying context, giving examples and specifying the output format, all work in a chat app. Coding becomes useful when you want to run a prompt many times, test it against a set of inputs, or feed the output into a program.
How long does it take to learn prompt engineering?
The basics take an afternoon: the parts of a good prompt and a handful of techniques such as few-shot examples and structured output. Getting reliable results on a real task takes longer, because it comes from testing your prompt on many inputs and fixing the cases where it fails.
Is prompt engineering a real job?
Some companies have hired for titles like "prompt engineer", but more often the skill is part of another role: developers building AI features, writers, analysts and support teams. In teams that build AI products, it overlaps with evaluation work and with designing everything the model sees, which is now often called context engineering.
Is prompt engineering still useful with newer AI models?
Newer models need fewer tricks. They follow plain instructions better, and reasoning models work through problems without being told to think step by step. What stays useful is the part that was never a trick: stating the task, giving the model the facts it cannot know, and defining what a good answer looks like.
