“Include” Is a Weak Verb

“Include examples.”

“Include data.”

“Include counterarguments.”

“Include a call to action.”

This is how most people try to control an AI. They sprinkle the word include into their prompt as if it were a command with teeth.

It isn’t.

“Include” is polite. It is vague. It signals preference, not priority. When you tell a language model to include something, you are not defining what role that element must play. You are asking it to add an ingredient, not to build a structure.

And so it does what the word invites: it appends.

You get a paragraph. Then a thin example stapled to the bottom. A token statistic. A ceremonial counterargument that exists only to be dismissed. The box is checked. The goal is not accomplished.

The problem is structural. “Include” does not specify weight.

If you say, “Include data,” you have not said whether the data must drive the argument, anchor the claims, or merely decorate the prose. The model cannot read your dissatisfaction. It sees that the requested object appears in the output. Task complete.

Humans do this too. Tell a student to “include evidence” and you will often get a quote dropped into the middle of a paragraph like a brick in wet cement. It is present. It is not integrated.

The word encourages surface compliance.

When you use “include,” you are describing content, not function. You are naming pieces, not defining relationships. You are thinking in ingredients instead of architecture.

Strong prompting is not about adding more elements. It is about assigning force.

Instead of “include examples,” you might demand: “Build the argument around two concrete examples. If the examples are removed, the argument should collapse.” Now the examples are load-bearing. The model must organize around them.

Instead of “include counterarguments,” you could say: “Present the strongest objection in a way that would make a smart critic nod, then respond in a way that materially strengthens the original claim.” Now the counterargument is not decorative. It is adversarial.

Instead of “include data,” you could instruct: “Use specific numbers to constrain the claims. Any general statement must be pinned to measurable detail.” Now data is a constraint, not an accessory.

Notice the difference. The weak prompt lists items. The strong prompt defines consequences.

“Include” also fails because it does not define proportion. If you ask for an essay that “includes history, examples, and practical advice,” you have not said how much of each. The model must guess. It will usually distribute attention evenly and safely. The result feels balanced and thin.

You did not ask for balance. You asked for inclusion.

There is a deeper issue here. People use “include” when they are unsure what they really want. It is a hedge word. It keeps options open. It avoids committing to a hierarchy.

But language models respond best to hierarchy.

What matters most?
What supports what?
What can be cut without damage?
What must dominate?

“Include” answers none of these questions. It is a shopping list in a context that requires a blueprint.

If your output feels like a collection of parts rather than a unified piece, look at your prompt. If it reads like a checklist of things to include, that is why. You asked for accumulation, not integration.

High-level operators rarely rely on “include.” They define roles, stakes, and failure conditions. They specify what the output must accomplish, not merely what it must contain. They describe what would make the result unacceptable.

That is pressure.

“Include” has no pressure behind it. It cannot threaten the structure. It cannot demand cohesion. It cannot signal that something is essential rather than optional.

So the model treats it as optional in spirit, even if it is mandatory in form.

If you want stronger outputs, stop asking for ingredients.

Start defining load-bearing elements.

“Include” will give you presence.

It will not give you power.