El coste oculto en IA de los frameworks de JavaScript

El agente pasó once minutos leyendo una guía de migración antes de escribir una sola línea de código. No tu agente: el que un compañero le puso a un proyecto SvelteKit la semana pasada, con el mismo prompt que tú le habías dado a tu app de React una hora antes. El tuyo terminó en unos ocho minutos y cuatro millones de tokens. El suyo tardó diecisiete minutos y casi diez millones, y buena parte de esa diferencia fue el modelo reenseñándose pacientemente una versión de framework que nunca había visto durante el entrenamiento. Esa brecha ya tiene nombre: el coste de IA de los frameworks de JavaScript. Y gracias a un acto poco habitual en nuestra industria, alguien que de verdad mide las cosas en lugar de afirmarlas, por fin tenemos números reales.

Nolan Lawson, que lleva años sustituyendo el folclore del frontend por benchmarks de verdad, hizo recientemente lo evidente que nadie se había molestado en hacer. Especificó una aplicación Pokémon pequeña pero no trivial (búsqueda, filtrado, páginas de detalle, datos de la PokéAPI) y pidió a un agente de programación que la construyera de doce formas distintas: Astro, Next.js, Nuxt, SvelteKit, React Router, SolidStart, Qwik, Angular, TanStack Start, Hono con htmx, Gracile con Lit y Vite puro sin ningún framework de UI. Cada framework tuvo cinco ejecuciones independientes con el mismo prompt, cada build se comprobó con una suite de conformidad para que el agente no pudiera hacer trampa, y los resultados se puntuaron en coste, tiempo, tokens y métricas de Lighthouse. No es un experimento perfecto, y el propio Lawson lo reconoce. Pero es el primer intento honesto que veo de poner precio a una decisión que la mayoría de equipos toma a ojo.

Qué midió realmente el benchmark

El montaje fue deliberadamente neutral. El agente recibió la especificación, se le indicó que usara la última versión de cada framework y se le dejó elegir su propia arquitectura: SSR o CSR, lo que quisiera. Cuando un framework publica un servidor MCP, una skill para agentes o un plugin oficial, se puso a disposición, para que ninguno pudiera quejarse de estar poco representado en los datos de entrenamiento. Las pruebas de conformidad se ejecutaron sobre el árbol de accesibilidad en lugar del DOM bruto, lo que importó porque uno de los contendientes renderiza con shadow DOM. Cada framework tuvo cinco ejecuciones y los resultados se reportan como medianas, salvo Angular, que dos veces no logró producir una app comprobable, así que parte de sus números salen de tres ejecuciones.

• El coste de construcción osciló entre una mediana de unos 2,67 $ y 4,97 $ por app: una diferencia de aproximadamente 2x entre los frameworks más baratos y los más caros.
• El consumo de tokens contaba la misma historia con más fuerza: unos 4 millones de tokens en las pilas más baratas y casi 10 millones en las más caras.
• El tiempo real siguió de cerca al coste, desde unos 8 minutos en el extremo rápido hasta 17 minutos en el lento.
• SvelteKit, Gracile+Lit y Angular fueron de forma consistente las compilaciones más caras. Astro y la combinación Hono+htmx fueron sistemáticamente baratas.
• Sorprendentemente, el build de Vite sin framework quedó por detrás de varios frameworks reales: algo de estructura siempre gana, incluso para una máquina.

Dos dólares por build suenan a nada. Para una sola build, efectivamente es nada. Pero el desarrollo con agentes es iterativo por naturaleza: nadie acepta la primera salida. Multiplica esa diferencia por decenas de sesiones de agente por desarrollador a la semana, por todo un equipo, durante un año, y un multiplicador de tokens de 2x en tu stack se convierte en una partida real del presupuesto. Y lo más importante: los tokens son un proxy de algo que me importa más que el dinero, es decir, cuánto ensayo y error necesita el modelo para producir código correcto en tu framework. Muchos tokens suelen significar que el agente está confundido, releyendo documentación y reintentando. Es una señal de calidad disfrazada de coste.

Por qué algunos frameworks hacen caros a los agentes

Después de años entrenando y evaluando modelos, encuentro los resultados menos misteriosos de lo que parecen. Tres mecanismos explican casi toda la diferencia, y ninguno tiene que ver con cuál framework es «mejor» en el sentido tradicional.

La densidad de datos de entrenamiento es el destino

La mayor ventaja de React en la era agéntica no es su modelo de programación, sino que una década de tutoriales, repositorios de GitHub y respuestas de Stack Overflow ha comprimido sus idiomas en los pesos de cada modelo puntero. Un agente que escribe React sobre todo recuerda. Un agente que escribe Gracile sobre todo descubre: en las ejecuciones del benchmark, los agentes que no conocían el framework acabaron clonando su repositorio o leyendo el código compilado desde node_modules. Son tokens quemados en una formación básica antes de que exista código de usuario. Es la misma dinámica que está reconfigurando cómo los desarrolladores buscan conocimiento en general: escribí sobre qué le pasa al corpus de conocimiento de los desarrolladores a medida que Stack Overflow se apaga, y el ángulo de los frameworks es un caso especial y muy claro: las herramientas poco populares no solo carecen de comunidad, sino también de presencia en el propio modelo.

El churn de APIs es un impuesto recurrente en tokens

El mal resultado de SvelteKit tiene una causa concreta y casi cómica: el agente leyó la guía de migración de SvelteKit v3 en cada una de las ejecuciones, porque esa versión era demasiado nueva para estar en los datos de entrenamiento del modelo. Cada cambio incompatible que publica un framework invalida patrones que el modelo había memorizado y le obliga a deducir de nuevo la API correcta desde la documentación en tiempo de inferencia. Se paga en tokens, en cada sesión, por cada usuario. Los frameworks tratan los cambios de versión mayor como un evento de marketing. Para quien usa agentes, es un recargo recurrente. Un framework aburrido que no ha roto su API en tres años es, según esta métrica, una funcionalidad premium.

La verbosidad se acumula en el bucle

El coste de Angular parecía seguir su volumen de código: más líneas generadas significan más tokens de salida, más tokens que releer en cada edición posterior y más superficie para que el agente tropiece. Esto se generaliza: cualquier stack con salida de herramientas verbosa, logs de build ruidosos o comandos de test lentos obliga al agente a atravesar más texto en cada iteración, y cada lint o comprobación de tipos fallida dispara otra costosa vuelta. Los profesionales describen el mismo patrón en todas partes: lo que domina el gasto de los agentes no es el coste de generar, sino el de iterar. Un framework con una cadena de herramientas rápida, silenciosa y estricta es más barato de operar que uno permisivo, porque la estrictez detecta los errores del agente en un ciclo en lugar de en cinco.

Cada cambio incompatible que publica tu framework es ahora un impuesto que alguien paga en tokens, y, a diferencia de una persona leyendo un changelog, el modelo lo paga en cada sesión.

El problema del dado en los benchmarks de agentes

Aquí es donde se activan mis viejos hábitos de evaluación de ML, porque el detalle más importante de todo el estudio son las barras de error. La salida de un LLM es una distribución, no un punto. El coste mediano de build de React Router fue alrededor de un dólar peor que el de Hono+htmx, pero la ejecución más barata de React Router salió por debajo de la más cara de Hono. Los rangos se solapan sustancialmente. Las ejecuciones de SvelteKit oscilaron entre unos 3,20 $ y 6,80 $. A veces el agente simplemente saca un número bajo, se desvía por una tangente y quema unos cuantos millones de tokens por razones que no tienen nada que ver con el framework.

Los datos de uso de herramientas apuntan en la misma dirección. Los frameworks publicaron servidores MCP y archivos de skills, y los agentes los usaron... a veces. El servidor MCP de Nuxt no se tocó en cinco ejecuciones. Los archivos de skills de TanStack Start se descubrieron en dos de cinco. La skill de React Router se usó siempre. Mismo prompt, mismo entorno, comportamientos muy distintos: esa es la naturaleza estocástica de la herramienta. Lo que significa que cada hilo de Twitter que afirma «el framework X es mucho mejor para agentes, reescribí toda mi app» tras una tarde de vibe-coding está midiendo ruido. Una ejecución es una anécdota. Si vas a dejar que el coste de IA influya en una decisión arquitectónica (y creo que deberías), exige medianas sobre ejecuciones repetidas antes de creer cualquier cosa, incluido este benchmark.

En calidad de salida, todo converge en «bien»

Lo más sorprendente es lo que no varió. Las puntuaciones de rendimiento, accesibilidad y Cumulative Layout Shift de Lighthouse estaban casi saturadas en las doce pilas: 99 y 100 casi en todas partes. Con una especificación clara y una suite de conformidad, los agentes modernos producen apps pequeñas, competentes y accesibles en prácticamente cualquier framework. El suelo de calidad ha subido hasta el punto de que el framework apenas diferencia la salida en un sitio orientado a contenido.

La única métrica de calidad con dispersión real fueron los bytes de JavaScript enviados: cero KiB para las compilaciones tipo islas de Astro y Hono+htmx, y hasta unos 142 KiB para la salida SPA más pesada. El Total Blocking Time fue trivial en todos los casos, y el LCP era demasiado ruidoso para extraer mucho. Aquí aplican dos advertencias honestas. La app de prueba se parece más a Wikipedia que a Figma, lo que favorece las arquitecturas multipágina, y el propio Lighthouse tiene un sesgo estructural contra las SPAs. Aun así, el resultado de JavaScript vanilla merece una pausa: al agente al que se le pidió Vite puro sin framework le salieron peores puntuaciones que varios frameworks reales, incluido el mayor layout shift de todas las compilaciones. Los frameworks codifican convenciones, y los agentes se apoyan mucho en ellas. Dale al modelo un surco bien trillado y se quedará en él; dale un campo en blanco y improvisará, no siempre bien.

Lo que este benchmark no puede decirte

Antes de que nadie reescriba su aplicación de producción basándose en una demo de Pokémon, seamos honestos sobre el alcance. Es una aplicación pequeña, sobre todo de contenido, con poco estado transversal, sin localización, sin formularios complejos y sin un equipo de personas que la mantendrá durante cinco años. Es una limitación real, y es la misma trampa alrededor de la que sigo dando vueltas en este blog: los benchmarks de IA pasan por alto sistemáticamente la mayor parte de lo que es el trabajo real. Las propiedades que hacen bueno a un framework para agentes en un juguete sin estrenar (familiaridad, simplicidad, estructura estática) no son las que importan en el mes dieciocho de un producto complicado.

Hay además un punto más profundo que acertaron los escépticos de los frameworks en la discusión. Gran parte del valor histórico de un framework nunca fue lo que te permite hacer, sino lo que te prohíbe. Java conquistó el desarrollo empresarial en parte porque obligó a diez mil programadores a escribir código que se parecía entre sí. Los frameworks son sistemas de restricciones para equipos de humanos que se incorporan, se van y se malentienden. Un agente no necesita barreras contra el aburrimiento ni contra el desarrollo guiado por el currículum; necesita una especificación clara y una suite de tests. Un profesional describió exactamente esta inversión con htmx: el agente pasó sin problemas por páginas sencillas, pero tropezó con un formulario complejo con estado, perdiendo datos y rompiendo los toggles, problemas que React habría resuelto de una sola vez, hasta que existieron suficientes tests para mantenerlo honesto. La restricción que importa para los agentes no es el framework. Es la suite de conformidad.

Y sí, la build más barata no es la base de código más barata. Pagar dos dólares extra por sesión de agente con una pila que tu equipo entiende a fondo y puede mantener durante años es obviamente correcto. Pero fíjate en lo que exige ese argumento: números. El sentido de medir el coste de IA no es coronar a un ganador, sino sustituir «este framework es mejor para agentes» por una cantidad que puedas sopesar frente al mercado de contratación, la madurez del ecosistema y el tamaño del bundle. Los sentimientos perdieron el debate sobre la DX; no deberían ganar el agéntico por defecto.

Cómo medir el coste de IA de tu propia pila

No extrapoles el resultado de nadie (incluido este) a tu base de código. Tu repo, tu especificación y tu modelo de referencia producirán su propia distribución. La buena noticia es que medir el coste de IA es realmente fácil, porque los agentes de programación ya informan de todo lo que necesitas. Si quieres entender cómo interactúan el bucle, el contexto y los permisos antes de instrumentarlos, nuestro artículo sobre cómo funciona realmente una CLI de programación agéntica es una buena base. Luego haz esto:

1. Elige una rebanada vertical que represente tu trabajo real: una funcionalidad que toque tu capa de datos, tu gestión de estado y tu UI, no una landing page.
2. Escribe primero las pruebas de conformidad. Los tests son a la vez tu puerta de calidad y tu antídoto contra las trampas; un agente sin tests declarará victoria demasiado pronto.
3. Ejecuta el mismo prompt al menos cinco veces por cada stack o configuración candidata. Informa de medianas y rangos, nunca de ejecuciones sueltas.
4. Registra los tokens totales (desglosados en lecturas de caché, entrada y salida), el tiempo real, el coste, y el número de llamadas a herramientas y de bucles de reintento.
5. Controla cuántos tokens se van en lecturas de documentación: guías de migración, changelogs, exploración de node_modules. Ese es tu impuesto por déficit de datos de entrenamiento, medido directamente.
6. Repite el benchmark tras las actualizaciones mayores del framework. El coste de IA cambia cuando las APIs rotan y se mueven los cortes de entrenamiento.

El arnés en sí puede ser una tarde de scripting. Este es el esqueleto que he usado: los detalles de los flags de la CLI dependerán de tu agente, pero la forma es universal:

import json
import statistics
import subprocess
FRAMEWORKS = ["astro", "react-router", "sveltekit"]
RUNS = 5
SPEC = open("spec.md").read()
def build_once(framework: str) -> dict:
"""One full agent session: build the app, return usage stats."""
result = subprocess.run(
[
"agent-cli", "run",
"--prompt", SPEC,
"--context", f"Build this with the latest {framework}.",
"--output-format", "json",
],
capture_output=True,
text=True,
check=True,
)
return json.loads(result.stdout)
for framework in FRAMEWORKS:
runs = [build_once(framework) for _ in range(RUNS)]
costs = [r["cost_usd"] for r in runs]
tokens = [r["tokens_total"] for r in runs]
print(
f"{framework}: "
f"median ${statistics.median(costs):.2f} "
f"(range ${min(costs):.2f}-${max(costs):.2f}), "
f"median {statistics.median(tokens) / 1e6:.1f}M tokens"
)

Vigila el número de reintentos tanto como el total de tokens. En mi experiencia, los tokens por test aceptado son la métrica más honesta: reúne coste, confusión y corrección en un solo número, y castiga el modo de fallo que de verdad duele, es decir, el agente dando vueltas en cinco bucles de errores de compilación antes de conseguir algo que pase. Un framework en el que el agente pasa limpio al primer o segundo intento vencerá siempre a uno nominalmente «más barato» que necesita correcciones constantes.

La conclusión práctica

Entonces, ¿deberías reescribir tu app de Angular en Astro porque los agentes lo encuentran más barato? No. Las diferencias en dólares son pequeñas, la varianza es grande, la app de prueba es un juguete, y tu migración costaría más tokens de agente de lo que ahorrarías en una década. Quien te venda una migración de framework «por los agentes» está haciendo el mismo razonamiento a ojo que siempre ha hecho la industria, solo que con una nueva justificación pegada encima.

Pero el coste de IA se ha ganado un sitio en la mesa de decisiones, junto a la oferta de talento, la profundidad del ecosistema y el tamaño del bundle. En proyectos nuevos, la evidencia apunta en una dirección consistente: elige stacks con amplia representación en los datos de entrenamiento, churn lento de APIs, cadenas de herramientas estrictas y silenciosas, y convenciones que el modelo haya visto diez mil veces. La tecnología aburrida siempre fue la opción pragmática; los agentes solo la hicieron medible. Fija las versiones de tu framework, porque cada actualización es ahora también un impuesto de inferencia hasta que los modelos se pongan al día. E invierte en tests de conformidad independientemente del framework que elijas: son el único activo que abarata a todos los agentes, los mantiene honestos cuando tropiezan y sigue dando rendimiento mucho después de que el modelo que usas hoy haya quedado obsoleto. Los frameworks seguirán cambiando. Lo que sobrevive son los tests y el hábito de medir.