The cure for AI slop is a 1986 aircraft manual

Source: https://www.youtube.com/watch?v=uJblcC4lKYw

Banning individual “AI words” does not solve AI slop. A ban removes visible symptoms. It does not give the model a writing system.

The video defines AI slop as six repeated writing habits:

• Synonym rotation. The text uses several names for the same item, such as user, customer, and client.
• Hedging. The text adds helper verbs but adds little information.
• Nominalization. The text says perform an analysis instead of analyze.
• Marketing adjectives. Words such as seamless, robust, and powerful claim quality without evidence.
• Long sentences. The text puts several ideas in one sentence.
• Ambiguous phrasal verbs. Phrases such as spin up, reach out, and take off replace exact verbs.

The video proposes ASD-STE100 Simplified Technical English as the solution. STE is a controlled language for technical documents. The aerospace industry first published its predecessor in 1986. It helped non-native readers understand maintenance instructions. The current standard has 53 writing rules and a controlled dictionary.

STE controls vocabulary and grammar to reduce ambiguity. An approved word usually has one meaning and one grammatical function. STE also selects one word from a group of synonyms. For example, it uses start instead of begin, commence, initiate, or originate.

Several STE rules address common forms of AI slop.

• Consistent terminology. Use one technical noun for one item.
• Simple verb constructions. Do not combine many auxiliary verbs.
• Active voice. Use passive voice only when the actor is unknown.
• Direct actions. Use an approved verb for an action when possible.
• Restricted -ing forms. Avoid forms that can make a sentence long or ambiguous.
• Short sentences. Use no more than 20 words for procedures and 25 words for descriptions.
• No semicolons. Use two sentences instead.
• No ambiguous phrasal verbs. Use extinguish instead of put out. Use release instead of give off.

The video compares normal AI text with STE-inspired text. The normal README introduction uses long sentences and promotional phrases. Examples include minimal friction and no lock-in. The STE-inspired version uses short statements. Each statement explains one part of the cache behavior.

The creator also rewrites an error message. The new message gives the same information with fewer words. The creator says the removed words added tone and padding, not useful information.

Experiment

The creator tests four writing methods on six developer tasks. The tasks include:

• a README;
• a pull-request description;
• API documentation;
• an error message;
• a getting-started guide;
• a deprecation notice.

The creator generates each task under four conditions:

1. A normal baseline.
2. A list of banned AI words and punctuation habits.
3. George Orwell’s six writing rules.
4. The STE-inspired writing skill.

A custom linter counts mechanical writing problems. It checks sentence length, semicolons, passive voice, phrasal verbs, marketing adjectives, and related patterns. The score shows violations per 100 words. A lower score is better.

Writing method	Claude result	GPT result
Banned-word list	3% reduction	40% reduction
Orwell’s rules	43% reduction	About 50% reduction
STE-inspired skill	74% reduction	About 50% reduction

The results do not prove that banned-word lists never work. The list had little effect on Claude. It worked much better on GPT. A structured writing system reduced measured problems by about half or more on both models.

The two models produced different forms of slop. Claude used more marketing language, em dashes, and long dramatic sentences. GPT used less dramatic language, but its sentences were often long and passive.

How the creator recommends using it

Do not add the complete 434-page standard to every prompt. The creator extracts the main rules into a small agent skill.

Use two levels of restriction.

• Strict mode. Use it for procedures, warnings, runbooks, safety text, and error messages. Apply all sentence limits and strict rules.
• STE-flavored mode. Use it for READMEs, pull-request descriptions, and general technical prose. Keep the structural rules but allow a larger vocabulary.

Use STE when clarity is more important than voice. It works well for instructions, reference documents, error messages, and text for international readers.

Do not use strict STE when the text needs a personal voice. Essays, marketing, stories, and personal messages can become dry and mechanical.

STE improves form, not substance. It can make a vague paragraph shorter and clearer. It cannot make a false claim true. It cannot add an original idea or useful evidence.

What viewers thought

Many viewers found the method useful. Some said that a full rule system works better than a list of banned words. Several viewers wanted to use the skill for documentation, reports, and LLM workflows.

One aircraft-maintenance worker described a similar system. Their team uses a reduced STE rule set with a fine-tuned Qwen model. The model checks internal documents. It helps non-native speakers and speeds up apprentice training. It checks compliance and flags possible logical errors. It does not replace the technical writer.

The most popular joke described the main risk:

“Next year: Why does all slop sound like an aircraft manual?”

The comment warns that widespread use could replace one repeated AI style with one repeated technical style.

Many viewers said that the video script sounded AI-written. They identified repeated patterns such as:

• “It is not X. It is Y.”
• “Here is why this matters.”
• “And here is the punchline.”
• dramatic words such as brutal and honest;
• short fragments presented as important discoveries.

Some viewers cited “Not a style guide. A specification.” and “Notice what that just did.” They saw these lines as examples of the style that the video criticized.

The creator confirmed that Claude helped edit the final script. He used the model to improve grammar and clarity because English is not his first language. Some viewers said that Claude changed more than a few phrases. They believed that it gave the script a clear AI style.

Some viewers preferred imperfect personal writing to polished AI prose. They feared that non-native writers could treat standard LLM language as ideal English. This process could remove the writer’s individual voice.

Several viewers separated clear writing from human writing. STE can improve understanding while the text still sounds mechanical. Short sentences and active voice do not create a natural rhythm or a personal style.

Other viewers raised safety concerns. They said that clear wording can hide incorrect technical content. Human experts must write or fully check all safety-critical instructions.

The response was mixed but useful. Most viewers accepted STE as a helpful framework for technical writing. They disagreed about the “cure” claim, the test quality, and the deeper value of human-sounding AI text.

Skill

---
name: ste-writing
description: Rewrite prose in ASD-STE100 Simplified Technical English. Use it for documents, READMEs, pull-request descriptions, error messages, release notes, and comments. Do not use it for code. Use strict mode for procedures and safety text. Use STE-flavored mode for general prose.
---

# ste-writing

Write prose with ASD-STE100 Simplified Technical English rules. Apply these rules to documentation, READMEs, pull-request text, error messages, release notes, and comments.

Do not change code, identifiers, or command syntax. Do not use this skill for marketing, essays, or text that needs a personal voice. STE removes personal style to improve clarity.

## Rules

WORDS

- Use one name for one thing.
- Use a short common word.
- Use start, not begin, commence, or initiate.
- Use use, not utilize or leverage.
- Use help, not facilitate.
- Use make sure, not ensure.
- Use before, not prior to.
- Use after, not subsequent to.
- Use about, not regarding or concerning.
- Use get, not obtain or acquire.
- Use show, not demonstrate.
- Use also, not additionally, furthermore, or moreover.
- Give each word one meaning. Use "fall" only for movement down.
- Do not use empty marketing adjectives.
- Use American spelling.

VERBS

- Use active voice when the actor is known.
- Use a verb for an action.
- Do not combine many auxiliary verbs.
- Use a simple tense when it gives the same meaning.
- Do not use an "-ing" main verb when a simple tense works.

SENTENCES

- Put one instruction in each sentence.
- Use no more than 20 words for an instruction.
- Use no more than 25 words for a description.
- Do not use contractions.
- Use articles when necessary.

PUNCTUATION

- Do not use semicolons. Use two sentences.
- STE does not ban the em dash. Add that rule separately when necessary.

STRUCTURE

- Put one topic in each paragraph.
- Use no more than six sentences in a paragraph.
- Use a numbered vertical list for steps.
- Put one action in each step.
- Use the imperative form for instructions.
- Put a condition before its command.

Write only the requested text. Do not add a preamble, summary, or closing statement.

## Modes

- **strict**. Use this mode for procedures, runbooks, safety text, and error messages. Apply all rules and length limits.
- **STE-flavored**. Use this mode for READMEs, pull-request descriptions, and general documents. Keep the structural rules and allow a larger vocabulary.

## Self-lint

1. Check each instruction sentence. Split it if it has more than 20 words.
2. Check each descriptive sentence. Split it if it has more than 25 words.
3. Replace each semicolon with a period.
4. Expand each contraction.
5. Change passive voice to active voice when the actor is known.
6. Replace avoidable "-ing" forms, nominalizations, and phrasal verbs.
7. Use one name for each item.

These mechanical rules remove many visible forms of AI slop. Full STE also needs human judgment. A checker cannot confirm full compliance.

This skill improves the form of the text. It cannot make an empty or false paragraph useful.

Free official standard: https://asd-ste100.org

Project files, linter, experiment results, and examples. https://github.com/woosal1337/blog/tree/main/videos/ep01-the-cure-for-ai-slop