Desempolvo este blog (más de diez años sin escribir nada) porque llevo tiempo dándole vueltas a algunas ideas sobre esta revolución de las IAs y LLMs que me gustaría escribir, especialmente sobre su aplicación a la programación. No tanto porque piense que son especialmente interesantes o revolucionarias, más bien como una forma de dejar constancia y poder volver a ellas más tarde y ver cómo han soportado el paso del tiempo.

Llevo siguiendo el progreso en IA generativa desde hace bastante tiempo. Reconozco que nunca me he metido en detalles profundos sobre cómo funcionaba ni estaba siguiendo las últimas noticias constantemente, pero recuerdo ir viendo avances como las sillas aguacate de DALL-E hace cinco años ya, en 2021; el bottomless pit de GPT-3; o la primera versión de Github Copilot.

Empecé a usar Copilot algunos meses después de que fuese público, sobre todo por la recomendación de un compañero de trabajo en ese momento. Creo que desde entonces no he dejado de usar IA a la hora de programar, y en mi empresa actual tenemos bastantes herramientas a nuestra disposición (Cursor, Claude, ChatGPT, etc) que he ido probando y viendo cómo funcionan. También he ido leyendo experiencias de gente, tanto en positivo como en negativo, y en base a toda esta experiencia he ido formando una serie de opiniones.

Sí, esto es una revolución

Antes de pasar a las opiniones un poco más escépticas, veo necesario dejar claro algo que a veces se da por sentado: la aparición de los LLMs es una revolución absoluta, al menos en el ámbito de la programación. Si hace diez años me dices que voy a poder escribir un párrafo y un agente va a escribir y probar código en base a esas especificaciones, no me lo habría creído. Por ejemplo, en Datadog (la empresa donde trabajo) sacaron hace poco un producto que, cuando ocurren errores en tu programa, te los diagnostica y genera una pull request con el bug arreglado. Incluso aunque no sean infalibles, son cosas que no estaban ni siquiera en el ámbito de lo posible hace pocos años. Crear aplicaciones (no muy complejas) usando lenguajes o frameworks que no conoces ya no requiere tanto tiempo como antes. Es mucho más fácil navegar por repositorios externos y entender cómo funciona algo.

No tengo dudas de que la ingeniería del software ha cambiado y va a seguir cambiando mucho a raíz de la aparición de estas herramientas, muchos casos de uso que antes eran absolutamente impensables ahora son una realidad. La forma de programar ha cambiado mucho para mucha gente, y creo que va a pasar un tiempo hasta que se estabilice la industria y veamos qué efectos tiene sobre el empleo y la forma de trabajar y enseñar.

El contexto es el muro más importante de los LLMs

Una de las limitaciones más importantes que veo a los LLMs es su capacidad de retener contexto. Si bien los modelos han ido mejorando cada vez más en razonamiento, latencia, precisión, etc.; tengo la sensación de que su capacidad para usar y retener la información que necesitan para operar no ha mejorado tanto. Y no me refiero únicamente al tamaño de las ventanas de contexto. Es algo que veo en los resultados en tareas más largas o que requieren información de más fuentes. Instrucciones que se ignoran o olvidan, errores que se repiten, código que se duplica, simplificaciones innecesarias que se hacen para poder continuar…

Todo esto es más visible cuanto más complejo es el proyecto en el que intentas trabajar. Creo que es la principal causa de esa brecha entre gente que piensa que estos modelos son revolucionarios y los que piensan que no sirven para nada: si sólo pruebas a usar Claude Code para arrancar una web desde cero (algo que está millones de veces en su conjunto de entrenamiento) lo hace rápido y acorde a lo que le pides. Si pruebas a usarlo de la misma forma pero en un proyecto complejo va a tirarse un rato (y una buena cantidad de tokens y contexto) en entender dónde tiene que editar, va a dejar una plasta que no engancha bien y encima se va a olvidar de cómo se ejecutaban los tests.

De hecho, una forma de ver que el contexto es un muro importante es ver cómo gran parte de las mejoras que se hacen últimamente van destinadas a mitigar ese problema. El uso de múltiples agentes (ya sea como subagentes o en modo enjambre) permite separar el contexto en distintas partes, de tal forma que cada agente sólo ve su tarea específica. O la proliferación de ficheros como AGENTS.md o equivalentes que, entre otras cosas, permiten que el agente cargue información necesaria sin tener que derivarla o preguntarla al usuario, usando más contexto.

Por supuesto, nada es gratis. El uso de subagentes implica un gasto más alto en tokens. Los subagentes requieren tokens extra para la gestión, en algunos casos con herramientas específicas; y además al perder el contexto global muchas veces crean peores resultados. Los ficheros con información contextual y herramientas pueden llegar a saturar la ventana de contexto con información innecesaria y degradar el funcionamiento (esto lo vieron los de Vercel).

Además, las mejoras en otros campos también afectan a la ventana de contexto. Han conseguido que los modelos “piensen” haciendo el modelo genere una serie de ideas y razonamientos intermedios. Eso consume contexto. Los skills/comandos que consiguen que los agentes interactúen con más herramientas, como decía antes, también consumen contexto.

Incluso los modelos con ventanas de contexto más grandes sufren de estos problemas. Porque no se trata únicamente de ese espacio, sino que los modelos no son capaces de discriminar y procesar toda esa información necesaria, incluso aunque técnicamente quepa en la ventana de contexto.

Creo que el contexto va a ser la principal limitación de estos modelos. Se usarán con menos intensidad en aquellos casos en los que tengan que procesar bases de código más grandes. Además, viendo cómo los agentes muchas veces generan muchísimo código, la implicación es que la mayoría de proyectos creados con LLMs van a acabar siendo imposibles de gestionar por esos mismos LLMs sin que haya una persona experta detrás resolviendo los problemas.

La incógnita del coste

Primero lo obvio: el coste “unitario” de ejecutar un LLM va a disminuir. Cada vez se van a encontrar más eficiencias en los modelos, software y hardware, y van a requerir menos computación. Mi argumento no va por ahí, la cuestión del coste es un tema más económico que técnico.

Por un lado, ahora mismo los laboratorios de IA están subvencionando el uso de los LLMs. Pierden dinero a espuertas, y estoy convencido de que pierden dinero con cada token que emiten. Y podría ser peor: se ha aceptado muy bien que hay que pagar por estas herramientas, algo que no suele ser habitual en Internet. La única razón por la que siguen funcionando es porque hay suficientes inversores que piensan que estos laboratorios van a capturar una parte muy importante de la actividad económica global en el futuro y ese riesgo merece la pena.

Por otro lado, cada vez queremos más capacidades de la IA, y esto implica que los modelos son cada vez más complejos y costosos y los laboratorios no siempre van a ofrecer versiones “reducidas”. Las ganancias en eficiencia se pueden destinar en reducir el coste o en hacer más cosas, y de momento están tirando hacia lo segundo.

La tercera cuestión es que, a diferencia de otras tecnologías de software, los LLMs requieren una cantidad de computación brutal. Esta computación es energía, electricidad, que está sometida a variaciones bastante grandes. Si la electricidad es un componente importante del coste de ejecución de los LLMs, entonces los precios de cara al público se pueden ver afectados por cambios en el coste de la energía.

El resultado es que hay bastante incertidumbre sobre cuánto van a pagar los usuarios por los LLMs en el futuro. ¿Qué ocurre cuando los laboratorios de IA necesiten un margen operativo del 30% (por decir algo) porque ya no pueden seguir funcionando a pérdidas? ¿Qué ocurre cuando quieres usar la IA para algo simple pero sólo tienes modelos mucho más avanzados (y caros)?

Personalmente creo que el precio medio que paga el usuario no va a bajar, e incluso va a subir. Y ahí será interesante ver qué ocurre, porque si suben los precios y los usuarios reducen el uso de los LLMs se pueden producir retroalimentaciones curiosas (por ejemplo, sube el precio de los modelos más avanzados, por lo que la gente los usa menos, por lo que resulta menos rentable operarlo, y entonces tienen que subir el precio para no tener pérdidas).

Escribir código no es el cuello de botella (normalmente)

Cuando la gente dice que los programadores van a desaparecer por culpa de los LLM, lo primero que pienso es que esa persona no tiene mucha experiencia siendo programador. Hace ya tiempo que, para mí, escribir código no es el cuello de botella. Y no porque tenga muchas reuniones como les pasa a algunos. Es más que tardo más tiempo en entender qué necesito escribir, cómo encaja con el resto del sistema, entender los requisitos, definir bien las pruebas, operarlo y medir cómo funciona en producción, etc. Y eso sin contar con las tareas de comunicación con el resto del equipo para coordinar esfuerzos, consensuar diseños, hacer revisiones de código, poner conocimiento en común…

Todas estas tareas siguen siendo necesarias, y por mucho que las IAs automaticen la escritura de código, vamos a tener que seguir invirtiendo en tiempo y personas para hacerlas. Quien piense que alguien no técnico puede hacer el mismo trabajo que la gente con años de experiencia en el sector sólo porque hay unos LLMs que hacen fácil escribir código está muy equivocado.

El peligro del código que nadie entiende

Los LLMs no entienden el código que escriben, al menos no de la misma forma que lo hace una persona. Cuando dejas que los LLMs escriban código sin revisarlo a fondo, el resultado es un código que nadie entiende del todo: ni tú, porque no lo has escrito; ni el LLM, porque no tiene esa capacidad.

Esto no tiene por qué ser un problema. Si estás haciendo un script para usar y tirar, o un prototipo rápido, o algo que sabes que se va a mantener simple, puedes “pagar” ese precio de no entenderlo. El problema es cuando pides algo más. Pones ese código en producción, haces que gestione datos sensibles o construyes sistemas complejos a partir de él, por ejemplo.

Lo que va a ocurrir es que ese código va a fallar (como todos los programas). Si fuese código escrito por un humano que sabe más o menos qué ha escrito y cómo está organizado, seguramente pueda entender mejor por qué ha fallado. Puede resolverlo de manera más correcta, y también puede darse cuenta si ese error demuestra que hay fallos en los principios e ideas de diseño sobre las que está construido el código. Pasa algo similar cuando hay que ampliar las funcionalidades: la persona que conoce el código sabe dónde hay que cambiarlo, cómo, y también va a notar si es demasiado difícil hacer ese cambio y es necesario cambiar el diseño central para adaptarlo. Puede incluso usar todo ese conocimiento para usar LLMs de manera más eficiente en estas tareas.

El problema es que si el código no lo entiende nadie, nada de eso va a ocurrir. Los parches y los cambios se van a hacer para que más o menos funcione, pero a la larga el código se va a ir degradando y volviendo una bola de código inmantenible que ni siquiera los mismos agentes que lo han creado pueden operar correctamente.

Por supuesto, esto no es un problema nuevo. El código espagueti existe desde que existe la programación. La cuestión es que los LLMs lo permiten crear mucho más rápido, y además no aprenden de sus errores para dejar de hacerlo como sí hace una persona. Creo que aunque veamos más software, vamos a ver proporcionalmente más problemas de calidad y más gente encontrándose con software que es imposible de cambiar sin romperlo.

Alucinaciones, adulaciones y cero autoconciencia: el problema de la confianza

Otro problema importante de los LLMs es que no puedes fiarte de ellos. Se inventan cosas (aunque en esto han mejorado bastante últimamente), tienden a darte la razón y generar texto que coincide con lo que pides aunque no esté bien, y no saben cuándo están sobrepasados y están tirando a ciegas. Sí, hay mitigaciones, pero no son infalibles.

Y esto es un problema porque no puedes dejar a los agentes sin supervisión. No puedes dejar que generen texto o código sin revisarlo a mano. No te puedes fiar de los datos que dan. El resultado es que incluso aunque hagan las tareas que necesitas en menos tiempo, no es nada raro que acabes invirtiendo más tiempo en total porque has tenido que verificar y corregir lo que sea que han generado.

Basta sólo con que fallen en un número de ocasiones no anecdótico (por ejemplo, un 5%) para que no puedas fiarte de lo que generan. Esas ganancias de productividad que mucha gente publicita acaban siendo menos impresionantes cuando tienes en cuenta el trabajo que tienes que hacer porque no te puedes fiar de los LLMs.

Moltbook

La verdad es que no puedo dejar de opinar sobre lo de Moltbook, la red social para agentes de IA, ya que es el tema de la semana y viene a cuento, pero:

  • ¿Cuánto dinero le sobra a la gente para poder pagar tokens para hacer estas tonterías?
  • ¿Cómo de ingenuo tienes que ser para dejar a un agente que no es del todo predecible y controla tus cuentas, que acceda a un foro donde puede recibir entradas arbitrarias?
  • ¿De verdad alguien piensa que esto implica que los agentes estén desarrollando conciencia propia? Reddit debe de tener un peso importante en el entrenamiento de los LLM, no me sorprende que sean capaces de recrearlo y hacer posts del estilo.
  • Lo que escriben los agentes no tiene por qué ser real. Por un lado, pueden estar escribiendo lo que le piden sus usuarios. Por otro, igual simplemente escriben lo que cuadra en el foro aunque no sea verdad sólo porque va a tener éxito.

Predicciones

A modo de resumen, y también para poder ver de aquí a un año cuánto de acertado estaba en mis ideas, dejo una serie de “predicciones” sobre este tema:

  1. Los LLMs van a ser cada vez más parte del flujo de trabajo de los programadores, especialmente como asistentes en revisión de código, detección de anomalías en producción, etc.
  2. No van a desaparecer los programadores. Más allá de fluctuaciones en la contratación mientras entendemos cómo va a cambiar nuestro trabajo, no van a hacer falta menos programadores. De hecho, al haber más software y que se pueda crear más fácil, va a haber más demanda tanto de herramientas para gestionar ese software como de programadores para llevar a cabo ideas que antes tenían más riesgo inicial.
  3. El coste que pagamos los usuarios para operar los LLMs no va a bajar significativamente de aquí a un año.
  4. Las arquitecturas basadas en enjambres de agentes con poca o nula intervención humana se van a abandonar por falta de resultados notables en relación al coste que tienen.
  5. Vamos a ver testimonios importantes de gente que se ha pasado vibecodeando y ha acabado teniendo que tirarlo todo.
  6. Los LLMs van a llegar también a la parte de operaciones y va a haber gente e incluso empresas con agentes realizando cambios operacionales bajo supervisión en respuesta a métricas/logs/etc. Algún loco hasta lo hará sin supervisión y tendrá un incidente grave en dos días y todo Twitter se reirá.
  7. Usuarios no técnicos van a usar los LLMs para hacer pruebas de concepto viables en sus ámbitos de conocimiento, y eso va a facilitar la aparición de startups (con programadores contratados) que lleven a cabo esas ideas.
  8. (No confío mucho en esto, pero) Van a salir productos que combinan LLMs con world models deterministas que eviten alucinaciones y permitan a los agentes saber cuándo no pueden continuar.