If you are following what happens around AI and LLMs, you have probably heard about Andrej Karpathy. If you didn’t, here is a short intro.
Karpathy did his PhD at Stanford with Fei-Fei Li, where he also designed and taught CS231n, one of the first university courses on deep learning for computer vision. In 2015 he joined OpenAI as one of its founding members. Two years later he moved to Tesla as Director of AI and led the computer vision team behind Autopilot until 2022. After a second, one-year stint at OpenAI, he started Eureka Labs, an AI education company, in July 2024. In May 2026 he joined Anthropic to work on pre-training research.
The job titles tell only half of the story. For many developers, Karpathy is first of all a teacher. His YouTube series Neural Networks: Zero to Hero builds a GPT starting from an empty file, and small projects like micrograd and nanoGPT show how much of a language model fits into a few hundred lines of Python. He also has a talent for naming things. In February 2025 he described “vibe coding”, where you tell the model what you want, accept what it writes, and “forget that the code even exists”. The term spread so fast that Collins Dictionary named it the Word of the Year for 2025.
The post that started this
On October 2, 2026, Karpathy posted on X that we will spend a lot more time trying to understand the outputs of language models. He then lists output formats that help with that, each one a step further than the previous: plain writing, diagrams, interactive HTML pages, and custom explainer videos in the style of 3Blue1Brown.
The first tip is the one that stopped me. Karpathy suggests asking your LLM to explain something in ASD-STE100, a controlled language that comes from aircraft maintenance documentation. He says LLMs know the language well and that the result is often a lot more readable. Because the spec is strict, he sometimes softens it and asks for “80% of the way to ASD-STE100”.
Technical writing is my background, so I know the name. Guess what, I didn’t expect to find it in a post about LLMs, right next to video explainers and API keys. Outside aviation and a few technical writing teams, STE almost never comes up. It was never part of the everyday tech vocabulary. After this post, that might change.
What ASD-STE100 is
ASD-STE100 Simplified Technical English, or STE for short, started in the late 1970s as AECMA Simplified English. The request came from the airlines. According to the official STE site, 80% of them were not from English-speaking countries, and their mechanics had to work with maintenance manuals written in English by manufacturers from the US, the UK and the rest of Europe. Long sentences and words with several meanings lead to misunderstandings, and in aircraft maintenance a misunderstanding can lead to an accident. The first official version came out in 1986.
The standard has two parts. The first part is a set of 53 writing rules in 9 sections, covering word choice, grammar, sentence structure and style. The second part is a controlled dictionary with about 900 approved words and about 1,200 words that are not approved, each with a suggested replacement. The principle behind the dictionary is one word, one meaning, one part of speech. The word “test”, for example, is approved only as a noun, so in STE you can do a test, but you cannot test something. The verb “close” works for a door or an electrical circuit, but not for a meeting or a business deal. Writers can still use the technical nouns and verbs of their own field, as long as they follow the rules for those terms.
The writing rules are the part most people recognize, even if they never heard of STE. A sentence in a procedure has a maximum of 20 words, and a descriptive sentence a maximum of 25. Each sentence gives one instruction. You write in the active voice and use passive only in descriptions, when you don’t know who does the action. You use only simple tenses, you don’t stack more than three nouns together, and you don’t drop articles or verbs to make the text shorter. A paragraph has one topic and a maximum of six sentences. You can find a longer list on the Wikipedia page for STE.
The current version is Issue 9, released on January 15, 2025. With it, STE officially changed from a “specification” to a “standard”. The Aerospace, Security and Defence Industries Association of Europe (ASD) owns it, and since Issue 6 in 2013 you can download it for free.
What it has to do with technical writing
In aerospace, STE is not optional. It has been a requirement of the ATA specification for technical publications (today ATA iSpec 2200) since 1986, the S1000D specification recommends it, and aviation authorities like EASA, FAA and CAAC reference it in their directives. Outside aerospace it spread further than most people expect. According to the distribution log for Issue 8, 64% of users came from other industries: automotive, renewable energy, offshore logistics, medical devices..
For most technical writers, STE sits at the strict end of a scale. On the softer end you have plain language, which since 2023 also has its own ISO standard, ISO 24495-1, and in the middle you have company style guides. Most of us will never write a page of certified STE, but its rules show up everywhere. If a style guide ever told you to stop switching between “folder” and “directory” in the same document, you met the “one word, one meaning” rule without its name.
Karpathy is not the first one
When I started digging, I found that the idea had been around for a couple of months before Karpathy’s post.
It started in late July, when a developer on X asked Claude to please just use plain English. Andrew Carr replied with one line: “only report to me in ASD-STE100 Simplified Technical English”. Pieter Levels (levelsio) saved the same instruction to Claude’s memory to stop its writing from getting more and more bloated. Within days, as Enterprise DNA noted, at least three GitHub repos turned the trick into a reusable skill.
The skills are worth a look. The asd-ste100-skill by danyuchn rewrites text that an AI agent has to read, like tool descriptions and error messages. Its reasoning is simple: an agent reading another agent’s output can’t ask what it meant, the same way a mechanic can’t call the author of a manual. toppa used it as a base for an output style for Claude Code, so Claude writes this way in every session. SimpleEnglish by AminBlg adds a strict mode and published benchmarks. Its README also answers the obvious question of why you wouldn’t just ask the model to “write clearly”: “Clearly” is an opinion, while STE rules you can count. There are more, like sdsheeks/ste100-skill and samber’s humanizer-en-asd-ste100.
In August the guides followed. Janos Farkas from 8 West Consulting wrote a step-by-step setup for Claude Code, the desktop app and Projects, and in the Hacker News thread about SimpleEnglish people pointed out that one line in the system prompt does most of the work.
What Karpathy added is reach. Thanks to his post, the idea of using ASD-STE100 with LLMs has now reached a much broader audience than a group of developers swapping prompts on X. And the “80%” part of his tip matters more than it looks.
The catch
STE was built around a dictionary, and the LLM doesn’t have it. When you ask for ASD-STE100, the model writes shorter sentences and drops the fancy words, but nobody checks each word against the approved list the way an STE checker would. Farkas makes the same point in his article, and the danyuchn skill says openly that it follows the principle, not the word list. What you get is STE-flavored English, not STE.
The bigger issue is what gets lost along the way. Lucian Ghinda ran a small experiment in August, asking Claude and Codex to explain four pieces of real code. With a loose “Simple Technical English” instruction, Claude’s average sentence went from about 18 words to 9 or 10, and the explanations lost 8.5% of the code-specific facts. With the full ASD-STE100 instruction, they lost 46.8%. Codex was already terse, and both instructions made it worse. It is a small test, but it lines up nicely with Karpathy’s “80%”. The strict version makes the text shorter by throwing out content you needed.
ASD itself is careful here too. The standard’s own front matter says STE is not meant to be used alone, but together with other specifications and style guides, and that it takes a high level of professionalism to use it correctly. It was also never meant for creative or marketing text, where voice is the point. STE is flat on purpose.
Where this leaves us
A writing standard that the aviation industry built so a mechanic wouldn’t misread a torque value now helps people read what a language model wrote. For technical writers, that is a nice confirmation: the rules we follow for human readers work on machines too.
There is one limit for those of us who don’t write only in English. ASD-STE100 exists only for English. The idea of a controlled language did reach a few other languages through research projects and industry efforts: Italian has Italiano Tecnico Semplificato, Spanish has Español Técnico Simplificado, French aerospace has Français Rationalisé, and there are controlled versions of Swedish, Russian and Chinese. Unfortunately, as far as I could find, Croatian has nothing like that. There is no controlled dictionary and no agreed set of rules. You can still borrow the principles when you write technical Croatian, but there is no standard to lean on.
The bigger lesson is why the trick works at all. Technical writing spent decades turning “write clearly” into rules you can count and check. Standards and conventions like these are what make clear writing repeatable, whether the reader is a tired mechanic, a non-native speaker, or a language model.
So next time an LLM gives you three paragraphs where one sentence would do, ask for 80% of the way to ASD-STE100. Then check what it left out.