Gli LLM di default scelgono React, Next.js e TypeScript, non perché siano la scelta migliore, ma perché dominano i dati di training. Esploriamo come questo feedback loop influisca sull'innovazione e se i nuovi stack tecnologici possano ancora farsi strada.
Sandro Taje Chiedi a un LLM qualsiasi di fare lo scaffolding di un nuovo progetto web. La risposta è quasi sempre la stessa: React, Next.js, Tailwind, TypeScript. Non perché sia la scelta migliore per ogni problema, ma perché è quello che il modello ha visto più spesso.
Non è un caso. È una conseguenza strutturale di come funzionano i Large Language Model. Sono addestrati sul passato, e il passato è dominato da poche tecnologie popolari. Il risultato è un feedback loop in cui gli stack tecnologici più popolari vengono raccomandati di più, generano più codice, producono più dati di training e diventano ancora più dominanti nella generazione successiva di modelli.
Ma è davvero vero che questo sta uccidendo l’innovazione? O l’AI potrebbe in realtà rendere più facile l’emergere di nuove tecnologie? Ci siamo tuffati nelle prospettive più interessanti del settore per scoprirlo.
La Dead Framework Theory di Paul Kinlan è la posizione più preoccupante. La tesi è semplice e sorprendente: React non sta più competendo con gli altri framework: è diventato la piattaforma.
Il meccanismo è un doppio feedback loop. Primo: React domina il web esistente, gli LLM si addestrano sul web esistente, gli LLM producono React di default, i nuovi siti usano React, e c’è ancora più React per il training futuro. Secondo: tool per developer come Replit, Bolt e prodotti simili non si limitano a riflettere passivamente questa situazione: cablano React direttamente nei loro system prompt perché è quello che gli sviluppatori si aspettano e sanno manutenere.
Kinlan porta dati a sostegno. Secondo BuiltWith, nei 12 mesi precedenti alla sua analisi sono stati rilasciati oltre 13 milioni di siti con React, contro circa 2 milioni per Vue e meno di 100.000 per Angular. La Stack Overflow Developer Survey 2025 racconta la stessa storia: React al 44,7% di utilizzo tra gli sviluppatori, Angular al 18,2%, Vue al 17,6%, Svelte al 7,2%. Il consumo di token su OpenRouter per task di programmazione mostra curve di crescita enormi che seguono da vicino la crescita del deployment di React. La correlazione non è causalità, ma il timing è impressionante.
L’implicazione è scomoda: se lanci un framework nuovo oggi, anche uno tecnicamente superiore, devi entrare nei dati di training degli LLM (con un ritardo di 12-18 mesi), convincere chi sviluppa i tool a modificare i system prompt, costruire un ecosistema di librerie e superare l’inerzia degli sviluppatori, il tutto mentre l’ecosistema esistente genera milioni di nuovi siti React.
Maximilian Schwarzmüller fa un’osservazione collegata ma distinta: prima degli LLM, una ricerca Google su “come costruire una web app” faceva emergere più approcci: framework diversi, architetture diverse, trade-off diversi. Con un LLM, ottieni un unico grande blocco di codice che usa lo stack di default. Scoprire alternative richiede ora che lo sviluppatore sappia già che esistono e le chieda esplicitamente.
Un recente studio empirico di Amplifying.ai riporta numeri precisi sul problema. Hanno puntato Claude Code su repo reali 2.430 volte con prompt aperti (nessun nome di tool, nessun indizio) tracciando cosa sceglieva. I risultati sono notevoli: GitHub Actions al 94%, shadcn/ui al 90%, Vercel al 100% per i progetti JS. Lo stack di default che emerge è estremamente ristretto: Vercel, PostgreSQL, Drizzle, Tailwind, shadcn/ui, Vitest, pnpm. Nel frattempo, tool consolidati come Redux, Express e Jest praticamente non vengono scelti. In modo interessante, lo studio rivela anche un “recency gradient”: i modelli più recenti si spostano verso tool più recenti (Prisma scende dal 79% su Sonnet 4.5 allo 0% su Opus 4.6, sostituito da Drizzle). Il bias non è statico; si muove, ma resta confinato in un corridoio stretto.
Non tutti vedono un futuro distopico. Magnus Madsen, lead developer del linguaggio di programmazione Flix, ha condotto un esperimento affascinante: Claude Code riesce a scrivere Flix idiomatico (un linguaggio con pochissimi dati di training) se gli dai la documentazione?
La risposta è stata sorprendentemente positiva. Scaricando la API reference e la documentazione di Flix nel progetto e fornendo un file CLAUDE.md con le istruzioni, Claude è stato in grado di pianificare e implementare un gioco completo di Tic-Tac-Toe usando l’effect system avanzato di Flix, handler custom e strutture dati funzionali. Il modello ha persino capito da solo come lavorare con gli effetti NonDet.
Questo apre una potente contro-narrazione: gli LLM non devono essere pre-addestrati sulla tua tecnologia per poterla usare. La vera barriera per l’adozione di un nuovo linguaggio è sempre stata il problema del “cold start”: niente librerie, niente community, nessuna risposta su Stack Overflow. Oggi puoi dare la documentazione in pasto a un modello e ottenere un ecosistema funzionante in pochi minuti. Non è mai stato così facile sperimentare con tecnologie nuove, se sai come impostare il contesto.
Simon Willison, una delle voci più rispettate nello spazio dei tool per sviluppatori, è arrivato a una conclusione simile appena pochi giorni fa. Osserva che con gli ultimi modelli e i coding agent, la preoccupazione sulla “boring technology” non regge nella pratica: puoi lanciare un agent in qualsiasi codebase (anche una che usa librerie troppo nuove o troppo private per essere nei dati di training) e funziona lo stesso. L’agent consulta gli esempi esistenti, capisce i pattern, e poi itera e testa il proprio output. Willison si aspettava che i coding agent fossero l’incarnazione definitiva dell’approccio “Choose Boring Technology”, ma la sua esperienza suggerisce il contrario.
Paul Kinlan ha sollevato una domanda stimolante già nell’ottobre 2024, in Will We Care About Frameworks in the Future?. Mentre guardava codice generato dall’AI su Replit, ha notato una cosa interessante: il codice era vanilla. Niente framework, nessuna logica condivisa, tanta ripetizione, e non importava, perché l’AI poteva fare refactoring di qualsiasi cosa su richiesta.
I framework esistono perché gli esseri umani hanno bisogno di astrazioni ergonomiche per gestire la complessità. Abbiamo bisogno di pattern, convenzioni e struttura per non impazzire. Ma a un LLM non importa della duplicazione di codice. Non ha bisogno di zucchero sintattico. Può gestire decine di migliaia di righe di codice vanilla, iper-ottimizzato, senza battere ciglio.
Seth Webster, executive director della React Foundation, si spinge oltre: sostiene che stiamo entrando in un “mondo post-framework frontend” in cui l’AI genera React e a nessuno importa cosa genera. Il vero problema, dice, è che i modelli sono addestrati sul peggior codice React pubblicamente disponibile, infilando logica di business dentro i componenti invece di costruire veri service layer.
Questo apre una domanda provocatoria: vedremo l’emergere di framework progettati non per la Developer Experience (DX) ma per l’Agent Experience (AX)? Tool ultra-densi, computazionalmente efficienti e ottimizzati per la comunicazione LLM-to-LLM invece che per la leggibilità umana?
C’è un lato oscuro in questa storia. Il paper del 2023 The Curse of Recursion di Shumailov et al. ha dimostrato un fenomeno chiamato Model Collapse: quando i modelli vengono addestrati sul proprio output generato, le code della distribuzione originale scompaiono. Pattern minoritari, approcci di nicchia e soluzioni meno comuni vengono progressivamente cancellati.
Applicalo al codice, e il quadro si fa inquietante. Se gli LLM generano la maggior parte del codice nuovo, e quel codice segue in modo schiacciante gli stessi pattern, e poi i modelli futuri vengono addestrati su quel codice, finiamo in una spirale di restringimento in cui la diversità dell’ecosistema software si contrae a ogni generazione.
Le conseguenze pratiche sono già visibili. Secondo un’analisi di Pixelmojo, lo studio di GitClear su 153 milioni di righe di codice ha trovato che il refactoring è sceso dal 25% delle righe modificate nel 2021 a meno del 10% nel 2024, mentre la duplicazione di codice è aumentata di circa quattro volte. La ricerca di Apiiro sulle Fortune 50 ha documentato un aumento di dieci volte delle vulnerabilità di sicurezza mensili tra dicembre 2024 e giugno 2025.
Il termine che sta emergendo per questo fenomeno è “code slop”: codice tecnicamente funzionale ma semanticamente vuoto, che non riflette più la logica di business del mondo reale. I nomi delle variabili diventano generici, i concetti di dominio si sfumano, e il codebase perde il design intenzionale che rende il software manutenibile.
Proiettando in avanti queste tendenze, emergono alcuni scenari:
Per l’80% delle applicazioni standard (dashboard, CRUD, tool interni), l’innovazione tecnologica potrebbe di fatto fermarsi. React, Node.js, Python e una manciata di altre tecnologie diventano il linguaggio assembly del futuro: un layer di base manutenuto dall’AI, raramente messo in discussione, raramente sostituito.
Per i domini mission-critical e nuovi, la storia può essere diversa. L’AI toglie il collo di bottiglia dell’apprendimento umano. Pattern architetturali nuovi che prima ci mettevano anni a diffondersi possono essere adottati dai team in pochi giorni, se qualcuno sa cercarli. Questo premia i system architect che sanno pensare oltre lo stack di default.
E potenzialmente potrebbe emergere una nuova classe di tecnologie “AI-native”: framework, protocolli e pattern progettati fin dalle fondamenta non per la comodità umana ma per l’efficienza degli agent. Il passaggio da DX ad AX potrebbe essere la più significativa transizione architetturale del prossimo decennio.
La tensione è reale e non sparirà. Gli LLM hanno un bias integrato verso lo status quo, e quel bias crea una potente attrazione gravitazionale verso l’omogeneità tecnologica. Il feedback loop tra dati di training, default dei tool e comportamento degli sviluppatori si auto-rinforza ed è difficile da spezzare.
Ma il quadro è più sfumato di “l’innovazione è morta”. La stessa AI che va di default su React può anche imparare Flix in un pomeriggio, con la documentazione giusta. Gli stessi modelli che generano code slop possono essere guidati verso un’architettura ragionata, con pratiche di engineering adeguate.
In Buildo ci pensiamo ogni giorno. Crediamo che la generazione di codice stia rapidamente diventando una commodity: la parte facile del software engineering. Quello che rimane difficile, e sempre più di valore, è la capacità di progettare sistemi che funzionano davvero: scegliere l’architettura giusta, mantenere la qualità su scala, e sapere quando lo stack di default è la risposta sbagliata.
La domanda non è se l’AI scriverà il nostro codice. Lo fa già. La domanda è se le lasceremo prendere anche le nostre decisioni architetturali, o se resteremo noi al volante, usando l’AI come uno strumento potente e tenendo il pensiero critico ben saldo nelle mani umane.
I moved from full-stack engineering to DevOps. I'm passionate about using Vim and k9s in the terminal and have diverse experience in software development and optimizing DevOps processes.
Matteo Pellegrino Matteo Pellegrino — 12 min 
Matteo Pellegrino Matteo Pellegrino — 6 min 
Livia Stevenin Livia Stevenin — 12 min Ogni mese scegliamo articoli utili ma anche idee fresche e stimolanti. Proprio quello che vorremmo trovare noi in una newsletter!
