Karpathy shares tips to make LLM output more readable, drawing on 40-year-old aviation standard ASD-STE100

LLMs write more and more, but "more" does not equal "easy to read." The set of techniques Karpathy shared targets exactly this problem: how to make the ever-growing output of LLMs easier to understand. His answer is unexpected—not making the model write more elaborately, but putting it under a 40-year-old aviation writing specification.

The source of this specification is the European aviation industry of the 1970s. At the time, the maintenance system was becoming increasingly internationalized, and English maintenance manuals had to be used by technicians from different countries and different language backgrounds, so every sentence in the manuals was required to have only one possible interpretation. The aviation industry therefore began to actively restrict English, and this controlled English gradually developed into ASD-STE100.

ASD-STE100's latest Issue 9 contains 53 writing rules, accompanied by about 900 approved basic words, as well as about 1200 words recommended to avoid, with alternative expressions provided. The rules themselves are very plain: a procedural instruction should be kept to within 20 words as much as possible; one sentence should contain only one action; use the active voice as much as possible; and for the same concept, use only the same name from beginning to end as much as possible.

This approach is exactly the opposite of the LLM's default tendency. To make language more "rich," models often rotate synonyms, but in many scenarios this rotation actually creates reading obstacles. ASD-STE100 does not pursue vocabulary variation, nor does it encourage beautiful long sentences—if one name can be used, use that name all the way through.

Karpathy found that after handing this specification to an LLM, the output becomes clearer and easier to read. But this judgment comes from his personal observation, and the source does not provide a quantitative evaluation, so it is better treated as an empirical claim rather than a verified conclusion.

He also did not really require the model to strictly enforce an entire aviation specification. Sometimes he would ask the model to achieve "80% ASD-STE100." The reason is straightforward: the full version is designed for professional technical documentation, and if it is followed to the letter in daily use, it easily appears too rigid.

The phrase "80%" itself also leaves room for ambiguity—the source does not explain how this 80% is specifically measured, whether it is a selection of rule counts or a discount on enforcement strictness. What is certain is that Karpathy's intention is not to copy the specification wholesale, but to borrow its spirit of constraint.

Karpathy's second suggestion is to directly have the model generate a diagram or image. The reason is that diagrams can help readers organize information; even if the diagram serves only you and no one uses it after you finish viewing it, generating it is still worthwhile.

One step further is web pages. He suggests directly having the model "output in HTML." As code models become increasingly good at front-end work, the answer no longer has to be a piece of static content, but can be a page with layout, animation, and even interactive functionality. The example given by the source is understanding the learning rate in a neural network: text can only tell you that if the learning rate is too small, convergence is very slow, and if it is too large, it may oscillate, whereas a web page can directly place a slider that lets you change the learning rate yourself and watch a small ball change its descent trajectory in real time. At this point the model is no longer just "explaining"; it has temporarily made a small tool to help you understand this matter.

What Karpathy is currently most optimistic about is generating fully customized explainer videos for any topic. The specific case he gives is having the model "make a 3b1b-style video explanation," then connect to the ElevenLabs API to generate narration; when there is no API, the model can also be asked to continue looking for free alternatives that can run locally. Here 3b1b refers to 3Blue1Brown, whose typical feature is using programmatic animation to "perform" abstract concepts step by step, accompanied by explanation.

He calls this kind of artifact large, custom, discardable software artifacts—large, custom software artifacts that can be thrown away after use. The emphasis of this naming is on "discardable": as intelligence and code become cheaper and cheaper, people can already temporarily generate things for a very specific problem that would previously not have been worth making specially at all.

Just as Karpathy posted his suggestion, Tibo did a test: he gave only a very simple task—"explain how Shazam works"—and the model immediately generated a video specifically explaining how Shazam works. It should be noted that this test is a secondhand retelling, and the source did not provide the video itself or independent verification.

The community's evaluations of ASD-STE100's effect are not consistent. Some people felt after trying it that with ASD-STE100-style constraints added, the information structure of complex HTML artifacts became clearer; but others compared ordinary answers with ASD-STE100 versions and concluded that "it seems like there's not much difference."

This disagreement is actually not hard to explain. If you are only asking a very simple question, the model originally only needs to answer in a few sentences, and adding another layer of specification is unlikely to produce earth-shaking changes. Inferring from the source's description, this specification is more suitable for long technical explanations, multi-step operations, or information passed between different Agents—the more complex the content, the easier it is to see the effect.

Some netizens further discovered that directly importing the entire set of rules may still be too strict. A better method is to pick out the part that truly suits your own usage scenario. One usage someone came up with is: have the model randomly select ten interactions between you and it from the past week, then use ASD-STE100 to check them one by one—which answers were not clear enough at the time? Where did unnecessary ambiguity arise? If a certain rule were applied, would that conversation become easier to understand? Finally, write the rules that are truly effective into the user-level AGENTS.md.

In fact, three months ago someone already turned ASD-STE100 into an open-source Skill and further applied this approach to scenarios such as tool descriptions, error messages, instructions between Agents, and system prompts.

This open-source Skill specifically divides into two modes. One is Strict, suitable for program steps, tool descriptions, inter-Agent instructions, and other content where the cost of misreading is higher; the other is STE-flavored, more suitable for ordinary scenarios such as READMEs and explanatory text, retaining principles such as sentence length, active expression, and clear structure, but not completely locking down vocabulary.

This is very much like further productizing Karpathy's phrase "80% ASD-STE100": not every place needs the strictest specification. It should be noted that the actual effect and applicable boundaries of this Skill are described in the source only by the author and the community, and lack third-party evaluation.

Karpathy's final judgment is: as LLMs become stronger and stronger, more and more concrete work will be completed autonomously by models, while human work will continue to move upward, becoming more about supervision, checking, and understanding.

This set of techniques happens to land on this judgment—what they deal with is not "whether the model can complete the task," but "whether the work completed by the model can be understood by people." As intelligence and code become cheaper and cheaper, people can temporarily generate things for a very specific problem that would previously not have been worth making specially; and what people need to do is judge which things are worth generating and which rules are worth keeping.

The boundary that needs to be maintained is: the source does not explain the applicability of these techniques to output in other languages such as Chinese, nor does it provide a quantitative evaluation. At present they are more like a set of practices quickly tested and modified by the community, rather than a set of verified standard answers.