Caveman fixed a real problem for me. AI agents use too many words.
The skill tells an agent to remove filler and keep the useful parts. It works well in a terminal. A short answer is easier to scan while several agents are changing code.
Then I started using the same voice outside the terminal.
The replies were short, but some sounded unfinished. That was fine for a build log. It was not fine for a client update or a LinkedIn comment.
I wanted less text without losing grammar, tone, or trust. ASD-STE100 Simplified Technical English gave me a better middle ground.
The difference is easy to see
Here is a normal AI comment:
This is a really interesting approach, and I especially like how the assistant works directly inside Slack instead of requiring users to switch to yet another dashboard. It will be exciting to see how the product develops as the knowledge base grows over time.
Here is the same idea in Caveman style:
Slack good. Another dashboard bad. Watch retrieval freshness as knowledge grow.
Here is the version approved after an STE edit:
The best part is that the assistant works inside Slack instead of another dashboard. Watch retrieval freshness as the knowledge base changes.
The last version keeps the useful point. It also sounds like a person who chose each word.
What I changed
The GattyWorks rollout note explains the first change. We added a working STE profile to 19 repositories through 8 pull requests.
This is not a claim of formal ASD-STE100 compliance. I use a practical subset of the standard for agent communication:
- Use short sentences.
- Put one instruction in each sentence.
- Use the active voice.
- Use one word for one meaning.
- Prefer simple words.
- Keep articles such as “a,” “an,” and “the.”
- Keep technical names, commands, paths, and error text unchanged.
I later applied the same rules to LinkedIn comments. That made the result easier to measure.
What our first small test showed
I compared 64 LinkedIn comment drafts before and after the STE edit. The topic, reaction, and core opinion stayed the same in each pair.
I used the o200k_base tokenizer for an approximate count. This is the same tokenizer used by the public Caveman eval script.
I kept the paired drafts and their independent review in the LinkedIn engagement audit in our repository.
| Measure | Before STE | After STE | Change |
|---|---|---|---|
| Approximate output tokens | 1,785 | 1,551 | 13.1% fewer |
| Total words | 1,494 | 1,299 | 13.1% fewer |
| Average words per comment | 23.3 | 20.3 | 13.1% fewer |
| Average words per sentence | 12.0 | 9.1 | 23.5% fewer |
This is a small writing test, not a model benchmark. It measures edited social comments from one batch. It does not measure hidden reasoning tokens, response time, or factual accuracy.
The useful result was not the 13.1% token reduction. The more important result was the 23.5% reduction in sentence length. The comments became easier to scan, but they kept complete sentences.
One political post also became a no-action item during the review. Clear rules helped us decide when silence was better than engagement.
How this compares with Caveman
The numbers need context.
The Caveman benchmark reports a 65% average reduction across 10 chat-style prompts. Its range is 22% to 87%. These figures measure output tokens against normal verbose replies.
Its newer three-arm evaluation gives a stricter comparison. Caveman used 1,026 approximate tokens. The terse control used 2,045. That is about 50% fewer tokens than an instruction that only says, “Answer concisely.”
A separate JetBrains test across 86 coding tasks found an 8.5% output-token reduction. Code, tool calls, and error text limit how much an output-style rule can remove.
Our 13.1% result sits between those two types of work. The comments were already brief, so they had less filler to remove. STE also keeps words that Caveman can remove, such as articles and some verbs.
The test sets are different, so the percentages are not a direct contest. They show the same basic pattern: the workload decides the saving.
Where I use each style
I still like Caveman for private terminal work:
- Fast build updates
- Repeated tool results
- Small debugging notes
- High-volume agent handoffs
I prefer the STE profile when another person will read the text:
- Client updates
- Review reports
- LinkedIn comments
- Public explanations
- Messages where tone affects trust
The choice is not between long and short. It is between compression levels.
Caveman removes most language that is not strictly necessary. STE keeps enough language to make the result clear, complete, and calm.
The honest tradeoff
STE can sound formal when I apply it too strictly. It also saves fewer tokens than Caveman in prose-heavy work.
That is acceptable for my use. I do not want every public sentence to look optimized for a tokenizer. I want readers to understand it on the first pass.
The next test should use more than social comments. I want a fixed set of client updates, code reviews, and technical explanations. It should measure token count, reading time, and whether a reviewer can state the required next action.
For now, the working rule is simple: use Caveman when machines pass notes to machines. Use STE when a person must trust the note.