Sign in with Google

How to Write Better AI Prompts

Why most prompts fail, five parts that fix them, and rewrites you can copy across any model.

beginner10 min read
ai-toolspromptingai-literacylearning-meta
"Write me a blog post about productivity" will always produce something forgettable, and no model release will change that. The prompt does not say who is reading it, how long it should be, what it should argue, or what would make it good — so the model fills in the most average possible answer to each of those questions, and average is exactly what you get back. Prompting well is not a bag of magic phrases. It is the ordinary discipline of saying what you actually want, and it transfers between every tool you will ever use.
iWhat you need
Any AI chat tool and something real you are trying to produce. Everything here is tool-agnostic — it works the same in ChatGPT, Claude, Gemini, or a coding agent. Bring an actual task rather than practising on made-up ones; the difference between a vague and a specific prompt only becomes obvious when you care about the output.
A model has to resolve every ambiguity you leave behind. It cannot ask a clarifying question unless you invite one, so it guesses — and it guesses toward the statistical middle of everything ever written on the topic. Nearly every disappointing answer traces to one of four gaps.

The four gaps

  1. 1It does not know your situation. Your role, your constraints, what you already tried, what you already know.
  2. 2It does not know your audience. Writing for a CFO and writing for a new hire are different jobs, and "clear and engaging" does not distinguish them.
  3. 3It does not know your standard. What makes an answer good here — brevity, rigour, being funny, being defensible in a review?
  4. 4It does not know the shape you need. A table, three bullets, a JSON object, and eight paragraphs are all valid readings of "tell me about X".
Five parts, and you rarely need all five. Context: the situation and the audience. Task: one clear verb, and what done looks like. Constraints: length, tone, what to avoid, what must be true. Format: the exact shape of the output. Examples: a sample of what good looks like, when describing it is harder than showing it.
Written out, that structure looks bureaucratic. In practice it takes about forty extra seconds and saves three rounds of iteration, which is a trade worth making on anything you plan to use.
text
BEFORE
Write a product update email.

AFTER
Context: We make scheduling software for dental practices.
Readers are office managers, not technical. Many were
annoyed that last month's update changed the calendar view.

Task: Announce that the old calendar view is back as an
option, and that recurring appointments now copy forward.

Constraints: Under 150 words. Lead with the calendar fix.
Acknowledge the disruption once, plainly, without grovelling.
No marketing adjectives.

Format: Subject line, then the email body, then one
sentence I could post in our support forum instead.

A vague writing request, then a specified one

text
BEFORE
My Python script is broken, can you fix it?

AFTER
Python 3.12, pandas 2.2. This function should return one
row per customer with their most recent order date, but
it's dropping customers who have no orders.

[paste the function]
[paste the full traceback or the wrong output]

I need the customers with no orders included, with a null
date. Explain what was wrong in two sentences before
showing the fix, and don't restructure the rest of the file.

The version that gets a runnable answer

text
BEFORE
Is it a good idea to raise our prices?

AFTER
We charge $29/month, 1,200 subscribers, about 3% monthly
churn. Support load is heavy; roughly 40% of tickets come
from the cheapest cohort. We're considering $39 for new
signups only.

Give me: (1) the three strongest arguments for, (2) the
three strongest against, (3) the single number I'd most
want to know before deciding, and why that one.

Don't recommend a decision. Flag anywhere you're inferring
something I didn't tell you.

Turning an opinion request into an answerable one

text
BEFORE
Explain recursion.

AFTER
I can write loops comfortably but recursion doesn't click.
I understand that a function calls itself; I don't have any
intuition for the base case or what the stack is doing.

1. Explain it using one worked example, tracing every call
   and return with the actual values.
2. Then show me the same thing written as a loop, so I can
   see what the recursion is buying.
3. Then ask me three questions that would expose whether
   I actually understood it. Wait for my answers.

The prompt that produces understanding rather than a paragraph

Notice the pattern across all four. None of them are clever. Each one just moves information from your head onto the page, then names the shape of the answer. The learning example goes one step further and puts work back on you, which is the difference between reading an explanation and acquiring a skill.
When the output has any structure at all, two or three examples beat a paragraph of instructions. This is what people mean by few-shot prompting, and it works because you are demonstrating a pattern rather than hoping your description of it lands.
text
Rewrite each raw support note as one neutral line for the
changelog. Match this pattern exactly:

Raw: "customer furious, export button does nothing on
safari, third report today"
Changelog: Fixed export button not responding in Safari.

Raw: "they want dark mode, asked twice, not urgent"
Changelog: Added dark mode.

Now do these twelve:
[paste notes]

Two examples do the work of a spec

Asking for an explicit shape — a table with named columns, numbered steps, valid JSON against a stated schema — also raises quality on its own, and not only because it is easier to read. A shape forces the answer to be committal. "Give me a table of the three options with columns for cost, risk, and time to ship" cannot be answered with waffle; there is nowhere to put it.
The single most reliable upgrade to any prompt is attaching the source. Models are good at reading and unreliable at remembering specifics, so a question about a document should always arrive with the document. Paste the policy, the error output, the schema, the transcript, the three drafts you already rejected.
Then add the escape hatch: "answer only from the text above; if it does not say, write not stated." That one clause removes most of the pressure to invent something plausible to fill a gap, because you have given it a legitimate thing to do instead.
Telling a model to work through the problem before answering genuinely improves multi-step tasks: arithmetic, logic puzzles, debugging, planning something with ordering constraints. Where it helps, it helps a lot, and you can also read the reasoning to spot where it went off.
!It is noise on single-step tasks
"Think step by step" before rewording a sentence or drafting an email adds length and a preamble you have to scroll past. Newer models also reason on their own when a task calls for it. Ask for visible reasoning when you want to audit it, not as a reflex on everything.
When an answer is most of the way there, the instinct is to scrap the prompt and start over. That throws away everything that worked and re-rolls the parts you liked. Say the delta instead: "Keep the structure and the opening. Section 2 is too abstract — replace it with one concrete example from a small business. Leave everything else alone."
Being explicit about what to preserve matters as much as what to change, because otherwise a fix to one section quietly rewrites the rest. Two or three targeted corrections usually converge faster than five fresh attempts.
text
CONTEXT
Who I am / what this is for / who reads it:
What I've already tried or ruled out:

TASK
What I want, as one verb:
What "done" looks like:

CONSTRAINTS
Length:
Must be true:
Must not appear:

FORMAT
Shape of the output:

SOURCE
[paste the actual material]
Answer only from this. If it isn't here, say "not stated."

UNCERTAINTY
If something is ambiguous, list it under "Need your input"
instead of guessing.

Keep this somewhere you can paste it from

You will not fill in every field every time, and that is fine — the value is that skipping one becomes a decision rather than an oversight.
No prompt extracts an answer the model does not have. If it never learned a library's current API, or the fact you need was published last week, or the detail lives only in your company's internal wiki, better phrasing produces a more confident wrong answer rather than a right one. That is precisely why verification is part of the loop and not an optional extra step: check the number, open the link, run the code. Prompting improves your hit rate; it does not remove your obligation to look.

Symptom, cause, fix

  1. 1The answer is bland and could have been written for anyone. No context and no audience. Add your role, the reader, and one real detail about the situation.
  2. 2It is technically correct and useless. You specified the task but not the standard. Say what would make this good, and what would make it fail review.
  3. 3The format is wrong every time. You described the shape instead of showing it. Paste two examples of the exact output you want.
  4. 4It invents specifics — functions, citations, figures. You asked it to recall rather than read. Attach the source and add "answer only from this text".
  5. 5Fixing one section silently changed three others. Your correction did not say what to preserve. Name the parts to leave alone.
  6. 6Long prompts make it worse, not better. Length is not the point; the prompt is probably repetitive or self-contradictory. Cut it to the constraints that actually matter.
  7. 7It refuses or hedges on something reasonable. Often the framing reads as riskier than the request. State the legitimate purpose and the audience plainly.
  8. 8It answered a question you did not ask. Your prompt had two readings. Say which one, rather than repeating yourself louder.
The verification half of the loop is where this pays off or does not, so How to Fact-Check AI Answers is the natural next read. Then apply the craft in a specific tool: How to Use ChatGPT Effectively covers model choice, custom instructions, and using it to study, while How to Use Claude Effectively covers long-document work and persistent project context. If you write code, prompting an agent that edits your files is a stricter version of the same discipline — How to Use Claude Code covers scoping work small and giving it a way to check itself. For the underlying model of what these systems are doing, and therefore why any of this works, the AI Fundamentals roadmap is the place to start.