Angular le sale al agente de IA el doble de caro que Hono+htmx: 4,97 $ frente a 2,67 $ por aplicación

Cuando un equipo elige un framework, normalmente piensa en los hábitos de los desarrolladores, el ecosistema y la contratación. Ahora ha aparecido otro factor: cuánto costará el trabajo de un agente de IA que escribe código en lugar de una persona. El desarrollador Nolan Lawson decidió medirlo en dólares y minutos.

Cómo se planteó el experimento

La tarea era la misma para todos: un catálogo de Pokémon con búsqueda, filtros y datos reales de PokéAPI. La ejecutó Claude Code con el modelo Opus 5.5 y un nivel de razonamiento alto. Lawson probó 12 variantes, incluido JavaScript puro sin framework de UI. Ejecutó cada variante cinco veces y tomó la mediana, para que la suerte o el fracaso casuales no distorsionaran el cuadro. El agente recibía la misma descripción de la tarea y pruebas funcionales con las que se verificaba el resultado.

El método es sencillo, y por eso merece más confianza que impresiones sueltas del tipo «Claude escribe bien en React». Aquí hay un listón común y repetibilidad.

Qué resultó

Angular tuvo los peores resultados en ambas métricas a la vez: 17,2 minutos y 4,97 dólares por aplicación. El más rápido fue Astro, que necesitó 8,2 minutos. El más barato fue la combinación de Hono y htmx: 2,67 dólares y 8,6 minutos. Angular tardó aproximadamente el doble y costó el doble que los líderes.

JavaScript puro resultó decente, pero no el mejor: 2,98 dólares y 10,1 minutos. No superó ni a Astro ni a Hono con htmx. La tesis de que «menos abstracciones significa más facilidad para el agente» no se confirmó aquí. Al parecer, al agente no le ayuda la ausencia de framework, sino unas convenciones claras y un código compacto que no hay que tardar en entender.

En tokens, la dispersión es esta: Nuxt gastó 3,85 millones y Angular 9,76 millones, es decir, 2,5 veces más. La mayor parte del gasto procedía de la relectura del contexto en caché. Cuanto más largo es el ciclo «escribir, ejecutar, corregir», más a menudo el agente relee el historial acumulado, y la factura crece casi por sí sola.

La calidad apenas se resintió

El resultado inesperado es que las aplicaciones finales se diferenciaban poco. El rendimiento mediano en Lighthouse fue de 97–100 puntos, y la accesibilidad fue de 100 en todos los casos. Resulta que el framework caro no daba un producto mejor. Solo exigía más pasos y tokens para el mismo resultado.

Qué hacer con esto

No conviene elegir el stack solo por estas cifras. Es una aplicación, un modelo y un escenario. Un catálogo con búsqueda y filtros encaja fácilmente en un enfoque server-first, mientras que un frontend corporativo complejo con formularios, estado y decenas de pantallas puede ofrecer otro panorama. Además, los precios de los tokens y el comportamiento de los modelos cambian rápidamente.

Aun así, hay conclusiones prácticas:

• Si ejecutas agentes con un gran volumen de tareas, como prototipos, herramientas internas o landings con dinamismo, una diferencia de 2 veces se convierte en dinero real. Conviene ejecutar tu propio benchmark con tus tareas habituales.
• Para prototipos rápidos con agente, es razonable considerar Astro o Hono con htmx. Dieron el mejor tiempo y precio con la misma calidad.
• Si Angular ya está adoptado en el equipo, no es motivo para abandonarlo. Basta con prever en el presupuesto que el agente trabajará más tiempo y costará más, y vigilar el tamaño del contexto.
• La métrica conviene contarla en su conjunto: tokens, minutos y proporción de relecturas del contexto. Optimizar solo el precio por solicitud no es suficiente.

La conclusión principal: el framework ahora influye también en el coste del desarrollo automatizado. Ese coste conviene medirlo igual que la velocidad de compilación o el tamaño del bundle.