Los lenguajes de programación se diseñaron para que los humanos dieran instrucciones a las máquinas.
Su sintaxis refleja esa historia. Usamos nombres de variables legibles, palabras clave memorables, indentación, comentarios, archivos, clases y abstracciones que encajan con modelos mentales humanos. Los errores del compilador están escritos para personas. La documentación se organiza para personas. Los repositorios se estructuran para que las personas puedan navegarlos.
Pero las personas están dejando rápidamente de ser responsables de escribir el código en sí.
A través de Senternet, el estudio de software donde construyo productos y experimento con desarrollo asistido por IA, ahora creo buena parte de mi software dirigiendo agentes de programación. Describo lo que quiero, reviso el resultado, pruebo el comportamiento y devuelvo al agente a arreglar lo que esté mal. El agente sigue produciendo TypeScript, Python, SQL y otro código fuente convencional, pero cada vez más eso parece un artefacto del ecosistema existente y no un requisito del trabajo.
El agente escribe código legible por humanos sobre todo porque nuestros compiladores, bibliotecas, sistemas operativos, APIs, gestores de paquetes e infraestructura de despliegue lo esperan.
Eso plantea una pregunta que no me quito de la cabeza:
¿Cuál será el primer lenguaje de programación diseñado principalmente para agentes y no para humanos?
El código legible por humanos se está volviendo un formato intermedio
Durante casi toda la historia de la computación, el código fuente tuvo dos públicos.
El primero era la computadora que lo compilaría o interpretaría. El segundo era cualquier humano que más adelante necesitara entenderlo, depurarlo, mantenerlo o ampliarlo.
Ese segundo público moldeó casi todas las decisiones importantes de diseño de lenguajes.
Python enfatiza la legibilidad. Ruby intenta resultar natural y expresivo. TypeScript añade estructura que ayuda a grupos grandes de personas a razonar sobre JavaScript. Rust hace explícitas la propiedad y la seguridad de memoria para que quien desarrolla pueda entender y controlar comportamientos que otros lenguajes esconderían.
Son características valiosas porque, tradicionalmente, el recurso escaso ha sido la atención humana.
La programación agéntica cambia esa economía.
Un agente no necesita una sintaxis fácil de teclear. No necesita palabras clave fáciles de recordar. No necesita un lenguaje que se pueda enseñar en un semestre o explicar en una estantería de libros. No se fatiga al recorrer un repositorio enorme. Puede procesar representaciones que a una persona le resultarían tediosas, verbosas o incomprensibles.
Puede beneficiarse de propiedades muy distintas:
- semántica sin ambigüedades
- representación compacta en tokens
- dependencias y efectos secundarios explícitos
- transformaciones deterministas
- verificación formal
- paralelización automática
- diagnósticos legibles por máquina
- procedencia incorporada
- compilación incremental
- optimización específica del hardware
- expresión directa de restricciones y pruebas
Cuando los agentes se conviertan en los autores principales del software, la legibilidad humana dejará de ser la restricción central del diseño.
No se vuelve inútil. Se vuelve una interfaz generada.
La representación nativa de la máquina podría convertirse en la fuente de verdad, mientras los humanos reciben la vista que resulte más útil en cada momento: una explicación, un diagrama, una especificación de comportamiento, un informe de seguridad, un plan de pruebas o incluso TypeScript generado.
Puede que el código legible por humanos acabe siendo no más fundamental que la vista gráfica del esquema de una base de datos.
Por qué los agentes siguen escribiendo Python y TypeScript
El mayor obstáculo para cualquier lenguaje nuevo no es su sintaxis.
Es el ecosistema.
Un lenguaje nuevo necesita compiladores, depuradores, bibliotecas, documentación, gestión de paquetes, soporte en editores, herramientas de despliegue, análisis de seguridad y acceso a las plataformas existentes. Quienes desarrollan se resisten a adoptar un lenguaje que les obligue a reconstruir todo lo que ya tienen.
Los agentes no eliminan este problema, pero pueden reducirlo drásticamente.
Históricamente, un lenguaje nuevo también tenía que convencer a millones de personas de aprenderlo. Hacían falta formación, ejemplos, libros, comunidad y confianza suficiente para arriesgar carreras y empresas en tecnología desconocida.
Un agente no necesita meses de formación. En cuanto un modelo o un sistema de programación puede producir un lenguaje con fiabilidad, todos sus usuarios obtienen acceso a él de inmediato.
Eso elimina una de las mayores barreras históricas para la adopción de lenguajes.
El problema del ecosistema persiste, lo que significa que el primer lenguaje agent-native con éxito probablemente no sustituirá a Python, JavaScript, Rust y C++ de golpe. Los absorberá.
Puede que compile a través de LLVM, apunte a WebAssembly, llame a interfaces de C existentes, importe paquetes actuales y hable con APIs establecidas. Puede empezar como una representación intermedia oculta bajo un agente de programación, y no como un lenguaje que quien desarrolla elija a sabiendas.
La transición podría ocurrir sin que la mayoría se dé cuenta.
Partes de esto ya están ocurriendo
Todavía no existe un lenguaje de programación de propósito general, ampliamente adoptado, escrito y consumido principalmente por agentes. Sí hay, en cambio, varios proyectos tempranos que van en esa dirección.
En 2025, unos investigadores presentaron Quasar como lenguaje para las acciones de código que ejecutan los agentes basados en grandes modelos de lenguaje. Los agentes suelen generar Python cuando necesitan llamar a herramientas o construir flujo de control, pero los investigadores sostenían que Python carece de las propiedades de rendimiento, seguridad y fiabilidad que este trabajo requiere.
Quasar añade paralelización automática, seguimiento de la incertidumbre y mecanismos para validar acciones potencialmente inseguras. En la implementación actual, el modelo escribe un subconjunto restringido de Python que se transpila a Quasar. Los investigadores reportaron una reducción del 42 por ciento en el tiempo de ejecución cuando la paralelización era posible, y del 52 por ciento en las interacciones de aprobación necesarias cuando se aplicaban sus mecanismos de seguridad.
Quasar no es la forma definitiva de un lenguaje agent-native. El agente todavía emite código parecido a Python. Pero deja clara la presión: un lenguaje diseñado para personas puede no ser el mejor modelo de ejecución para agentes.
Pel es otro lenguaje experimental creado específicamente para orquestar agentes de IA. Usa una gramática mínima y pone el acento en la generación restringida, el control de capacidades, la comunicación entre agentes, la ejecución segura y la paralelización automática.
Pel está influido por lenguajes como Lisp, Elixir, Gleam y Haskell, pero su diseño asume que la facilidad con la que un modelo puede generarlo de forma fiable es, en sí misma, una característica del lenguaje.
Eso supone un cambio importante de prioridades. Quienes diseñan lenguajes tradicionales se preguntan si la sintaxis resulta comprensible para una persona. Quienes diseñan lenguajes agent-native pueden preguntarse, en cambio, si un modelo puede generarlo de forma consistente, validarlo mecánicamente y recuperarse de errores sin intervención humana.
Los agentes de programación también empiezan a demostrar que no necesitan aprender lenguajes desconocidos como lo hacen los humanos.
En un estudio de 2026 sobre agentes de programación trabajando con lenguajes esotéricos, los agentes punteros escribían con frecuencia programas en Python que generaban y depuraban el código objetivo desconocido. Cuando los investigadores prohibieron esa estrategia de metaprogramación, el rendimiento cayó de forma sustancial.
Esa es una forma primitiva pero importante del futuro que describo.
Un agente puede inferir una representación objetivo, construir un generador para ella, probar el resultado y revisar el generador. No necesita entender ni mantener el código objetivo en el sentido humano. El lenguaje objetivo es simplemente otra representación de máquina que puede manipular.
El primer lenguaje agent-native puede no parecer un lenguaje
Cuando la gente imagina un lenguaje de programación nuevo, suele imaginar una sintaxis nueva.
Puede que esa sea la parte menos importante.
Un lenguaje agent-native podría ser una representación estructurada de:
- comportamiento deseado
- interfaces
- restricciones
- permisos
- invariantes
- pruebas
- límites de recursos
- objetivos de rendimiento
- políticas de seguridad
- modos de fallo aceptables
El agente de programación y el compilador podrían decidir conjuntamente cómo implementar esos requisitos.
Para una carga de trabajo, el resultado podría ser código máquina nativo. Para otra, WebAssembly. Para otra, un plan de consulta de base de datos, un kernel de GPU, una función serverless o una composición de servicios existentes.
Puede que no exista ningún archivo fuente permanente que corresponda a la implementación.
El artefacto duradero sería la intención, y la evidencia de que la implementación la satisface.
Esto sugiere una progresión en tres etapas.
Etapa uno: los agentes escriben lenguajes de programación humanos
Aquí es donde estamos ahora. Los agentes producen código que parece algo que podría haber escrito una persona.
Etapa dos: los agentes escriben representaciones intermedias orientadas a la máquina
Las personas revisan sobre todo comportamiento, pruebas, especificaciones, explicaciones generadas y cambios en las capacidades. La implementación subyacente pierde importancia en la revisión rutinaria.
Etapa tres: los agentes generan sistemas ejecutables directamente
La fuente de verdad pasa a ser un conjunto de intención, políticas, interfaces, restricciones y evidencia de verificación. El agente genera y regenera implementaciones ejecutables según haga falta.
Llegados a ese punto, preguntar en qué lenguaje de programación está «escrita» una aplicación puede dejar de tener mucho sentido.
Legible por humanos no significa auditable por humanos
El argumento más fuerte contra este futuro es que el código fuente no solo sirve para escribir software.
También sirve para depurar, auditar, gobernar, revisar la seguridad, mantener y rendir cuentas.
No podemos operar con seguridad sistemas importantes cuyo comportamiento nadie puede inspeccionar.
Pero el código fuente legible ya es un sustituto pobre de la comprensión real. Una aplicación moderna grande puede contener millones de líneas de código propio y depender de millones más a través de paquetes, archivos generados, servicios en la nube, sistemas operativos y firmware. Casi nadie entiende el sistema completo.
El código puede ser legible sin que el sistema sea comprensible.
Un sistema agent-native tendría que ofrecer formas de inspección más potentes que un montón de archivos fuente. Podría generar:
- explicaciones de comportamientos concretos
- mapas del movimiento de los datos
- demostraciones de propiedades importantes
- informes de permisos y capacidades
- historiales de dependencias
- simulaciones de cambios propuestos
- pruebas ejecutables
- registros de por qué se tomó cada decisión
- implementaciones legibles por humanos cuando haga falta
El objetivo no debería ser preservar el código legible a toda costa.
El objetivo debería ser preservar el control humano.
No son lo mismo.
El coste ambiental del código amable con los humanos
Hay otra razón por la que los agentes pueden acabar yendo más allá de los lenguajes de programación actuales: la energía.
Un estudio de 2017 sobre la eficiencia energética de 27 lenguajes de programación, muy citado, comparó tiempo de ejecución, uso de memoria y consumo energético en diez problemas de referencia.
En sus resultados normalizados, Python consumía aproximadamente 76 veces más energía que C y necesitaba unas 72 veces más tiempo de ejecución. Python quedaba cerca del final de la tabla en eficiencia energética.
Ese resultado se ha simplificado a menudo hasta convertirse en la afirmación de que Python es uno de los peores lenguajes de programación para el medio ambiente.
La realidad es más complicada.
Un reanálisis de 2024 de la eficiencia energética de los lenguajes de programación halló que estas comparaciones pueden confundir el lenguaje con su implementación, con la calidad del programa de referencia, con el número de núcleos activos, con el comportamiento de las bibliotecas, con la actividad de memoria y con otros detalles de ejecución.
Tras controlar esos factores, los investigadores concluyeron que la implementación del lenguaje de programación no tenía un efecto significativo sobre el consumo energético más allá del tiempo de ejecución.
La cuestión central no era que la sintaxis de un lenguaje consumiera de algún modo más electricidad. Los programas más lentos usaban en general más energía total porque el hardware permanecía activo más tiempo.
Esa distinción no hace desaparecer el problema.
El Python estándar suele ser mucho más lento que el código compilado optimizado en trabajo computacionalmente intensivo. Un programa que tarda muchísimo más en hacer lo mismo puede consumir muchísima más energía, aunque el procesador consuma potencia a un ritmo similar mientras lo ejecuta.
La buena noticia es que esa ineficiencia no es inevitable.
Un estudio de 2025 sobre implementaciones compiladas de Python comparó CPython con varios sistemas de compilación y optimización, entre ellos PyPy, Numba, Codon, Cython, Nuitka, Mypyc y Pyston-lite.
Los investigadores encontraron que la compilación podía mejorar significativamente el tiempo de ejecución, el uso de memoria y el consumo energético. Codon, PyPy y Numba produjeron mejoras de velocidad y energía de más del 90 por ciento en algunas de las cargas probadas.
La conclusión más precisa no es que Python sea intrínsecamente destructivo para el medio ambiente.
Es que los humanos hemos elegido a menudo lenguajes de programación en función de la productividad humana, tratando la eficiencia de ejecución como una preocupación secundaria.
Python tiene éxito porque es legible, expresivo, indulgente y está respaldado por un ecosistema enorme. En muchas organizaciones, ahorrar tiempo de desarrollo compensa gastar tiempo de cómputo adicional.
Los agentes no afrontan la misma disyuntiva.
Un agente de programación no necesita una sintaxis amable para seguir siendo productivo. No necesita un lenguaje fácil de enseñar, teclear o recordar. Podría generar una representación elegida para la carga concreta, compilarla para el hardware disponible, medir el resultado y sustituirla cuando aparezca una implementación más eficiente.
El consumo energético podría convertirse en una propiedad de primera clase de la programación, en vez de una optimización que se intenta cuando el software ya está escrito.
Esto importa porque los agentes no van simplemente a sustituir el código escrito por humanos línea a línea. Es probable que aumenten el volumen total de software producido y ejecutado.
Los agentes pueden generar decenas de implementaciones, ejecutar miles de pruebas, crear programas desechables para tareas concretas y regenerar continuamente sistemas en funcionamiento. Una ineficiencia tolerable cuando el software lo producían lentamente los humanos se vuelve más consecuente cuando las máquinas pueden generar código casi ilimitado.
Por eso el primer lenguaje agent-native puede optimizar algo más que corrección y velocidad. Podría considerar:
- consumo energético total
- frecuencia de ejecución esperada
- procesadores y aceleradores disponibles
- movimiento de memoria
- coste de compilación
- la intensidad de carbono de la electricidad disponible
- si una carga puede retrasarse o reubicarse
- si una implementación se ejecutará una vez o miles de millones de veces
Puede que no exista una representación óptima universal.
Una conversión de datos puntual puede favorecer una sobrecarga mínima de compilación. Un servicio que espera atender miles de millones de peticiones puede justificar una optimización nativa agresiva. Una carga que corre en un dispositivo con batería puede priorizar la energía sobre la latencia. Un trabajo en un centro de datos podría programarse en función de la disponibilidad de electricidad más baja en carbono.
Un agente podría tomar estas decisiones automáticamente.
Quizá el error ambiental no sería dejar que los agentes escriban código ilegible. Sería obligarlos a seguir escribiendo Python simplemente porque a los humanos nos gusta leerlo.
¿Qué será del programador?
Nada de esto significa que los humanos dejemos de construir software.
Significa que nuestro trabajo se desplaza hacia arriba.
En lugar de dedicar la mayor parte del tiempo a describir pasos de implementación en una sintaxis pensada para compiladores, dedicaremos más tiempo a definir:
- qué debe lograr el sistema
- qué no debe hacer nunca
- qué compromisos son aceptables
- quién puede acceder a qué
- cómo se mide el éxito
- cómo deben gestionarse los fallos
- qué evidencia se exige antes del despliegue
Eso sigue siendo programar.
En muchos sentidos, es programar de forma más directa que traducir a mano esas decisiones a bucles, clases, funciones y archivos de configuración.
El papel de quien programa tiene menos que ver con producir código fuente y más con establecer intención, restricciones, arquitectura y criterio. Es otra razón por la que vuelvo siempre a la idea de que el gusto es el cuello de botella una vez que construir sale barato.
Lo difícil del desarrollo de software nunca fue teclear la sintaxis. Lo difícil era decidir qué debía ocurrir.
Los agentes están eliminando la capa de traducción.
¿Quién lo creará?
El primer lenguaje verdaderamente agent-native puede que no se presente en una conferencia de desarrolladores.
Puede que no tenga un nombre ingenioso, ni una especificación pública, ni una comunidad debatiendo su sintaxis.
Puede surgir en silencio dentro de una plataforma de agentes, como una representación intermedia privada usada para planificar, generar, verificar, optimizar y compilar software. Puede que al principio apunte a lenguajes convencionales y cadenas de herramientas existentes, y que poco a poco vaya prescindiendo de ellas.
Para cuando los humanos lo reconozcamos como un lenguaje de programación, puede que los agentes ya lo estén usando para escribir una parte significativa del software del mundo.
El ganador no será necesariamente el lenguaje que a los humanos nos guste más leer.
Será la representación que los agentes puedan usar para producir los sistemas más fiables, seguros, eficientes y verificables, sin dejar de dar a los humanos un control significativo sobre el resultado.
Los lenguajes de programación se inventaron para que los humanos pudiéramos decirles a las computadoras qué hacer.
El próximo puede que se invente para que las computadoras se lo digan a sí mismas.
Top comments (0)