Requests Grew from 19 to 71 Characters: What Was Added── The added length was a definition of done and an order of work the AI could not see, and writing those two down is what makes a request workable

01Requests grew because they began to carry a definition of done and an order of work

In the operator's recorded exchanges with Claude, which begin in February 2026, the median length of a request changed from month to month. Measured in Japanese characters, it was 19 in February, 25 in March, 35 in April, 18 in July and 71 in September. Across the record, the longest tenth of requests reached 275 characters.

Read on their own, the numbers suggest the requests simply became politer or wordier. The long September requests show something more specific. A single request now set out a definition of what the finished result should be, then a design, then the program that would carry it out, in that order.

The conclusion of this piece is short. Length has no value of its own. A request becomes something an AI can act on to the extent that it supplies what the AI cannot see from inside the conversation: the conditions for being finished and the order in which to work. Before sending a request, check that both are there.

02A short command names one task; a full request names a job from start to finish

In March the record shows a request that handed work to another AI with a one-line instruction to carry out what followed, leaving everything else to pasted text. The command was little more than a verb. Nothing said what had to be true for the work to count as done.

The long September requests look different. One asked for a system that would publish three articles every morning at a fixed time, in Japanese and English. It said to have the writing agent first record the house rules for past articles, then to build the delivery system, and finally to publish automatically. The finished state, the decisions to settle first, and the build order all sat in one continuous request.

The July median fell to 18. Many of the July requests in the record are short steering messages inside work already under way, saying only which step to take next. When the background is already in the conversation, a short message is enough. Length tracks how much new information the AI needs, not how carefully the person writes.

03Conditions left out are filled by the AI's guesses, and each guess can cost a round of fixes

An AI fills in whatever the request leaves out and starts work anyway. Anthropic's prompting guidance asks users to treat Claude as a brilliant but new employee who lacks context on the team's norms and workflows. The more precisely you explain what you want, it says, the better the result.

The same guidance offers a simple test. Show the prompt to a colleague who knows little about the task and ask whether they could follow it. If they would be confused, Claude will be too.

Anthropic's best practices for Claude Code tie this directly to rework. Name the file, describe the symptom and say up front what fixed looks like, and you usually save a round of corrections. The page also notes that Claude tends to read a request conservatively and build the smallest thing that satisfies it, because it cannot see how much the person was hoping for.

A short command is not wrong. It moves the decisions from the moment of writing to the moment of reviewing the output. Whatever is postponed comes back as rework.

04A request needs four parts: purpose, definition of done, order of work and limits

Sorting what the long September requests added gives four parts.

Other vendors list much the same parts. Microsoft's introduction to Copilot prompts names four elements: goal, context, source and expectations. It adds that only a clear goal is essential and the rest add specificity. Google's prompt design guidance for Gemini recommends clear and specific instructions, the information the model needs to solve the problem, and any constraints on the response.

There is also a boundary. Longer is not better. A 275-character request can still leave the AI guessing if one of the parts is missing. And the Claude Code guidance says a vague prompt is fine when you are exploring rather than fixing something specific, as long as you accept more correction along the way. The four parts matter when you want a usable result the first time.

One limit on the evidence: the summary of the record does not say how pasted material was counted. The medians are best read as a rough picture of what the person typed.

05In material review, an AI first read needs a written definition of a finding

Teams in pharmaceutical material review and medical affairs increasingly ask AI to pre-read promotional materials. Ask it in one line to review a piece, and it tends to return something close to general copy-editing. It may catch typos and awkward sentences while missing the checks that matter in review, such as whether claims stay inside the approved indications or whether a comparison is presented fairly.

The right-hand request runs to a few sentences, several times the September median. Yet every line in it is a condition only the reviewer knows. With it, the AI no longer has to guess what a finished answer looks like.

A second benefit is that the request contains its own check. If the definition names the columns, any row that comes back with an empty basis column is flagged for a closer look by that fact alone. The reviewer still makes the final judgment and owns it.

06The larger the unit of work handed over, the more the AI cannot decide alone

Behind the longer requests is a change in what was being handed over. A request to fix one error carries few decisions, and whether it worked is easy to see. A request for a whole daily publishing system carries many more: how articles are written, how many, in which languages, when they go out, and in what order the parts are built.

Few of those decisions can be made correctly from what the AI has on hand. Who reads the site, where the house rules live and which language goes first exist only in the person's head. Left unwritten, they are filled with a cautious guess or a plausible default.

This is why the September requests began to spell out definition, design and build in that order. Once the rules are set, design and build can use them as material. Without a stated order, the AI may start by building and later rework whatever does not fit the rules.

In short, request length grows with the size of the job. Hand over a larger job with the same short request, and the gap is filled by guesses.

07From tomorrow, reread each request against the four parts before sending it

Four steps are enough.

1. State the purpose in one sentence. Say what the work is for, not only what to do.
2. Write the definition of done. List the number, form, timing and rules. If you want a table, name the columns.
3. Write the order of work. Set the rules, then design, then build, and say that each stage should use the result of the one before.
4. Read it as a colleague who knows nothing of the task. Ask whether they could act on this text alone, and add whatever would make them hesitate.

If you cannot yet write the definition of done, you do not have to force it. The Claude Code guidance describes asking Claude to interview you until it could write the spec, then having it write the spec down. Build the definition with the AI, then put it at the top of the next request.