El código que generan los agentes LLM se parece a un katamari

Un comentario en un agregador de noticias de programación comparó estos días el resultado de dejar sueltos a los agentes de código basados en LLM con un katamari: la bola del videojuego Katamari Damacy que rueda pegando a su superficie cualquier objeto que encuentra. La imagen funciona. El desarrollo agéntico tiende a añadir funcionalidad sin mirar la composición del conjunto, coge el camino más corto para cumplir el prompt y arrastra todos los defectos de un ingeniero con prisa y mal pagado.

Al katamari, en cambio, le hace un flaco favor. Aquella bola era redonda por diseño, y el método para lograr que rodara así tuvo suficiente complejidad como para acabar en una patente. Lo que hace un LLM es otra cosa: no tiene criterio para decidir cómo encaja una función nueva, así que la pega donde caiga, modulada por una distribución de probabilidad.

Las fuerzas del barro

Para entender el fenómeno, el ensayo tira del Big Ball of Mud que describieron Foote y Yoder, y repasa las fuerzas que aquellos atribuían a los amasijos de software: tiempo, coste, experiencia, habilidad, visibilidad, complejidad y escala.

Tiempo no es el problema: un agente trabaja 24 horas, fines de semana incluidos. Coste tampoco: hay empresas con presupuesto de tokens sin límite, y la propuesta de los LLM es precisamente salir más baratos que una persona. Experiencia, menos aún: un modelo frontera se ha entrenado con más o menos todo el software escrito, además de libros y foros, así que no hay proceso de diseño que le suene nuevo.

Quedan tres fuerzas que sí explican el desastre. La primera es la habilidad. La inteligencia de un modelo es desigual: resuelve búsquedas mal especificadas sobre corpus enormes y se atasca en tonterías que cualquier persona detecta al instante. Sus errores no son los que cometería un humano, y por eso cuesta más verlos en una revisión.

Lo que nadie lee

La segunda es la visibilidad, y es la que más incomoda. Un agente genera cientos o miles de líneas para cualquier cambio, y nadie hace una lectura atenta de una pull request de +6.000/-400 sloc. Cuanto más código sale de un modelo, menos se lee. El texto menciona el caso de Andrej Karpathy, que según el autor ya no lee el código, y recupera una frase de Foote y Yoder: si el sistema funciona y se puede desplegar, a quién le importa cómo es por dentro.

La tercera es el cambio. El esfuerzo humano frena el ritmo de modificación; con un LLM, implementar algo cuesta lo mismo que pedirlo. Pero ese cambio se aglomera sobre la arquitectura existente en vez de atravesarla, y el resultado típico es un núcleo bien diseñado por una persona sepultado bajo capas de objetos domésticos. Un agente puede decidir rehacer el sistema entero, aunque rara vez tiene con qué.

Ni la complejidad ni la escala sirven de excusa: la mayoría del software tiene poca complejidad esencial, y los agentes rinden igual de mediocres en pequeño que en grande.

El diagnóstico es que esto no se arregla pidiéndole al modelo que sea más ordenado. Mientras generar código cueste casi nada y revisarlo siga siendo caro, la bola seguirá rodando y pegando cosas.