01Most of the 14 vague requests became measurable within one or two turns

Count the operator's exchanges with Claude in the record that runs from February to September 2026, and 14 requests contain what this article calls vague words. A vague word is one that tells the AI something feels wrong but gives no line between pass and fail: "somehow", "more", "cooler", "wordy", "I don't get it".

Most of those 14 requests did not stay vague. Within the next one or two turns, they were restated either as a measurable attribute or as a structure with a fixed order and count. Not all of them were. But where the restatement happened, the thing the AI had to change was settled in words.

This article lists those restatements. The conclusion has three parts. A vague word is fine in the first message. In the second message, say which thing must change into which value for the result to pass. And the target almost always falls into one of two kinds: an attribute or a structure.

02Vague words end up as either a measurable attribute or a fixed structure

The table sets the vague words from the record beside the requests that replaced them. The left column is the first wording, the middle column is the restated request, and the right column is the kind of target.

First wordingRestated requestKind of target
Make the English site's font "cooler"The letters sit too far apart; use a tighter typefaceAttribute (letter spacing)
The portal title is "a bit big"Make the title text smallerAttribute (size)
Narration that only reads the slides is "pointless"For each slide, explain why it matters and what it means in concrete termsStructure (order of explanation)
A report or page "I don't understand"Write so that 90 out of 100 readers understandAttribute (reader level as a number)
Symbols and coined words a first-time reader "can't follow"Leave none that a first-time reader cannot readAttribute (allowed count set to zero)
A draft that is "wordy" and takes "too long" to reach AIOpen with the question, then its meaning, seven sections in order, three key points, a conclusion, three diagramsStructure (order and count)

An attribute is a property settled by a single value: letter spacing, text size, the share of readers who understand, the number of unexplained symbols left. A structure is the order and number of parts: which point comes first, how many sections there are, how many key points are listed.

Figure 1 From a vague word to a request
Ask with avague wordcooler, wordy,unclearAI returns afirst draftPoint to onedifferenceAttributeor…A measurablerequestvalue, share,order, countAsk with a vague wordcooler, wordy, unclearAI returns a first draftPoint to one differenceAttribute orstructure?A measurable requestvalue, share, order, count
In the record, most of these restatements happened within the next one or two turns.

03Left vague, a request makes the AI guess, and the fixes go back and forth

A vague word describes the reaction of the person who says it. "Cooler" is not a property of a typeface. It is how someone felt when looking at one. The AI can change the typeface. It cannot change the feeling directly.

So an AI that receives only a vague word has to guess which property to change. In the September example, when the request said only that the English font should look cooler, nothing fixed whether the change was to the typeface family, the weight or the spacing. The next message said the letters sat too far apart, and the property to change narrowed to one.

Each wrong guess adds a round: read the result, find the problem, say it again. The number of rounds grows with every turn in which the vague word goes unreplaced.

Writing guides for technical requirements warn against the same thing. NASA's guide to writing a good requirement asks writers to avoid terms that cannot be verified, such as "easy", "sufficient" and "adequate", and to check that a means exists to measure whether the requirement is met. Anthropic's guide to defining success criteria makes the same point for AI work: instead of "good performance", state the target with numbers or a consistent scale.

04A vague word is an evaluation the receiver cannot turn into pass or fail

For this article, the scope is fixed. A vague word expresses a judgement, but the person or AI receiving it cannot decide from that word alone whether a result passes. "Somehow", "more", "a bit", "taste", "wordy" and "I don't get it" are typical.

A vague word is not a bad word. It is the fastest signal that something is off. The trouble starts only when it is still a signal in the next message.

In the record, the replacements fell roughly into four forms.

1

Visual attribute

Pick one value

Letter spacing, text size, line length. Turn "too wide" or "too big" into a direction and an amount.

2

Reader level

State a share

Turn "I don't get it" into how many readers out of 100 should understand.

3

Allowed count

Set a ceiling

How many unexplained symbols or coined words may remain. Usually zero.

4

Order and count

Fix the sequence

Turn "wordy" or "too far" into what comes first and how many sections or points there are.

Some cases fall outside this scope. When the AI uses a term you do not know, such as a technical word for a type of contract or processing, that is not a vague word on your side. It calls for asking the meaning, not for restating the request.

05In promotional material review, "too strong" and "unclear" can be handed to AI once they are made measurable

Vague words are common in pharmaceutical material review too: "the wording is too strong", "this is hard to follow", "efficacy and safety are out of balance". Between reviewers who share years of experience, these sometimes work. With an AI, they do not.

If you ask an AI to pre-read or redraft material, restate the comment as an attribute or a structure. "Too strong" becomes: which adjective or adverb in which sentence goes beyond what the package insert or the trial results support. "Out of balance" becomes: place the safety information on the same page as the efficacy claims, at the same text size. "Hard to follow" becomes: who the intended reader is, and what share of them should understand.

The restated comment also works between reviewers. Because the reason for the change is recorded in measurable form, it is easier to explain to the author when the material goes back for revision.

06A sense that something is off only becomes words once there is something to compare, so the restatement comes second

That the restatements came in the next one or two turns has a plain explanation. At the first request there is nothing to compare against. The discomfort is only a sense that something is not right.

Once the AI returns a first draft, there is an object to compare: a screen of text, a finished draft, a narration track. Only then can someone say exactly what differs, for example that the letters are too far apart or the opening runs too long.

Figure 2 The fork at the second message
The first draft stillfeels offRepeat the vague wordmake it coolerName an attributetighten the letter spacingName a structurequestion first, three keypointsThe first draft still feels offRepeat the vague wordmake it coolerName an attributetighten the letter spacingName a structurequestion first, three key points
Repeating the word adds guesses and rounds. Naming an attribute or a structure settles the property to change.

So there is no need to remove vague words before the first message. Holding back a request until the discomfort can be named is slower than sending it vague, getting a first draft, and naming the difference against it. The rule is narrower: do not repeat the vague word in the second message. Saying "cooler" twice only gives the AI more to guess.

Anthropic's prompting guide suggests showing a prompt to a colleague with little context on the task; if the colleague would be confused, the AI will be too. Write the second message so that colleague would not be confused.

07From tomorrow, use the second message to say which thing must change into which value

There are four steps.

  1. Send the first request with the vague word in it. Do not wait until you can name the discomfort.
  2. Compare the first draft and point to one difference. Name the place on the screen or the paragraph in the draft.
  3. Choose attribute or structure. For an attribute, give a value or a share. For a structure, give an order or a count. Put it as: change this into that, and it passes.
  4. Write down the pairing. Keep a list of your own vague words and where they went, such as "cooler: tighten the letter spacing". Next time you can use the measurable form in the first message.

If you cannot restate it yourself, ask the AI to help: list the unclear words in this request and give two measurable alternatives for each. Candidates for attributes and structures come back. Choosing among them stays with you.

Figure 3 Building your own list of restatements
Send it vagueCompare and point toone thingChange thisinto thatAdd the pairing tothe listSend it vagueCompare and pointto one thingChange thisinto thatAdd the pairing tothe list
Pairings on the list can be used in the first message of the next request.
Key Points ── 3 to take away
  1. In the record, most of the 14 requests containing vague words became, within one or two turns, a measurable attribute or a structure with fixed order and count.
  2. A vague word describes the speaker's reaction, so the AI has to guess the property to change. Every turn without a restatement adds a round of fixes.
  3. Start vague if you need to. Compare the first draft, point to one difference, say in the second message which thing must change into which value, and keep the pairing in a list.
Closing

Episodes 1 to 9 of this series each covered one replacement: letter spacing, the order of sections, reader level, the meaning of a term. Laid side by side, the 14 cases share one shape. The discomfort comes out in the first message, gets compared against the AI's draft, and is restated as an attribute or a structure in the next. Putting things into words does not mean never using vague words. It means not carrying them into the second message.

Sources & references
  1. NASA. Appendix C: How to Write a Good Requirement. NASA Systems Engineering Handbook. https://www.nasa.gov/reference/appendix-c-how-to-write-a-good-requirement/
  2. Anthropic. Define success criteria and build evaluations. Claude Developer Platform Docs. https://platform.claude.com/docs/en/test-and-evaluate/define-success
  3. Anthropic. Prompting best practices. Claude Developer Platform Docs. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
What this episode is based on The operator's own record of requests to and decisions with Claude since February 2026 (the operator has used generative AI since March 2023), anonymised and generalised into a pattern. No messages are quoted. The sources listed are public material used to check the background of the pattern.