Prompt Engineering: Definition, Techniques and Why Context Matters More

You are probably looking for the right formula. It is the question I hear most often when I train teams, and it is almost never where the problem lies. Prompt engineering was a real discipline when models were fragile. A few solid techniques remain from that time, along with one idea that outweighs them all: a model cannot guess what it cannot see.

I start with the definition and the techniques that still hold up, then explain why context engineering is taking over, with a tool to measure what fits in a context window. I finish with the prompt engineer job: what it involves, what it pays, and whether it still exists.

Prompt engineering: definition

Prompt engineering refers to the methods used to write and organize the instructions given to a language model in order to get the best possible result. The prompt is the instruction; the engineering is the methodical process of designing and testing it.

In practice, doing prompt engineering means choosing the words of a request, its structure, the examples that go with it and the expected format, then adjusting until you get a usable answer. For an individual user, this happens in ChatGPT or Claude. For a company that builds AI into software, it becomes engineering work: system instructions, test sets, successive versions.

What is a prompt in AI?

A prompt is the message you send to an AI to get an answer: a question, an instruction, sometimes with a document attached. It is your only way to tell the model what you expect. For concrete templates sorted by use case, I gathered 40 examples in my article on ChatGPT prompts.

Where does prompt engineering come from?

Between 2022 and 2024, wording really mattered. Models were fragile: changing "write" to "act as an experienced copywriter and write" noticeably changed the output. Libraries of formulas circulated, and a job appeared. In early 2023, an Anthropic job posting for a prompt engineer role made the rounds in the press, with an advertised salary of $175,000 to $335,000 a year.

Since then, models have largely absorbed that fragility. They easily rephrase a clumsy request and reason on their own before answering. What they lack has not changed: they know nothing about your company, your customers or your real constraints.

The prompt engineering techniques that still work

Some techniques have survived every generation of models. They are the ones Anthropic's documentation still recommends for its current models, and the ones I apply every day. They have one thing in common: they all consist of giving the model more information.

1. Be clear and explicit

Picture a brilliant colleague who started this morning and knows neither your habits nor your files. That is the image Anthropic uses to describe a model, with a golden rule: have a colleague who knows nothing about the task read your prompt. If they hesitate, the model will too.

• Vague: "Summarize this report."
• Explicit: "Summarize this report in 10 lines for the executive committee, who have no time to read it. Start with the decision to be made, then the three numbers that support it."

2. Explain the why behind an instruction

A bare instruction is applied to the letter. An explained instruction is understood, then generalized to cases you had not anticipated. Anthropic's documentation recommends it explicitly: saying why a behavior matters helps the model aim right.

• Bare: "Never use jargon."
• Explained: "This text is for tradespeople who are new to SEO: avoid jargon, and if a technical term is essential, explain it in one sentence."

3. Show examples

Examples remain one of the most reliable ways to set the tone, format and structure of an answer. This is few-shot prompting: Anthropic advises 3 to 5 examples, close to your real case and varied enough that the model does not copy an accidental trait. To get your own style back, nothing beats two or three texts you wrote yourself.

4. Structure the request

When a prompt mixes instructions, documents and examples, separate them clearly. Headings are enough in most tools. Claude's documentation recommends tags such as <context>, <documents> or <instructions>, which help it avoid mistaking an example for an instruction.

5. Put long documents before the question

With long documents, order matters. Anthropic recommends placing documents at the top of the prompt and the question at the end: in its tests, this order improves response quality by up to 30%, especially with several documents. It is the opposite of the natural reflex, which is to ask the question and then paste the text.

6. Give a role, in one line

"You are an employment lawyer" steers the vocabulary and tone, and one sentence is enough. But the role does not replace information: describing your real situation brings far more than a fictional character. Keep it short, and do not build the request around it.

7. Break down complex tasks

A request that chains analysis, writing and formatting gives you three half-results. Three successive requests, each fed by the result of the previous one, work better: this is prompt chaining. The old "think step by step" trick matters less now that recent models have a reasoning phase whose depth they adjust themselves.

What no longer really helps

• Magic formulas ("you are the best expert in the world", threats, promised tips): none of them makes up for missing information.
• Instructions shouted in capital letters: a "NEVER" with no reason gives you a rule applied to the letter, sometimes where it makes no sense. The explained version works better.
• Prefilling the response, an API trick that consisted of writing the start of the answer in the model's place: recent Claude models no longer accept it.
• Two-page prompts with no document: length never replaces substance.

Why context engineering is taking over

Reread the list above: every technique that still works consists of giving the model more information. That observation is what brought a new term to the surface in 2025, and it is the thesis of this article.

Prompt vs context: the difference

The prompt is your request: the sentence or paragraph in which you state what you want to get.

The context is everything the model receives to produce its answer: your request, but also the attached documents, the conversation history, your account's standing instructions, the tools it has access to, and sometimes web search results.

So the prompt is one element of the context, usually the smallest. Spending an hour polishing the wording while forgetting to attach the document is like polishing the handle of a door that stays shut.

Context engineering: the definition

In June 2025, Tobi Lütke, the CEO of Shopify, said he preferred the term context engineering to prompt engineering, because it better describes the real skill: providing the model with all the context it needs for the task to be solvable. Andrej Karpathy, a cofounder of OpenAI, backed the idea right after.

In September 2025, Anthropic formalized the distinction. Prompt engineering is about writing and organizing instructions. Context engineering refers to the strategies for curating and maintaining the best set of information in the model's window while it works. In other words: deciding what goes into the window, in what order, and in what form.

It rests on four decisions.

• What should go in? Strictly useful documents, examples of the expected result, real constraints.
• What should stay out? Anything that does not help answer. It is the hardest decision and the one that pays off most.
• In what order? Long documents first, the question and instructions after.
• In what form? A structured text, with headings or explicit tags, is used better than an undifferentiated block.

The context window and its limits

A model can only process a limited amount of text at once: its context window, measured in tokens, which are fragments of words. Current Claude models range from 200,000 tokens, about 150,000 words according to Anthropic, to one million tokens, about 555,000 words with the tokenization of recent models. These equivalents are orders of magnitude, which vary with the language and the text.

Two mechanisms often surprise people. First, the history counts toward the window. The model has no memory between two exchanges: the app sends it the whole conversation again with every message. A fifty-message conversation therefore makes the model reread fifty messages with each new question, which explains why usage limits are hit surprisingly fast. When the window is full, the earliest exchanges are summarized or dropped, and the model "forgets" what you said at the start.

Second, too much context hurts. Anthropic describes the phenomenon: the fuller the window gets, the less precisely the model retrieves a piece of information it contains. A model you give three hundred pages to answer about one specific paragraph will answer worse than with the three useful pages. The right context is the smallest set of information that lets the task succeed.

How much can you really give a model to read? Estimate what your documents and your history represent, and how much room is left.

Standing context: write once what you always repeat

The real time savings come when you stop rebuilding the context for every request. Every tool offers some form of standing context: instructions attached to your account, projects that group reference documents, or a file read at startup, such as the CLAUDE.md file in Claude Code. If you want to set it up, my tutorial on installing Claude Code starts there.

Context engineering also extends to tools. An MCP server gives the model direct access to your data instead of copy-pasting, and Claude Skills load a complete method, instructions and scripts, only when the task calls for it. In both cases, the idea is the same: the right information, at the right time, without cluttering the window.

Here is what I put in my own standing context:

• Who I am and what I do, in three lines. It prevents generic answers from the very first message.
• My writing constraints: the voice I use, the phrasings I refuse, the usual length.
• Examples of my work, two or three texts that set the tone.
• What must never be done: it is the most useful part, and the one users fill in least.

The gain is measurable: on repetitive requests, I go from about four rounds of back-and-forth to one. Over twenty requests a week, that adds up to several hours saved, without changing anything about how I phrase things.

One trap, though: a standing instruction applies to everything, including where it makes no sense. I have seen users permanently require very short answers, then wonder why they got shallow analyses on complex topics. Put in your standing context what is true for everything you do, and leave the rest in the request.

Prompt engineering example: the same prompt, without and with context

Here is a common request, first as it is often written, then rewritten with context.

Without context

Write a blog post about boiler maintenance.

With context

<context>
I'm an independent heating technician in Nantes. My customers are private homeowners, often elderly, who receive my blog by email.
</context>

<documents>
[Paste here two articles you have already written, for the tone]
[Paste here the questions your customers ask most often on the phone]
</documents>

<instructions>
Write a 600-word article that answers the question: "Do I really need to have my boiler serviced every year?"
Start with the answer, in two sentences. Match the tone of my articles. No jargon: if a technical term is essential, explain it.
If you are missing any information, ask me before writing.
</instructions>

Nothing about the second version's wording is clever. It simply contains what the model could not guess: who is writing, for whom, in what style, based on which real questions. I filmed a demo of the same principle (in French), a request sent with and without context: the video is embedded in my article with 40 ChatGPT prompt examples to copy.

Prompt engineer: a job or a skill?

What does a prompt engineer do?

A prompt engineer designs, tests and improves the instructions an AI application sends to a model: the system instructions of a customer assistant, the prompts of a writing tool, the instructions of an agent. Most of the work is not writing but measuring. Anthropic's documentation makes it a prerequisite: before any tweak, define success criteria and a way to test them.

In practice, a prompt engineer builds sets of real cases, compares versions of a prompt on those cases, documents what works, and increasingly manages the context: which documents to inject, which tools to expose, what to keep in memory.

Does the prompt engineer job still exist?

As a standalone job, it has receded. In April 2025, the Wall Street Journal ran a headline saying the hottest job of 2023 was already obsolete, citing a Microsoft survey of 31,000 employees in 31 countries: among the new roles their companies were considering creating, prompt engineer came second to last.

The skill, on the other hand, has spread. It is now part of the work of developers, data teams, writers and marketing managers who use AI every day. That is what I see when I train teams: they do not need a prompt specialist, they need everyone to know how to provide the right context.

What is a prompt engineer's salary?

The figure that keeps circulating comes from Anthropic's 2023 job posting: $175,000 to $335,000 a year for a role based in San Francisco, according to Fortune magazine. It was an exception, at a cutting-edge AI company and on the US market. In France, where I work, I have not found a reliable salary grid specific to this job: the few postings attach the skill to an existing role (developer, AI engineer, project manager, writer), and pay follows that role.

How to become a prompt engineer

1. Practice on real cases, yours or your team's, rather than on generic exercises.
2. Learn to evaluate: build a set of test cases and compare two versions of a prompt on the same cases. This is what separates a professional from a collector of formulas.
3. Master context and tools: system instructions, documents, MCP servers, skills, and how to build an AI agent. That is where the job is moving.
4. Learn from the source: the official guides from Anthropic, OpenAI and Google are free and kept up to date, and Anthropic publishes an interactive tutorial on GitHub.
5. Aim for an existing role (development, data, content, product) where this skill makes the difference, rather than a job title that is becoming rare.

The most common prompt mistakes

1. Summarizing a document from memory instead of attaching it. The model then works from your rough summary.
2. Piling everything into a single conversation. The context fills up with unrelated topics that interfere with the answer.
3. Starting from scratch every time you are not satisfied. Correcting within the current conversation is almost always better, because the context is already there.
4. Never giving examples of your own work. It is the only reliable way to get your style back rather than an average style.
5. Keeping constraints to yourself. Budget, deadline, what is off-limits: this information changes the answer completely, and it often stays in your head.

One last remark, which doubles as a warning. Providing context means passing information to a third-party service. Before pasting a contract or a customer file, check which type of account you are using and what its terms allow. It is a thirty-second check, and it spares you awkward questions later.

When the same requests come back every week with the same documents, a prompt is no longer the right answer: it is a candidate for automation. That is the kind of project I take on in an AI automation engagement.

Written by

Anthony Courtin

SEO, GEO & AI automation consultant

I help small businesses and independent professionals with their visibility (Google, ChatGPT, Perplexity) and with how they actually use AI at work. I go into companies to train teams and rethink their processes. Everything I write here, I use in my client work.

Follow me on LinkedIn My YouTube channel (in French)