O custo oculto em IA dos frameworks JavaScript

O agente passou onze minutos lendo um guia de migração antes de escrever uma única linha de código. Não o seu agente, e sim o que um colega apontou para um projeto SvelteKit semana passada, usando o mesmo prompt que você tinha dado ao seu app React uma hora antes. O seu terminou em uns oito minutos e quatro milhões de tokens. O deles levou dezessete minutos e quase dez milhões, e grande parte dessa diferença foi o modelo reensinando pacientemente a si mesmo uma versão de framework que nunca tinha visto no treinamento. Essa lacuna agora tem nome: o custo de IA dos frameworks JavaScript. E graças a um ato genuinamente incomum na nossa indústria, alguém realmente medindo as coisas em vez de apenas afirmando, finalmente temos números reais para ele.

Nolan Lawson, que passou anos substituindo o folclore do frontend por benchmarks de verdade, fez recentemente o óbvio que ninguém tinha se dado ao trabalho de fazer. Ele especificou um app de Pokémon pequeno, mas não trivial, com busca, filtros, páginas de detalhes e dados da PokéAPI, e pediu a um agente de código para construí-lo de doze jeitos diferentes: Astro, Next.js, Nuxt, SvelteKit, React Router, SolidStart, Qwik, Angular, TanStack Start, Hono com htmx, Gracile com Lit e Vite puro, sem nenhum framework de UI. Cada framework teve cinco execuções independentes com o mesmo prompt, cada build foi verificado contra uma suíte de conformidade para que o agente não pudesse trapacear, e os resultados foram avaliados em custo, tempo, tokens e métricas do Lighthouse. Não é um experimento perfeito, e o próprio Lawson admite isso. Mas é a primeira tentativa honesta que vejo de colocar um preço em uma decisão que a maioria das equipes toma no puro achismo.

O Que o Benchmark Realmente Mediu

O setup foi deliberadamente neutro. O agente recebeu a especificação, foi instruído a usar a versão mais recente de cada framework e teve liberdade para escolher a própria arquitetura: SSR ou CSR, o que preferisse. Quando um framework oferece um servidor MCP, skill de agente ou plugin oficial, ele foi disponibilizado, para que nenhum framework pudesse reclamar de estar sub-representado nos dados de treinamento. Os testes de conformidade rodaram sobre a árvore de acessibilidade em vez do DOM bruto, o que importou porque um dos concorrentes renderiza via shadow DOM. Cada framework teve cinco execuções e os resultados são reportados como medianas, exceto o Angular, que duas vezes não conseguiu produzir um app testável, então parte dos seus números vem de três execuções.

• O custo de build variou de uma mediana de cerca de US$ 2,67 a US$ 4,97 por app, uma diferença de aproximadamente 2x entre os frameworks mais baratos e os mais caros.
• O consumo de tokens contou a mesma história com mais volume: cerca de 4 milhões de tokens nas stacks mais baratas e quase 10 milhões nas mais caras.
• O tempo de relógio acompanhou o custo de perto, de cerca de 8 minutos na ponta rápida a 17 minutos na ponta lenta.
• SvelteKit, Gracile+Lit e Angular foram consistentemente os builds mais caros. Astro e a combinação Hono+htmx foram consistentemente baratos.
• Surpreendentemente, o build Vite sem framework ficou atrás de vários frameworks de verdade. Alguma estrutura vence a ausência de estrutura, mesmo para uma máquina.

Dois dólares por build parecem nada. E são nada, para um único build. Mas o desenvolvimento com agentes é iterativo por natureza, ninguém aceita a primeira saída. Multiplique essa diferença por dezenas de sessões de agente por desenvolvedor por semana, por uma equipe, por um ano, e um multiplicador de tokens de 2x na sua stack vira um item de custo real. Mais importante, tokens são um proxy para algo que me importa mais do que dinheiro: quanta tentativa e erro o modelo precisa para produzir código correto no seu framework. Contagens altas de tokens geralmente significam que o agente está confuso, relendo documentação e tentando de novo. É um sinal de qualidade disfarçado de custo.

Por Que Alguns Frameworks Tornam os Agentes Caros

Depois de anos treinando e avaliando modelos, acho os resultados menos misteriosos do que parecem. Três mecanismos explicam quase toda a diferença, e nenhum deles tem a ver com qual framework é “melhor” no sentido tradicional.

Densidade de dados de treinamento é destino

A maior vantagem do React na era dos agentes não é o modelo de programação. É que uma década de tutoriais, repositórios no GitHub e respostas no Stack Overflow comprimiu seus idiomas nos pesos de cada modelo de fronteira. Um agente escrevendo React está, em grande parte, recordando. Um agente escrevendo Gracile está, em grande parte, descobrindo: nas execuções do benchmark, os agentes que não conheciam o framework recorreram a clonar o repositório do framework ou a ler o código compilado dentro de node_modules. São tokens queimados em aulas de reforço antes mesmo de existir código do usuário. É a mesma dinâmica que está reformulando a forma como desenvolvedores encontram conhecimento de modo geral. Escrevi sobre o que acontece com o corpus de conhecimento de desenvolvedores conforme o Stack Overflow perde força, e o ângulo dos frameworks é um caso especial e agudo: ferramentas pouco populares não só carecem de comunidade, como também carecem de presença no próprio modelo.

Rotatividade de API é um imposto recorrente em tokens

O desempenho fraco do SvelteKit tem uma causa específica, quase engraçada: o agente leu o guia de migração do SvelteKit v3 em todas as execuções, porque essa versão era nova demais para estar nos dados de treinamento do modelo. Cada mudança incompatível que um framework lança invalida padrões que o modelo memorizou e o força a deduzir de novo a API correta a partir da documentação, no momento da inferência. Quem paga é o usuário, em tokens, em cada sessão. Frameworks tratam mudanças de versão maior como um evento de marketing. Para quem usa agentes, isso é um adicional recorrente. Um framework chato, que não quebra a API há três anos, é, por essa métrica, um recurso premium.

A verbosidade se acumula no loop

O custo do Angular parecia acompanhar o volume bruto de código: mais linhas geradas significam mais tokens de saída, mais tokens para reler a cada edição seguinte e mais superfície para o agente tropeçar. Isso se generaliza: qualquer stack com saída de ferramentas verbosa, logs de build barulhentos ou comandos de teste lentos obriga o agente a percorrer mais texto a cada iteração, e cada lint ou checagem de tipos que falha dispara mais uma viagem cara de ida e volta. Quem trabalha com isso relata o mesmo padrão em todo lugar: o custo da iteração, e não o custo da geração, é o que domina os gastos com agentes. Um framework com uma toolchain rápida, silenciosa e estrita é mais barato de operar do que um permissivo, porque a rigidez pega os erros do agente em um ciclo em vez de cinco.

Toda mudança incompatível que o seu framework lança agora é um imposto que alguém paga em tokens. E, ao contrário de um humano lendo um changelog, o modelo paga isso em toda sessão.

O Problema do Dado Viciado nos Benchmarks de Agentes

É aqui que meus velhos hábitos de avaliação de ML entram em cena, porque o detalhe mais importante do estudo inteiro são as barras de erro. A saída de um LLM é uma distribuição, não um ponto. O custo mediano de build do React Router ficou cerca de um dólar pior que o do Hono+htmx, mas a execução mais barata do React Router saiu abaixo da mais cara do Hono. As faixas se sobrepõem bastante. As execuções do SvelteKit oscilaram de cerca de US$ 3,20 a US$ 6,80. Às vezes o agente simplesmente tira um número baixo, se desvia para um tangente e consome alguns milhões de tokens por motivos que nada têm a ver com o framework.

Os dados de uso de ferramentas reforçam o mesmo ponto. Os frameworks lançaram servidores MCP e arquivos de skills, e os agentes os usaram… às vezes. O servidor MCP do Nuxt nunca foi tocado em cinco execuções. Os arquivos de skill do TanStack Start foram descobertos em duas de cinco. A skill do React Router foi usada em todas. Mesmo prompt, mesmo harness, comportamentos muito diferentes: essa é a natureza estocástica da ferramenta. Isso significa que toda thread no Twitter alegando “o framework X é muito melhor para agentes, reescrevi meu app inteiro” baseada em uma tarde de vibe-coding está medindo ruído. Uma execução é uma anedota. Se você for deixar o custo de IA influenciar uma decisão arquitetural, e acho que deve, exija medianas de execuções repetidas antes de acreditar em qualquer coisa, incluindo este benchmark.

Na Qualidade da Saída, Tudo Converge para Bom

O resultado mais surpreendente é o que não variou. As pontuações de Performance, Acessibilidade e Cumulative Layout Shift do Lighthouse ficaram quase saturadas nas doze stacks: 99 e 100 quase em todo lugar. Dada uma especificação clara e uma suíte de conformidade, os agentes modernos produzem apps pequenos competentes e acessíveis em basicamente qualquer framework. O piso de qualidade subiu a ponto de o framework quase não diferenciar a saída em um site focado em conteúdo.

A única métrica de qualidade com dispersão real foi o JavaScript enviado: zero KiB para os builds baseados em ilhas, Astro e Hono+htmx, e até cerca de 142 KiB para a saída mais pesada de SPA. O Total Blocking Time ficou irrelevante em todos, e o LCP foi ruidoso demais para tirar muitas conclusões. Duas ressalvas honestas se aplicam. O app de teste se parece mais com a Wikipédia do que com o Figma, o que favorece arquiteturas multipágina, e o próprio Lighthouse tem viés estrutural contra SPAs. Mesmo assim, o resultado do JavaScript puro merece uma pausa: o agente instruído a usar Vite simples, sem framework, produziu notas piores que vários frameworks de verdade, incluindo o maior layout shift de todos os builds. Frameworks codificam convenções, e agentes se apoiam muito nelas. Dê ao modelo um caminho já batido e ele fica nele; dê a ele um campo em branco e ele improvisa, nem sempre bem.

O Que Este Benchmark Não Consegue Dizer

Antes de alguém reescrever seu app de produção com base em uma demo de Pokémon, sejamos honestos sobre o escopo. Esta é uma aplicação pequena, majoritariamente orientada a conteúdo, com pouco estado transversal, sem localização, sem formulários complexos e sem uma equipe de humanos que vá mantê-la por cinco anos. É uma limitação real, e é a mesma armadilha em que continuo batendo neste blog: benchmarks de IA sistematicamente deixam de fora a maior parte do que é o trabalho real. As propriedades que tornam um framework bom para agentes em um brinquedo de projeto novo, familiaridade, simplicidade e estrutura estática, não são as que importam no mês dezoito de um produto bagunçado.

Há também um ponto mais profundo que os céticos dos frameworks na discussão acertaram. Boa parte do valor histórico de um framework nunca foi sobre o que ele permite fazer, e sim sobre o que ele proíbe. Java conquistou o desenvolvimento corporativo em parte porque obrigou dez mil programadores a escrever código com cara de igual. Frameworks são sistemas de restrição para equipes de humanos que entram, saem e se desentendem. Um agente não precisa de guardrails contra o tédio ou contra o desenvolvimento orientado a currículo; precisa de uma especificação clara e de uma suíte de testes. Um profissional relatou exatamente essa inversão com o htmx: o agente passou tranquilo por páginas simples, mas tropeçou em um formulário complexo com estado, perdendo estado e quebrando toggles, problemas que o React resolveria de primeira, até existirem testes suficientes para mantê-lo honesto. A restrição que importa para agentes não é o framework. É a suíte de conformidade.

E sim, o build mais barato não é a base de código mais barata. Pagar dois dólares a mais por sessão de agente em uma stack que sua equipe entende a fundo e consegue manter por anos é obviamente correto. Mas repare no que esse argumento exige: números. O objetivo de medir o custo de IA não é coroar um vencedor, e sim trocar “este framework é melhor para agentes” por uma quantidade que você possa pesar contra o mercado de contratação, a maturidade do ecossistema e o tamanho do bundle. A vibe perdeu o debate de DX; não deveria ganhar o debate agêntico por padrão.

Como Medir o Custo de IA da Sua Própria Stack

Não extrapole o benchmark de ninguém para a sua base de código, incluindo este. Seu repositório, sua especificação e o modelo escolhido vão produzir a própria distribuição. A boa notícia é que medir custo de IA é genuinamente fácil, porque os agentes de código já reportam tudo o que você precisa. Se quiser entender como o loop, o contexto e as permissões interagem antes de instrumentá-los, nosso texto sobre como uma CLI de código agêntica realmente funciona é uma boa base. Depois, faça isto:

1. Escolha uma fatia vertical que represente o seu trabalho real: uma funcionalidade que toque na sua camada de dados, no gerenciamento de estado e na UI, não uma landing page.
2. Escreva os testes de conformidade primeiro. Testes são ao mesmo tempo seu portão de qualidade e seu antídoto contra trapaça; um agente sem testes vai declarar vitória cedo demais.
3. Rode o mesmo prompt pelo menos cinco vezes por stack ou configuração candidata. Reporte medianas e faixas, nunca execuções isoladas.
4. Registre o total de tokens (separado em leituras de cache, entrada e saída), o tempo de relógio, o custo e o número de chamadas de ferramentas e de loops de retentativa.
5. Acompanhe quantos tokens vão para leituras de documentação: guias de migração, changelogs, vasculhar node_modules. Esse é o seu imposto de déficit de dados de treinamento, medido diretamente.
6. Rode o benchmark de novo após upgrades grandes do framework. O custo de IA muda conforme as APIs mudam e os cortes de treinamento avançam.

O harness em si pode ser uma tarde de script. Aqui está o esqueleto que eu usei. Os detalhes das flags da CLI vão depender do seu agente, mas o formato é 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"
)

Observe a contagem de retentativas tão de perto quanto o total de tokens. Na minha experiência, tokens por teste aceito é a métrica mais honesta de todas: ela junta custo, confusão e corretude em um único número, e pune o modo de falha que de fato machuca, que é o agente se debatendo em cinco loops de erro de compilação antes de chegar a algo que passa. Um framework em que o agente acerta limpo na primeira ou segunda tentativa vai sempre superar um que parece “mais barato”, mas exige correção constante.

O Veredito Pragmático

Então você deveria reescrever seu app Angular em Astro porque os agentes acham mais barato? Não. As diferenças em dólar são pequenas, a variância é grande, o app de teste é um brinquedo, e sua migração custaria mais tokens de agente do que você economizaria em uma década. Quem vende migração de framework “para os agentes” está fazendo o mesmo raciocínio baseado em vibe que a indústria sempre fez, só com uma justificativa nova colada por cima.

Mas o custo de IA merece um lugar na mesa de decisão, ao lado do mercado de contratação, da profundidade do ecossistema e do tamanho do bundle. Para projetos novos, as evidências apontam numa direção consistente: escolha stacks com representação profunda nos dados de treinamento, rotatividade lenta de API, toolchains estritas e silenciosas e convenções que o modelo já viu dez mil vezes. Tecnologia chata sempre foi a escolha pragmática; os agentes apenas tornaram o chato mensurável. Fixe as versões do seu framework, porque cada upgrade agora também é um imposto de inferência até os modelos alcançarem. E invista em testes de conformidade independentemente do framework escolhido. Eles são o único ativo que torna cada agente mais barato, mantém-no honesto quando ele se atrapalha, e continua compensando muito depois que o modelo que você usa hoje estiver obsoleto. Os frameworks vão continuar mudando. Quem sobrevive são os testes e o hábito de medir.