Prompt engineering best practices come down to four moves: state the task and its constraints explicitly, give the model the context and examples it needs, let it reason before it answers, and test the prompt against real inputs before it reaches a user. Everything else here is detail underneath those four.
Think of a prompt as a job sheet you slide across a counter to a contractor who is extraordinarily fast, works for pennies, and takes every word literally. Write "fix the door" and you will get a door that opens, somewhere, somehow. Write which door, which way it should swing, and what to do if the frame turns out to be rotten, and you get the job you actually wanted. The counter never gets a second conversation. Whatever is on that sheet is the whole brief.
That is why prompts matter commercially. A prompt is the cheapest part of an AI feature to change and the most expensive part to get wrong, because a bad prompt does not fail loudly. It produces plausible output. Someone downstream has to catch it.
This article covers the fundamentals, the techniques that improve output quality, the practices worth standardising across a team, the advanced controls such as reasoning effort and token limits, and what prompt quality costs the business. It uses OpenAI's GPT-5 family as the working example (GPT-5.4 at the time of writing), though the practices transfer to any large language model with a comparable API. Let's get into it.
Developed by OpenAI, ChatGPT is a large language model, or LLM, trained on a very large body of text, which lets it generate human-like responses to a prompt. In plain words: it predicts the next token in a sequence, and a token is roughly three quarters of a word. That is the whole trick, and it has been enough to put the thing in front of professionals across every industry you can name.
Does that mean you need to track every model release? No, and if you have watched the last eighteen months, you know why. OpenAI retired the entire GPT-4 and GPT-4o line in early 2026 and consolidated on the GPT-5 family; anyone whose code still hard-coded gpt-4-turbo found out the hard way. Model names churn faster than any article can follow, so fix on the three specifications that change what you can build rather than on the name of this quarter's release:
The context window, measured in tokens, sets how much material you can put in front of the model at once. A current frontier model such as GPT-5.4 carries a window of roughly a million tokens, well over two thousand pages, which is what makes long-document work such as summarising a contract or an entire support history practical in a single call rather than a chain of them. Watch the pricing tiers, though: on the million-token models, everything above about 272k input tokens is billed at a premium for the whole session, so a bigger window is not a licence to stop thinking about retrieval.
The knowledge cutoff is the date after which the model knows nothing. Every model has one, and it is always earlier than you would like. Anything later than the cutoff has to reach the model through the prompt, through retrieval or a tool call. A model answering quietly from stale training data is one of the more common causes of confidently wrong output. Check the current model card for the exact date before you rely on it.
The cost per token, charged separately for input and output, and now often split by context length and reasoning effort. GPT-5.4 sits at roughly $2.50 per million input tokens and $15 per million output at short context, rising for long-context calls. A shift in these numbers moves use cases from too expensive to viable overnight, which is exactly why you re-cost a feature every time the lineup changes rather than once at the start.
A fourth variable used to sit alongside these three; it now sits on top of them: how hard the model reasons before answering. On the GPT-5 family this is a dial (reasoning effort runs from none through to the highest setting), and it does internally what the chain-of-thought prompting below asks an older model to do out loud. Higher effort costs more per call and answers more slowly. Where the task genuinely needs multi-step reasoning, that trade is usually worth taking, and your prompt gets simpler because you are no longer scripting the steps. Where it does not, turning the dial down is free money.
Check OpenAI's API reference for current figures before you build a business case on any of them. They move monthly.
Prompt engineering is what turns a general model into something that does one job reliably. This section covers what it is, why prompts carry so much of the weight, and what drives the choice of one prompt over another.
Prompt engineering is the strategic process of planning and generating prompts to elicit desired responses from a model like ChatGPT. It means writing the instructions and inputs that control the model's behaviour and shape the quality and relevance of what comes back.
Its value lies in adjusting the model's responses to a specific task without touching the model itself. State your intent precisely and you get accurate, contextually appropriate output from a system that would otherwise answer a vague question with a vague answer. Ask vaguely, receive vaguely. That is the deal.
Prompts give the model the context it needs to produce a relevant response, and they set the starting point for the conversation. Structure the instruction clearly and you steer the model towards the outcome you want.
This is documented in OpenAI's own research, not just folklore. Language Models are Few-Shot Learners, the GPT-3 paper, showed that supplying a handful of worked examples inside the prompt improves task performance substantially without any change to the model weights, and that performance scales with the number of examples given. Earlier work on unsupervised multitask learning showed the same models performing tasks they were never explicitly trained on, provided the task was stated clearly in the input. Newer models need fewer examples to get there, but the direction of the finding still holds.
Compare these two:
Prompt 1
Summarise this support ticket.
Prompt 2
Summarise this support ticket in three sentences for a second-line engineer. State the product area, what the customer has already tried, and the single next action. Do not restate the customer's tone.
The second gives an engineer something to act on. The first gives a paraphrase. Nothing changed except precision.
Knowing how prompts are classified helps you build them around the response you actually want. The major categories:
A handful of elements decide the quality, relevance and accuracy of what comes back:
Prompt engineering is still an active area of study, so expect the techniques below to keep moving as the models do.
A prompt is the interface between a general-purpose model and one specific job. It carries the task, the context the model cannot infer, the constraints on the output and, when it matters, the examples that show what good looks like. Precision in that instruction is what separates output an engineer can use from output someone has to rewrite. The categories above are a checklist for the kind of response you are asking for. The factors are a checklist for what the model needs before it can hand one over.
Five techniques do most of the work.
Explicit guidance improves response quality more reliably than any other change you can make.
Generic prompt
Tell me about our churn problem.
Specific prompt
Here is a table of monthly churn by customer segment for the last 12 months. Identify the two segments with the steepest increase, state the size of the increase, and list three questions I should ask the account team before drawing conclusions. Flag anything the data cannot tell me.
The generic prompt returns a definition of churn. The specific one returns something you can take into a meeting.
Constraints are extra instructions that shape the model's behaviour and narrow the space of acceptable answers. Want a procedure? Ask for "a detailed, sequential process, with each step as a numbered line and no step depending on information the reader does not yet have". Ask instead for "steps" and you will get a paragraph with the word "first" in it.
Constraints are also the cheapest guardrail on the shelf. A prompt that ends with a defined failure state hands you a machine-checkable outcome instead of an invented one:
Summarise the attached policy in no more than 120 words, in British English, in plain prose with no bullet points. If the policy does not state a retention period, reply exactly: NOT FOUND.
Context is the highest-yield addition to almost any prompt. Compare:
Prompt without context
Write an email about the delay.
Prompt with context and desired output
Write an email to a customer whose integration go-live is slipping by two weeks because of a dependency on their own IT team. Acknowledge the impact, state the new date, name the one thing we need from them to hold it, and offer a call. Six sentences, no apologising twice, British English.
The second carries everything the model could not have known. That is the whole technique. Truth be told, most prompts that "don't work" are just prompts missing this.
System 1 questions elicit quick, instinctive responses. System 2 questions demand thoughtful, detailed reasoning. Combine both in one workflow and you buy speed where speed is enough, depth where it is not.
A support triage assistant:
The System 1 query routes the ticket in a fraction of a second and a fraction of the cost. The System 2 query is held back for tickets that survive triage, where a wrong answer is expensive and the extra tokens earn their keep. On the GPT-5 family this maps cleanly onto reasoning effort: route at minimal effort, investigate at high. Splitting a workflow this way is usually the single largest cost saving available in an LLM feature. Worth doing before you go looking for a cheaper model.
Verbosity control sets the level of detail and the length of the output, which matters most when the response has to fit a screen or a downstream field.
Low verbosity
Give me the deployment steps as a numbered list. One line each, no explanation.
High verbosity
Give me the deployment steps as a numbered list. Under each step, explain what it does, what it depends on, and what to check before moving to the next one. Assume the reader has never deployed this service.
The same underlying knowledge serves an experienced engineer running a familiar release and a new starter running it for the first time. Verbosity is the only difference, and it is a prompt-level decision rather than a model-level one.
Techniques improve a single prompt. Practices are what keep a hundred prompts working across a team, and across the model updates nobody warned you about.
On the AI features we take to production at Imaginary Cloud, we write prompts as specifications with four parts. We call it the prompt spec, and it is the structure sitting behind every example in this article:
The fourth part is the one teams skip, and skipping it is exactly what makes prompt work feel like guesswork. A prompt without an acceptance check cannot be reviewed, cannot be regression tested, and cannot be handed to a second engineer without a twenty-minute conversation. The same failure shows up in technical debt generally: work with no definition of done piles up quietly until someone pays for it at the worst possible moment.
Good prompts are iterated, not written. Review the output, adjust, repeat.
Iteration 1: Extract the action items from these meeting notes. → output includes decisions and observations alongside actions.
Iteration 2: Extract only the action items. An action item has an owner and an implied deadline. Exclude decisions and observations. → better, but owners come back as first names that don't match the directory.
Iteration 3: Extract only the action items as a table with columns Owner, Action, Due. Match each owner to the full name in the attendee list. Exclude decisions and observations. If a due date is not stated, write TBC.
Three passes turned a paragraph into a table another system can consume. Keep the fixture set as you go: the same meeting notes, run again on every prompt change, so you can see whether iteration four quietly broke iteration three.
Some tasks want one correct answer. Others want options. A copy assistant that produces a single headline is less useful than one that produces six, and a contract summariser that produces six versions is not useful at all.
Generate six subject lines for this product announcement email. Two plain and factual, two benefit-led, two curiosity-led. Under 60 characters each. Do not use exclamation marks. Return them as a numbered list with the style in brackets.
The prompt draws the fence. Inside it, the model can be as inventive as you like without wandering off the brief.
A model cannot know your order status, your stock levels or today's weather. Tool calls and API integrations are what connect the job sheet to live data. The prompt defines when the model should call the tool, and what to do when the call fails:
You are an order status assistant. When the customer asks about an order, call get_order_status with the order reference. Answer only from the values it returns. If the reference is missing or the call fails, ask the customer for the reference. Never estimate a delivery date that the tool has not returned.The tool itself is ordinary code:
def get_order_status(order_ref: str) -> dict:
response = requests.get(
f"https://api.example.com/orders/{order_ref}",
headers={"Authorization": f"Bearer {API_KEY}"},
timeout=5,
)
response.raise_for_status()
data = response.json()
return {
"status": data["status"],
"carrier": data["carrier"],
"expected": data["expected_delivery"],
}Generated response: "Order 4417 shipped yesterday with DPD and is expected on Thursday 12 March."
The value of the pattern is the division of labour. The fact came from your system, the sentence came from the model, and neither is doing the other's job.
The API lets you build the same interaction into your own product:
from openai import OpenAI
client = OpenAI()
def ask(question: str, history: list[dict] | None = None) -> str:
messages = [{"role": "system", "content": SYSTEM_PROMPT}]
messages += history or []
messages.append({"role": "user", "content": question})
response = client.chat.completions.create(
model="gpt-5.4",
messages=messages,
temperature=0.2,
max_tokens=500,
)
return response.choices[0].message.contentThe system prompt carries the spec, the history carries the conversation, and temperature and max_tokens carry the product decisions we come to below. One caveat worth knowing: on reasoning-first models, temperature has less effect than it did on GPT-4-era models, and reasoning effort becomes the dial that matters, so treat the value here as illustrative and confirm behaviour against the model card. Getting from a snippet like this to something you can run in front of customers is a longer road, and we have written about taking an AI prototype to production separately.
Where a model touches a decision about a person, bias stops being a quality issue and becomes a legal one. Say a system uses an LLM to summarise interview responses for a hiring panel. These steps reduce the risk:
The higher the stakes, the more that "human in the loop" line has to be real rather than decorative, and the discipline is the same whether the system is an LLM or something else entirely. When we built the Geo Matrix Decision Engine for Aurora Analytica, a scenario-planning tool for clinical-trial teams, the point was never that the software sounded convincing. It was whether a CRO analyst could look at a result and check it before it fed a real trial decision. That is not an LLM story (it is a decision engine), but it is the same reason the acceptance check sits in our prompt spec: in a regulated setting, output a person cannot verify is a liability no matter how it was generated. The same bar applies to any LLM feature that reaches a customer, a regulator or a contract. If you work in a supervised field such as healthcare or legal, our applied AI and machine learning team treats evaluation as part of delivery rather than a phase bolted on after it.
Prompt engineering reads like a craft topic and lands like a cost line. Four numbers make the case to a board:
Time-to-value is the reason to care about all four at once. Prompt-level work is fast, which is precisely why teams skip the parts that are not, and then spend the weeks they saved on incident response. The tech stack decisions around an AI feature follow the same pattern: the cheap choice early is rarely the cheap one over three years.
On the GPT-5 family, the first dial to reach for is reasoning effort, from none to the highest setting. Low effort for anything shallow and high-volume; high effort for the few calls where a wrong answer is expensive. It is the cleanest cost lever you have.
Temperature still controls randomness where it applies. Low values such as 0.2 produce focused, largely deterministic answers; higher values such as 0.9 produce more variable, exploratory ones. The decision is a product one:
temperature=0.2: Extract the payment terms from this contract clause and state them in one sentence.temperature=0.9: Give me ten names for an internal tool that reconciles invoices against purchase orders. Plain and memorable rather than clever.Anything a customer will read as fact belongs at low temperature and low effort. Anything a person will choose from can afford more of both.
Token limits cap the length of the response. Setting max_tokens deliberately keeps the output inside the space it has to fit, and stops a verbose answer truncating mid-sentence in a UI that expected three lines. With output tokens the expensive side of the bill, capping length is often a bigger saving than trimming the input.
Chaining connects prompts so each one can reference earlier inputs and outputs. That is what makes multi-step work possible.
An onboarding assistant:
The second turn depends entirely on the first. Chaining also keeps each prompt small enough to be reviewed by a colleague, which a single monolithic prompt attempting both steps would never be.
Adapting a prompt to a domain means bringing its vocabulary, its constraints and its risk profile into the instruction.
A general prompt, Summarise this contract, becomes:
You are assisting a commercial lawyer reviewing a supplier agreement. Identify the termination provisions, the liability cap, the payment terms and any auto-renewal clause. Quote the clause number for each. If a provision is absent, say so explicitly rather than inferring an equivalent. Do not offer legal advice or an opinion on whether the terms are favourable.
The response then arrives in a shape the reviewer can check clause by clause:
The domain adaptation is not the tone. It is the explicit list of what to look for, plus the instruction on what to do when a thing is missing.
Users ask for contradictory things, and a model that resolves the contradiction silently will resolve it wrongly some of the time.
User: Give me last quarter's revenue by region, but only for the enterprise accounts, and include the pipeline.
Revenue and pipeline are different measures, and "last quarter" could mean calendar or fiscal. So instruct the model to stop and ask:
If the request is ambiguous, do not guess. Ask one clarifying question and wait.
Assistant: Do you want closed revenue and open pipeline as separate columns, and should the quarter be fiscal Q3 or calendar Q1?
Once the user answers, the model can produce something correct rather than something plausible. Building the clarifying turn into the prompt is what stops an assistant inventing its own definition of "last quarter" and reporting confidently against it.
DeepLearning.AI's short course ChatGPT Prompt Engineering for Developers, taught by Isa Fulford and Andrew Ng, remains the clearest free introduction for engineers. A note on vintage: the course was recorded against GPT-3.5 Turbo, since retired, so treat the model specifics as dated; the principles transfer intact to the GPT-5 family. Here is what its material contributes to each part of the prompt spec, and where production work needs more than the course covers.
Task: why specific instructions beat short ones. The course's first principle is to write clear and specific instructions, and its most useful correction is that a clear prompt is not the same as a short one. Two of its tactics belong in the task line. Delimiters mark the distinct parts of the input (triple quotes, backticks, dashes, angle brackets or XML tags) so the model can tell your instruction from your user's text, which also reduces prompt-injection risk. Few-shot prompting supplies examples of the task done correctly before you ask for the real one. What the course does not cover is where the task line lives: in an API call, the system message carries the role and standing rules while the user message carries only this request's input. Teams that stuff the standing rules into the user message watch their prompt drift.
Constraints: structured outputs and machine-checkable failure. The course's second tactic is to request structured output such as JSON. Asking politely for JSON is the weak version. Current APIs will enforce a schema on your behalf: a JSON mode that guarantees valid JSON, or structured outputs where you supply the schema and the model is constrained to validate against it. If the output feeds another system, use the schema. A parse error you catch at the boundary beats a prompt that usually complies.
Evidence and acceptance: verify the assumptions, then test the batch. The course's third tactic is to have the model check its conditions first and report any that are unsatisfied, the acceptance check, moved inside the prompt. Its iterative loop applies the same idea outside the prompt: attempt, analyse the divergence, clarify, refine against a batch. The batch is the fixture set, and it is the difference between a prompt that works on the example you had open and one that works on the inputs you actually receive. This is where our practice parts company with the course: a course prompt is finished when the notebook output looks right; a production prompt is finished when it passes a fixture set, has a named owner, and has a decided answer to "what happens the day the model underneath it changes."
Chain-of-thought: give the model room to reason. The second principle is to give the model time to think. Ask for the reasoning steps and then the conclusion, which stops the model committing to an answer it has not worked out. Reasoning models now do this internally, which changes the economics rather than the principle: on those, asking explicitly for steps adds cost without much accuracy, so try the simple prompt first and add scaffolding only where your evaluation shows it helps.
What LLMs do well: summarising, inferring, transforming, expanding. The course groups everyday use cases into four, and it is a genuinely useful triage tool. Summarising can focus on one dimension rather than compressing evenly. Inferring determines sentiment, extracts names, infers topics without task-specific training. Transforming (translation, grammar, tone, format conversion) is the most reliable of the four, because the input already contains the answer. Expanding turns a short input into a longer piece, and carries the most risk, because the model is adding material that was not in the input, which is precisely where fabrication lives. Weight your evaluation accordingly.
Prompt engineering is the layer where most of the quality, and most of the cost, of an LLM feature gets decided. The techniques are not hard: be specific, supply context, constrain the output, give the model room to reason, and set effort and length deliberately. What separates the teams shipping reliable AI features from the teams shipping demos is the unglamorous part. Writing prompts as specifications with an acceptance check. Keeping a fixture set of real inputs. Running it again when the model underneath changes, and in 2026, it will.
Back to that counter. The contractor is not going to ask you what you meant, and a new one starts every few months without telling you. So the job sheet had better say everything, and you had better be able to prove the last one still works. Prompts written as specifications survive that. Prompts written as lucky sentences do not.
As long as it takes to remove ambiguity, and no longer. A short prompt is not a clear prompt. Most production prompts run to several hundred words, because they carry the task, the constraints, the failure state and one or two examples. The cost of those tokens is real, and small next to the cost of an output someone has to correct.
Constrain it, and give it something to work from. Supply the source material in the prompt or through retrieval, instruct the model to answer only from that material, and give it an explicit way to fail, such as replying "NOT FOUND" when the answer is not there. Lower the temperature and reasoning effort for anything factual. None of this eliminates fabrication, which is why anything consequential keeps a human review step.
Yes, though less as a job title and more as ordinary engineering practice. Better models need less coaxing, but they still do not know your data, your constraints, or what your users mean by "last quarter". Stating a task precisely and defining what a correct answer looks like remains the work.
Prompt engineering changes the instruction. Fine-tuning changes the model, by training it further on your own examples. Prompting is faster, cheaper and reversible, so it is the right first move. Fine-tuning becomes worth considering when a task is high volume, narrow, and stable enough that the examples will not go stale, and when prompting has already been pushed as far as it goes.
Build a fixture set of twenty to fifty real inputs with the outputs you expect, run the prompt against all of them, and review the results as a set rather than one at a time. Re-run it on every prompt change and after every model update. It is the only reliable way to know whether a change improved the prompt or simply moved the failure somewhere you were not looking.
Controlling reasoning effort, temperature and token limits for cost, randomness and length; chaining prompts across multiple turns; adapting prompts to a specific domain with its vocabulary and constraints; and handling ambiguous or contradictory inputs by instructing the model to ask rather than guess.
If you are weighing up whether an LLM belongs in a particular workflow, the useful first conversation is usually about the acceptance check rather than the model: what a correct output looks like, who notices when it is wrong, and what that costs you. Our data science and AI-enabled custom development teams work with clients on exactly that question, from evaluating a use case to running it in production. If you have a workflow in mind, get in touch and we will tell you honestly whether it is worth building.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
CEO @ Imaginary Cloud and co-author of the Product Design Process book. I enjoy food, wine, and Krav Maga (not necessarily in this order).
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
