AI Output Too Fast to Review? Adopt Aviation Writing Standards & Visual Aids
The article argues that AI generation speed outpaces human review capacity, creating a bottleneck. It proposes adopting aviation's Simplified Technical English principles—short sentences, consistent terminology, active voice, structured steps—to make AI outputs more readable. It also recommends diagrams for relationships, interactive web pages for parameter exploration, and explainer videos for complex reasoning, while preserving verification checkpoints with evidence, conditions, and risks.
Generation completion does not equal task completion
An AI task delivery time can be roughly split into generation, understanding, verification, and rework. Even if some stages run in parallel, each cost remains after generation finishes. The diagram illustrates how results pile up before human understanding and verification when generation accelerates.
If every AI answer mixes repetitive summaries, vague terms, and irrelevant background, readers must first clean that up. Worse, the same object may appear under three different names, forcing reviewers to decide whether they are synonyms or distinct components. The goal is not merely "write less" but to reduce guesswork, back‑and‑forth searching, and omissions during review.
Why aviation maintenance manuals are worth borrowing
ASD‑STE100 (Simplified Technical English) uses writing rules and a controlled vocabulary to help readers understand technical documents, especially non‑native English speakers. The first guide was published in 1986 as the AECMA Simplified English Guide; the ASD‑STE100 name was adopted in 2005. Maintenance personnel need to know who operates what, under what conditions, and in what sequence — a requirement shared with reviewing AI deployment notes, troubleshooting advice, and code changes: reduce ambiguity.
Key rules adapted from ASD‑STE100:
Procedural sentences ≤ 20 English words; descriptive sentences ≤ 25 English words — Avoid nesting multiple conditions in one breath
Each sentence usually gives one instruction; synchronous actions are an exception — Clarify the order of operations
Approved words used only with their defined meaning and part of speech — Reduce drift of the same word across contexts
Procedural instructions use active voice — Make the actor and action explicit
One paragraph per topic; complex content uses vertical lists — Lower the cost of locating steps
The standard permits compliant technical names and verbs; it is not a requirement to force every domain concept into a small dictionary. It also does not guarantee zero ambiguity — wrong device states, missing preconditions, or erroneous steps still cause problems.
Adapt principles for Chinese output, don’t mechanically copy English word counts
Karpathy mentions relaxing the requirement to "80% of the way to ASD‑STE100" — a prompt hint, not a formal compliance level or measurable score. For Chinese, the author prefers explicit requirements: short sentences, one operation per sentence, consistent terminology, explicit conditions, ordered steps. English word limits cannot be mechanically converted to Chinese character counts; deleting necessary subjects or conditions to meet a count makes text harder to understand.
Editing example (not a model benchmark):
Before: 为了进一步提升任务处理过程中的可靠性,我们建议在遇到一些可能具有暂时性的网络异常时,引入适当的重试机制,同时结合指数退避和一定程度的随机抖动,从而避免对下游服务造成过大的瞬时压力,不过还需要充分考虑请求的幂等性。 After: 仅对暂时性错误自动重试。重试前,确认重复执行不会产生额外副作用。两次重试之间使用指数退避,并加入随机抖动,以减少集中重试对下游的压力。
The second version is easier to scan because conditions, actions, and reasons occupy distinct positions. However, "transient error" still needs per‑interface definition, and "no extra side effects" requires implementation evidence. Clear writing exposes these gaps; it does not solve them.
Software documentation can also borrow from the Google Developer Documentation Style Guide, which emphasizes explicit actors, conditions before instructions, and numbered lists for sequence — directly applicable to API docs, runbooks, and AI‑generated technical explanations.
Give AI an executable output requirement
Simply saying "be concise" may cause the model to drop key constraints. The following prompt works well for Chinese technical explanations and can be copied directly:
请借鉴 ASD-STE100 的清晰写作原则,用自然中文回答。
采用宽松风格,不声称符合完整标准。
先给结论,再解释关键原因。
每句尽量表达一个意思;操作步骤使用编号。
同一对象始终使用同一名称。首次出现的术语给出解释。
明确谁执行什么操作;条件放在操作之前。
删除寒暄、重复总结和不影响判断的背景。
保留必要前提、例外、风险与不确定性。
事实附来源;演示示例与实测结果分开标注。
关系或分支复杂时,配一张有解释价值的图。If AI is writing code, add:
完成后先提交审查摘要:
1. 哪些行为改变了,影响哪些入口。
2. 关键改动对应的文件与位置。
3. 实际运行的测试及结果;未运行的检查单独列出。
4. 已知风险和需要人工确认的事项。
不要用“已全面验证”替代具体证据。This summary provides a review entry point. When checking permissions, data migration, concurrency, or compatibility, reviewers still need to read the relevant code and tests. The summary’s value is helping locate where deep inspection is needed.
Charts, web pages, videos — each solves a different problem
Karpathy also suggests delivering output as charts, HTML pages, and custom explainer videos. These formats let the model shoulder more information‑organization work. The author selects based on the reader’s task. The diagram maps understanding actions (left) to delivery media (right); they are paired, not a mandatory upgrade from text to video for every answer.
Charts suit relationship viewing. Request flows across components, failure propagation, retry termination conditions — these have spatial, temporal, and branching structure. A diagram lets readers follow arrows to check logic. Key conditions must still be labeled; a pretty arrow cannot replace causal explanation.
Interactive web pages suit condition changing. For example, understanding the "results enter review queue" mechanism: adjust generation speed, review speed, and result size to observe queue behavior. The page must expose the calculation formula and state simplifying assumptions; a queue simulation must not be packaged as a team productivity predictor. HTML should also retain a static conclusion for citation and archiving.
Explainer videos suit step‑by‑step reasoning. For instance, gradually showing a concurrency conflict or how a mathematical object evolves. Karpathy referenced 3Blue1Brown‑style custom explainers; this is an exploration direction, not a claim that models already stably match that channel’s teaching quality.
Remotion can serve as a video implementation tool: it supports programmatic video creation with React, but after choosing a tool, scripting, verification, and revision of visuals and narration remain. Video also incurs narration, subtitle, synchronization, and playback‑wait costs. Whether it becomes a daily recording method depends on task‑specific verification cost; today it can be used for key processes that static diagrams struggle to explain.
Scenario‑deliverable mapping:
Review code changes — Primary deliverable: Clear summary + code diff. Also retain: File locations, test results.
Understand system dependencies — Primary deliverable: Topology diagram. Also retain: Boundaries, connection meanings.
Understand failures and retries — Primary deliverable: Flowchart or state diagram. Also retain: Branch conditions, termination conditions.
Compare parameter impact — Primary deliverable: Interactive web page. Also retain: Formulas, assumptions, static conclusion.
Learn continuous reasoning — Primary deliverable: Segmented explainer video. Also retain: Text script, key steps.
Readable answers must also be traceable
Richer expression forms demand stronger verification entry points. A diagram can neatly draw a wrong dependency; a web page can animate a wrong formula. Visual clarity and factual correctness are two separate checks.
The red "manual verification" node in the diagram is a pre‑delivery checkpoint. The left loop indicates that when doubts arise, one must return to conclusions, conditions, and evidence, modifying the implementation if necessary. The flow represents the article’s review recommendation.
For technical output, the author recommends preserving at least three things: conditions the conclusion depends on, sources or test records supporting the conclusion, and files, formulas, or implementation locations that enable further checking.
When length limits conflict with these details, first delete repetitive explanations, then move necessary details into traceable appendices. Do not turn "unverified" into "no problem" just to make the answer look crisp.
Next time you ask AI to deliver a task, start with a concrete requirement:
Give me review‑ready results: explicit changes, conditions, evidence, and risks; use diagrams when explaining relationships.
Generation speed has already increased. The next optimization target is the distance between result appearance and our ability to understand, verify, and decide.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Ops Development & AI Practice
DevSecOps engineer sharing experiences and insights on AI, Web3, and Claude code development. Aims to help solve technical challenges, improve development efficiency, and grow through community interaction. Feel free to comment and discuss.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
