A prompt is the brief that guides the AI’s response
“Summarize this text.” “Write an article.” “Give me some ideas for the blog.” “Improve this introduction.” These are prompts you write every day to an AI assistant, and to you, they’re practical and sufficient. But in reality, they’re incomplete, because they leave out what you didn’t write: who the audience is, how long it should be, what angle to take, and what quality standards to follow.
Every blank or implied field is filled in by the AI, which takes the well-trodden path to do so: the most frequent solutions it encountered during training, the one-size-fits-all approach, the cautious tone, the most common structure. It’s the statistical average of many similar texts—correct, readable, interchangeable.
An effective prompt includes the choices that matter right in the request, before the system fills them in.
What Is a Prompt
A prompt is the input you provide to a generative AI system to obtain a targeted response. It can be a question, an instruction, a text to be reworked, a table to be interpreted, a line of code, an outline to be completed, or a description of an image, a scene, or a visual output to be generated. The form changes, but the role remains the same: it feeds into the system what you want to achieve and the conditions under which the response must be generated.
In computer science terminology, a prompt originally referred to an invitation to type a command into a terminal. In current usage, it guides ChatGPT, Gemini, or any other AI to continue the text in a probabilistic manner, defining the scope of the generation—which includes the objective, context, constraints, format, examples, and criteria. The clearer it is, the more the response has a recognizable direction.
The prompt you write, however, is just one of the levels that guide the response. Higher up is the system prompt—the instructions the platform has already given to the model, out of your sight: basic tone, prohibited topics, and default format. Added to this are the conversation history—where each turn influences the next—the memory the assistant retains of you between sessions, and the attachments or documents it retrieves to respond. Your request interacts with all of this: you make some of the choices, while others have already been made by layers you don’t control—and sometimes don’t even see.
Think of an editorial brief: when it’s well-crafted, it tells the writer what the goal is, who the audience is, what angle to take, what to include, and what to leave out; if it’s slapdash, it forces the recipient to guess, to fill in the gaps with experience, habits, and interpretations.
A prompt follows the same logic, but it’s directed at a model rather than a person, and it applies when you’re asking for text, an analysis, a summary, or a classification. The main difference is that AI is forced to produce a response, even when the prompt leaves out the necessary choices. And while a person can ask for clarification, challenge a criterion, or pause when faced with ambiguity, an AI assistant inevitably relies on the data and patterns it was trained on and takes the easiest path—the one that resembles many others.
Many mediocre responses stem from editorial decisions that were never made
When a response is disappointing, the instinct is to blame the model, but often the problem lies further back—in a decision the person who wrote the prompt had yet to make.
Asking “rewrite this paragraph” assumes you already know why it needs to be rewritten: shorter, clearer, more conversion-oriented, or more consistent with the rest of the article. If that choice is missing from your mind even before it appears in the prompt, the model will invent it and adopt the most neutral option it has. The same happens with “evaluate this text” without any criteria, or with “prepare an outline” without a specific angle, target audience, or depth.
A poor prompt—whether in writing, analysis, or a diagnosis on a page—is often a symptom of an editorial decision that was never made, which the system compensates for by producing a text that is correct, readable, and uncontroversial.
A vague prompt yields a different result every time you issue it
AI constructs the response piece by piece, working on tokens—fragments of text that can be words, parts of words, or characters. At each step, it weighs the possible continuations and favors the most probable sequences, based both on those that recur in the training data and those that depend on the context of your work—your prompt, the conversation history accumulated up to that point, the sources the system may retrieve, and parameters such as temperature (which regulates how closely it sticks to the most probable options). A constrained prompt shifts the weight toward responses consistent with what you asked for; a generic prompt leaves it where it was, on the most frequent formulations—which are often also the least specific.
What you don’t write, the model fills in with the most common version. An unspecified recipient becomes a generic reader; an unspecified length settles on the average length of similar cases; and the quality criterion—if you don’t provide one—remains the model’s own: correct, polished writing that doesn’t stick out in any way.
Repeat the same vague request twice and you’ll get two different responses, because each time the model takes one of the many paths left open by the prompt. This is the clearest sign that decisions remain unresolved: the less restrictive the request, the more the responses vary. When the choices are fixed, however, the responses resemble each other from one run to the next, and revision becomes a predictable task rather than a lottery.
The Invisible Assumptions Within the Response
An output always comes with assumptions embedded within it, even when they’re hidden. When given “analyze this data,” the model decides on its own which metrics matter, how to frame the summary, who it’s being written for, and how much detail to include. Audience, objective, priorities, preferred sources, tone, intended use: everything you haven’t specified is a choice you delegate, and one that the AI makes on your behalf.
If the work proceeds in stages, the assumptions accumulate and carry over into the final result—and with a poor initial prompt, every subsequent choice falls to the model.
Editing then becomes a process of working backward, but the reason a sentence turned out poorly remains unchanged because it may stem from a flawed criterion introduced much earlier. Bringing to light the assumptions used in the generation puts them back on the table: you confirm the correct ones, redo the incorrect ones, and in the next round, the output becomes more precise.
A few explicit decisions change the result more than many words
An effective prompt matters more for the choices it embodies than for the quantity of instructions.
- The objective specifies what action you’re actually asking for. “List the three main risks” sets a different task than “Tell me about the risks.”
- The context provides a setting for the response: an email to a client, an internal memo, a diagnosis on a page, or an outline for the editorial team.
- The constraints on length, language, and tone narrow down the areas most open to interpretation.
- The format determines the form the content should take—whether a list, a table, a paragraph, or a draft email.
Together, they transform an intention into instructions that leave the model with less to guess.
Take “improve this introduction” on an article that’s already been written. “Improve” seems like a sufficient request, but it actually opens the door to different approaches: shortening it, making the hook more direct, strengthening the thesis, removing repetitions, or changing the rhythm. These are different—sometimes even opposing—approaches. When the direction remains vague, the AI tends toward the safest solution: a bland rewrite that smooths everything out, leaves the first generic sentence intact, still defers the connection to the user’s question, and delivers a different, smoother, but not very useful text.
The output changes when you specify the task. “Make this introduction more direct, cut the first generic sentence, connect immediately to the user’s question, and present the thesis in the first three lines” incorporates the objective, editorial context, constraints, and quality criteria. The output still needs to be reviewed, but it addresses the right parts: it cuts the generic opening, anticipates the question, and presents the thesis right at the start.
At that point, the revision changes in nature: you have something to correct rather than something to redo. What remains to be evaluated is how well it addresses the query, the coherence of the shortened thesis, and the tone relative to the rest of the piece. The prompt has narrowed the scope; the final check is still up to you.
Conflicting instructions leave the model to determine the hierarchy of priorities
When you try to make the prompt more precise, however, you run the opposite risk: overloading it with contradictory criteria. “Write a text that is brief yet comprehensive, technical yet simple, persuasive yet neutral” seems like a request rich in criteria, but instead it presents the system with priorities that pull in opposite directions.
“Short” calls for brevity, “comprehensive” calls for depth; “technical” raises the level of language, “simple” brings it back to a more accessible level; “persuasive” pushes for a choice, “neutral” cools it down.
Faced with incompatible criteria, the AI builds a hierarchy for you. It may prioritize brevity at the expense of completeness, maintain a technical tone while sacrificing clarity, or make the text more neutral while draining its persuasive power. The choice remains within the response, even if it seemed already resolved in the prompt.
Overload gives the impression of completeness but actually hands control back to the system. Every contradictory criterion reopens a decision you thought you’d settled. A few coherent criteria, ranked by importance, govern the output more than ten adjectives competing with one another.
The wrong technique bloats the prompt and confuses the task
B PromptingB is the process of shaping the request; it determines how much structure to give the task.
A straightforward translation or a three-point summary works well with a direct instruction—the B zero-shotB —where the task is simple and the model handles it without assistance. When the format or style is difficult to describe in words, it’s best to show it: few-shot describes
If you have a format or style that’s hard to describe in words, switch to few-shot: choose a couple of practical examples that illustrate the desired result better than any explanation—but be careful, because a bad example teaches the wrong pattern.
When the answer depends on a point of view, assigning a role—such as “respond as a reviewer evaluating the page for conversion”—shifts the starting point, because the model adopts that role’s vocabulary, priorities, and criteria. It works as long as it remains a guide, but it becomes a mask when it rigidifies everything and forces the text into a fixed pose.
For complex tasks involving planning, deduction, multilevel problem-solving, or nonlinear reasoning, you might adopt the chain-of-thought (CoT) prompting strategy, which lays out an explicit path of thought, by segmenting the request into clear steps that the model must execute in sequence to generate the response through a chain of inferences, and makes errors easier to identify, because every stage of processing is visible.
Other techniques focus on the structure of the request, which is important when instructions, input, and output risk becoming confused. Delimiters—such as quotation marks or tags—separate instructions from the data to be processed, eliminating ambiguity about what constitutes a command and what constitutes the text to be processed. Specifying the output format—such as a table with specific columns or a list of fields—prevents a rambling response when you need structured data and makes it easier to compare multiple responses. For tasks where there’s a risk of an error in reasoning, asking for explicit steps helps identify where the logic breaks down, rather than discovering the mistake only in the final result. And when the task is too large for a single prompt, it’s best to break it down into multiple concatenated prompts, where the result feeds into the next one and each part remains manageable.
The problem arises when you apply the heaviest technique to the simplest task. A step-by-step reasoning process to shorten a meta description lengthens the prompt and slows down the response—and rarely improves a task that the model already performs well. Too many examples for a task that’s already clear shift the focus to the pattern to be imitated and obscure the objective.
The first response shows you what was missing from the prompt
The final prompt almost always emerges through trial and error: you write it, read the first response, figure out what’s missing, and revise the prompt. The first output serves as a diagnosis of the process: it shows you what the system understood, what assumptions it made, and where it filled in the gaps on its own.
Correction almost always starts with a choice you had left implicit. You look at what it misunderstood, which criteria it took for granted, which parts are correct but useless for your purposes, and which constraints are missing entirely. From there, you decide what to keep and what to have regenerated, and above all, whether it’s better to correct the prompt or edit the text manually.
An error in setup—wrong audience, off-focus angle—is resolved in the prompt, because it would recur with every regeneration; a single clumsy sentence is fixed more quickly by you alone than by explaining to the model how to rewrite it. Each iteration narrows the margin, and after two or three passes, the prompt you have in hand is worth more than the initial one, because it contains the decisions that the first attempt forced you to make.
A prompt that stands the test of time is designed and tested
The refinement process serves to make the framework replicable, so that a prompt ceases to be disposable and begins to become a method that can be successfully and immediately applied to every subsequent task.
In editorial work, you often find yourself having to repeat a task—preparing an article outline, reviewing a product sheet, analyzing a page, reading a SERP, or turning a brief into an outline. If you start from a blank chat every time, you lose the decisions you’d already worked hard to make explicit.
However, you need more than just copying the instructions into a new window. An effective instruction includes precise decisions—target audience, angle, quality criteria, format—that remain useful only if the instruction is written in a way that holds up even for a slightly different task and in the hands of someone who didn’t come up with it. For recurring tasks—such as an article outline, a product page review, or a website audit—it’s worth setting the prompt in stone and ensuring its robustness, because that’s where decisions made once no longer need to be revisited every time.
On a technical level, you can distinguish two specific skills here. Prompt design focuses on interaction: how the prompt fits into the workflow, what it asks of the user, what choices it requires the user to specify, and how clear it remains to those who didn’t write it. Prompt engineering focuses on robustness: it documents the schema, versions it, and tests it on real-world cases and on the AI assistant it’s intended to run on.
Prompting frameworks to standardize and replicate results
A prompt may work well for reviewing informational articles but fall short on product pages or landing pages, where constraints, tone, and completeness criteria change. The real work begins there: testing, correcting, and distinguishing what needs to be fixed from what must remain flexible.
To simplify this systematic approach, you can also refer to frameworks like RACE or RISEN, which help organize role, task, context, and constraints; when applied by rote, they become blank templates. In practice, they provide you with a syntactic and functional grid within which to formulate consistent, replicable requests that are easily adaptable to different contexts.
The RACE framework (Role, Action, Context, Explanation) organizes the prompt around four key elements. As Kate Moran explains, it is designed to provide the model with a precise identity, a specific task, a reference context, and a clear description of the desired output. It works well with models like ChatGPT, Claude, and other general-purpose LLMs, especially when the prompt needs to guide the tone, form, and purpose of the response.
A conversational example: “You are a child psychologist with experience supporting preschool-aged children who are afraid of the dark. Design a series of practical and reassuring strategies to help a 2-year-old girl sleep peacefully. The child often wakes up crying and seeks her parents’ presence to fall back asleep. There have been no recent changes to her routine, but the family wants gentle, non-invasive solutions. Provide guidance with advice broken down into short- and long-term strategies, using simple language suitable for parents.”
Here, the Role is explicit (“you are a child psychologist”), the Action is defined (“design practical strategies”), the Context is realistic and detailed, and the Explanation of the output is clear (“guide with advice broken down”). This framework guides the model to select relevant knowledge, respond in a structured manner, and choose a tone appropriate for the target audience.
The RISEN framework (Role, Instructions, Steps, End goal, Narrowing) aims to structure more complex requests, where the steps involved are just as important as the final goal. It is a practical model well-suited for prompts that require a response organized into sequences of actions, such as itineraries, operational checklists, scripts, schedules, and practical guides.
A prompt built using RISEN might sound like this: “You are a travel expert who plans cultural experiences in London for first-time visitors. Create a plan for a 4-day trip: break down the itinerary into morning/afternoon/evening segments, including museums, walking tours, and local restaurants. Specify the modes of transportation to use, recommended tickets, and average visit durations. The plan should be suitable for an adult couple with a moderate budget and a relaxed pace. Write everything in no more than 400 words, in a hierarchical list format.”
The expected output is clear and well-defined. There is a task (create an itinerary), a step-by-step execution (days/times), an objective (an enjoyable cultural experience), and a set of constraints regarding format, tone, and content. Compared to RACE, RISEN focuses more on the internal sequence of the response and the operational constraints to be followed.
If you prefer to work on something more personalized and tailored to your specific needs, start by analyzing recurring tasks. For example, if you often work on promotional tone of voice, comparative lists, persuasive emails, or UX microcopy, you could build a prompt template that includes:
- Expert role + usage context + end-user type
- Specific objective (e.g., generate a persuasive opening paragraph)
- Constraints on format and style
- Level of detail
- Additional instructions on the response’s tone (avoid technical language, use metaphors, avoid passive voice).
When a prompt is crafted this way, the result depends less on the writer’s mood that day and more on the choices already embedded in the prompt. The decisions you’ve made explicit remain within the tool, ready for the next piece of content, and you no longer have to start from scratch with every request.
The model retains some decision-making autonomy
Even the most precise prompt leaves the model with a margin of discretion that’s beyond your control. The same prompt, when fed to ChatGPT, Gemini, or Claude, returns different responses, because the training, policies, system prompts, and methods of retrieving sources vary. This is a concrete reality in everyday work: each person can use the assistant of their choice or the one adopted by the company, and the same request yields different results depending on where it’s run.
Within that margin, three forces in particular come into play. Guardrails are the filters the platform imposes on certain topics: they trigger based on criteria that are often opaque, and it can happen that a legitimate request is blocked while a more ambiguous one gets through, without you being able to predict it. B Prompt injectionB exploits the fact that the model reads everything together—instructions and content: commands that compete with yours may be hidden within a document, webpage, or email you give it to process, and sometimes they are executed. B Contaminated contextB is more subtle: if the sources you provide are biased or one-sided, the response inherits that bias and returns it to you as if it were neutral.
You must accept that the prompt doesn’t control everything. Part of the response is determined by the platform’s rules, the text the model encounters, and the sources you provide. Knowing this changes how you interpret an output, because it keeps you from trusting a response just because it’s well-written.
The model’s boundaries can be shifted
The guardrails give way depending on how you frame the question. The same topic that’s blocked in a direct request can slip through if you frame it as a hypothesis, a role-playing scenario, or a fictional scene—and red-team experiments show that even the most filtered models can be led outside their boundaries with a carefully crafted chain of messages.
The point isn’t to exploit this flexibility, but to recognize it. The model’s refusal is less stable than it seems, because it also depends on how you phrase the request. And this very maneuverability makes the material you feed the system risky: a page or a document might contain exactly that kind of framing and push the model in a direction you didn’t ask for—without you having written a single word.
Accommodating confirmation turns verification into consent
The most insidious limitation takes the form of agreement. Ask a model to evaluate your draft, and if you’ve already hinted in your request that you like it, it tends to agree with you. It’s sycophancy—the tendency to align with the stance it already finds in the question. For those seeking confirmation, this is convenient; for those seeking verification, it’s a problem, because the response risks simply echoing your own thesis, disguised as analysis. The countermeasure lies in creating friction within the prompt: asking for counterarguments, treating the hypothesis as provisional, and requesting that the model separate facts from inferences. A request designed to be contradicted yields verification, not an echo.
Writing a prompt, ultimately, is deciding how many of the important choices remain yours and how many are left to the model. This applies to a line jotted down on the fly as well as to an outline you refine over time: the quality of what you get is the sum of the decisions you’ve made in the prompt and those you’ve let the system make.
Those same prompts, when viewed across an entire market rather than one at a time, reveal what questions the public asks assistants and where a brand appears in the responses: this is the realm of prompt monitoring, a discipline in its own right that nevertheless relies on the same skills you’re developing now.
Ultimately, the logic remains the same. The more criteria you can establish, the less room you leave for the average response. The more choices you retain control over, the more the AI becomes a work tool rather than a generator that makes decisions for you.
