Por qué fallan los lenguajes de programación I
Septiembre de 2026
Asumiendo que la inteligencia artificial se convertirá en superinteligencia algún día, creo que todos los lenguajes de programación que ahora existen quedarán obsoletos de forma práctica.
Sé que suena absurdo decir algo así, pero cuando veo a personas gamificar para entender su propio código, afirmar que leer código ya no importa o construir sistemas agénticos con pruebas infinitas, me convenzo de que los demás entenderán este punto de vista.
No creo que programar esté muerto. Solo creo que todos los ejemplos anteriores son mecanismos que existen para lidiar con una falta de herramientas.
Durante los últimos meses he estado diseñando un nuevo lenguaje de programación que sobreviva a una superinteligencia. Una tarea bastante intimidante que la programación actual me obligó a intentar. Y en este camino encontré tres razones por las que los lenguajes de programación ya no funcionan como antes: carecen de una estructura que escale entender, no escalan buscar información y fuerzan una capa de abstracción fija.
Estos no eran problemas cuando los lenguajes eran usados solo por humanos. Antes, programar significaba entender lo que yo escribía. Ahora que la IA escribe código en un volumen exponencial, es más fácil pedirle que escriba y explique su código. Sin embargo, a largo plazo esto ha delegado mi entendimiento a la IA. Peor aún, no puedo volver atrás porque programar a mano ya no es eficiente. Describirle a la IA lo que quiero siempre parece más rápido que escribir líneas de código. Esto me hizo pensar que un nuevo lenguaje era imposible. No importaba qué reglas de diseño se me ocurrieran, siempre podía imaginar un escenario en el que no entendería el código por la cantidad infinita de líneas que escribiría la IA. Lo que quería era un lenguaje que escale entender a medida que aumentan las líneas de código.
Producir código exponencialmente también significa que ahora necesitamos hacerle preguntas a la IA sobre nuestro código. Pero preguntar sobre y leer el código son cosas distintas. Pedirle a la IA que busque y cambie código te vuelve, con el tiempo, incapaz de encontrar el código correcto y cambiarlo tú mismo. Te hace, una vez más, entregar tu entendimiento a otra inteligencia. Y de nuevo, los lenguajes contemporáneos no ayudan aquí. La lógica que necesitas buscar muy probablemente vive en múltiples archivos y líneas de código. Así que, si asumimos que nuestro código es infinito, nos vemos forzados a usar la IA para buscar código.
He llegado a la conclusión de que un lenguaje debe hacer fácil encontrar dónde está el cambio que quieres hacer. Me parece curioso que antes de la IA también teníamos este problema, pero la búsqueda por texto y el análisis estático bastaban. En ese entonces teníamos cantidades humanas de código y podíamos confiar en que el lenguaje delimitara el alcance de lo que un humano debe entender.
Es obvio que los lenguajes de programación viven en una capa fija de abstracción. Assembly te exige entender registros. C++ te pide entender memoria, pero no registros. Los lenguajes de alto nivel como Python te piden pensar con lógica imperativa y no preocuparte tanto por la memoria. Ha sido así por tanto tiempo que se ha vuelto una cualidad obvia del diseño de lenguajes. Es impensable que pueda ser de otra forma. ¿Qué pasaría si de alguna manera pudieras crear punteros en Python o usar registros en React? ¿Tendría siquiera sentido? Por supuesto que no. Un lenguaje debería definir una capa de abstracción que un humano pueda entender y con la que este ser humano pueda escribir un número humano de líneas de código. ¿Pero ves ahora el problema? Es el mismo problema de antes. Un lenguaje con una capa fija de abstracción es inutilizable en la era de la IA. Sea cual sea el alcance de abstracción que diseñes para un lenguaje, la IA producirá infinitas líneas de código en ese nivel y superará tu capacidad para entenderlo.
Estos tres problemas: entender código a escala, buscar información rápido en el código base y las capas fijas de abstracción, deben resolverse. Dejar sin resolver una basta para que un nuevo lenguaje sea inutilizable. Aunque es curioso que, después de resolver los tres, puedo decir que en teoría solo necesitaba resolver cualquiera de ellos para resolverlos todos.
¿Pero estos problemas realmente tienen solución? Y si la tienen, ¿cómo empezamos a resolverlos?
Por suerte, en 2003, Paul Graham, en su ensayo “El lenguaje de los cien años” (“The Hundred-Year Language”), propuso las dos ideas de diseño simples que yo necesitaría para crear mi nuevo lenguaje. La primera idea es:
Una forma de diseñar un lenguaje es simplemente escribir el programa que te gustaría poder escribir, sin importar si existe un compilador que pueda traducirlo o hardware que pueda ejecutarlo.
Su segunda idea incluía una advertencia:
¿Qué programa le gustaría a uno escribir? El que menos trabajo cueste. Aunque no exactamente: es el que menos trabajo costaría si tus ideas sobre la programación no estuvieran ya influenciadas por los lenguajes a los que estás acostumbrado. Esa influencia puede estar tan extendida que superarla requiere un gran esfuerzo. … Un truco útil aquí es usar la longitud del programa como una aproximación de cuánto trabajo cuesta escribirlo. No la longitud en caracteres, por supuesto, sino la longitud en elementos sintácticos distintos; básicamente, el tamaño del árbol sintáctico.
Ambas ideas juntas, forman la más simple de las preguntas: ¿Hay una forma de escribir poco y que quiera escribir? Resulta que la respuesta es sí.
Gracias a Cristhian Agüero y Matias Avendaño por leer los borradores de este ensayo.