Andrej Karpathy, exdirector de IA en Tesla y cofundador de OpenAI, ha encendido un debate técnico fascinante: ¿y si obligamos a los grandes modelos de lenguaje a escribir con la misma precisión que un manual de mantenimiento de un Boeing 737? Su propuesta no es capricho estético, sino una apuesta por la verificabilidad y la seguridad en sistemas donde la ambigüedad cuesta vidas —o, en el caso empresarial, millones en errores operativos.

El estándar en cuestión es ASD-STE100, conocido como Simplified Technical English (STE). Desarrollado en los años 80 por la industria aeroespacial europea, dicta reglas estrictas: una palabra, un significado; frases de máximo 20 palabras; voz activa obligatoria; prohibición de gerundios y tiempos perfectos. El resultado es un inglés que no admite interpretación: "Open the valve" (abre la válvula), nunca "The valve should be opened" (la válvula debería ser abierta).

Karpathy ha demostrado que, al forzar a Claude 3.5 Sonnet a generar salida conforme a STE mediante system prompts cuidadosamente diseñados, el modelo reduce drásticamente la verbosidad, elimina hedging innecesario ("it seems that", "potentially") y produce instrucciones accionables. Pero la innovación real no es el prompt, sino el validador: un script de apenas 50 líneas en Python que parsea la respuesta del modelo y rechaza cualquier violación del estándar —longitud de frase, vocabulario no aprobado, voz pasiva— devolviendo el control al modelo para reintentar hasta cumplir.

Este patrón —generar, validar, retroalimentar— recuerda al concepto de "constitutional AI" pero aplicado a nivel sintáctico y semántico superficial, no ético. Es una capa de “linting” para lenguaje natural, análoga a lo que ESLint o Ruff hacen por código. Y abre la puerta a pipelines donde la salida de un LLM alimenta directamente a otro sistema —un ejecutor de runbooks, un generador de tests, un actuador robótico— sin intervención humana de limpieza.

Las implicaciones para la ingeniería de software son inmediatas. Los equipos que usan Copilot, Cursor o agentes autónomos como Devin lidian hoy con código que compila pero no sigue convenciones internas, o documentación que mezcla tono conversacional con especificación técnica. Un validador STE-like adaptado a guías de estilo corporativas (Google, Microsoft, Rust API Guidelines) convertiría la salida del modelo en "código limpio" por construcción, no por revisión posterior.

Sin embargo, hay fricción. STE reduce expresividad: no hay lugar para matiz, analogía o explicación pedagógica. Un tutorial de onboarding escrito en STE sería funcional pero árido. La solución híbrida —zonas STE para specs y contratos, zonas naturales para docs humanas— parece inevitable. También está el coste de latencia: cada ciclo de validación-reintento añade llamadas al modelo. Karpathy sugiere fine-tuning de modelos pequeños (7B-13B) especializados en STE para absorber esa carga, reservando los frontier models para razonamiento complejo.

La movida de Karpathy señala una madurez del campo: pasamos de "impresiona que escriba bien" a "necesito que escriba *exactamente así* para que mi pipeline no se rompa". La aviación llevaba 40 años resolviendo este problema. La IA generativa acaba de descubrir que la solución ya existía, archivada en un estándar ISO.