Common Lisp: el lenguaje que la era de los LLM hace brillar

Un argumento polémico: Common Lisp como el mejor lenguaje de programación

Common Lisp lleva más de tres décadas como estándar ANSI y, según un argumento reciente de la desarrolladora Vivien Henz, sus viejas ventajas técnicas se vuelven decisivas justo cuando los LLM se encargan de escribir la mayor parte del código. La tesis es directa: si la IA ya escribe el código, el cuello de botella pasa de "escribir" a "verificar que el programa funciona". Y ahí, dice Henz, Common Lisp tiene propiedades que ningún lenguaje mainstream replica.

La discusión importa para founders porque reabre una pregunta rara vez formulada en español: cuando el coste marginal de generar código se acerca a cero, ¿qué lenguaje maximiza la productividad por token de IA y la velocidad del ciclo de desarrollo?

El feedback loop casi instantáneo

La pieza de Henz arranca con un punto medible: el tiempo entre editar y ejecutar. En la mayoría de lenguajes hay que esperar una compilación, un reinicio o un redeploy que puede ir de segundos a minutos. Common Lisp es image-based: tu programa es una imagen viva en memoria, y redefinir una función la reemplaza en caliente sin reiniciar nada. Read-time, compile-time y runtime son casi la misma cosa, como lo expuso Paul Graham en su clásico What Made Lisp Different (2002).

Ese detalle cambia la dinámica con un LLM. Cuando un modelo propone un parche, el humano (o el propio modelo) puede probarlo en milisegundos, ver el efecto, y volver a iterar. Con ciclos de compilación de varios minutos, en cambio, el contexto se pierde entre cada intento y se dispara el coste de mantener al modelo enfocado.

Un debugger en lugar de un crash

El segundo argumento es sobre cómo fallan los programas. En lenguajes como Python, JavaScript o Go, un error de runtime normalmente mata el proceso y deja un log que hay que leer a posteriori. En Common Lisp, el error abre un REPL con todo el stack y las variables a la vista, y la ejecución queda pausada, no muerta. Puedes modificar el estado y reanudar sin reiniciar.

En un flujo de trabajo con IA esto significa algo muy concreto: el LLM puede leer el debugger completo, entender qué variable tenía qué valor y proponer un fix que se aplica sobre el mismo programa en ejecución. Se elimina la tradicional cadena "escribir → compilar → ejecutar → leer log → reescribir", que es la que más tiempo y tokens consume en sesiones largas con modelos de código.

Macros: definir el lenguaje antes de escribir el programa

La tercera pieza es la más antigua y también la más controversial. En Common Lisp, código y datos comparten la misma estructura (las listas S-expression), lo que permite macros: funciones que reciben código y devuelven otro código que se ejecuta en su lugar. Una macro añade constructos nuevos al lenguaje.

La consecuencia práctica la describe Henz con el caso de un ERP: en vez de configurar un software genérico, defines un lenguaje de dominio con las reglas y opiniones de tu empresa, y los usuarios (o un LLM) escriben cambios directamente en ese lenguaje. Las modificaciones salen alineadas con el modelo del producto, no rompen su coherencia. Esto es exactamente la idea de los Domain-Specific Languages (DSLs) que la comunidad Lisp lleva décadas defendiendo.

Un debate histórico sobre esta misma idea, recogido en The Challenge of Metaprogramming de Ian Bicking, señala el riesgo: los macros son muy potentes pero penalizan a quien no domina el lenguaje, porque el código resultante es más denso y requiere entender las abstracciones además de la sintaxis. Bicking lo resume con la frase: "75% menos código, pero el doble de difícil de entender". Henz invierte esa crítica para la era LLM: si el que escribe las macros es el modelo y el humano supervisa, la densidad deja de ser un problema y la concisión se convierte en ahorro directo de tokens.

Código más corto, ventana de contexto más grande

Henz reporta que, en su propia experiencia, las apps que escribe en Common Lisp terminan entre seis y siete veces más cortas que sus equivalentes en Python. La causa directa son las macros, que absorben patrones repetitivos en constructos del propio lenguaje.

Hay dos efectos derivados que importan al programar con LLM:

• Menos tokens consumidos por el modelo. Los proveedores de modelos de IA cobran por token; un programa seis veces más corto cuesta una fracción en cada iteración de generación.
• Más código cabe en la ventana de contexto. Cuando todo el programa entra en el contexto del modelo, el LLM ve la intención completa y toma mejores decisiones; cuando solo ve una parte, introduce bugs por no conocer el resto. La concisión multiplica las opciones de stack completo.

Henz lo formula así: "un buen número de bugs de LLM vienen de cambiar una pieza sin ver las demás. Con Common Lisp, eso pasa menos".

El estándar que no se mueve desde 1994

Otro punto contraintuitivo: Common Lisp no se ha actualizado como estándar desde 1994. Henz lo presenta como una ventaja. Si vas a construir un producto cuyos usuarios van a programar dentro de él con ayuda de un LLM, quieres que la base no cambie debajo de tus pies. Un DSL encima de Common Lisp hereda esa estabilidad: nada de lo que construyas encima se rompe por una nueva versión mayor del lenguaje.

Esta propiedad contrasta con la dirección habitual del ecosistema JavaScript o Python, donde una actualización mayor puede obligar a reescribir integraciones. Para founders que están pensando en plataformas de personalización user-driven, la estabilidad del substrate es un argumento de arquitectura.

El problema de las librerías, relativizado

Henz asume un problema real: Quicklisp, el gestor de paquetes de Common Lisp, tiene unos pocos miles de proyectos frente a los millones de npm. En el mundo anterior a los LLM eso era casi una sentencia de muerte para nuevos productos.

La autora invierte la objeción con dos argumentos:

• Menos dependencias es más seguridad. Cada paquete extra es una superficie de ataque: los incidentes recientes en npm demuestran que las cadenas de suministro de paquetes son un vector real de compromiso. Menos librerías, menos riesgo.
• El LLM puede portar código por ti. Como los modelos son buenos leyendo un repositorio en un lenguaje y reescribiéndolo en otro, la ausencia de una librería en Common Lisp se resuelve pidiéndole al modelo que porte la implementación que ya existe en Python o JavaScript. Ya no es un bloqueo técnico.

Qué significa esto para tu startup

El argumento de Henz no es una defensa tribal de Lisp; es una propuesta de arquitectura para empresas que están repensando su stack en función de los LLM. Si tu roadmap incluye personalización masiva, generación de código por el usuario o productos configurables, Common Lisp como base para un DSL interno es una hipótesis que vale la pena prototipar.

Tres acciones concretas para founders:

• Mide tu feedback loop actual. Cronometra cuánto tarda un cambio de código en llegar a producción en tu stack. Si supera los cinco minutos, estás pagando un coste compuesto cada vez que un LLM itera. Common Lisp y el patrón REPL-driven development son la mejor respuesta documentada a ese problema.
• Experimenta con un DSL en Lisp sobre un caso pequeño. No hace falta reescribir tu producto. Elige una regla de negocio compleja y exprésala como macros Lisp. Si el LLM puede escribir transformaciones dentro de ese DSL con menos tokens y menos errores que en tu stack actual, tienes evidencia para escalar.
• Calcula el coste de oportunidad de las dependencias. Revisa tu package.json o requirements.txt y cuenta cuántas dependencias usan tus caminos críticos. Un stack con menos librerías y un lenguaje estable puede ser, paradójicamente, más defendible en 2026 que un stack lleno de dependencias de moda.

La hipótesis de Henz puede caer bien o mal, pero la pregunta que plantea es inevitable: si la IA escribe el código, ¿no debería cambiar la elección del lenguaje hacia uno optimizado para verificar y modificar ese código, no para escribirlo?

Fuentes

• Why Common Lisp Is Now the Best Programming Language
• The Challenge of Metaprogramming - Ian Bicking
• The Beauty of Syntactical Macros - lepisma.xyz