Karpathy's Aircraft-Manual Prompt: What It Means for AEO

Karpathy's suggestion tells AEO teams something useful but narrow. People are starting to ask models to rewrite the web into plainer, stricter explanations, and pages that already read that way lose almost nothing in the translation. It doesn't change how engines choose sources. It raises the value of writing that survives being compressed, quoted and re-explained.

Key takeaways

• Karpathy's tip is a prompting habit, not a ranking change, but it shows what readers want back from AI: plain, unambiguous, structured answers.
• Pages written like a good manual survive being summarised, quoted and re-explained by a model with the least damage.
• Engines select passages, not whole pages, so each section should answer one question completely and stand alone.
• Rewrite your highest-value pages first: one instruction per sentence, one term per concept, steps numbered, tables where the data is a table.
• Measure citations and referral behaviour per page before and after edits, and keep the changes small enough to attribute.
• Do not rewrite the whole site in a stilted style, and do not chase every new format an LLM can produce.

What Karpathy suggested, and what it isn't

Search Engine Journal reported that Andrej Karpathy, an OpenAI founding member, suggests asking LLMs to explain topics in an aerospace writing standard. He also suggests asking for answers as diagrams, HTML pages or custom explainer videos. That is the development in full: a prompting tip from a prominent practitioner.

It is not a product launch. It is not a change in how any search engine ranks or cites anything. Nobody has published evidence that answer engines prefer manual-style prose, and you should be wary of anyone who claims they have.

Why aircraft manuals, though? Maintenance documentation is written for a technician who is tired, in a hangar, possibly reading in a second language, and cannot afford to misread a step. The best-known version of that discipline is Simplified Technical English. Sentences stay short. Each sentence carries one instruction. A word means one thing and is used the same way every time. Warnings come before the step they apply to, not after.

A model asked to write that way produces text with very little slack. That's the point of the tip, and it's the part worth stealing.

Why a prompting habit matters for AEO and GEO

Most AEO talk is about what engines do to your content. This tip points at the other half: what users do to engines. If a growing number of people prompt for stripped-down explanations, tables or diagrams, then the model is regularly transforming your page into something else before the reader sees it.

That transformation is where ambiguity hurts. A sentence like 'It typically takes a few weeks, depending on several factors' survives a rewrite as mush. A sentence like 'Approval takes 10 business days; add 5 if the account is new' survives as a fact. The model can restate it, tabulate it, or turn it into a diagram without inventing anything.

So the practical read is this. Writing for answer engines and writing for a reader who has asked for 'the manual version' converge. Both reward text that can be lifted out of context without losing its meaning.

There's a second effect, quieter. Teams that adopt this habit themselves, using LLMs to explain competitor pages, regulations or tools to their own staff, will start to notice which sources explain cleanly and which don't. Your content gets judged by the same experience.

How AI answer engines actually select and cite sources

The mechanics differ by engine and change often, so check each vendor's own documentation and your own testing rather than any blanket rule. Still, a few patterns are stable enough to plan around.

Most answer engines that cite sources work in two stages. First, a retrieval step finds candidate documents or passages for the query, often by expanding one question into several narrower ones. Second, a generation step writes the answer and attaches citations to the passages it leaned on. Retrieval operates on chunks, which means a page is rarely judged as a whole. A single clear paragraph under a descriptive heading can be cited from a page that is otherwise forgettable.

Three things follow from that.

1. A passage has to make sense alone. If the key sentence starts with 'This also means' and the thing it refers to sits two paragraphs up, the chunk is weaker.
2. Headings act as labels. A heading phrased as the question a person would ask gives the retrieval step something to match.
3. Structured data and plain HTML both matter. Search Engine Journal's Ask An SEO column on common structured data mistakes that hurt AI visibility is a reasonable reminder that markup which contradicts or duplicates the visible page creates trouble rather than help.

Notice what's absent from that list: writing style as a direct ranking signal. Style matters because it controls whether the chunk is quotable and unambiguous, not because an engine scores it for 'manual-ness'. Keep that distinction. It stops you from over-engineering prose that engines never asked for.

Writing to a manual standard, in practice

You don't need a style guide with 50 rules. You need five habits applied to the pages that matter most: the ones that answer a buyer's real question, such as pricing logic, setup, comparison, compliance or troubleshooting.

1. One instruction or claim per sentence. If a sentence has 'and' joining two actions, split it. 'Export the report and send it to finance' becomes two sentences, or two numbered steps.
2. One term per concept. If your product page says 'workspace', the help article says 'project' and the pricing page says 'account', a model summarising all three will treat them as three things, or blur them into one. Pick the word. Use it everywhere.
3. Put the condition before the action. 'If the audience is under 1,000 contacts, skip the holdout' reads cleanly. 'Skip the holdout, unless the audience is under 1,000' invites misreading.
4. Number sequences and bullet sets. Anything that is a procedure gets numbers. Anything that is a list of parallel options gets bullets. Prose is for reasoning and trade-offs.
5. State the number or say there isn't one. Replace 'fast', 'affordable' and 'quickly' with a figure you can defend, or with a plain statement of what it depends on.

A worked example. Imagine a B2B analytics vendor with a page titled 'Data retention'. The old copy says: 'We keep your data for as long as you need it, subject to your plan and applicable regulations, and you can always request deletion.' A model asked to summarise that has nothing to hold. The rewrite: 'Event data is kept for the retention period set on your plan. You can request deletion at any time; deletion requests are completed within the period stated in the contract.' Better still, a small table of plan against retention period, with real values from the contract. Same page, same facts, now quotable.

Do this to ten pages before you do it to a hundred.

Diagrams, HTML pages and video: the format part of the tip

The second half of the tip, asking for diagrams, HTML pages or explainer videos, is less about your copy and more about what users will expect an answer to look like. It's early, and nobody can tell you how far it goes. Take a measured position.

For most teams the right response is cheap. Make sure the facts in your diagrams also exist as text. A process diagram with no adjacent description is invisible to a text-first retrieval step, and useless to a model that is asked to restate it. Give every diagram a caption that states its conclusion, and keep the labels in HTML rather than baked into an image.

Similarly, if you have comparison data, publish it as a real table, not a screenshot. A model can turn a table into a chart on request. It cannot reliably turn a JPEG into a table you'd trust.

What you should not do is start producing explainer videos for every page because a model might one day generate them. Users can already ask for that on demand. Your advantage is being the accurate source those generated explainers draw from, not competing with them on format.

How to measure whether the changes help

AI search measurement is noisy. Citations vary between runs, between engines, between days. So the goal is not a precise score. It's a before-and-after comparison on a fixed set of questions, with a changelog you can trust.

Here's a plan that a small team can run without special tooling.

Question	Where to look	Owner	Cadence
Is the rewritten page cited for its target questions?	Fixed list of 20-30 prompts run against each engine you care about, logged in a sheet	SEO lead	Weekly, same prompts
Is the answer the engine gives accurate?	Read the answer against the page; flag wrong numbers or terms	Content lead	Weekly, on changed pages
Does AI-referred traffic behave differently?	Referral and landing-page reports, segmented by AI sources	Analytics lead	Monthly
Did the page change cause the shift?	Changelog of edits with dates, one change batch per page at a time	Growth lead	Per edit
Is markup consistent with the visible page?	Structured data validation on changed templates	Technical SEO	Per release

Two cautions. First, referral data from AI surfaces is patchy. Search Engine Roundtable reported that Google is testing URL tracking parameters on links in AI Overviews and AI Mode, which suggests attribution is still being worked out. If your analytics treat unknown parameters carelessly, you may be mislabelling or splitting that traffic. A clear tracking specification for how those parameters are read is worth writing before the data arrives, not after.

Second, changes must be isolated enough to learn from. If you rewrite copy, restructure the page and add schema in one release, you won't know which part moved anything. Where a page is high-traffic, consider treating the rewrite as an experiment, with Evolve as the place Cresia covers experimentation, and keep the AI-citation tracking alongside it.

For teams that want the visibility side in one place, MediaPilot is Cresia's product for media and AI-search visibility. Check the product page for what it covers today.

What not to do

The risk with any tip from a famous name is that it turns into a content mandate. Resist these.

• Don't rewrite the whole site in telegraphic prose. Brand pages, opinion pieces and case studies need voice. Manual style belongs on pages whose job is to answer a factual or procedural question.
• Don't treat 'aircraft manual' as a ranking factor. There is no evidence for it. It's a writing discipline that makes passages easier to quote correctly.
• Don't strip the nuance. A manual is clear because the domain is bounded. Where your answer is 'it depends', say what it depends on, in a list. Hiding the conditions to sound crisp makes the page wrong, and models will repeat the wrongness confidently.
• Don't duplicate pages for the machine. A 'plain version' and a 'real version' of the same page splits signals and doubles maintenance. Fix the original.
• Don't chase formats. Diagrams, HTML explainers and video are things a user can ask a model to produce. Spend your effort on the underlying facts and their structure.
• Don't skip the owners. Plain writing exposes disagreements. If product, legal and marketing each use a different term for the same thing, someone must decide. That's a marketing operations problem as much as a copy problem.

A sensible first month

Week one: pick ten pages that answer questions your buyers actually ask. Run the same set of prompts against the engines that matter to you and record what's cited and what's said.

Week two: rewrite those pages against the five habits above. Add real tables where the content is tabular. Align terminology with a short glossary agreed by product, legal and marketing.

Week three: validate structured data against the visible page, fix mismatches, and publish. Log the dates.

Week four: rerun the prompts. Read the answers, not just the citation counts. If the engine now quotes your figure correctly, that's the win. If it still cites a competitor, look at what their passage does that yours doesn't. Often it's a plain number you haven't published.

This fits comfortably inside a normal growth team workload, and none of it depends on Karpathy's tip proving to be a trend.

Frequently asked questions

Should we write our content in Simplified Technical English?

Not across the board. It's a useful discipline for procedures, specifications and troubleshooting pages, where ambiguity costs the reader something. For narrative, thought-leadership and brand pages, it would flatten the voice without a clear benefit.

Do AI answer engines prefer plain, manual-style writing?

There's no published evidence that they score for it. What's reasonable is that passages which are unambiguous and self-contained are easier to retrieve, quote and restate accurately. Treat it as a quality of the passage, not a ranking signal.

Do we need diagrams and video for AI search?

Not as a priority. Make sure the facts inside any diagram also exist as adjacent text, and publish data as real tables. Users can ask a model to generate other formats from your accurate text on demand.

How do we know a rewrite worked?

Run a fixed set of prompts before and after, log which pages are cited, and check whether the answers state your facts correctly. Change one batch of things per page at a time so you can attribute the result, and expect some run-to-run noise.

Which pages should we rewrite first?

Start with pages that answer a buyer's factual or procedural question: pricing logic, setup, comparisons, compliance, retention and troubleshooting. These are the pages most likely to be summarised, and the ones where a vague sentence does the most damage.

Sources

• https://www.searchenginejournal.com/karpathy-llm-aircraft-manual-writing/591813/
• https://www.searchenginejournal.com/what-are-common-structured-data-mistakes-that-hurt-ai-visibility-ask-an-seo/589924/
• https://www.seroundtable.com/google-ai-overview-link-tracking-parameters-42219.html