luismori.

AI-Assisted Engineering Practice

AI Frontend Architecture

Menos código, menos alucinaciones: por qué la cogeneración con IA exige frontends más simples

Cuando un agente de IA inicia tareas en un frontend complejo, la complejidad se convierte en el enemigo. La hipótesis: bases de código más simples significan menos bugs y, en la era de la cogeneración con IA, también menos alucinaciones.

15 min de lectura

Una crisis silenciosa se está gestando en el desarrollo de frontends asistido por IA. Los equipos que adoptan agentes de programación con IA —Cursor, Claude Code, GitHub Copilot— están descubriendo que las herramientas funcionan de maravilla en tareas aisladas, pero su rendimiento se desploma en cuanto aumenta la complejidad. ¿Un componente de formulario? Excelente. ¿Estado distribuido entre varios pasos en una base de código real? Mucho menos confiable.

El culpable no es el modelo. Es la base de código.

La relación entre complejidad y alucinaciones

Los benchmarks de IA muestran que los modelos de programación alcanzan aproximadamente un 40% de éxito en tareas aisladas de React —crear la estructura inicial de componentes, implementar especificaciones explícitas—, pero esa cifra cae a ~25% en integraciones de varios pasos. Addy Osmani llama a esto el «precipicio de la complejidad»: en cuanto una tarea exige comprender estado no local, aspectos transversales o convenciones arquitectónicas implícitas, las tasas de error se disparan.

No se trata de ruido aleatorio. Un estudio de ICIS de 2025 confirmó que las respuestas alucinadas de la IA generativa perjudican directa y mensurablemente el rendimiento de los desarrolladores, y que el efecto se agrava en entornos de equipo. Una encuesta de Qodo de 2025 reveló que el 25% de los desarrolladores estima que 1 de cada 5 sugerencias de IA contiene errores fácticos o código engañoso; además, casi un tercio de todas las solicitudes de mejora de los desarrolladores se referían a que las herramientas de IA comprendieran mejor el contexto, no a que fueran más rápidas.

La causa raíz es simple: los LLM tienen una ventana de contexto finita y las bases de código complejas la consumen rápidamente. Cuando un agente que ejecuta varias tareas de frontend tiene que razonar sobre cientos de archivos, patrones de gestión de estado que compiten entre sí y años de abstracciones acumuladas, la relación señal-ruido se desploma. El modelo comienza a llenar los vacíos con alucinaciones que suenan plausibles.

Mientras tanto, el informe State of AI Code Quality 2025 de GitClear documentó un aumento del 800% en la duplicación de código en repositorios de React desde 2023. Los agentes de IA generan código más rápido de lo que las personas pueden controlarlo. El resultado es el «deterioro del código»: una acumulación silenciosa de patrones inconsistentes, abstracciones sin uso y lógica copiada y pegada que hace que la siguiente interacción con la IA sea aún más difícil de razonar.

Es un círculo vicioso. Código complejo → más errores de IA → más complejidad generada por IA → errores de IA más graves.

La hipótesis: simplificar para escalar la IA

El antídoto no son mejores prompts. Es una base más simple.

Las investigaciones sobre miles de proyectos de software confirman lo que todo desarrollador experimentado ya sospecha: más líneas de código significan más bugs. El equipo de Spotify redujo la complejidad ciclomática promedio de 15 a 8 y registró 30% menos bugs y un desarrollo de funcionalidades 20% más rápido. Netflix redujo la complejidad ciclomática de su herramienta Chaos Monkey en un 25%, lo que mejoró significativamente su mantenibilidad.

Para la cogeneración con IA, la relación es aún más directa. De la guía de LogRocket sobre arquitectura preparada para IA: «Un paso clave antes de aplicar medidas de protección es simplificar la arquitectura para que la IA necesite menos contexto para hacer su trabajo. Si todos los casos de uso siguen la misma estructura de archivos y el mismo patrón de nombres, la IA puede generar otros nuevos a partir de esos ejemplos. Si todos son diferentes, hace lo que cree que es mejor».

Menos contexto necesario → menos alucinaciones. Menos alucinaciones → código que realmente funciona. Código que realmente funciona → una base de código que sigue siendo manejable.

Dicho sin rodeos, la hipótesis es: la mejor manera de mejorar la calidad del código de frontend generado por IA es elegir frameworks y arquitecturas que minimicen la cantidad de código que un agente necesita leer, escribir y sobre el cual debe razonar.

¿Qué hace que un framework sea compatible con IA?

No todos los frameworks de JavaScript son igual de hostiles para los agentes de IA. Varias propiedades hacen que sea más fácil para los LLM generar código correcto con un framework:

  • Superficie de API pequeña y estable: menos tokens únicos que deben ser correctos y menor probabilidad de alucinar métodos que no existen
  • Sintaxis declarativa y cercana a HTML: más próxima a los patrones de los datos de entrenamiento y con menos indirección
  • Sin magia: un flujo de datos explícito permite que una IA razone localmente sin comprender todo el sistema
  • Convención sobre configuración: los patrones consistentes de archivos y nombres permiten que la IA genere código a partir de ejemplos
  • Menos JavaScript enviado: menos elementos en movimiento durante la ejecución significan menos cosas que pueden fallar

Con estos criterios en mente, estos son los frameworks que destacan en 2026.

HTMX — La apuesta minimalista

HTMX es la opción más radical de esta lista. Extiende HTML con atributos como hx-get, hx-post y hx-swap, lo que te permite construir interfaces dinámicas sin escribir JavaScript. El servidor devuelve fragmentos de HTML; HTMX los intercambia en la página.

Para la generación con IA, HTMX es casi ideal. Toda la API cabe en unas pocas decenas de atributos. El patrón es declarativo y local: cada elemento declara su propio comportamiento en línea. Una IA puede generar una interacción funcional con HTMX a partir de una descripción de una sola oración, sin comprender el código que la rodea.

La contrapartida: HTMX requiere un servidor que devuelva HTML. Es, fundamentalmente, un patrón del lado del servidor. Para los equipos que ya trabajan con stacks que renderizan en el servidor (Django, Rails, Go, Laravel), encaja de forma natural. Para las SPA puramente del lado del cliente, requiere replantear la arquitectura.

Alpine.js — JavaScript progresivo sin el costo adicional de un framework

Alpine.js se presenta como «jQuery para la web moderna». Agrega comportamiento reactivo directamente en HTML mediante los atributos x-data, x-bind y x-on: sin paso de build, sin bundler y sin DOM virtual. Agrega una etiqueta <script> y tendrás un componente reactivo.

Donde Alpine destaca para la generación con IA es en su localidad. El estado se declara directamente en el elemento que lo usa. No hay un store separado, proveedores de contexto ni prop drilling. Una IA que genera código Alpine no necesita comprender los componentes circundantes: solo lee el elemento y sus atributos.

El AHA Stack (Astro + HTMX + Alpine) formaliza esta combinación: Astro se encarga del renderizado durante el build, HTMX de las interacciones con el servidor y Alpine de la interactividad ligera del lado del cliente. Varios casos de estudio reales, incluida la migración de una plataforma de streaming de alto tráfico, respaldan el uso de este stack en producción.

Astro — Arquitectura de islas, sin JS por defecto

La idea central de Astro es que la mayor parte de un sitio web no necesita JavaScript. Renderiza HTML estático durante el build y no envía JS al cliente, a menos que agregues explícitamente una isla interactiva con client:load o client:visible.

Para la generación con IA, Astro ofrece varias ventajas. Los archivos .astro tienen una estructura clara de dos secciones: un bloque de script de frontmatter y una plantilla HTML. La separación es explícita y consistente. El contenido vive en archivos Markdown con frontmatter en YAML, un formato que los LLM generan excepcionalmente bien. El enrutamiento se basa en archivos, por lo que una IA puede inferir toda la estructura de rutas a partir del directorio pages/.

Astro también admite componentes de React, Vue, Svelte y Solid como islas, lo que te permite comenzar de forma simple y agregar complejidad gradualmente, solo donde sea necesario.

SvelteKit — El framework que desaparece al compilar

La filosofía de Svelte es eliminar por completo el framework mediante la compilación. No hay DOM virtual ni biblioteca de runtime que descargar. Lo que se envía es el JavaScript mínimo necesario para actualizar el DOM y, a menudo, es muy poco.

Para la generación con IA, podría decirse que la sintaxis de Svelte es la más natural: un solo archivo .svelte contiene HTML, CSS de alcance local y JavaScript en bloques claramente delimitados. La reactividad se logra mediante asignaciones simples de variables: sin hooks, sin useState, sin useEffect. Un componente que ocupa 40 líneas en React podría ocupar 20 en Svelte.

Las runas de Svelte 5 ($state, $derived, $effect) hacen que la reactividad sea explícita y local. Una IA no necesita comprender un grafo reactivo complejo: solo lee las declaraciones de las runas.

SolidJS — Signals sin magia

SolidJS se parece a React (JSX, componentes de función), pero reemplaza el DOM virtual y el reconciliador por signals de granularidad fina. Las actualizaciones son quirúrgicas: solo se vuelven a renderizar los nodos del DOM que dependen de un signal modificado. No se vuelven a ejecutar las funciones de los componentes y no hay bugs por closures con valores desactualizados.

Para la generación con IA, SolidJS ofrece la API de React sin sus trampas habituales. No hay reglas de hooks, arrays de dependencias ni useCallback para optimizar renderizados. La API es más pequeña y consistente. Los signals (createSignal, createMemo, createEffect) cubren la mayoría de los casos de uso. Una IA que conoce React puede generar código correcto de SolidJS de inmediato y producir un código más limpio y predecible que con React.

Ripple — Creado para la era de la IA

Ripple, la incorporación más reciente a esta lista, fue creado por Dominic Gannaway (creador de InfernoJS y antiguo miembro del equipo principal de React). Su objetivo de diseño explícito es el desarrollo de frontends para la era de la IA. La filosofía, en palabras de Gannaway: «Tener código mucho más simple, mucho más fácil de leer y ergonómico; tener un sistema reactivo con el que no tengas que pelear; tener un conjunto muy pequeño de APIs: al ser menos, puedes recordarlas rápidamente y combinarlas mejor».

Ripple rechaza tanto el DOM virtual como los signals en favor de lo que Gannaway llama un sistema reactivo más ergonómico. Está en una etapa temprana, pero vale la pena seguirlo como el primer framework diseñado explícitamente pensando en la cogeneración con IA.

El «precipicio de la complejidad» visualizado

Piensa en la calidad del código generado por IA como una función de la complejidad de la base de código:

Code Quality
     │
100% ┤████████████████████
 75% ┤████████████████
 50% ┤         ██████████
 25% ┤              █████
  0% ┴──────────────────── Complexity
     Simple      Complex

Con frameworks simples (HTMX, Alpine, Astro), un agente opera en la región plana de alta calidad. Con React + Redux + React Query + un sistema de diseño personalizado, operas en la pendiente descendente, donde las alucinaciones se acumulan.

Esto no es una crítica a React. React es un excelente framework para equipos con la experiencia necesaria para gestionar su complejidad. El problema es la superficie expuesta a un agente de IA cuando el framework no limita la complejidad por defecto.

Guía práctica para equipos asistidos por IA

La investigación apunta a algunos principios concretos:

1. Elige frameworks con APIs pequeñas y estables. Cuanto mayor sea la superficie de API única que la IA debe recordar, mayor será la tasa de alucinaciones. HTMX tiene ~20 atributos. React tiene cientos de patrones, hooks e integraciones de terceros de uso común. La diferencia importa enormemente cuando un agente genera código sin acceso a documentación en tiempo real.

2. Exige patrones consistentes de archivos y nombres. De la guía de LogRocket: «Si todos los casos de uso siguen la misma estructura de archivos y el mismo patrón de nombres, la IA puede generar otros nuevos a partir de esos ejemplos». El enrutamiento de Astro basado en archivos y los componentes de Svelte en un solo archivo facilitan esto. Los monorepos con patrones mezclados lo dificultan.

3. Mantén el estado local. El estado global es donde los agentes de IA cometen los errores más costosos. El x-data en línea de Alpine, la reactividad de alcance local de Svelte y los signals explícitos de Solid hacen que el alcance del estado sea visible de un vistazo. El contexto de React, los stores de Zustand y los slices de Redux requieren que el agente comprenda todo el grafo de estado de la aplicación.

4. Minimiza el JavaScript enviado al navegador. Menos código en tiempo de ejecución significa menos código que el agente debe generar y mantener. La opción de Astro de no enviar JS por defecto y el enfoque de renderizado del lado del servidor de HTMX reducen drásticamente la superficie del lado del cliente.

5. Estructura el código para que su intención sea evidente por su ubicación. La separación entre «qué se renderiza» y «cómo se comporta» debe ser evidente. La división entre frontmatter y plantilla de Astro, los bloques <script>/<template>/<style> de Svelte y el enfoque de HTMX de colocar atributos en los elementos hacen que esto sea explícito. La ubicación conjunta de la lógica y la interfaz en JSX de React puede ocultarlo.

El panorama general

La era de la cogeneración con IA no es una razón para adoptar frameworks más sofisticados. Es una razón para reconsiderar si la sofisticación alguna vez fue el objetivo correcto.

La revolución de las SPA trajo experiencias de usuario extraordinarias, pero también, como señala la documentación del AHA Stack, «una montaña de complejidad: gestión de estado, versionado de APIs, enrutamiento del lado del cliente, validación duplicada de formularios, herramientas de build y los cambios constantes del ecosistema de JavaScript».

Los agentes de IA no necesitan frontends complejos. Necesitan código consistente y explícito que se pueda razonar localmente. Los frameworks que proporcionan eso —HTMX, Alpine, Astro, SvelteKit, SolidJS— también son los que producen páginas más rápidas, bundles más pequeños y desarrolladores más satisfechos.

Cuando tienes menos código, tienes menos bugs. Cuando tienes menos código sobre el cual una IA debe razonar, tienes menos alucinaciones. El principio siempre fue cierto. La era de la cogeneración con IA simplemente lo vuelve urgente.

Fuentes