Dijkstra ya lo advirtió en 1978: programar en lenguaje natural es una insensatez

Envío este artículo a todo el que me dice que el inglés ahora es un lenguaje de programación de alto nivel, el siguiente nivel de abstracción en la cadena desde el lenguaje máquina hasta <su lenguaje favorito>. Esta analogía suele ir seguida de "Igual que la mayoría de los programadores nunca miran el código ensamblador, mirar el código fuente de alto nivel va a convertirse en algo que solo harán unas pocas personas".

Los argumentos de Dijkstra tienden a no hacerles cambiar de opinión. Creo que la analogía cala porque tiene un grano de verdad. Los modelos de IA ahora nos dan la mágica capacidad de programar en lenguaje natural, pero la implicación de que un modelo de IA es una forma de compilador es profundamente errónea. Los modelos de IA no reemplazan a los compiladores, reemplazan a los desarrolladores de software. La razón por la que los desarrolladores de software rara vez miran el código ensamblador es que los compiladores (y los emuladores y las máquinas virtuales) son capaces de preservar con precisión la semántica del programa original.

Una especificación en lenguaje natural no es un programa, y hay muchos programas posibles que pueden cumplir la especificación. Los ingenieros de software y los modelos de IA convierten especificaciones en código, pero el código no es la especificación. Creo que la analogía enturbia nuestro pensamiento sobre el valor de los lenguajes de programación como herramienta para describir formalmente lo que el ordenador debería hacer y para imponer propiedades del programa que no deberían quedar en manos ni de los humanos ni de los modelos de IA para su mantenimiento.

Creo que la diferencia está entre comunicarse con un ser puramente mecánico y comunicarse con una entidad inteligente: a diferencia de los programas, que son lenguajes puramente formales, escribimos libros de texto y artículos en una mezcla de lenguaje humano y lenguaje formal. A menudo introducimos notaciones "justo lo bastante formales". Y el lector inteligente leerá entre líneas; inter legere significa literalmente eso: leer entre. Rellenar los huecos, conectar los puntos.

Y en la práctica me parece _muy_ eficaz expresar las ideas clave con algo de lenguaje formal cuando corresponde. Un poco de EBNF por aquí, algunos fragmentos de Python o Prolog por allá u otros lenguajes por acá. Y me parecen maravillosos los LLM para rellenar los puntos y, y este es el tema que nos ocupa, para traducir nuestra conversación semiformal a un lenguaje riguroso y formal.

Y me atrevo un paso más: también me parecen útiles los LLM para formular y refinar propuestas técnicas, para la revisión por pares humana y la implementación impulsada por LLM, y por supuesto estas propuestas mezclan prosa en lenguaje natural con detalle semiformal y formal. Piensa en el estilo de PEP-12 y PEP-1. Y luego estos se convierten en paquetes de trabajo que cada uno incluye una especificación como en SDD.

Parece que funciona bastante bien hasta ahora :-)

He tenido la misma opinión desde que aparecieron los agentes de programación. Los LLM son buenos para resumir, así que tiendo a usarlos para entender código. Sin embargo, cuanto más entiendo una base de código, más exigente tiendo a ser con el agente. Mientras que cuanto menos sé sobre la base de código, más abierto estoy a dejar que haga lo suyo.

Me he dado cuenta de que el agente no escribe código 'bueno'; más bien, mi vaga comprensión de lo que espero me hace pensar que sí lo hace. Cuando miro el código de la IA, veo que hay más matices y decisiones que había que tomar antes de escribir el código. Uno diría que una especificación bastaría, pero entonces recuerdo TLA+, desarrollado por Leslie Lamport para ayudar a los desarrolladores a pensar críticamente sobre sus programas/algoritmos. Sentarme y escribir formalmente lo que quiero hacer me ayuda a comprender mejor el problema y a dar con una solución real —no vagamente definida—.

El lenguaje natural está lleno de matices y connotaciones implícitas culturales y específicas de cada dominio. Los LLM funcionan porque han sido entrenados con un corpus masivo de materiales que codifican algunos (pero no todos) de esos significados ocultos.

Con el desarrollo guiado por especificaciones, los prompts deben ser muy detallados para producir exactamente lo que se requiere.

El programa en lenguaje natural de hoy no funcionará mañana debido a la naturaleza inestable del lenguaje natural.

Aparte de la evolución natural de los significados, fíjate en las limitaciones orwellianas que algunos modelos (en la nube) nos imponen: hacen que nuestro programa en lenguaje natural se vuelva ilegal. Por el tema o la combinación de palabras, el programa debe ser marcado y pronto probablemente reportado a una agencia de tres letras.

Luego, RMS preguntaría: ¿puedes hacer tu propio compilador de programas en lenguaje natural desde cero?

Sé que tenemos modelos locales (muy caros), pero espera a que las GPU tengan sus propias suscripciones online para funcionar y pinchazos de vigilancia.

Posiblemente relevante:

El experimento de diseñar un lenguaje que se pareciera a los lenguajes naturales (inglés y japonés) no tuvo éxito. -[1]- William R. Cook, AppleScript, HOPL IV

Ahora nuestros nuevos LLM son diferentes, porque no usan "un lenguaje que se parecía a los lenguajes naturales", sino lenguaje natural de verdad. Pero la lección es instructiva de todos modos, porque nos da cierta evidencia empírica con la que comparar los argumentos teóricos de Dijkstra.

Y es que el lenguaje natural es, en el mejor de los casos, un arma de doble filo. Sí, hay beneficios, pero también hay enormes inconvenientes. Y un problema es que los beneficios están cargados al principio y los inconvenientes son problemas a largo plazo.

Para mí, una cosa que se nos escapa es que lo que los LLM hacen por nosotros en realidad tiene 2 partes.

1. Nos permite usar lenguaje natural, permitiéndonos ser difusos.

2. Nos permite especificar lo que queremos a un nivel mucho, mucho más alto de lo habitual.

Con nuestros LLM, estas dos cosas están intrínsecamente ligadas. Creo que el conjunto sería mucho, mucho más valioso si pudiéramos separarlas.

[1] https://dl.acm.org/doi/10.1145/1238844.1238845

> Sospecho que las máquinas que se programen en nuestras lenguas nativas —ya sea neerlandés, inglés, americano, francés, alemán o suajili— son tan malditamente difíciles de hacer como lo serían de usar.

Sigue teniendo bastante razón. Yo generalmente considero que una máquina está "programada en" lo que sea que se rastree en el control de versiones. Así que mientras tu repositorio de git esté rastreando cambios en Java, eso sigue estando programado en Java, incluso si el Java se generó con la ayuda de LLM. Puede que considere invalidada la tesis de este artículo solo cuando la mayoría de los repositorios empiecen a rastrear lenguaje natural en lugar de lenguajes de programación como los artefactos principales que definen el comportamiento del software.