Le Apliqué a Mis Docs un Estándar Aeronáutico de 1986. Y Lo Medí.

Caveman borra tus artículos para ahorrar tokens. Un estándar aeronáutico de 1986 prohíbe eliminarlos, porque eliminarlos genera ambigüedad. Ambos dicen que hacen la escritura más clara. Solo uno fue probado en un dominio donde una mala lectura mata al lector.

La idea de este post salió del video de Ege Chelebi, The cure for AI slop is a 1986 aircraft manual. Tomó ASD-STE100 —Simplified Technical English, el lenguaje controlado en el que la industria aeroespacial escribe sus manuales de mantenimiento—, lo empaquetó como un skill de agente y lo midió contra un baseline, una lista de palabras prohibidas y las seis reglas de Orwell, en seis tareas de escritura técnica. Las violaciones por cada cien palabras bajaron 74% en Claude Sonnet y 50% en GPT-5.5. Él es cuidadoso con lo que eso significa: n=6, dependiente del modelo, y mide la forma.

Yo llevaba un tiempo pasando ese mismo estándar por dos sistemas muy distintos —un vault personal de trabajo y un plugin de documentación que mantengo— y medí otra cosa. No si la escritura mejoró. Cuánto del estándar puede verificar realmente una máquina.

La respuesta, a grandes rasgos: la mitad que menos importa. Y ese resulta ser el hallazgo útil, porque la mitad que una máquina no puede verificar es donde el estándar se gana el sueldo — y el segundo port produjo entre seis y nueve bugs reales para demostrarlo.

Los Fundamentos

Concepto. Un lenguaje natural controlado es un subconjunto restringido de un idioma real, con vocabulario fijo y gramática fija. ASD-STE100 aprueba 875 palabras generales, le asigna un solo significado a cada una, exige formas de oración específicas y limita la longitud a 20 palabras para procedimientos y 25 para descripciones. El vocabulario del dominio es ilimitado: el estándar no lista ni una sola pieza de avión. Define 22 categorías de “sustantivo técnico” y 4 de “verbo técnico”, y cualquier palabra que encaje en una categoría es legal.

Conexión. Ya usas un lenguaje controlado. El RFC 2119 reservó MUST, SHOULD y MAY y le dio a cada uno exactamente un significado, para que quien escribe una especificación no pueda matizar sin darse cuenta. El mismo mecanismo, con cinco palabras en vez de 875.

Por qué ahora. Tu prosa tiene un segundo lector. AGENTS.md, CLAUDE.md, archivos de skills, descripciones de tickets — eso ya no es documentación, es entrada para algo que ejecuta. Un humano que encuentra una ambigüedad pregunta. Un agente llena el vacío con una suposición plausible y sigue adelante, y te enteras tres pasos después.

Chequeo de realidad. Esto hace que la escritura sea verificable. No la hace correcta. Todo lo que sigue es una variación de esa frase.

Los Rulesets Le Ganan a los Adjetivos

Dos herramientas estuvieron en todas partes esta temporada, y son la razón por la que el resultado de STE aterriza como aterriza.

Caveman le quita el relleno a la salida del modelo y responde en lenguaje telegráfico —una reducción de tokens del 65 al 75% según las pruebas de su autor—. Ponytail es un ruleset de YAGNI que baja al agente por una escalera de seis pasos antes de que escriba cualquier cosa: ¿esto necesita existir?, ¿lo hace la stdlib?, ¿lo hace la plataforma?, ¿ya es una dependencia?, ¿es una sola línea?, y solo entonces el mínimo que funcione.

Ambas hacen lo mismo, y lo hacen bien: reemplazaron un adjetivo por un ruleset. “Sé conciso” y “no sobre-diseñes” son instrucciones que los modelos asienten e ignoran, porque el objetivo no está definido. Una escalera de decisión sí lo está. La misma lección que todos aprendimos a los golpes sobre el contexto: la especificidad lo es todo.

Ninguna de las dos apunta a la ambigüedad en la prosa. Caveman apunta al conteo de tokens; Ponytail, a las líneas de código. Un ruleset dirigido específicamente a que no te malinterpreten existe desde 1986, escrito para un mecánico no angloparlante con una llave en la mano a las 3 de la mañana, donde una mala lectura cuesta bastante más que un turno perdido.

Lo cual produce una colisión directa. Caveman elimina artículos porque cuestan tokens. La regla 4.5 de STE dice que no elimines artículos ni demostrativos; la 4.2 dice que no omitas palabras en absoluto. Ambas herramientas prometen claridad y dan instrucciones opuestas.

Mi port tuvo que resolverlo, porque una línea de Kanban es deliberadamente telegráfica y no pensaba renunciar a eso. La solución generaliza: lo telegráfico es seguro cuando el formato aporta estructuralmente lo que la oración omite. Una línea con la forma #tag Owner: Task @{date} lleva el sujeto en el campo Owner, así que el sujeto ausente no está ausente. Conserva la línea corta, y exige que todos los campos estén llenos. Esa es una lectura más estricta de la regla que escribirla completa — y es justo la verificación que Caveman no hace, porque cuenta tokens, no referentes.

Port Uno: Lo Que Sí Transfirió

Lo hice en dos compuertas. La primera produjo una destilación: los 61 ítems marcados como adoptar, adaptar o rechazar, cada uno con su razonamiento. La segunda diseñó el estándar a partir de ese registro. Pareció trabajo de más y no lo fue: tres veces más adelante un veredicto quedó en duda y el razonamiento ya estaba escrito. Sáltate la primera compuerta y te quedas con las reglas pero pierdes el por qué, que es lo único que ayuda cuando una regla empieza a estorbar seis semanas después.

Tres cosas transfirieron mejor de lo esperado.

Controla el vocabulario general; nunca enumeres el dominio. Esto es lo que hace que el proyecto se pueda terminar en una tarde. Nunca catalogué nuestros productos, proveedores ni servicios — seis categorías de sustantivo y cuatro de verbo los legalizan al por mayor. Lo que queda por controlar es el pequeño conjunto de palabras generales que generan vaguedad: una lista de una página, no un programa de glosario.

Las reglas de conteo de palabras sostienen todo, y todo el mundo se las salta. La parte famosa de STE son los límites de longitud. Adóptalos solos y son inservibles en un corpus denso en identificadores y fechas. Cuatro reglas sin glamour lo arreglan: un número, una fecha, una abreviatura, un identificador, un título entre comillas, un nombre propio, un grupo con guion y cualquier paréntesis cuentan como una sola palabra. Publicar el documento de política en la wiki antes del 2026-08-01 son seis palabras, no nueve. Cuando portas un conjunto de reglas, la regla que hace viable a otra regla es fácil de pasar por alto y fatal pasarla por alto.

La sección que esperaba botar resultó ser la mejor. La sección 7 rige las instrucciones de seguridad —las advertencias de un manual de avión—, en apariencia irrelevantes para lo que yo escribo. Su forma obligatoria es [palabra de señal] + [orden o condición] + [consecuencia si se ignora], y eso es exactamente lo que debería ser un bloqueo de proyecto. La tercera parte es la que siempre falta:

• Antes: Bloqueos: esperando al equipo de plataforma.
• Después: BLOQUEO: Conseguir la aprobación del equipo de plataforma sobre la política del gateway antes del 2026-08-01. Sin eso, el requisito de tiering no es exigible.

Escribir la consecuencia no es un ejercicio de formato. Cambió repetidamente lo que el ítem significaba. Una alerta que decía “esto toca una ruta crítica” se convirtió, una vez que me obligué a terminar la frase, en “esto recrea exactamente la dependencia que la decisión de hoy eliminó, y falla en silencio”. El mismo hecho, otra urgencia, y la segunda versión es la verdadera.

La regla de mayor valor es la prohibición de los verbos compuestos del inglés —reach out to, look into, circle back, spin up, loop in—. Son vagos de una forma específica y dañina: esconden la prueba de finalización. “Contactar al proveedor” — ¿un correo enviado y sin respuesta cuenta como hecho? Ni yo ni el agente podemos decirlo, así que ninguno de los dos puede estar de acuerdo en que la tarea terminó. “Enviar un correo al contacto del proveedor” no admite discusión. Mi propio documento de formato Kanban usaba la forma mala como ejemplo oficial.

La Medición Que Me Cambió la Cabeza

Después vino la pregunta que de verdad importaba: ¿puede un script hacer cumplir esto?

El experimento más barato posible. Dos agentes, prompts neutrales idénticos byte a byte, un README, solo lectura, salida estructurada — RULE_ID | línea | texto | razón. Y luego un diff de los conjuntos de hallazgos.

	Resultado
Hallazgos del agente 1	116
Hallazgos del agente 2	104
Misma regla en la misma línea	89
Unión	131
Concordancia	68%

68% suena a estándar mediocre. No lo es: el desacuerdo no era ruido. Se dividió casi perfectamente sobre un solo eje:

Tipo de regla	Concordancia	Naturaleza
Puntuación, tiempo verbal, posición del verbo, longitud de oración	100%	Sintáctica. Visible en la cadena
Agente nombrado, voz activa, verbos compuestos	67–93%	Casi sintáctica, algo de criterio
Un nombre por cosa, abstracción, pruebas de finalización	14–40%	Semántica. Requiere conocimiento del dominio

La regla que yo había clasificado como la más importante sacó 17%. “Un nombre por cosa” — un agente encontró 11 violaciones y el otro 3, en el mismo archivo. Eso no es un defecto de la regla. Decidir si “el gateway central” y el nombre real del producto se refieren a lo mismo exige conocer el dominio, y ninguna expresión regular lo va a conocer jamás.

Dos conclusiones, y la segunda es el post entero:

1. Un linter certifica la mitad mecánica de un estándar y nada más. Nunca presentes un lint limpio como un documento limpio.
2. La automatizabilidad está inversamente correlacionada con el valor. Las reglas que atrapan ambigüedad real son precisamente las que un script no puede verificar. Diseña tu estándar para que sea linteable y vas a construir el estándar equivocado.

El Estándar Se Contradecía a Sí Mismo

Las mismas pruebas encontraron algo más incómodo que los números. Seis defectos eran el estándar contradiciéndose: un perfil cuyo propio ejemplo usaba el modo verbal que esa misma página prohíbe, dos archivos que daban conteos de oraciones distintos para la misma sección, una regla sin ID en un documento que exige IDs estables.

Todos estaban en un ejemplo, no en una regla. Los ejemplos son donde el autor se relaja, y un ejemplo malo enseña más fuerte que una regla buena. Escribí los seis en cuestión de horas y no encontré ninguno releyendo.

Port Dos: Cuando el Pase de Estilo Encontró Bugs Reales

Meses después porté la misma destilación a un plugin de documentación — otro contexto, porque las reglas de un plugin terminan copiadas en repos que no controla. El PDF original de 434 páginas nunca se volvió a abrir. Ese es el argumento más fuerte a favor del método de dos compuertas: la destilación es el artefacto duradero; la especificación es apenas su insumo.

Dos cosas cambiaron en el nuevo contexto.

La regla del 17% se volvió verificable. “Un nombre por cosa” sacó 17% en prosa porque nada en ese corpus sabía qué términos correferían. Un repo de código sí lo sabe: los identificadores, los nombres de servicios y los comandos de CLI son un registro de nombres. “Usa el término aprobado” se convierte en “usa el nombre que usa el código”, verificable con grep contra una fuente de verdad. La baja concordancia era una propiedad de los corpus sin registro, no de la regla.

Las bandas de medición tenían que volverse un contrato de entrega. No puedes publicar tres porcentajes de concordancia. Se colapsaron en dos niveles —mecánico, que se puede afirmar, y criterio, que se marca para confirmación y nunca se corrige automáticamente— más una cláusula de degradación: cualquier hallazgo cuya confirmación requiera conocimiento del dominio se reporta en nivel criterio, sin importar el nivel por defecto de su regla. Una sola frase viaja como protocolo: un pase de estilo limpio certifica únicamente el nivel mecánico.

Y ahora la parte que me encantaría decir que evité. Ejecuté este port con la historia de las seis autocontradicciones conscientemente presente, tratando activamente de no repetirla. Un agente de contexto limpio, prompt neutral, 97.291 tokens, unos nueve minutos: 64 hallazgos en nueve archivos de política, 13 de ellos en el archivo de reglas nuevo, escrito horas antes. Una regla etiquetada como mecánica cuya prueba es claramente de criterio. Tres nombres distintos para un mismo alcance, dentro del archivo que define la regla de un-nombre-por-cosa.

Ser consciente del modo de falla mientras escribes vale aproximadamente nada. Agenda la lectura de contexto limpio; no presupuestes cuidado.

Y luego el resultado que justifica todo el ejercicio. Cuando el estándar pasó a regir los propios skills y archivos de instrucciones del plugin —no su documentación, sus instrucciones— y lo corrí contra repositorios reales, aparecieron entre seis y nueve fallas que venían ocurriendo desde siempre. No hallazgos de estilo. Comportamiento real y equivocado, hasta entonces invisible.

El mecanismo es simple una vez lo ves. Los bugs vivían en los vacíos: una instrucción que no decía del todo cuál artefacto, un paso cuya prueba de finalización estaba implícita. El agente venía llenando esos vacíos con suposiciones razonables y siguiendo adelante — y una suposición razonable es indistinguible de una correcta hasta que deja de serlo. Cierra los vacíos y el agente deja de adivinar, y los lugares donde venía adivinando salen a la superficie como las fallas que siempre fueron.

Reescribir las instrucciones de un agente según un estándar controlado es un pase de búsqueda de bugs. Y los bugs que encuentra son exactamente los semánticos que ningún linter ve — la misma afirmación que hace el número 17%, llegando desde la dirección contraria.

El efecto va más allá de los archivos. Aplica las reglas a lo que el agente te escribe de vuelta —nombra la acción y su prueba de finalización, nombra al actor, usa los nombres del código, declara la consecuencia, resuelve todo referente— y se vuelve notablemente más claro qué te está diciendo, en una forma sobre la que puedes actuar. Ese bloque se publica con una excepción explícita, y esa excepción importa: las reglas prohíben las referencias vagas, no la incertidumbre honesta. Un agente que dice “no estoy seguro” te está dando información. Un agente que dice “se actualizó la configuración” está escondiendo cuál y quién.

Dónde Esto No Va

La documentación entra de lleno en el alcance: la consistencia y la previsibilidad son justo lo que necesita. Dos cosas quedan fuera, y el límite es medible.

Apliqué las reglas a una nota diaria personal. La reescritura quedó 22% más larga y se leía como un reporte de estado escrito sobre su autor. No es tuyo, pero pregúntales para que no te agarren mal parado se convirtió en Ellos son dueños de la renovación. Tú necesitas el resultado. La instrucción sobrevivió; la lectura política no. Una reescritura que se alarga y cambia de registro te está diciendo que las reglas están peleando contra el artefacto — un diagnóstico barato y mecánico de alcance equivocado. Las notas donde el matizar es la información quedan exentas, igual que cualquier cosa creativa.

Tres costos que hay que contemplar:

• Cada término reservado deja huérfana a su clase general. Reservar una palabra como nombre de producto no deja forma legal de usarla como adjetivo común. Mantén la lista de prohibidas mínima; hazla crecer solo con evidencia de una mala lectura real.
• Un pase de estilo se detiene en el bloque de código. El mío sacó a la luz bugs genuinos dentro de ejemplos de comandos, y corregir la sintaxis ahí cambia lo que la cosa hace, no cómo se lee. Reporta; no repares en silencio.
• Una regla que nunca se dispara es un dato ambiguo. Una de las mías no se disparó nunca, junto con 11 de 13 filas de reemplazo de palabras. O el alcance está mal o el corpus está sano, y no puedes saber cuál sin mirar.

Siguiente Paso

No empieces adoptando STE. Empieza preguntando qué otro estándar maduro ya resolvió el problema que estás teniendo con los agentes — la respuesta suele ser que sí, y suele ser más viejo de lo que crees.

Dos preguntas para correr contra cualquier candidato:

1. ¿Qué dice, versus cómo está construido? El setenta por ciento de ASD-STE100 es un diccionario de verbos aeroespaciales que no me servía de nada. Su arquitectura —un conjunto cerrado y diminuto de palabras generales controladas, más un conjunto abierto e ilimitado definido por categorías— fue la idea más valiosa del documento. La segunda respuesta se porta cuando la primera no. Haz ambas preguntas, por separado.
2. ¿Este dominio castiga la ambigüedad con algo peor que la vergüenza? Ese es el filtro. Los estándares escritos donde una mala lectura solo es incómoda nunca se sometieron a esfuerzo real.

Una lista corta para arrancar, toda probada en combate y nada de ella pensada para la IA: RFC 2119, un vocabulario controlado que ya tienes y probablemente usas mal. La fraseología estándar de la OACI y su protocolo de readback/hearback — un lazo cerrado que confirma el entendimiento del receptor en vez de la transmisión del emisor, que es exactamente el modo de falla de un agente confiado. Las Frases Normalizadas de Comunicación Marítima de la OMI, un repertorio fijo para tripulaciones sin idioma nativo en común. SBAR —Situación, Antecedentes, Evaluación, Recomendación—, un formato clínico de entrega de turno que pasó de los submarinos a los hospitales precisamente porque obliga a enunciar la recomendación. IEC/IEEE 82079-1, el estándar internacional para escribir instrucciones de uso.

Escoge uno. Destílalo antes de adoptarlo, y escribe el razonamiento junto a cada veredicto. Ese registro, y no las reglas, es lo que sobrevive al siguiente port.

Para Profundizar

• The cure for AI slop is a 1986 aircraft manual — el experimento de Ege Chelebi, más el kit completo con su linter y las muestras antes/después
• ASD-STE100 Issue 9 (2025-01-15) — el estándar fuente. ASD entrega una copia oficial gratuita a solicitud; el texto es material con derechos de autor, así que deriva de él en lugar de citarlo en algo que publiques
• Caveman y Ponytail — el patrón de ruleset-sobre-adjetivo aplicado a tokens y a código

Una pregunta para la que todavía no tengo buena respuesta: si un pase de estilo limpio solo puede certificar el nivel mecánico, ¿cuál es la forma honesta de reportar la otra mitad —a un compañero, o en CI— sin sobrevender ni enterrar el resultado? Cuéntame qué te ha funcionado.