AI can now produce a surprising amount of work before a human catches up.

A coding agent can inspect a repository, edit twelve files, run tests and propose a pull request while you are doing something else. A research agent can search dozens of sources and return a report. A data agent can inspect a failed pipeline and suggest a fix.

Then comes the awkward part.

You have to understand what it did.

Andrej Karpathy recently pointed at this problem from an unexpected direction. On October 2, he suggested asking language models to explain things using ASD-STE100, the controlled English developed for technical documentation in aerospace.

Sometimes, he said, he asks for something closer to "80% of the way to ASD-STE100" because the full standard is quite strict.

But that was only the first step.

Karpathy then moved from simplified text to diagrams, from diagrams to interactive HTML pages, and from HTML to custom explainer videos.

His underlying argument was more interesting than the prompting trick:

As models perform more of the work, humans will spend more of their time understanding and supervising what the models produced.

We have spent years trying to make AI generate more.

We may now need to spend more time making its output cheap for humans to inspect.

Why an aircraft manual?

ASD-STE100, formally Simplified Technical English, was not designed for chatbots.

Its roots go back to aerospace maintenance documentation. The problem was practical: technical instructions had to be understood consistently by people from different linguistic backgrounds, sometimes while working on equipment where ambiguity had real consequences.

The current Issue 9 was released on January 15, 2025.

It contains 53 writing rules and a controlled dictionary of roughly 900 approved general words. In general, one approved word gets one meaning and one part of speech. Technical terminology is still allowed when the subject requires it.

One of the simplest examples explains the philosophy.

Ordinary English might use:

• start
• begin
• commence
• initiate
• originate

STE selects start.

Not because "commence" is a bad word.

Because vocabulary variation adds no useful information here.

If an aircraft manual uses "start" on page 10, "initiate" on page 20 and "commence" on page 30, the reader must decide whether the writer intended three different actions.

STE removes that question.

That happens to attack a habit language models have in abundance.

LLMs often write for variety. Engineers read for meaning.

Ask a language model for a long technical explanation and watch what happens to terminology.

A "service" becomes a "system."

Then it becomes a "component."

Then a "platform."

Later, it may become a "solution."

The model may still mean the same thing each time.

A human reviewing an architecture cannot safely assume that.

Literary writing benefits from variation.

Technical review often benefits from repetition.

If the same database appears seven times in an explanation, calling it the same thing seven times is useful.

The goal is not beautiful prose.

The goal is low-cost comprehension.

Consider an illustrative incident report.

A typical LLM might produce this:

The ingestion workflow experienced an authentication-related disruption after the credential validation mechanism failed to successfully verify the supplied token. This subsequently prevented the downstream processing layer from executing as expected.

Nothing is technically wrong with the sentence.

But compare it with:

The ingestion job received the token.
The authentication service rejected the token.
The ingestion job stopped.
The downstream job did not start.

The second version is less elegant.

It is also easier to inspect.

You can ask four concrete questions:

• Did the job receive the token?
• Which service rejected it?
• Did ingestion stop?
• Did the downstream job run?

That is much closer to how an engineer reviews a failure.

"80% ASD-STE100" may be more useful than 100%

There is an important qualification.

Karpathy did not suggest turning every AI conversation into certified aerospace documentation.

His "80%" formulation is useful precisely because full ASD-STE100 is a real standard with detailed rules and a controlled dictionary. Writing correctly in it is not simply a matter of making sentences short.

The organization responsible for the standard explicitly says that writing proper STE requires both subject knowledge and knowledge of the standard.

So for normal AI work, "80% ASD-STE100" is better understood as a style instruction, not a compliance claim.

A practical version would be:

Explain this approximately 80% of the way to ASD-STE100.
Use short, direct sentences.
Use the same term for the same concept.
Prefer active voice.
Put one important action or idea in each sentence.
Keep all technical details, conditions and uncertainties.
Do not add decorative wording.

That last part matters.

Making an answer easier to read must not mean deleting the qualifications that make it correct.

"Usually" cannot silently become "always."

"May fail" cannot become "fails."

"Observed in one benchmark" cannot become "proven."

Comprehension bought by throwing away precision is not much of an improvement.

But Karpathy did not stop at writing

This is the part of his post that deserves more attention.

After ASD-STE100, he suggests diagrams and images.

Then interactive web pages.

Then custom explainer videos.

That progression changes the question.

Instead of asking:

How can the model explain this better?

ask:

What is the cheapest format for me to understand and verify this?

Those are different problems.

Suppose you ask an agent:

Explain how authentication works in this application.

It could respond with 1,500 words.

Or it could produce a simple flow:

Browser
   |
   v
Login API
   |
   v
Identity Provider
   |
   v
Access Token
   |
   v
API Gateway
   |
   +------ valid ------> Application
   |
   +------ invalid ----> 401

For this question, the diagram may be superior because the important information is structural.

Now consider:

Explain why changing batch size affects GPU memory.

Text can explain it.

A diagram can improve it.

But a tiny HTML page may be better still.

Give the reader sliders for batch size and sequence length. Show memory usage change as they move them. Let them toggle FP32, BF16 and quantized weights.

The reader is no longer reading an explanation of a relationship.

They are manipulating the relationship.

Disposable software is the strange new part

Five years ago, building a custom web application to explain one technical concept would usually have been ridiculous.

The explanation might take ten minutes to read.

The application might take a day to build.

The economics made no sense.

Code generation changes that.

If an agent can create a useful interactive explanation quickly, the application does not need customers.

It does not need a roadmap.

It does not need version 2.

It may not even need to exist tomorrow.

Use it once.

Understand the problem.

Delete it.

Karpathy describes this category as large, custom, discardable software artifacts that become possible because intelligence and code are becoming abundant.

That deserves more attention than the phrase "write in ASD-STE100."

We normally think software is valuable because people continue using it.

AI makes another category plausible:

software whose entire purpose is to help one human understand one thing once.

A generated architecture explorer for one code review.

A small simulator for one capacity-planning decision.

An animated execution trace for one distributed-systems bug.

An interactive timeline for one production incident.

None of these needs to become a product.

The new bottleneck is review

Imagine an engineer who previously spent three hours fixing a difficult bug.

Two hours went into finding the cause.

One hour went into implementing and testing the repair.

Now give the first two hours to an agent.

Perhaps it produces a patch in ten minutes.

That does not make the task a ten-minute task.

The engineer still has to determine:

• What did the agent change?
• Why?
• Which assumption did it make?
• Which execution path does the patch affect?
• What happens under concurrency?
• What does the test prove?
• What did the agent fail to test?

Generation became dramatically cheaper.

Verification did not become equally cheap.

This pattern appears outside coding too.

A research agent can collect 40 sources faster than you can verify 40 sources.

A data agent can propose 15 transformations faster than you can validate their business meaning.

An AI security tool can generate 50 findings faster than a team can distinguish meaningful vulnerabilities from noise.

The output rate can exceed the review rate.

When that happens, adding another faster model does not necessarily solve the problem.

The human interface becomes part of the system architecture.

Readability can also make wrong answers more dangerous

Clear output feels trustworthy.

That can be dangerous.

The ASD Simplified Technical English Maintenance Group now has explicit guidance about AI-generated STE. It warns that AI text can appear clear, authoritative and consistent with the standard while still applying its rules incorrectly.

Its warning can be summarized simply:

Plausibility is not verified compliance.

The same principle applies far beyond STE.

A beautiful architecture diagram can show the wrong architecture.

An interactive simulator can implement the wrong equation.

A polished video can explain a hallucination perfectly.

There is even a small irony around Karpathy's own post. A later line-by-line comparison of the ASD-STE100 reference image attached to the post against Issue 9 found several inaccuracies in the cheat sheet.

The image was easy to understand.

That did not automatically make every detail correct.

This is exactly why comprehension and verification should not be confused.

A good AI interface should help you inspect the claim, not merely make the claim pleasant to consume.

A better default prompt

For technical work, I would not use:

Explain this in detail.

That almost invites a wall of prose.

I would use something closer to:

Explain this approximately 80% of the way to ASD-STE100.
Preserve every important fact, condition, number and uncertainty.
Use consistent terminology and short direct sentences.
Do not use different words for the same component merely for variety.

Then add:

Do not default to prose.
Choose the format that makes the result easiest to understand and verify.
Use concise text, a diagram, a table or interactive HTML when appropriate.

For an agent that has actually performed work, I would go further:

Show me what changed, why it changed, the assumptions you made, the evidence that supports the change, and what remains uncertain. Choose the clearest format for each part.

That is closer to a review interface than a chatbot response.

We optimized the wrong side of the conversation

A remarkable amount of AI engineering focuses on what goes into the model.

• Prompt design
• Context windows
• RAG
• Memory
• Tool definitions
• System prompts
• MCP servers
• Agent skills

All of that is useful.

But increasingly capable agents create a second problem on the other side.

How does a human efficiently understand what came back?

For a chatbot answering one question, plain text is usually fine.

For an agent that researched 60 documents, edited 20 files, called seven tools and made several judgment calls, a transcript starts to look like a debug log.

We would never intentionally design a production system where the operator's primary dashboard was thousands of lines of raw logs.

Yet that is surprisingly close to how we interact with many AI agents today.

Karpathy's ASD-STE100 suggestion is useful because it improves the lowest rung of that interface.

His bigger suggestion is more important.

Sometimes the answer should not be prose at all.

As AI gets better at doing the work, the next interface problem is making its work cheap enough for a human to understand, question and approve.

The AI did the work.

Now make it explain itself.

Sources

• Andrej Karpathy, October 2, 2026 - original discussion of ASD-STE100, diagrams, interactive HTML, explainer videos and human oversight.
• ASD Simplified Technical English Maintenance Group, ASD-STE100 Issue 9 - current standard, released January 15, 2025.
• ASD STEMG, About STE - history of Simplified Technical English, its writing rules and controlled dictionary.
• ASD STEMG, Frequently Asked Questions - explanation of controlled terminology and synonym restrictions.
• ASD STEMG, Simplified Technical English and Artificial Intelligence - guidance on AI-generated STE and human verification.