Karpathy’s Aircraft Manual Prompt Is Really a Spec for Better AI Output

TL;DR: Karpathy’s “aircraft manual” prompt works because it turns a vague writing request into an output spec, which is what most AI workflows still lack.

What did Karpathy actually suggest?

Search Engine Journal’s “OpenAI Founding Member: Make LLMs Write Like An Aircraft Manual” by Matt G. Southern reports that Andrej Karpathy suggested asking LLMs to explain topics in an aerospace writing standard, or to answer using diagrams, HTML pages, and custom explainer videos.

That sounds like a writing tip. I think it is more useful than that.

The important move is not “make it sound technical.” The move is giving the model a standard to imitate. Aircraft manuals are not trying to be clever. They are trying to reduce ambiguity. Short sentences. Controlled vocabulary. Step-by-step instructions. Clear warnings. No decorative prose. No vibes.

That is exactly where many LLM outputs fail. They are fluent but mushy. They answer the question, sort of. They include a reasonable structure, sort of. They sound confident, even when the user needed precision.

Karpathy’s prompt points in the opposite direction: make the model behave like the output has to survive use by a tired human in a high-stakes environment.

Not because every blog post should read like maintenance documentation. It should not. But because most prompts are under-specified. “Explain this clearly” is weak. “Explain this like an aircraft manual, with numbered procedures, definitions before use, no synonyms for key terms, and explicit failure modes” gives the model a job.

Why does a format constraint improve LLM answers?

LLMs are good at style transfer. That is the shallow explanation.

The deeper point is that format constraints reduce the model’s degrees of freedom. If you ask for “a helpful explanation,” the model can choose a metaphor, a tone, a structure, and a level of detail. If you ask for a manual-style answer, the model has fewer places to hide.

It has to define terms. It has to order steps. It has to separate concepts. It has to make dependencies visible.

That matters for builders. A support article, onboarding flow, agent instruction, API guide, or internal SOP is not better because it sounds polished. It is better if a user can complete the task without asking a second question.

The same logic applies to Karpathy’s other suggested output modes, diagrams, HTML pages, and custom explainer videos. Those are not just presentation layers. They are constraints. A diagram forces relationships. An HTML page forces hierarchy. A video script forces sequence and pacing.

The catch: none of this makes the model correct. A hallucinated aircraft manual is still a hallucination. In fact, the more formal the style, the more dangerous wrong content can feel. Precision theater is real.

So the workflow needs a second layer: source grounding, checks against known docs, and review by someone who knows the domain. Manual style improves usability. It does not replace verification.

Where should teams use this?

I would try it first on content that people use to do work, not content people skim.

Good fits: customer support macros, implementation guides, internal runbooks, product docs, sales engineering explainers, compliance checklists, and training material. Anywhere ambiguity creates tickets, rework, or risk.

A practical prompt pattern:

Ask the model to identify the user’s task first. Then ask it to produce a manual-style answer with prerequisites, definitions, numbered steps, expected result, common errors, and recovery steps. If the answer depends on a product, policy, API, or current pricing, require citations from approved material and mark unknowns as unknown.

Then test it with real users. Can a new employee complete the task? Can a customer follow the page without support? Does the output reduce back-and-forth, or does it just look cleaner?

That is the useful metric. Not whether the prose is elegant.

For builders, the move is simple: stop prompting for “better writing” and start prompting for operational artifacts. Take one messy explainer or SOP this week, rewrite it in a controlled manual style, then compare failure points before and after. The catch most readers miss is that the style is only half the system. The real win comes when the manual-style output is tied to trusted source material and tested against actual user tasks.