Andrej Karpathy, uno de los fundadores de OpenAI, ha propuesto pedir a los modelos de lenguaje que redacten sus explicaciones siguiendo ASD-STE100, el inglés técnico simplificado con el que se escriben los manuales de mantenimiento aeronáutico. Lo planteó a principios de octubre en X, dentro de una reflexión más amplia: si la IA hace cada vez más trabajo por su cuenta, a las personas les tocará sobre todo revisar y entender lo que produce, y el texto largo y adornado que generan los modelos es un mal formato para eso.
Las claves de la propuesta de Karpathy sobre ASD-STE100 en 30 segundos
- Qué propone: pedir a los modelos de IA que escriban según ASD-STE100, el inglés técnico simplificado de los manuales aeronáuticos.
- Qué es el estándar: lo mantiene la asociación europea ASD, tiene unas 900 palabras aprobadas y 53 reglas; la versión vigente es la Issue 9, de enero de 2025.
- Más allá del texto: Karpathy sitúa por encima los diagramas, las páginas HTML interactivas y los vídeos explicativos generados.
- Por qué importa: si la IA produce más trabajo, revisarlo rápido y sin ambigüedades pasa a ser una tarea central de los equipos técnicos.
Según recoge Search Engine Journal, Karpathy explicó que le había funcionado bien pedir a los modelos que explicaran las cosas en ASD-STE100 porque el estándar impone restricciones fuertes de estilo. Admitió que es bastante estricto y que, cuando relaja la petición, se conforma con un texto que llegue más o menos al 80 % de ese nivel. Para quien administra sistemas la idea tiene una lectura inmediata: buena parte de lo que hoy se pide a un asistente de IA son procedimientos, explicaciones de errores, resúmenes de incidentes y documentación interna, justo el tipo de texto donde una ambigüedad cuesta tiempo o algo peor.
Un estándar de aviación con 900 palabras y 53 reglas
ASD-STE100, conocido como Simplified Technical English (STE), nació en la industria aeroespacial europea para que los manuales de mantenimiento se entendieran sin margen de interpretación, también por técnicos cuya lengua materna no es el inglés. El grupo que lo mantiene, el STEMG, se creó en 1983 dentro de la asociación que hoy es ASD (Aerospace, Security and Defence Industries Association of Europe), y la primera guía oficial, entonces con el nombre de AECMA Simplified English, se publicó en 1985. Algunos textos sitúan su origen a finales de los años setenta; la documentación de referencia fecha esos dos hitos en los ochenta.
La versión vigente es la Issue 9, publicada en enero de 2025, y se descarga gratis desde la web de ASD desde la Issue 6, de 2013. Combina dos piezas: un diccionario de unas 900 palabras aprobadas, la mayoría con un único significado, y 53 reglas de redacción. Entre las más conocidas están limitar las frases de procedimiento a 20 palabras y las descriptivas a 25, dar una sola instrucción por frase, usar la voz activa y no cambiar de término para variar: si una pieza es un perno, se llama perno en todo el documento. El estándar ya no es solo cosa de aviones. Según el registro de distribución de la Issue 8, el 64 % de quienes lo descargaron trabajaba fuera del sector aeroespacial y de defensa, en ámbitos como la automoción, la energía o los dispositivos médicos.
Hay dos matices que conviene tener presentes. El primero es que STE es una norma para el inglés: aplicada a un texto en castellano solo se puede tomar su espíritu (frases cortas, una acción por paso, terminología fija y voz activa), no su diccionario. El segundo es que la propia ASD advierte en sus preguntas frecuentes de que el estándar no está pensado para escritura general y de que ninguna herramienta sustituye a conocerlo. Tras la publicación de Karpathy circularon en GitHub varias skills para agentes que aplican reglas de STE, pero al menos una de las más compartidas no incluye el diccionario, que es la mitad del estándar.
Del texto al HTML desechable: la escalera de formatos
La propuesta de Karpathy no se queda en la redacción. En su publicación ordenó varios formatos de menos a más útiles para entender lo que produce un modelo: primero, texto controlado en ASD-STE100; después, diagramas, que considera mucho más fáciles de procesar; luego, páginas HTML interactivas; y, en lo más alto, vídeos explicativos al estilo de 3Blue1Brown generados por el propio modelo, con narración sintetizada mediante un servicio como ElevenLabs o una alternativa local. Es el formato en el que dijo tener más confianza. Cerró animando a pedir lo que llamó large, custom, discardable software artifacts: piezas de software grandes, hechas a medida y pensadas para tirarse después de usarlas.
La idea de fondo es que generar código ya cuesta tan poco que compensa crear una herramienta solo para entender algo y borrarla al terminar. En un artículo publicado en Medium, el desarrollador Nikhil cuenta que probó las dos recomendaciones durante una semana. Para entender cómo afecta la tasa de aprendizaje al descenso de gradiente pidió un único fichero HTML con un control deslizante y una bola que rodaba sobre una superficie de error; según su relato, le bastaron unos segundos moviendo el control para entender lo que antes habría leído en varios párrafos, y después borró el archivo. También describe que añadir a sus peticiones técnicas una instrucción del tipo «explica esto con el espíritu de ASD-STE100» hizo que las respuestas se parecieran más a un manual de taller que a una charla.
Qué puede aprovechar un equipo de sistemas
Los runbooks, los procedimientos de cambio y los informes posteriores a un incidente comparten problema con los manuales de aviación: alguien tiene que seguirlos bajo presión y sin dudar de qué significa cada paso. Pedir a la IA que redacte esos documentos con una acción por línea, frases de menos de 20 palabras y el mismo nombre para cada servidor, servicio o volumen de principio a fin reduce las lecturas dobles. Lo mismo vale para revisar lo que un agente propone hacer: una lista de pasos cortos y con términos fijos se audita mejor que tres párrafos donde el mismo disco aparece como volumen, unidad y almacenamiento.
Los otros escalones también encajan en el trabajo diario. Un diagrama de arquitectura en Mermaid o una vista de infraestructura como las que genera FossFLOW explican una topología mejor que una descripción, y una página HTML desechable con controles puede servir para ver cómo cambia la latencia o el uso de memoria al mover un parámetro. Encaja además con prácticas que ya usan muchos equipos, como dar a Claude Code un prompt detallado para auditar un proyecto. La propuesta de Karpathy es una recomendación de uso, no una función de ningún producto, y su eficacia depende del modelo y de la tarea, pero tiene la ventaja de que se puede probar en el siguiente prompt.
Preguntas frecuentes
¿Qué es ASD-STE100?
Es el Simplified Technical English, un inglés controlado creado por la industria aeroespacial europea para redactar documentación técnica sin ambigüedades. Tiene unas 900 palabras aprobadas y 53 reglas de redacción, y su versión vigente es la Issue 9, de enero de 2025.
¿Qué ha propuesto Andrej Karpathy?
Pedir a los modelos de IA que expliquen las cosas siguiendo ASD-STE100 y, cuando el texto no basta, pedir diagramas, páginas HTML interactivas o vídeos explicativos generados a medida.
¿Sirve ASD-STE100 para textos en español?
El estándar está definido para el inglés. En castellano solo pueden aplicarse sus principios: frases cortas, una acción por paso, voz activa y el mismo término para cada elemento.
¿Es gratis el estándar?
Sí. Desde la Issue 6, de 2013, ASD permite descargarlo sin coste desde su web.
Fuente: Andrej Karpathy en X (vía Search Engine Journal), ASD-STE100 y Medium
