The Model Can’t Read Your Mind

When you send a prompt, there isn’t a mind on the other side trying to figure out what you really meant.

The model generates the most likely continuation of the text you gave it. It won’t magically fill in the gaps with your intent. Every important detail you leave out has to be inferred from patterns in the training data.

And those patterns reflect what is typical, not necessarily what you had in mind.

That’s why vague prompts tend to produce vague answers. The most likely answer to a generic question is usually a generic answer.

Reasoning models are noticeably better at handling underspecified prompts. Before answering, they can consider several possible interpretations and break the problem into smaller steps.

But the fundamental problem doesn’t disappear; it just becomes more expensive.

The model still doesn’t know what you intended. It simply spends more effort identifying the most likely interpretation. Every missing piece of context means additional tokens spent trying to infer what you meant.

There’s a simple test you can use to evaluate almost any prompt:

If I gave exactly these instructions to someone who started working at Polcode this morning, would they be able to complete the task the way I expect?

If the answer is no, the model probably needs more context too.

Why “You Are an Expert” Isn’t a Magic Trick

One of the most common patterns in examples of supposedly “good” prompts is assigning the model a role:

You are a senior developer.

You are an experienced security auditor.

You are an expert copywriter.

This technique can influence the output, but not quite in the way people often assume, and its effect is much weaker than prompt-engineering folklore would suggest.

A study published in Findings of EMNLP 2024 tested 162 personas across four families of open models and 2,410 factual questions. Adding a persona to the system prompt did not improve accuracy compared with using no role at all. Even selecting the supposedly best persona for a particular question performed no better than choosing one at random.

Research published in 2025 and 2026 points in a similar direction. A relevant expert persona often produces either no measurable improvement or only a modest one. At the same time, seemingly irrelevant details added to a role description can reduce performance by nearly 30 percentage points.

So what does a role actually do?

It can steer the model toward a particular vocabulary, style, level of detail, or professional convention. Asking for a “senior developer” may make the answer sound more like something a senior developer would write.

But sounding more expert is not the same as being more correct.

In some cases, personas add industry jargon and apparent expert depth while making the answer less clear, without improving its factual quality.

Instead of relying on:

“You are an expert.”

tell the model what expert performance actually looks like for this specific task.

The Six Ingredients of a Good Prompt

A practical prompt structure that consistently produces useful results consists of six elements:

1. Context — the project, situation, and relevant data.

2. Task and expected outcome — what needs to be done, for whom, and what success looks like.

3. Rules — preferably phrased as positive instructions: do X; when Y happens, do Z.

4. Examples — one strong example can replace an entire paragraph of explanation.

5. Output format — the expected structure, length, and form of the answer.

6. Fallback behavior — what the model should do when information is missing or uncertain.

The important part is that these elements reduce ambiguity.

You are not trying to find a magical combination of words that “unlocks” the model. You are giving it enough information to make the behavior you want more likely.

From a Vague Request to an Actionable Prompt

Here’s an example: a prompt for reviewing the security and quality of a pull request.

Instead of writing:

“You are a senior security engineer. Review this PR.”

we can describe the task explicitly.

Context

E-commerce project: PHP 8.3, Symfony 7, MySQL.

The diff below adds an endpoint for changing the delivery address of an order that has already been placed. The diff is included at the end of the message.

Task

Analyze the diff for security and code quality.

Check, in this order:

• access control — can users modify only their own orders?

• input validation,

• error handling,

• consistency with the service layer.

Audience and Goal

The result will be posted as a PR comment for a mid-level developer.

The developer should be able to fix every reported issue without asking follow-up questions. Every finding therefore needs to include the file, line number, and a concrete proposed change.

Success Criteria

The review is complete when every finding contains:

• severity: critical, important, or cosmetic,

• location,

• a description of the problem in no more than two sentences,

• a concrete proposed fix.

Rules

Evaluate only the code visible in the diff. Treat the architecture of the rest of the project as given.

If you suspect a problem but don’t have enough context to confirm it — for example, because a class definition isn’t included — label the finding “TO VERIFY” and briefly explain what needs to be checked instead of guessing.

If there are no critical or important issues, say so in one sentence.

Only report issues supported by the code or clearly identify them as requiring verification.

Output Format

List findings from highest to lowest severity.

Then add a “To Verify” section.

Finish with one sentence stating whether the PR is ready to merge.

Example Finding

[CRITICAL] src/Controller/OrderController.php:42

The endpoint does not verify whether the authenticated user owns the order. As a result, a user could change another customer’s delivery address by providing that order’s ID.

Proposed fix: before modifying the order, call:

$this->denyAccessUnlessGranted('ORDER_EDIT', $order);

Notice what’s missing from this prompt: a long description of who the model is supposed to pretend to be.

Instead, the prompt describes what good work looks like.

The “Pink Elephant” Problem

There’s another common prompt-engineering habit worth examining: long lists of DO NOT instructions.

This introduces a problem sometimes described as the pink elephant problem.

Tell someone:

“Don’t think about a pink elephant.”

And what appears in their mind?

A pink elephant.

Something similar can happen with language models. Research suggests that model representations and attention mechanisms do not always handle negation in the intuitive way humans expect. The concept you explicitly introduce into the context can remain strongly activated even when the instruction says to avoid it.

In other words, mentioning an unwanted behavior may sometimes make that behavior more salient.

A forbidden concept introduced into the prompt can become a strong prior rather than simply disappearing because it was preceded by “don’t.”

Prefer Positive Instructions

Does that mean you should never use negation?

No.

Modern models are significantly better at following negative constraints than models from a few years ago, and explicit prohibitions are sometimes necessary.

But whenever possible, pair a prohibition with the behavior you actually want.

Instead of:

“Don’t make assumptions.”

write:

“When information is missing, identify what is missing and ask for clarification.”

Instead of:

“Don’t write long explanations.”

write:

“Keep each explanation to a maximum of two sentences.”

Instead of:

“Don’t invent security issues.”

write:

“Report issues supported by the code. Put uncertain findings in a separate ‘To Verify’ section and explain what additional context is needed.”

The difference is simple but important.

A prohibition tells the model which path not to take.

A positive instruction gives it another path to follow.

Prompt Engineering Is Mostly Context Engineering

The most useful shift in thinking is to stop treating prompts as magic spells.

There is rarely one perfect phrase that suddenly makes a model dramatically smarter.

Good prompting is much closer to good delegation.

Give the model the context it needs. Define the task. Explain what a successful result looks like. Provide constraints where they matter. Show an example when the expected output is difficult to describe. And tell the model what to do when it encounters uncertainty.

Before sending a prompt, ask yourself:

Could a capable person who knows nothing about this task beyond what I’ve written execute it correctly?

If not, add the missing context.

That will usually improve the result far more than adding another sentence beginning with:

“You are a world-class expert in…”

Sources

• Zheng et al., When “A Helpful Assistant” Is Not Really Helpful (Findings of EMNLP 2024): https://aclanthology.org/2024.findings-emnlp.888/

• Luz de Araujo et al., Principled Personas (EMNLP 2025): https://aclanthology.org/2025.emnlp-main.1364/

• Xiao et al., When Does Persona Prompting Actually Help? (2026): https://arxiv.org/abs/2605.29420

• Do not think about pink elephant! (2024): https://arxiv.org/abs/2404.15154

• Anthropic, Prompt Engineering Overview: https://docs.claude.com/en/docs/build-with-claude/prompt-engineering/overview