AI & Practice · 10 min read

How to Write Prompts Like a Pro

Practical lessons from the people who build AI systems: give models better context, clearer constraints, useful examples, and room to express uncertainty.

By Shivam KhareJuly 28, 2026

Everyone who has used ChatGPT, Claude, or Gemini has had the same frustrating experience: you type a quick question, get a mediocre answer, rephrase it three times, and eventually stumble into something useful — without ever really understanding why the third version worked and the first one didn't.

It turns out the people who actually build these models have thought about this problem obsessively, and their advice converges on a surprisingly small set of principles. This article pulls together what the engineers, researchers, and executives behind Anthropic's Claude, OpenAI's GPT models, and the broader AI research community have actually said — in their official documentation and in public — about how to prompt well. Not tricks. Not "magic words." The real, tested ideas.

Start With What a Model Actually Is

Before the tactics, it helps to sit with one uncomfortable fact that every AI lab's own documentation is built around: a language model doesn't know what you want. It has no access to your intent, your unstated assumptions, or the context sitting in your head. All it has is the text you give it, plus whatever it learned about how language and reasoning generally work during training. Every technique below is really just a different way of closing that gap between what's in your head and what's on the page.

This is why the single most repeated piece of advice across every major AI lab's guidance is some version of: be explicit. Anthropic's own prompt engineering documentation puts it plainly — "tell the model exactly what you want to see." Not because the model is dumb, but because it's a probability machine with no telepathy. If you leave something ambiguous, it will resolve that ambiguity for you, and it usually won't resolve it the way you would have.

Lesson One: Specificity Beats Cleverness

Anthropic's engineering team, who spend their working lives building and testing Claude, converge on a small number of moves that show up again and again in their published best practices:

Be explicit and clear. State your request directly, in plain language, without assuming the model will infer what you actually meant.

Provide context and motivation. It's not enough to say what you want — explaining why it matters helps the model make better judgment calls on everything you didn't explicitly specify. If you tell a model you need a summary "because it's going into a board deck," it will make different formatting and tone choices than if you'd said "because I'm skimming it before a call in five minutes."

Be specific about structure. Word counts, formats, audience, and required sections aren't fussy details — they're the difference between a usable output and one you have to rewrite yourself. Anthropic's guidance recommends spelling out constraints, relevant context, desired output structure, and any hard requirements up front, rather than hoping the model guesses correctly.

Use examples. Few-shot prompting — showing the model one or two examples of the kind of output you want — is one of the most reliable ways to communicate a subtle style or format that's hard to describe in words. The catch, per Anthropic's own guidance, is that modern models "pay very close attention to details in examples," so a sloppy example will teach the model your sloppy habits just as effectively as a good one teaches good habits.

Give the model permission to say "I don't know." This one is counterintuitive but important: explicitly telling a model it's allowed to express uncertainty, rather than being pressured to always produce a confident answer, measurably reduces made-up information. If you never give a model an acceptable way to say "I'm not sure," it will often manufacture confidence instead.

Anthropic sums up the whole philosophy in a single line worth remembering: "the best prompt isn't the longest or most complex. It's the one that achieves your goals reliably with the minimum necessary structure." More is not automatically better. The goal is precision, not volume.

Lesson Two: Talk to It Like You'd Talk to a Person

OpenAI's leadership has landed on strikingly similar ground, from a different angle. OpenAI president Greg Brockman has shared a four-part framework for prompting (originally developed by engineer Ben Hylak) that's worth memorizing because it's simple enough to actually use under deadline pressure:

State your goal. Say clearly what output you actually want.
Specify your preferred format. Tell it how you want the answer structured — a list, a table, citations, specific fields.
Add warnings and guardrails. Flag the specific ways the answer could go wrong. Brockman's own example: when asking for a hiking trail recommendation, explicitly warn the model to "be careful to make sure the name of the trail is correct, it actually exists, and that the time is correct."
Give it a context dump. Share the background information naturally, the way "you would [tell] another human being."

That last point is the real insight buried in this framework: good prompting isn't a special skill separate from good communication. It's good communication, applied to a very literal-minded listener who has zero shared history with you and will not ask a clarifying question unless you invite one.

OpenAI's more technical guidance for its newest models reinforces the specificity point from a different angle, and with a warning attached: "poorly-constructed prompts containing contradictory or vague instructions can be more damaging to GPT-5 than to other models." As models get more capable and more literal about following instructions precisely, sloppy or self-contradictory prompts don't just produce mediocre results anymore — they actively confuse a model that's trying hard to satisfy every clause you wrote, including the ones that quietly contradict each other. The fix OpenAI recommends is unglamorous but effective: resolve contradictions before you hit send, and for anything you'll reuse often, structure your instructions clearly — headers, numbered steps, or explicit XML-style sections — rather than one long paragraph.

Lesson Three: The Best Prompt Is a Well-Built Context, Not a Clever Sentence

Perhaps the single most influential reframing of prompting in the last two years came from Andrej Karpathy — a founding member of OpenAI and former head of AI at Tesla, and one of the most widely respected voices in the field. In a widely shared post, Karpathy argued for retiring the term "prompt engineering" in favor of something he called context engineering:

"People associate prompts with short task descriptions you'd give an LLM in your day-to-day use," he wrote. "When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step."

This matters because it reframes the entire activity. A "prompt" sounds like a single clever sentence you craft once. "Context," in Karpathy's framing, is everything the model sees before it generates its next output: your instructions, yes, but also the examples you've included, the documents you've retrieved, the results of any tools the system has already called, the conversation history, and the state of whatever task is in progress. For a simple one-off question, the distinction barely matters. For any serious AI application — a coding assistant, a research tool, an autonomous agent — the quality of the output is overwhelmingly determined by the quality and relevance of everything sitting in that context window, not by how the final instruction sentence is phrased.

The practical takeaway for anyone writing prompts, even outside of building full applications: think about what the model needs to know, not just what you want it to do. Before you ask a question, ask yourself what background, examples, and constraints you'd want a competent new hire to have if you handed them this exact task with zero other context. Then give the model that same package.

Lesson Four: Iterate Like an Engineer, Not a Supplicant

One habit that separates people who get consistently good results from people who don't: professionals treat prompting as an iterative, testable process, not a one-shot incantation you either get right or don't.

Anthropic's guidance explicitly recommends techniques like prompt chaining — breaking a complex task into a sequence of smaller prompts rather than trying to cram everything into one giant instruction — and prefilling, where you start the model's response yourself to steer its format or tone before it writes a single word on its own. Both techniques share a philosophy: instead of trying to perfectly specify everything up front, you give the model a scaffold and correct course as you go, the same way you'd manage a junior collaborator on a multi-step task rather than handing them one enormous brief and walking away.

OpenAI's own tooling for its latest models has moved in the same direction — reasoning models can be steered with parameters like verbosity and reasoning effort, and OpenAI explicitly recommends testing prompts against a prompt optimizer and iterating rather than assuming the first version is right. The unglamorous truth behind almost all published advice from people who prompt models for a living: they write a version, run it, look at what went wrong, and adjust — the exact same debugging loop that governs writing code, because in a very real sense, that's what a prompt is.

Lesson Five: Ask for Reasoning When the Task Deserves It

Both major labs converge on a related idea: for anything requiring multiple logical steps — analysis, math, multi-part decisions — explicitly asking the model to reason step by step, sometimes called chain-of-thought prompting, tends to produce more reliable answers than asking it to jump straight to a conclusion. Anthropic's guidance recommends this directly, and OpenAI's reasoning-model documentation builds the same idea into the product itself, letting you dial reasoning effort up for hard problems and down for simple, latency-sensitive ones.

The intuition behind this is simple once you think about how these models generate text: they produce one token at a time, and each token is influenced by everything generated before it. A model that jumps straight to "the answer is X" has committed to that answer before doing any visible work to check it. A model that's asked to lay out its reasoning first has, in effect, given itself scratch paper — and scratch paper measurably helps, both for the model and for you, since you can actually see where its logic went wrong if the answer is off.

Common Mistakes That Undo Good Prompting

Knowing the principles is one thing; avoiding the habits that quietly sabotage them is another. A few patterns show up constantly, even among people who've read every guide above.

Piling on instructions instead of resolving conflicts. It's tempting to keep adding sentences to a prompt every time you notice a new edge case — "also make it shorter," "also be more formal," "also don't mention pricing" — until the prompt contains instructions that quietly contradict each other. OpenAI's own guidance on this is blunt: newer, more capable models are actually more sensitive to contradictory instructions than older ones, because they try harder to satisfy every clause. The fix isn't fewer instructions; it's instructions that have been read back and checked for internal consistency before you send them.

Telling the model what not to do, instead of what to do. "Don't be too formal" leaves the model to guess what the acceptable alternative looks like. "Write in a conversational, second-person tone, like you're explaining this to a colleague over coffee" gives it an actual target. Negative constraints are useful as guardrails, but they work far better stacked on top of a positive instruction than used as the entire instruction.

Assuming one great prompt will work forever. Prompts that worked well on one model version can quietly degrade after an update, and prompts tuned for one task rarely transfer cleanly to a different one. Treat prompts you rely on repeatedly the way you'd treat a piece of code you depend on: something to periodically re-test, not something you write once and trust indefinitely.

Skipping context because it feels obvious. What's obvious to you, sitting inside your own head with weeks of background on a project, is invisible to a model that only sees the words in front of it. The context that feels too basic to mention is very often exactly the context that was missing.

Accepting the first answer instead of pushing back. The single biggest gap between casual users and people who get consistently excellent results isn't prompt phrasing — it's that professionals treat the first response as a starting point. They tell the model what was wrong with it, ask it to revise, or restructure the prompt entirely, rather than accepting a mediocre first draft or giving up and doing the task by hand.

Putting It All Together: A Practical Framework

Distilled into something you can actually use the next time you sit down to prompt a model:

State the goal in one clear sentence. What do you actually want as the end result?

Give real context, including the "why." What's this for, who's it for, and what do you already know that the model doesn't?

Specify the format explicitly. Length, structure, tone, and any required sections — don't leave these to chance.

Show, don't just tell, when style matters. If the format or voice is subtle, include one or two examples of what "good" looks like.

Name the failure modes you're worried about. If accuracy on a specific detail matters, say so directly, the way Brockman's "make sure the trail name is correct" example does.

Give it permission to push back or admit uncertainty. Ask it to flag when it's unsure rather than guess confidently.

For anything with real logical steps, ask for reasoning before the answer.

Treat the first draft as a draft. Read the output, notice what's off, and refine — the same way you'd edit a first draft of your own writing, or review a junior colleague's first pass at a task.

The Common Thread

Strip away the specific vocabulary — Anthropic's "minimum necessary structure," Brockman's four-part framework, Karpathy's "context engineering" — and every major voice in this field is really saying the same thing from a different angle: a language model is a powerful but literal-minded collaborator that can only work with what you give it. It has no access to your intentions, only your words and whatever surrounding context you provide. The people who prompt these systems for a living have simply gotten disciplined about making that context as clear, complete, and well-structured as possible, then treating the result as a first draft to refine rather than a verdict to accept.

That's not a secret trick. It's closer to good writing, good delegation, and good editing — three skills that, it turns out, transfer remarkably well to talking with a machine.