Karpathy's 4 AI Output Formats: Text, Diagrams, Interactive Web & Video

When AI explains a new concept, it can quickly produce definitions, principles, and use cases. Yet after reading, you may still not grasp how it actually works; when it organizes a plan, every sentence flows but you don't know which step is most error‑prone. The usual reaction is to ask “make it simpler” or “give an example.” On October 2, Karpathy shared another set of approaches: constrain the writing style, draw diagrams, build interactive web pages, or generate custom explanatory videos. His premise: as models become more autonomous, we need to spend more time understanding and verifying their outputs. This is especially acute in content creation—when AI delivers technical research, you must know whether it got the principles right before turning it into an article or script.

Text: Write One Clear Sentence First

Karpathy’s first suggestion is surprising: have the model explain using ASD‑STE100. This is a controlled‑language standard for English technical documentation, originally created to help readers understand aircraft maintenance manuals. It includes writing rules and a controlled dictionary that constrain word meanings, sentence structures, and terminology usage. Karpathy says this constraint makes reading more comfortable, though the standard is strict; he sometimes asks the model to achieve only an “80%” approximation—this is a style instruction, not a compliance score. His attached overview splits the rules and dictionary into two parts; the Chinese writer can borrow the principles but cannot directly apply the English word list.

Borrowed principles for Chinese: make the actor explicit, break long sentences, use the same term for the same concept. For example, “RAG enhances the model’s generation ability with external knowledge” leaves readers knowing every word but not what actually happens. Rewriting as a sequence of short sentences makes it concrete:

User asks a question. System retrieves relevant materials from the knowledge base. System passes the question and materials to the model. Model composes the answer based on them. If the retrieved materials are wrong, the answer may also be wrong.

This example omits implementation details like vectors and indexes but retains the main steps and a failure mode. For definitions, specifications, or operating procedures, clarifying the text is often sufficient.

Prompt: Explain RAG in Chinese to a non‑technical audience, borrowing ASD‑STE100’s clarity principles without claiming compliance with the English standard. Each sentence conveys one main idea; write out the subject and action; use the same term for the same concept. First describe the process in five sentences, then illustrate with “retrieving from a company knowledge base.” Keep necessary conditions and failure cases; do not delete key constraints just to be brief.

If the text is still confusing—especially when multiple roles and paths are intertwined—it’s time to switch to a diagram.

Diagrams: Draw the Relationships Hidden in Paragraphs

Text must be read sequentially; a diagram lets you see several relationships at once. In the same example: user, knowledge base, retrieval step, model—what is each responsible for? Where do the materials enter the model? What should the system do if nothing is found? These questions are easier to point out in a flow chart.

The illustration shows the answer phase only, omitting knowledge‑base preparation. Solid black lines represent the main flow of question → retrieval → answer; a dashed line shows the original question going directly to the model; the red branch at the bottom indicates the suggested handling when materials are insufficient.

The arrows themselves express a judgment. Whether an arrow indicates sequence or data flow must be made explicit. A pretty diagram can still depict wrong relationships.

For technical popularization, dissecting business processes, or explaining system architecture to colleagues, I try diagrams first. But if you only need to look up a term or verify a quote, text is more efficient.

Prompt: Draw a Chinese flow chart of “AI retrieves from knowledge base then answers,” covering only the answer phase. Distinguish user, retrieval step, knowledge base, and model; show where the question and materials flow. Add a “insufficient materials found” branch that prompts “information insufficient.” Do not depict the model as having automatically learned the entire knowledge base. After the diagram, use three sentences to explain the arrow meanings and list the omitted steps. If the model cannot output an image directly, provide Mermaid code.

Interactive Web Page: Change Conditions and See Results

Karpathy suggests simply asking the model to “output HTML.” However, merely wrapping a long text in a web page helps little. What deserves a web page are problems that require you to change conditions and observe the outcome.

For instance, a RAG teaching page: you can toggle “materials complete” vs. “materials missing,” step through the retrieved segments, and compare the resulting answers. This lets you discuss a concrete question: when the answer is wrong, is it because the retrieval failed or because the model misused the materials?

The mockup below shows the page concept: condition toggles on the left, retrieved segments and sample answers on the right. It is not a screenshot of a running page.

Training, explaining proposals to clients, or teaching a concept with variables—web pages work well. Budget changes or schedule simulations can use similar approaches, but the calculation rules must be verified separately. Ordinary chat tools may not save, preview, or run files; tools with code execution or file generation are better suited. After getting the HTML, open it and test whether buttons actually change content, not just whether the first screen looks good.

Prompt: Generate a single‑file HTML page that runs in a browser and explains RAG in Chinese. Use only built‑in fictional materials, no external APIs. Provide “materials complete / materials missing” toggle, step‑by‑step playback button, and side‑by‑side comparison of retrieved segments and sample answers. Clearly label this as a teaching simulation with no connection to a real knowledge base or real model. Support mobile viewing, include save and open instructions, and list the interactions I must manually verify.

A teaching page may only switch pre‑written answers. Whether it actually calls retrieval and the model must be made clear to the reader.

Video: Narrate the Changing Process Step by Step

Among the four formats, Karpathy is most optimistic about custom explanatory videos. He points to 3Blue1Brown‑style visual explanations and mentions using ElevenLabs for narration or seeking local‑compute alternatives. This is his experiment and expectation; no controlled experiment measuring “how much video improves understanding over text” is provided.

Video suits processes: a problem arises, materials are found, segments enter the model, the answer forms. The narration explains the current step while the visual highlights only what matters at that moment, so the viewer doesn’t have to mentally stitch together multiple static diagrams.

The storyboard below breaks the same process into three shots. It is a storyboard design mockup, not generated video frames.

For content creators, you can first ask AI for the script, storyboard, and narration draft, then decide whether to produce. Checking whether the concept is explained correctly early avoids a wasted animation round.

Video has costs: missing a key sentence means pausing or rewinding; checking data, verifying citations, or copying steps is usually easier in text. Generating a finished video still requires animation, rendering, and dubbing tools; a single prompt does not guarantee the chat window can deliver a video file.

Prompt: Design a 60‑second Chinese explanatory video for “AI retrieves from knowledge base then answers.” Use simple graphics and stepwise highlighting to clarify the process; do not copy existing video assets. First deliver the script, storyboard, and narration draft; each shot explains one key point and retains the “wrong retrieval leads to wrong answer” example. If the current environment supports rendering, list the tools and dubbing options; if not, stop at the design stage. Do not present the storyboard as a finished video.

Choosing the Right Format

These four methods are not a mandatory upgrade sequence. Pick based on where you are stuck:

Sentences too convoluted, too much jargon → Clear short sentences

Cannot distinguish roles and relationships → Diagram

Want to see results under changed conditions → Interactive web page

Cannot follow a continuous changing process → Explanatory video

Next time an AI explanation makes your head spin, first tell it where you’re stuck, then specify the output format. After switching, try to explain a failure case in your own words and cross‑check with the source material. Being able to follow its explanation is not enough—you still have to verify it got things right.