“A IA consegue fazer melhor com esse framework” virou uma justificativa rápida demais para reescrever frontend. Só que, quando o agente passa a produzir código, a escolha da stack não some: ela reaparece em tokens, tempo de execução, manutenção e na quantidade de coisa que alguém precisa revisar depois.
Um benchmark recente de Nolan Lawson tentou colocar números nessa conversa. Ele pediu a um agente que construísse o mesmo aplicativo, com a mesma especificação, em diferentes frameworks JavaScript e comparou custo, linhas de código, conformidade, performance e acessibilidade. Não é um veredito universal — é um único tipo de app, com variação natural de modelos —, mas é uma forma bem mais honesta de decidir do que repetir que uma tecnologia é “melhor para agentes”.
O que foi medido de fato
O experimento usou um app de Pokémon pequeno, mas não trivial: lista, busca, filtros e dados de API. Cada implementação foi gerada várias vezes, com ferramentas oficiais quando existiam, e testada por uma suíte de conformidade e pelo Lighthouse. A avaliação separou três coisas que costumam virar uma só discussão: custo para gerar, qualidade do resultado e manutenção do código entregue.
Isso importa porque um agente não trabalha de graça só porque a equipe já tem uma assinatura. Tokens, ciclos de revisão, falhas de build e correções posteriores entram na conta. No recorte do autor, Hono com htmx, Astro e Nuxt ficaram entre as menores medianas de custo por execução; SvelteKit, Gracile com Lit e Angular apareceram no grupo mais caro. A distância entre execuções, porém, também foi relevante.
Não transforme uma tabela em ranking de arquitetura
O ponto mais útil do benchmark não é declarar um campeão. É mostrar que o resultado muda conforme a tarefa. Um site de conteúdo, com interatividade moderada, não exige a mesma arquitetura de um editor colaborativo ou de um painel que mantém estado complexo por horas.
Nos comentários da discussão aberta no Hacker News, apareceu justamente a tensão que os times conhecem: um lado lembra o custo de dependências, camadas e mudanças coordenadas; outro lembra que código “feito em casa” também acumula manutenção e pode virar um problema que só uma pessoa entende. As duas leituras falham quando viram dogma. O que a IA mudou foi a velocidade com que esse custo aparece — e não a necessidade de medi-lo.
Quatro perguntas antes de deixar o agente escolher sua stack
- Qual é o produto real? Se a maior parte é conteúdo e formulários, comece simples. Se há colaboração, offline, estado longo ou interação densa, documente por que isso muda a decisão.
- Que evidência será aceita? Defina antes: build reproduzível, testes passando, orçamento de bundle, Lighthouse, acessibilidade e tempo de revisão humana.
- O agente conhece o caminho? Documentação atual, exemplos locais e regras de arquitetura reduzem tentativa e erro. Uma stack popular não resolve sozinha instrução ruim.
- Quem mantém após o merge? Conte atualizações, dependências, convenções e a capacidade do time de depurar sem depender do mesmo prompt para sempre.
Faça um teste curto com uma tarefa do seu time
Em vez de abrir uma migração por causa de uma demo, escolha uma entrega pequena e representativa: uma tela com autenticação, um fluxo de busca ou uma integração que já deu trabalho. Rode duas alternativas com a mesma especificação. Registre custo, erros, tempo até o PR aceitável e o que sobrou para revisão. Depois repita. Uma execução isolada pode ser só sorte — boa ou ruim.
Esse tipo de teste também evita um erro comum: otimizar apenas para a primeira geração de código. A escolha que parece barata no prompt pode ficar cara quando vierem as exceções, os acessos, os bugs e a próxima pessoa precisando entender por que aquilo foi feito assim.
O ganho não é escolher a ferramenta “da IA”
Agentes reduzem o custo de experimentar, não eliminam o custo de decidir. Se um framework facilita uma entrega mensurável para o seu caso, ótimo. Se adiciona volume, incerteza ou revisão sem entregar algo concreto, o nome conhecido não compensa. A melhor mudança de hábito é simples: trocar a promessa vaga por uma hipótese que o time consegue testar.
