A.I. really loves to talk nonsense.
To this end, Karpathy shares a set of techniques aimed at making it easier for larger models to understand more and more outputs.
It's a bit surprising.
This is because Karpathy produced a set of aviation writing standards from 40 years ago.
40 years ago's aviation specification makes it easy to read big models
In the 1970s, the European aviation industry faced an increasingly international maintenance system. English maintenance manuals needed to be handed over to technicians from different countries, different language backgrounds.
As a result, the aviation industry began to proactively restrict the use of English. This controlled language was later developed into ASD-STE100. The latest Issue 9 contains 53 writing rules and contains about 900 approved basic words for use, as well as about 1200 recommendations to avoid while providing a substitute for DA.
The rules are simple:
A procedural instruction should be kept as short as possible as 20 words;
One sentence arranges only one operation;
Try to be as proactive as possible and explain who is doing what;
The same concept, trying to use the same name as much as possible from beginning to end.
Large models often use synonyms frequently in order to make language more "rich", but in many cases, this rotation causes a certain impediment to reading.
The ASD-STE100 is quite the opposite. It does not seek to change vocabulary, nor does it encourage beautiful long sentences.
Karpathy found that once this set of norms were passed on to the LLM, loss encounters became clearer and easier to read.
However, he did not really require the model to strictly follow the entire aviation specification. Sometimes he would require: to achieve "80% ASD-STE100".
The full version of the ASD-STE100 is designed for professional technical documentation, and it's easy to find that it's too hard to execute on a daily basis.
But then again, Karpathy felt that writing was not the best way to draw a picture, so why write everything in writing?
His second suggestion was to let the model directly generate a diagram or image.
Graphics can help the reader organize information. Even if the graphic is only for you and no one uses it after you see it, it is still cost-effective to generate it.
There's even a better form: a web page that lets models directly "output in HTML".
As code models become more and more front-end, the answer may no longer be static content, but rather a page with layout, animation, or even interactive functions.
For example, you want to understand the learning rate in a neural network. The text can tell you that the learning rate is too small, too slow, too large and potentially vibratory.
At this point, the model is no longer just an explanation. It is a temporary tool to help you understand this.
A similar idea has been added in the comments section: if it's mathematical and technical content, you can directly ask Agent to produce a technical report in PDF with TeX. Forms, codes, charts, and diagrams can all be rendered more appropriately.
In other words, users can ask the model to choose a more understandable expression based on the problem itself.
Finally, Karpathy is currently the most watched form: it produces fully customized instructional videos for any topic.
He gave a very specific example: allowing the model to "create a 3b1b-style video explanation" and then access the ElevenLabs API to create a side effect; without an API, the model can continue to look for free alternatives that can run locally.
3b1b here is 3Blue1Brown. Its most typical feature is the use of programmatic animation to "develop" abstract concepts step by step and accompany explanations.
These techniques are all focused on one topic, which is to rework the model into something that is easier to understand.
Karpathy's final judgement was the same.
As the LLM becomes stronger, more and more specific work is done by the model itself. Human work continues to move upwards, becoming more supervised, checked and understood.
Fortunately, AI can also continue to help people do this part of the work. Because as intelligence and code become more affordable, we are now able to temporarily generate something that in the past wasn't worth doing specifically for a very specific problem.
Karpathy calls them: large, custom, discardable software artifacts. Large, customized, disposable software products.
Tibo immediately tested it.
Karpathy had just made the suggestion, and Tibo had immediately come up with a test.
He gave only one very simple task: "Explain how Shazam works".
The model then generates a video that explains how Shazam works.
The results were unexpectedly apparent. The information structure became clearer after the ASD-STE100 constraint was added, especially in the face of the more complex HTML Artifact.
However, some people compared the general answer to the ASD-STE100 version, concluding that "it doesn't seem to make any difference".
This is not surprising. If only one simple question were asked, the model would have to answer only a few sentences and set a standard.
The more appropriate scenarios for this specification are long-technical interpretations, multi-step operations, or the transmission of information between different agents. The more complex the content, the easier it is to see the effect.
Some netizens have also found that the whole set of rules may still be too strict to move directly. A better way is to select the part that really suits their use of the scene.
So someone came up with a way: to have the model randomly extract 10 interactions it had with it over the past week, and then check it step by step with ASD-STE100.
Which answers were not clear enough at the time? Where did unnecessary ambiguity arise? If a rule were applied, would it make that conversation easier to understand? Finally, write those rules that really work into user-level AGENTS.md.
In fact, three months ago, someone had already made ASD-STE100 an open source Skill.
github：
Asd-ste100-skill uses this idea further in instances such as tool description, error message, agent-to-agent instructions, system prompt, etc. It even specifically separates the two patterns.
One is Strict, which is more cost-effective for misreading program steps, tool descriptions, and inter-agent instructions.
The other is STE-flavored, which is better suited to ordinary scenarios such as README, explanatory text, the principle of retaining sentence length, active expression, and structural clarity, but does not completely lock the vocabulary.
This is similar to Karpathy's phrase "80% of ASD-STE100" being further producted, and not all places require the strictest standards.
Some developers simply created an instant Claude Skill and put the code directly on GitHub.
github：
Karpathy, on the other hand, has already shared his tricks, so let's try it soon.
The link is as follows: