En los últimos dos años, los asistentes de IA para programar se han colado en la vida de prácticamente todos nosotros. Incluso de quienes juraban que no los iban a usar nunca (hola, sí, yo también era de esos y he acabado convirtiéndome).
Con HTML, CSS, JavaScript del de toda la vida y funciones puras funcionan de maravilla. Pero les das un componente de React con cinco hooks que se hablan entre sí, o un computed() de Vue conectado a un estado que se modifica tres archivos más allá, y de repente el asistente parece que se ha tomado dos copas de más.
Y no, no es una impresión sacada de una charla después de un meetup. Hay una razón bastante concreta detrás, y es la misma por la que estos frameworks también nos complican la vida a los humanos. La diferencia es que, con la experiencia, nosotros desarrollamos una especie de callo mental que nos ayuda a esquivar ciertas trampas. Los modelos no tienen ese callo, así que caen en ellas con todo el entusiasmo del mundo.
El problema no es la sintaxis, es la magia
Los modelos de lenguaje generan código prediciendo qué texto viene después a partir de lo que tienen delante. Se les da bien cuando pueden deducir cómo funciona algo mirando el propio código: una función pura se explica prácticamente sola. Miras lo que entra, lo que sale y listo. No hay misterio.
El problema llega cuando el comportamiento depende de algo que no aparece por ninguna parte en el archivo que están leyendo en ese momento.
En los últimos años, los frameworks web reactivos han ido todos en la misma dirección: más magia automática y menos código que escribir a mano. Todo comodísimo mientras funciona.
Para un desarrollador con experiencia, esto puede ser una maravilla: escribes tres líneas y el grafo de actualizaciones se monta él solito. Pero para un modelo que tiene que generar código correcto sin poder ejecutar mentalmente ese grafo invisible, la cosa cambia.
Es como participar en una carrera de obstáculos a oscuras. Y sin que nadie te haya explicado dónde están los obstáculos.
Un ejemplo práctico. En Vue 3, desestructurar un objeto reactivo puede cargarse la reactividad en silencio:
const state = reactive({ count: 0 })
// Deja de actualizarse. Sin errores, sin avisos. Silencio absoluto.
const { count } = state
// Esto, en cambio, funciona perfectamente.
const count = computed(() => state.count)Lenguaje del código: JavaScript (javascript)Quien lleva un tiempo trabajando con Vue ya se lo sabe y lo evita casi por instinto. Pero un modelo que genera código basándose en patrones habituales de JavaScript, donde desestructurar un objeto es inofensivo en el 99 % de los casos, tiene muchas papeletas para caer en la trampa.
Y la misma película se repite, con distintos protagonistas, en los arrays de dependencias de useEffect en React: te olvidas de una dependencia y aparece un bug silencioso; añades una de más y puedes acabar en un bucle infinito. O con el seguimiento automático de dependencias de computed().
Ampliando la familia: Solid y Angular
A quien insiste en que «bueno, los signals de Solid son solo un get/set, tampoco es para tanto» le diría que sí, siempre que estés mirando un signal por separado.
El problema empieza cuando los combinas.
Un memo o un effect en Solid registra en tiempo de ejecución qué signals ha leído durante su ejecución, sin que tengas que declarar esas dependencias en ningún sitio. Es el mismo principio que el seguimiento automático de Vue, solo que aplicado de otra manera.
Y cuando un signal activa otro, que a su vez dispara un efecto que modifica el primer signal, el grafo de propagación no aparece escrito en ninguna parte del código. Hay que reconstruirlo siguiendo las lecturas y escrituras que se producen en tiempo de ejecución.
Para un modelo, es el mismo tipo de acertijo que en Vue, pero con otro disfraz.
Angular, por completar la fiesta, consigue sufrir dos problemas a la vez.
Por un lado, también ha adoptado los signals al estilo de Solid, con el mismo seguimiento implícito de dependencias. Por otro, sigue siendo Angular: decoradores, inyección de dependencias, módulos y una cantidad de código repetitivo que llamar «generosa» sería quedarse corto.
Aquí alguien dirá: «Pero si ahora las ventanas de contexto tienen cientos de miles de tokens, ¿qué más da que Angular sea verboso? ¡Si ya hay espacio de sobra!».
Y sí, pero ese no es el problema.
La cuestión ya no es que se acabe la memoria, sino la relación entre la información útil y el ruido. Doscientas líneas de código repetitivo para decir «este componente recibe una entrada y expone una salida» son doscientas líneas en las que el modelo tiene que repartir su atención. Y, mientras tanto, la lógica de negocio que de verdad importa queda diluida entre decoradores, providers y configuraciones que se repiten una y otra vez.
Es el mismo fenómeno que se conoce como lost in the middle: cuanto más ruido rodea al detalle importante, más probabilidades hay de que ese detalle reciba menos atención. No porque falte espacio, sino porque hay poca información útil por línea.
¿El resultado? Más posibilidades de perder el hilo entre un decorador y otro, sobre todo cuando toca enfrentarse a archivos interminables.
Por qué los estándares web salen mejor parados
Los asistentes de IA generan mejor código con HTML, CSS y JavaScript sin demasiadas capas por exactamente el mismo motivo por el que sufren con los frameworks más «mágicos»: cuanto menos tengan que deducir para saber qué va a pasar, mejor.
Una función que recibe un estado y devuelve uno nuevo es un libro abierto. Un manejador de eventos que hace exactamente lo que dice que hace, también.
¿Un sistema que rastrea dependencias escuchando qué variables se leen durante la ejecución? Eso ya es otra historia.
Esto no es un ataque a los frameworks web, que quede claro. React, Vue, Svelte, Solid y Angular siguen siendo herramientas muy potentes, utilizadas con éxito a gran escala. Y nadie está proponiendo que volvamos a crear webs con document.write, tampoco nos vengamos arriba con la nostalgia.
Es más bien una reflexión sobre un equilibrio que hasta ahora hemos valorado casi siempre desde el punto de vista humano: cuánto código tengo que escribir, lo cómodo que resulta y lo rápido que puedo trabajar. Pero hoy toca mirarlo también desde otra perspectiva: la de quienes cada vez más a menudo programamos en pareja con un modelo de IA o, directamente, le dejamos escribir el código por nosotros.
Qué significa todo esto en la práctica
Estas son algunas de las reglas que sigo cuando trabajo con un asistente de IA.
Cuanto más oculta un framework quién tiene que actualizarse cuando algo cambia, más atención hay que prestar al código que genera la IA. Los hooks de React, los composables de Vue y las computaciones de Solid son el terreno perfecto para que se cuelen bugs sutiles. No porque la IA tenga malas intenciones, sino porque desconoce parte del contexto implícito.
El código explícito también es más fácil de comprobar para un modelo, no solo para una persona.
Una buena prueba es pedirle a la IA que explique por qué un fragmento de código hace lo que hace. Si para explicarlo tiene que adivinar comportamientos que no aparecen en el archivo que tienes delante, ahí hay un punto delicado.
Y no solo para la IA: también para ese compañero que abrirá el archivo dentro de seis meses sin acordarse de nada de lo que teníais en la cabeza cuando lo escribisteis.
Algunos proyectos están apostando claramente por arquitecturas más explícitas: estados como datos sencillos, renderizado mediante funciones puras y nada de proxies ni compiladores de por medio. El objetivo es que el código sea fácil de leer tanto para las personas como para las máquinas.
Inglorious Web, el framework de código abierto en el que trabajo, es uno de estos intentos, aunque ni mucho menos el único. La misma filosofía lleva tiempo detrás de librerías minimalistas como Alpine.js y de enfoques que ponen HTML en el centro, como htmx.
Que este camino acabe convirtiéndose en la norma o se quede en un nicho para quienes no quieren renunciar a lo sencillo está por ver. Pero sí es una señal de hacia dónde se está moviendo parte del debate sobre arquitectura frontend.
Una pregunta abierta (y cero cruzadas)
No estoy diciendo que tengamos que volver todos al JavaScript vanilla escrito a mano como en 2010, con jQuery para rematar la jugada nostálgica. Los frameworks con su buena dosis de magia ofrecen ventajas reales para la productividad humana que los estándares web, por sí solos, no pueden igualar fácilmente. Y para muchos equipos, el trato sigue compensando.
Pero quizá ha llegado el momento de hacernos una pregunta: cuando elegimos una arquitectura, ¿debería empezar a pesar tanto que el código sea legible y predecible para un modelo como que resulte cómodo para un desarrollador con experiencia?
Porque en 2026 el código ya no lo escribe siempre una única persona que se conoce de memoria todas las trampas del framework. Cada vez más, nace del trabajo conjunto de una persona y un modelo de IA.
Y que el código sea fácil de entender para ambos deja de ser una manía estilística para convertirse en una característica de la propia arquitectura.
La magia está muy bien, pero que luego no nos toque hacer de detectives.
