222 of our 3,470 prompts to an AI agent were one word

The word we typed most to our AI coding agent this autumn was “status”. Sixty-one times, as the whole message, in 41 different sessions.

The second most common was “done”, 46 times. Third was “yes”, 23 times. When we sorted these short replies by what had just happened in the session, they turned out to be three different things. One of them is the best part of our setup. The other two are leaks.

Half our prompts are twelve words or fewer

We count our own sessions every few weeks, as we did for the 20.5 hours spent watching CI. This time we counted everything still on disk: 631 Claude Code sessions between 18 September and 12 November, and the 3,470 prompts Mark typed or pasted into them. Claude Code deletes transcripts after 30 days, so nearly all of it is October and November. The count ignores what the agent said, what tools returned and any scheduled runs. It only reads our side.

The median prompt is 67 characters, or 12 words. One in five is under 20 characters. At the other end, 7.2% are over 1,000 characters, and those are the long briefs that run for hours without us. Our count on 4 November gave a median of 71, so the number is stable.

The shape matters more than the median. The first prompt of a session has a median of 221 characters. Every prompt after that has a median of 52. We open with a sentence or two and then steer in a few words. That works because the context is not in the prompt. It is in the repo: the agent rules file, the task file and a handover note. A prompt is a steering input. The specification is somewhere else.

The three kinds of one-word reply

Exactly 222 prompts, 6.4%, were a single word, and 660 were three words or fewer. Three families account for 196 of the short ones.

The handshake (76). “done” 46 times, “signed in” or “i signed in” 19, “copied” 7, “uploaded” 4. The agent had reached a step only a person can do: sign in to a console, tick a policy box, drag a file into an upload dialog. In 65 of the 76, the agent’s last message named exactly that step (a rough text match, so treat it as a floor). Our rules say a turn that ends on a wait must end with one line, Waiting on <step> · resumes when <event> · then <next action>, and a one-word reply hands control back. This is the loop working as designed. We do not want fewer of these. We want each one to need less from us, which means the agent writing the click path out in full.

The status poll (74). “status” 61 times and “whats next” 13. These are bugs. The agent ended its turn on a wait, usually a pull request merging or a deploy queued, and nothing on screen said what was pending or for how long. We added the wait line above on 2 November for exactly this. The rate dipped the week after, then climbed again.

We do not know why, and a count this small proves little. A likely cause is more sessions running in parallel, so more waits to lose track of. On 10 November we went further and made every session report its state to a task board, so nobody has to ask. Since then there have been 3 status polls in 111 prompts. That is too early to call.

The permission (46). “yes” 23 times, “go” 8, “do it” 7, “do it for me” 5, and three others. Only 20 of the 46 came straight after a message ending in a question or an offer. The rest followed statements such as “this isn’t released yet”, which the person then answered with an instruction. Some of these are legitimate: a few actions are reserved for a person on purpose, such as uploading an iOS beta build or changing what a site promises about tracking. Most are not. Our agent rules record that in the 21 days to 10 November, 152 turns ended on a question or an offer and waited about 103 hours between them. A bare “yes” costs a person three seconds. It costs the work however long that person was away.

Long briefs finish alone more often

The first prompt predicts something. We grouped sessions by how long the opening prompt was and counted how many finished on that one prompt, with no follow-up at all.

This is a pattern, not a controlled test. The long group includes pasted alerts and one-shot jobs that were never going to need a second message, and sessions under 20 characters were too few (16) to compare. Once a session did continue, the median was three follow-ups in every group. A long brief does not shrink the conversation. It raises the odds that there is none.

Our guess, which we have not tested, is that the middle band is the worst because a paragraph that explains how to do the work invites a second paragraph correcting it. The long briefs that finish alone are mostly a short list of rules followed by an ordered list of outcomes, each ending in “done when” and something we can check. Anything left over becomes a task file, as we describe in tickets as files.

Count yours in a minute

The quick route is our prompt reviewer. Paste a prompt and it checks it against what this count found, shows the number behind each suggestion and rewrites it. It runs in your browser, so nothing you paste leaves the page, and the first thing it looks for is a pasted key or password, which is the problem behind our guard hooks.

To count your own history instead, Claude Code keeps its transcripts as JSON lines under ~/.claude/projects. This prints your most common short prompts. It is rougher than our script, because it does not strip hook messages, but the top of the list will tell you the same story.

jq -r 'select(.type=="user" and .isSidechain!=true and .isMeta!=true and ((.message.content|type)=="string"))
  | .message.content | ascii_downcase | select(length<=12)' \
  ~/.claude/projects/*/*.jsonl | sort | uniq -c | sort -rn | head -15

If “status” is in your top three, your agents are ending turns without saying what they are waiting on. That is a one-line rule, and it is worth writing before you write anything else.