Il costo nascosto dell'AI nei framework JavaScript

L'agente ha passato undici minuti a leggere una guida alla migrazione prima di scrivere una sola riga di codice. Non il tuo agente, ma quello che un collega ha puntato su un progetto SvelteKit la settimana scorsa, usando lo stesso prompt che tu avevi dato alla tua app React un'ora prima. Il tuo ha finito in circa otto minuti e quattro milioni di token. Il loro ha impiegato diciassette minuti e quasi dieci milioni, e gran parte di quella differenza è stata il modello che si rieducava pazientemente su una versione del framework che non aveva mai visto durante l'addestramento. Quel divario ha ormai un nome: il costo in AI dei framework JavaScript. E grazie a un atto davvero insolito per il nostro settore, cioè qualcuno che misura le cose invece di affermarle, finalmente abbiamo numeri reali.

Nolan Lawson, che da anni sostituisce il folklore del frontend con benchmark veri, ha di recente fatto la cosa ovvia che nessuno si era preso la briga di fare. Ha definito le specifiche di una piccola ma non banale app Pokémon (ricerca, filtri, pagine di dettaglio, dati dalla PokéAPI) e ha fatto costruire a un agente di coding dodici versioni diverse: Astro, Next.js, Nuxt, SvelteKit, React Router, SolidStart, Qwik, Angular, TanStack Start, Hono con htmx, Gracile con Lit e Vite semplice senza alcun framework UI. Ogni framework ha avuto cinque esecuzioni indipendenti con lo stesso prompt, ogni build è stata verificata con una suite di conformità così che l'agente non potesse barare, e i risultati sono stati valutati su costo, tempo, token e metriche Lighthouse. Non è un esperimento perfetto, e Lawson stesso lo ammette. Ma è il primo tentativo onesto che vedo di dare un prezzo a una decisione che la maggior parte dei team prende basandosi solo sulle sensazioni.

Cosa Ha Misurato Davvero il Benchmark

Il setup era volutamente neutro. L'agente riceveva le specifiche, gli veniva chiesto di usare l'ultima versione di un dato framework e poteva scegliere da solo l'architettura (SSR o CSR, quella che preferiva). Quando un framework fornisce un server MCP ufficiale, un agent skill o un plugin, questo veniva reso disponibile, così nessuno poteva lamentarsi di essere sottorappresentato nei dati di addestramento. I test di conformità giravano sull'albero di accessibilità anziché sul DOM grezzo, il che era importante perché un concorrente esegue il rendering tramite shadow DOM. Ogni framework ha avuto cinque esecuzioni e i risultati sono riportati come mediane, tranne Angular, che per due volte non è riuscito a produrre affatto un'app testabile, quindi alcuni suoi numeri derivano da tre esecuzioni.

• Il costo di build variava da una mediana di circa 2,67 $ a 4,97 $ per app, una differenza di circa 2x tra i framework più economici e quelli più costosi.
• Il consumo di token raccontava la stessa storia in modo ancora più evidente: circa 4 milioni di token per gli stack più economici, quasi 10 milioni per i più costosi.
• Il tempo reale seguiva da vicino il costo, da circa 8 minuti all'estremità veloce a 17 minuti a quella lenta.
• SvelteKit, Gracile+Lit e Angular sono stati costantemente i build più costosi. Astro e la coppia Hono+htmx sono stati costantemente economici.
• Sorprendentemente, la build Vite senza framework ha fatto peggio di diversi framework veri: una struttura batte l'assenza di struttura, anche per una macchina.

Due dollari a build sembrano nulla. Per una singola build, in effetti è nulla. Ma lo sviluppo agentico è per natura iterativo: nessuno accetta il primo output. Moltiplica la differenza per decine di sessioni di agenti per sviluppatore a settimana, su un intero team, per un anno, e un moltiplicatore di token 2x sul tuo stack diventa una voce di costo reale. Ancora più importante, i token sono un proxy per qualcosa che mi interessa più dei soldi: quanta prova ed errore serve al modello per produrre codice corretto nel tuo framework. Un numero alto di token di solito significa che l'agente è confuso, rilegge la documentazione e riprova. È un segnale di qualità travestito da costo.

Perché Alcuni Framework Rendono Costosi gli Agenti

Avendo passato anni ad addestrare e valutare modelli, trovo i risultati meno misteriosi di quanto sembrino. Tre meccanismi spiegano quasi tutta la differenza, e nessuno di essi ha a che fare con quale framework sia «migliore» in senso tradizionale.

La densità dei dati di addestramento è destino

Il più grande vantaggio di React nell'era agentica non è il suo modello di programmazione: è che un decennio di tutorial, repository GitHub e risposte su Stack Overflow ha compresso i suoi idiomi nei pesi di ogni modello di frontiera. Un agente che scrive React sta per lo più ricordando. Un agente che scrive Gracile sta per lo più scoprendo: nelle esecuzioni del benchmark, gli agenti che non conoscevano il framework ricorrevano a clonare il repository del framework o a leggere il suo codice compilato da node_modules. Sono token bruciati per un ripasso elementare prima ancora che esista codice utente. È la stessa dinamica che sta rimodellando il modo in cui gli sviluppatori trovano informazioni in generale. Ne ho scritto parlando di come cambia il corpus della conoscenza degli sviluppatori con il declino di Stack Overflow, e il lato framework ne è un caso particolare netto: gli strumenti poco diffusi non solo non hanno una community, ma non hanno nemmeno presenza nel modello stesso.

L'API churn è una tassa ricorrente sui token

Lo scarso risultato di SvelteKit ha una causa specifica, quasi buffa: l'agente ha letto la guida alla migrazione di SvelteKit v3 in ogni singola esecuzione, perché quella versione era troppo recente per essere nei dati di addestramento del modello. Ogni breaking change rilasciato da un framework invalida pattern che il modello ha memorizzato e lo costringe a ricavare di nuovo la API corretta dalla documentazione al momento dell'inferenza, pagata in token, a ogni sessione, da ogni utente. I framework trattano i cambiamenti di versione major come un evento di marketing. Per chi usa agenti, è un sovrapprezzo ricorrente. Un framework noioso che non rompe la sua API da tre anni è, con questa metrica, una funzionalità premium.

La verbosità si amplifica nel ciclo

Il costo di Angular sembrava seguire la sua pura quantità di codice: più righe generate significano più token in uscita, più token da rileggere a ogni modifica successiva e più superficie su cui l'agente può inciampare. Questo vale in generale: qualsiasi stack con output di strumenti prolisso, log di build rumorosi o comandi di test lenti costringe l'agente a districarsi in più testo a ogni iterazione, e ogni lint o controllo di tipo fallito innesca un altro costoso giro. Chi lavora sul campo riporta lo stesso schema ovunque: a dominare la spesa dell'agente è il costo dell'iterazione, non quello della generazione. Un framework con una toolchain veloce, silenziosa e rigorosa costa meno da gestire di una permissiva, perché il rigore intercetta gli errori dell'agente in un ciclo invece che in cinque.

Ogni breaking change rilasciato dal tuo framework è ormai una tassa che qualcuno paga in token, e a differenza di un umano che legge un changelog, il modello la paga a ogni singola sessione.

Il problema del dado nei benchmark sugli agenti

Qui entrano in gioco le mie vecchie abitudini di valutazione ML, perché il dettaglio più importante dell'intero studio sono le barre di errore. L'output di un LLM è una distribuzione, non un punto. Il costo mediano di build di React Router era circa un dollaro peggiore di quello di Hono+htmx, eppure la singola esecuzione più economica di React Router è costata meno della più cara di Hono. Gli intervalli si sovrappongono in misura notevole. Le esecuzioni di SvelteKit oscillavano da circa 3,20 $ a 6,80 $. A volte l'agente tira un numero basso, si perde in una digressione e brucia qualche milione di token per motivi che non hanno nulla a che fare con il framework.

I dati sull'uso degli strumenti dicono la stessa cosa. I framework rilasciavano server MCP e file di skill, e gli agenti li usavano... a volte. Il server MCP di Nuxt non è mai stato toccato in cinque esecuzioni. I file di skill di TanStack Start sono stati scoperti in due esecuzioni su cinque. La skill di React Router è stata usata ogni volta. Stesso prompt, stesso harness, comportamenti molto diversi: è la natura stocastica dello strumento. Il che significa che ogni thread su Twitter che afferma «il framework X è molto migliore per gli agenti, ho riscritto tutta la mia app» basato su un pomeriggio di vibe-coding sta misurando rumore. Una singola esecuzione è un aneddoto. Se lasci che il costo dell'AI influenzi una decisione architetturale (e penso che dovresti), chiedi mediane su esecuzioni ripetute prima di credere a qualsiasi cosa, compreso questo benchmark.

Sulla qualità dell'output, tutto converge su un buon livello

Il risultato più sorprendente è ciò che non variava. I punteggi di Performance, Accessibilità e Cumulative Layout Shift di Lighthouse erano quasi saturi in tutti e dodici gli stack, con 99 e 100 quasi ovunque. Con una specifica chiara e una suite di conformità, gli agenti moderni producono piccole app competenti e accessibili in praticamente qualsiasi framework. La soglia minima di qualità si è alzata al punto che il framework differenzia a malapena l'output su un sito orientato al contenuto.

L'unica metrica di qualità con una differenza reale è stata il JavaScript inviato: zero KiB per le build in stile islands di Astro e Hono+htmx, fino a circa 142 KiB per l'output SPA più pesante. Il Total Blocking Time è rimasto trascurabile ovunque, e l'LCP era troppo rumoroso per trarne molto. Qui valgono due avvertenze oneste. L'app di test assomiglia più a Wikipedia che a Figma, quindi favorisce le architetture multipagina, e Lighthouse stesso è strutturalmente sfavorevole alle SPA. Resta il fatto che il risultato del JavaScript vanilla merita una pausa: l'agente a cui è stato chiesto di usare Vite semplice senza framework ha prodotto punteggi peggiori di diversi framework veri, incluso il layout shift più alto di qualsiasi build. I framework codificano convenzioni, e gli agenti si appoggiano molto alle convenzioni. Dai al modello un binario già battuto e ci resta; dagli un campo vuoto e improvvisa, non sempre bene.

Cosa Non Può Dirti Questo Benchmark

Prima che qualcuno riscriva la propria app di produzione sulla base di una demo Pokémon, siamo onesti sul perimetro. Questa è una piccola applicazione, per lo più orientata al contenuto, con poco stato trasversale, nessuna localizzazione, nessun form complesso e nessun team di persone che la manterrà per cinque anni. È un limite reale, ed è la stessa trappola su cui continuo a girare intorno in questo blog: i benchmark sull'AI tralasciano sistematicamente la maggior parte di ciò che il lavoro reale è davvero. Le proprietà che rendono un framework buono per gli agenti su un giocattolo greenfield (familiarità, semplicità, struttura statica) non sono quelle che contano al diciottesimo mese di un prodotto disordinato.

C'è anche un punto più profondo che gli scettici dei framework nella discussione hanno colto bene. Gran parte del valore storico di un framework non riguarda mai ciò che ti permette di fare, ma ciò che ti vieta. Java ha conquistato lo sviluppo enterprise in parte perché costringeva diecimila programmatori a scrivere codice dall'aspetto simile. I framework sono sistemi di vincoli per team di persone che entrano, escono e si fraintendono. Un agente non ha bisogno di protezioni contro la noia o lo sviluppo guidato dal curriculum; ha bisogno di una specifica chiara e di una suite di test. Un professionista ha riportato proprio questa inversione con htmx: l'agente se la cavava con le pagine semplici ma arrancava su un form complesso con stato, perdendo lo stato e rompendo i toggle, problemi che React avrebbe risolto al primo colpo, finché non sono esistiti abbastanza test per tenerlo sulla strada giusta. Il vincolo che conta per gli agenti non è il framework. È la suite di conformità.

E sì, la build più economica non è la base di codice più economica. Pagare due dollari in più per sessione di agente per uno stack che il tuo team conosce a fondo e può mantenere per anni è ovviamente la scelta giusta. Ma nota cosa richiede questo ragionamento: numeri. Lo scopo di misurare il costo dell'AI non è incoronare un vincitore, ma sostituire «questo framework è migliore per gli agenti» con una quantità che puoi confrontare con il mercato del lavoro, la maturità dell'ecosistema e la dimensione del bundle. Le sensazioni hanno perso il dibattito sulla DX; non dovrebbero vincere quello agentico per impostazione predefinita.

Come Misurare il Costo AI del Tuo Stack

Non estrapolare dal benchmark di qualcun altro, incluso questo, alla tua base di codice. Il tuo repo, le tue specifiche e il modello che scegli produrranno una distribuzione tutta loro. La buona notizia è che misurare il costo dell'AI è davvero semplice, perché gli agenti di coding riportano già tutto ciò che ti serve. Se vuoi capire come interagiscono loop, contesto e permessi prima di strumentarli, il nostro articolo su come funziona davvero una CLI di coding agentico è una buona base. Poi fai così:

1. Scegli una fetta verticale che rappresenti il tuo lavoro reale: una funzionalità che tocca il livello dati, la gestione dello stato e la UI, non una landing page.
2. Scrivi prima i test di conformità. I test sono sia il tuo cancello di qualità sia il tuo dispositivo anti-imbroglio; un agente senza test dichiarerà vittoria in anticipo.
3. Esegui lo stesso prompt almeno cinque volte per ogni stack o configurazione candidata. Riporta mediane e intervalli, mai esecuzioni singole.
4. Registra i token totali (suddivisi tra letture dalla cache, input e output), il tempo reale, il costo e il numero di chiamate agli strumenti e di cicli di retry.
5. Traccia quanti token vanno in letture della documentazione (guide alla migrazione, changelog, esplorazioni di node_modules). Quella è la tua tassa sul deficit dei dati di addestramento, misurata direttamente.
6. Ripeti il benchmark dopo i major upgrade del framework. Il costo dell'AI si sposta man mano che le API cambiano e i cutoff di addestramento avanzano.

L'harness in sé può richiedere un pomeriggio di scripting. Ecco lo scheletro che ho usato: i dettagli dei flag della CLI dipenderanno dal tuo agente, ma la forma è universale:

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"
)

Tieni d'occhio il numero di retry tanto quanto il totale dei token. Nella mia esperienza, i token per test accettato sono la metrica più onesta in assoluto: unisce costo, confusione e correttezza in un unico numero, e penalizza la modalità di errore che fa davvero male, cioè l'agente che si dibatte in cinque cicli di errori di compilazione prima di produrre qualcosa che passa. Un framework in cui l'agente supera i test pulitamente al primo o secondo tentativo batterà ogni volta uno che nominalmente «costa meno» ma richiede correzioni continue.

La Conclusione Pragmatica

Quindi dovresti riscrivere la tua app Angular in Astro perché gli agenti la trovano più economica? No. Le differenze in dollari sono piccole, la varianza è grande, l'app di test è un giocattolo, e la tua migrazione costerebbe più token d'agente di quanti ne risparmieresti in un decennio. Chiunque ti venda una migrazione di framework «per gli agenti» sta facendo lo stesso ragionamento basato sulle sensazioni che il settore ha sempre fatto, solo con una nuova giustificazione appiccicata sopra.

Ma il costo dell'AI merita un posto al tavolo delle decisioni, accanto al bacino di assunzione, alla profondità dell'ecosistema e alla dimensione del bundle. Per i progetti greenfield, le evidenze puntano in una direzione coerente: scegli stack con una profonda rappresentazione nei dati di addestramento, un churn lento delle API, toolchain rigorose e silenziose e convenzioni che il modello ha visto diecimila volte. La tecnologia noiosa è sempre stata la scelta pragmatica; gli agenti hanno solo reso misurabile la noia. Blocca le versioni dei framework, perché ogni aggiornamento è ormai anche una tassa in fase di inferenza finché i modelli non si mettono al passo. E investi nei test di conformità a prescindere dal framework scelto: sono l'unico asset che rende ogni agente più economico, lo mantiene onesto quando arranca, e ripaga molto dopo che il modello che usi oggi sarà obsoleto. I framework continueranno a cambiare. I test e l'abitudine di misurare sono ciò che sopravvive.