How Much Detail Should an AI Prompt Have?

Specify the constraints and the output shape. Do not specify the method. That one rule resolves most of the question, because the detail that helps is detail about what a correct answer must satisfy, and the detail that hurts is detail about how to get there.

Vague prompts and over-specified prompts both fail, and they fail in opposite directions. Knowing which one you are looking at tells you what to do next, and most people reach for "add more detail" in both cases.

The two failure signatures

Under-specified produces an answer that is fine in general and wrong for you. It hedges. It covers cases you do not have. It picks a plausible interpretation of an ambiguous request and does not mention that it chose. The tell is that the output would be equally reasonable for someone else's version of your problem.

Over-specified produces an answer that follows every instruction and misses the point. It applies your step four even where step four is clearly wrong. It stops at exactly the scope you drew, including the part just past the line that obviously needed doing. The tell is that it did what you said rather than what you wanted, and you can point at the line that caused it.

These need opposite fixes. Adding detail to an over-specified prompt makes it worse, which is why "my prompt is very detailed and still not working" is such a common complaint.

What detail helps

Four kinds earn their tokens.

Constraints on the output. Length, format, what must be included, what is out of bounds. "Under 200 words, no bullet points, aimed at someone who has not read the previous email" is all useful, and none of it tells the model how to write.

Context it cannot infer. Who the audience is, what was decided last week, why the obvious approach is off the table. This is the most under-supplied category by a wide margin.

Concrete examples of the target. One good example of the output you want does more than three paragraphs describing it. This is the highest-value-per-token detail available.

Definitions of ambiguous terms. If "customer" in your business means something specific, say so.

What detail hurts

Three kinds cost you.

Step-by-step method for a task the model already knows. Prescribing how to structure a summary removes the model's ability to notice that this particular document needs a different structure. You have traded judgment for compliance, and on easy tasks that is a fine trade. On tasks where the right approach depends on the input, it is a bad one.

Defensive instructions for failures you have not seen. Every "do not forget to" and "make sure you also" is a rule the model now weighs against everything else. A prompt accumulating twelve of these over months is carrying eleven rules for problems that occurred once.

Long preambles about why the task matters. This is throat-clearing that competes for attention with the actual instruction.

The test

When you are unsure whether a piece of detail is helping, delete it and run the prompt five times on real inputs.

If the output is the same quality, the detail was doing nothing and costing tokens. If it degrades on all five, keep it. If it degrades on one of five, you have found a rule that handles a rare case, and the honest question is whether catching that case is worth constraining the other four.

This is a small experiment that almost nobody runs, and it is the only way to know. Prompts accumulate rules because adding one feels free. Deleting one feels risky. The test is how you make deletion cheap.

A worked comparison

Suppose you want a summary of a customer support thread.

Too vague:

Summarize this support thread.

Gets you a chronological retelling with no view on what matters.

Too specific:

Summarize this support thread. Start with the customer name and
account tier. Then list each message in order with the sender and
a one-line summary. Then state the current status. Then list three
possible next actions. Use exactly four sections with those headings.
Keep each section under 50 words. Do not speculate.

Gets you exactly that, including a chronological message list for a thread where only the last two messages matter, three next actions where there is obviously one, and a refusal to note the pattern you actually needed flagged.

About right:

Summarize this support thread for a manager who has not seen it
and has two minutes.

They need to know: what the customer wants, what we have committed
to so far, and what is currently blocking resolution.

If anything in the thread suggests this is a repeat of an earlier
issue, say so. If the customer has stated a deadline, lead with it.

Under 150 words, prose not bullets.

The third one specifies the reader, the decision the summary supports, two things worth surfacing, and a shape. It does not specify structure or order, so the model can put the deadline first when there is one and skip it when there is not.

When more detail genuinely is the answer

Sometimes over-specification is correct, and it is worth naming when.

If the output feeds a program that expects an exact format, specify the format exhaustively. If you need the same shape across a thousand runs, consistency beats per-case judgment. If compliance matters more than quality, such as a document that must contain specific clauses, prescribe it.

The pattern: the more your output is consumed by a machine or a process rather than read by a person, the more specification helps. Structured output constraints are the extreme end of this and are the right tool there.

If it used to work and stopped

That is a different problem with a different diagnosis, usually a model change or an input that drifted outside what the prompt assumed. Debugging a prompt that stopped working covers it. Adding detail is the wrong first move there too.

And if the model is following some of your instructions and ignoring others, the issue is usually attention rather than volume. Why AI ignores parts of your prompt has the mechanics, and the fix is often structuring the prompt with clear delimiters rather than saying it again more emphatically.

More on the general approach in our guide to prompt engineering.

FAQ

Is a longer prompt always better?

No. Detail about constraints and context helps. Detail about method removes the model's judgment, which hurts on any task where the right approach depends on the input.

How do I know if my prompt is over-specified?

The output follows your instructions and misses the point, and you can point at the specific line that caused it. Under-specified output, by contrast, is generic rather than wrong.

Should I tell the model not to do things?

Sparingly. Each negative instruction is a rule competing with the others. If you have more than two or three, check whether they are guarding against failures you have actually seen recently.

What is the highest-value thing to add to a weak prompt?

One example of the output you want. It communicates tone, structure and depth in fewer tokens than any description of those things, and it is harder to misread.