Writing

Don't Tell Your AI to Always Keep It Short

Clear writing rules can make an agent easier to work with. Hard global limits can also reduce the quality of the work that happens before the answer.

Hundreds of posts now promise to make AI agents easier to read. The advice comes in several forms:

“Save in memory to always use ASD-STE100 Simplified Technical English when you talk to me.”
Tell the model to use the Minto Pyramid Principle.
Ask for “Google developer documentation voice.”
“Switch to Codex” or another model with a different default style.
Install one of the countless custom skills built to remove verbosity and AI-sounding prose.

X post recommending that Claude always use ASD-STE100 Simplified Technical English

X post recommending ASD-STE100 and William Zinsser's writing principles as global Claude instructions

X post recommending the Minto Pyramid Principle for LLM responses

Examples of the advice circulating on X.

Load one of these writing rules before the task begins, and it can shape more than the answer you read at the end.

A writing preference becomes part of the work

ASD-STE100 Simplified Technical English is a controlled language developed for clear, unambiguous aircraft maintenance documents, especially for readers who do not speak English as a first language. Its official FAQ says it was designed for technical documentation rather than general-purpose writing.

The Minto Pyramid Principle puts the conclusion first and groups the supporting ideas underneath it.

An LLM processes input tokens and generates output tokens throughout the task. It produces plans, tool calls, intermediate summaries, and the final answer through that same process. A writing rule present from the start can influence the work, not only how the final handoff sounds.

The context window holds the instructions and information available to the model during a task. Depending on the product, that can include the conversation, system instructions, project files, tool results, and persistent memory. Anthropic’s Claude Code documentation describes CLAUDE.md instructions and auto memory as part of that context, and its memory documentation says those files load at the start of every session. Saving “always write this way” there puts the rule beside the evidence and instructions the agent uses to do the task.

A clean answer can arrive too early

Complex work is often messy before it becomes clear. During a difficult investigation, you want the agent to notice the odd log entry, keep two possible explanations alive, record the failed attempt, and admit when the evidence conflicts. Some of those details will disappear from the final answer. They still matter while the work is underway.

An always-on instruction to be brief, lead with the conclusion, and strip away secondary detail may encourage the agent to impose a clean structure before it has earned one. That can mean:

Settling on the first plausible explanation
Dropping observations that do not fit the emerging story
Making uncertainty less visible
Exploring fewer alternatives because they appear secondary
Summarizing evidence so aggressively that useful details no longer remain in context

Consider an agent investigating a failed file upload. It finds an authorization error, a credential setting, and evidence that the main request succeeded before the attachment failed. A thorough investigation keeps those facts separate and checks several possible failure points. A rushed summary can turn them into a confident diagnosis: “The credentials are invalid. Replace them and retry.” That answer is wonderfully clear. It may also be wrong, and retrying may create a duplicate request.

We cannot reliably inspect a model’s private reasoning, and different products may apply style instructions differently. Judge observable actions and task results instead.

The tradeoff has been measured

The viral advice treats verbosity as a cosmetic defect. Anthropic’s account suggests it can be tied to capability. When the company introduced Opus 4.7, it noted that the model “tends to be quite verbose.” Its next sentence was the important one:

“This makes it smarter on hard problems.”

Anthropic still wanted to reduce unnecessary output. On April 16, 2026, it added a hard limit to the Claude Code system prompt: 25 words between tool calls and 100 words in the final response unless the task required more detail. Its initial evaluations found no regression. Broader ablations later found a 3% drop on one coding evaluation for both Opus 4.6 and 4.7. Anthropic reverted the prompt four days after release.

That does not prove that every long response is necessary, or that every brevity prompt will cause a 3% decline. It does show that writing style and work quality are not independent. Some of the verbosity people dislike may be entangled with the behavior that makes the agent good at difficult work.

Brevity can work when the constraint fits the task. A study of 12 language models across five datasets reduced response length enough to save 25–60% of inference energy while preserving response quality. A Chain of Draft study on 300 SWE-bench tasks used 55.4% of the tokens of full chain-of-thought prompting while retaining more than 90% of its code-quality scores.

In a TechLoom benchmark, asking for brief docstrings saved about 13% of output tokens without a statistically significant quality change. Removing docstrings entirely lowered the composite score by 2.27 points.

Benchmark chart: Brief docstrings scored 0.32 points below the bare prompt, not statistically significant, while saving about 13 percent of output tokens. No docstrings scored 2.27 points below the bare prompt, a statistically significant loss. Verbose docstrings scored 0.36 points above the bare prompt while using about 29 percent more output tokens.

Redrawn from TechLoom’s targeted-constraints benchmark. Composite scores combine static analysis with an LLM judge and should be compared only within this experiment.

The effect changes with the model, the task, and the severity of the constraint. Hard global limits can reduce the quality of complex agent work even when they make the conversation easier to read.

Run the test

Give the same model a set of complex debugging, research, and implementation tasks under four conditions:

No special writing instruction.
A hard length limit loaded before the work begins.
A soft clarity instruction loaded before the work begins, with permission to expand when the task requires it.
The same clarity instruction applied only after the work is complete.

Run each task more than once, because model outputs vary. Keep the model version, tools, starting context, and task rubric the same. Then grade the results without telling the reviewer which prompt produced them.

Start with correctness. Then count missed requirements, unsupported conclusions, edge cases found, evidence gathered, unnecessary tool calls, human corrections, and time spent reading the final response.

My expectation is that the fourth condition will produce the best balance of thorough work and a readable handoff. Test your exact prompt before putting it in context at the start of complex work.

Put the writing rule at the end

Treat the writing style as post-processing. Let the agent finish the work, then rewrite the response for clarity. A skill, command, or saved prompt can make that second pass convenient.

Some agents choose skills from their names and descriptions, so a broadly described skill may load during the original work even when its instructions say “manual only.” Use a true manual-only setting when the product offers one. If automatic selection cannot be disabled, store the rewrite prompt as a command or snippet outside the agent’s skill set.

The manual rewrite skill needs one instruction:

Use this skill only when the user explicitly invokes it to rewrite an existing response. Do not use it during research, planning, investigation, implementation, or tool use. Rewrite for a busy technical reader. Preserve the conclusion, material evidence, assumptions, uncertainty, risks, and next actions. Remove repetition and background that does not affect the decision.

Add Simplified Technical English, the Minto Pyramid Principle, Google developer documentation voice, or your own editing rules to that instruction. If the product has a separate final-answer setting, put the style there. Keep it out of the instructions that govern research and implementation.