The Cure for AI Slop Is Not More Training Data. It’s a 1980s Aviation Standard.

You’ve been there. You ask ChatGPT to explain something simple, and it vomits back a 500-word essay that says nothing. You try again, and it’s all fluff, vague hand-waving, and that same robotic tone. You’re not alone. The frustration with AI slop—the bloated, ambiguous, repetitive nonsense—is almost universal. But what if the fix isn’t a bigger model, better fine-tuning, or more RLHF? What if it’s a dusty, 40-year-old technical writing standard designed for aircraft manuals?

We’ve been looking for the cure in the wrong place. It was never about the machine—it was about the language we feed it.

Meet ASD-STE100 (Simplified Technical English). It was built in the 1980s to make aviation documentation unambiguous. Every sentence must be short, every word must have only one meaning, and every instruction must be written in a controlled vocabulary. No metaphors. No poetic license. Just pure, constrained clarity. And it turns out—when you apply this same logic to the prompts and training data you give an LLM, the slop evaporates.

I saw this firsthand. I took a prompt that usually produced a three-paragraph, meandering answer and rewrote it using STE rules. The result? A single, crisp sentence that answered the question directly. No filler. No hallucinations. The AI had no room to wander because I had locked the door.

Here’s the twist: the very constraints that make language machine-friendly—simple syntax, limited vocabulary—are exactly what make it human-friendly too. We’ve been told that AI needs “rich” context and “creative” prompts. That’s a lie. Most of the time, what an AI needs is a blank, unambiguous instruction set. Give it freedom, and it will produce slop. Give it a cage, and it will produce gold.

Stop treating your LLM like a poet. Treat it like a pilot following a checklist.

This principle works beyond prompts. If you’re training models on technical documentation, code comments, or any domain where precision matters, STE is the cheapest, most effective filter you will ever apply. It doesn’t require a GPU cluster. It requires a simple style guide. The aviation industry has been using it for decades to prevent crashes. Now you can use it to prevent AI slop.

Of course, there’s a trade-off. Constrained language strips away nuance, creativity, and contextual richness. That’s fine—most of the time, you don’t want your AI to be creative. You want it to be accurate. If you need a sonnet, don’t use STE. If you need a system that writes reliable error messages, API docs, or legal summaries, this is your magic bullet.

So the next time you’re staring at a paragraph of AI-generated fluff, remember: the problem isn’t the model. It’s the language. Give it a cage. Watch it sing.

FAQ

Q: Isn't constraining language just dumbing down AI? Won't we lose important nuance?

A: Not if you're in a domain that demands precision. For creative writing, yes—STE is a straightjacket. But for technical documentation, code generation, or any task where accuracy beats flair, constrained language is a feature, not a bug. You're not dumbing down the AI; you're focusing it.

Q: How do I actually apply this to my prompts? Give me a concrete example.

A: Replace fluffy instructions like 'Explain the concept of recursion in a friendly way' with a STE-style command: 'Write a five-sentence explanation of recursion. Use only words from the 1000 most common English words. Each sentence must be under 20 words. Use the word 'function' to mean only a programming routine.' The result will be concise and unambiguous.

Q: Isn't this just a fancy way of saying 'write better prompts'? What's really new here?

A: It's deeper than that. 'Write better prompts' is vague advice. STE gives you a specific, testable framework: a controlled vocabulary, a maximum sentence length, and a ban on ambiguous words. It's a standard, not a suggestion. And it works for training data too—not just prompts. That's the real leap: applying a rigorous engineering standard to the language we feed AI.

📎 Source: View Source