Los lenguajes operativos

Nadie lee hoy la salida del compilador.

En los ochenta la leían todos los buenos.

Cuando C empezó a comerse el mundo, los programadores serios de assembly hicieron lo que haría cualquier profesional al que le cambian la herramienta: compilaron, abrieron el resultado y lo leyeron línea a línea. Y se llevaron las manos a la cabeza. Registros desperdiciados, saltos absurdos, instrucciones de más. Peor aún: no se fiaban del proceso. Para ellos el compilador no era determinista. No en el sentido formal, sino en el que importa cuando firmas un sistema: no podías predecir qué iba a salir por el otro lado, y lo que salía cambiaba con cada versión y cada flag.

Algunos fueron más lejos. No aceptaron el intermediario y se construyeron sus propias herramientas, su propio assembly, sus propias rutinas a mano para las partes críticas. Está escrito: la historia de Mel, el programador que desconfiaba hasta del ensamblador, es de 1983. No es leyenda de barra de bar. Es un patrón documentado de cómo reacciona el mejor talento de una generación cuando aparece una capa nueva entre él y la máquina.

¿Y cómo acabó? El compilador ganó. Pero fíjate en cómo ganó, porque ahí está la clave de todo lo demás.

No ganó porque los programadores aprendieran a quererlo. Ganó porque la confianza se mudó de sitio. Dejamos de confiar en leer la salida y empezamos a confiar en la capa de verificación: semántica definida, tests, benchmarks, builds reproducibles. El día que el compilador optimizó mejor que el humano medio, la discusión se acabó. Hoy solo leen assembly los que escriben compiladores.

El mismo fotograma, cuarenta años después

Ahora mira lo que está pasando con los modelos.

Un modelo escribe código y el programador serio abre el diff y lo lee línea a línea. Y se lleva las manos a la cabeza. Abstracciones de más, un patrón que él no habría elegido, código que funciona pero no es el suyo. Y la frase exacta, calcada: "es que no es determinista".

Es el programador de assembly leyendo la salida de cc en 1985. El mismo fotograma con otra fecha.

Y la salida será la misma. La confianza no va a volver a la lectura del código. Se va a mudar, otra vez, a la capa de verificación: contratos, evals, trazas, gates de aprobación. Es exactamente lo que es un harness. No es una moda de la IA: es el movimiento que ya hicimos una vez con los compiladores, aplicado al nuevo traductor.

Lo que espero con impaciencia

Aquí viene la parte que me interesa de verdad.

Los lenguajes de programación son interfaces para humanos. La sintaxis legible, los nombres de variables, los frameworks, los linters que discuten sobre comas: todo eso existe porque el que escribía y el que mantenía era una persona.

Cuando el que escribe y el que mantiene es un modelo, esa capa entera es overhead.

Estoy impaciente por ver a los modelos saltarse el intermediario: emitir representaciones intermedias directamente, inventarse su propio intérprete, definir sus propios lenguajes operativos optimizados para generación y verificación en vez de para lectura humana. Volver al assembly, en la práctica. La vuelta completa a la casilla de salida, pero con una diferencia: esta vez la garantía no la da un humano leyendo, la da el harness comprobando.

El código legible quedará donde haga falta auditoría humana. Que no es poco, pero no es todo. El resto irá en lo que la máquina prefiera, igual que hoy nadie exige que su binario sea bonito.

WordPress es la otra cara de la misma moneda

Este mismo movimiento está pasando en otra capa, y ahí ya no hace falta esperar: se ve navegando.

WordPress existe porque un humano sin programador necesitaba editar su web. Ese es el trabajo que hace: panel de administración, plugins, un intérprete de PHP corriendo las veinticuatro horas para servir contenido que cambia dos veces al mes. Toda esa maquinaria es la interfaz humana de un problema que ya no la necesita.

Y esa interfaz se paga. Navega un rato con los ojos abiertos y encontrarás mil sitios con WordPress vulnerables: versiones de PHP sin soporte, plugins abandonados hace años, webs de negocios reales sirviendo spam inyectado sin que el dueño lo sepa. No es mala suerte. Es el coste de mantenimiento de una capa pensada para humanos que ya no la mantiene nadie.

Cuando el mantenedor es un agente, la arquitectura correcta es otra: fuente en un repo, salida estática, un agente que edita, valida y despliega. Sin panel, sin runtime esperando peticiones, sin superficie de ataque viva. El cambio de horario que hoy pasa por un plugin con tres CVEs mañana es un diff con su traza.

WordPress tiene los días contados por la misma razón que el assembly escrito a mano: no porque fuera malo, sino porque la interfaz humana que justificaba su existencia deja de ser necesaria.

La regla que queda

De las dos transiciones sale la misma regla.

El determinismo nunca vuelve al lenguaje. Se muda a la capa de verificación.

Pasó con los compiladores: dejamos de leer la salida y construimos semántica, tests y builds reproducibles. Pasará con los modelos: dejaremos de leer cada diff y construiremos contratos, evals y trazas. Y pasará con las webs: dejaremos de administrar paneles y tendremos agentes editando fuente verificada.

El lenguaje operativo del futuro no está pensado para que lo leas tú.

Está pensado para que lo compruebe el harness.