Descrivi un’interfaccia a parole e in dieci secondi hai un pezzo di codice React che funziona (quasi) perfettamente. Se la parte visibile del web si genera con un prompt, ha ancora senso pagare qualcuno per farla? La domanda è legittima. La risposta, come spesso accade, dipende da cosa intendiamo per “frontend”.
Se ne parla da qualche tempo… Il frontend è morto? Chi l’ha ammazzato? È meglio che gli sviluppatori frontend vadano a zappare? O meglio che aprano un chiringuito su qualche spiaggia? Partiamo dallo scenario che rende la domanda seria, non da una difesa d’ufficio del mestiere.
Nel 2026, lo sappiamo tutti, esistono strumenti che da una descrizione in linguaggio naturale, restituiscono applicazioni funzionanti.
- v0 di Vercel genera interfacce React con Tailwind e shadcn/ui di qualità difficile da distinguere da quella di un dev senior
- Bolt.new di StackBlitz costruisce app full-stack dentro il browser, con tanto di dipendenze installate e preview attiva in pochi minuti
- Lovable porta un non-programmatore da un’idea a un prodotto con database e autenticazione già cablati. Non sono demo da conferenza: sono categorie di prodotto con curve di crescita da record e milioni di utenti (e persone che ci fanno milioni di dollari).
Il gesto più identitario del frontend developer, tradurre un design in markup e stili, comporre componenti, gestire stati e layout è esattamente ciò che questi strumenti fanno meglio.
Da qui una domanda legittima, ma allo stesso tempo provocatoria: se la produzione dell’interfaccia si automatizza, il frontend developer è diventato un mestiere in via di estinzione?
Vale la pena prenderla sul serio. Costruiamo il caso più forte possibile, poi smontiamolo e vediamo cosa resta in piedi. Benvenuti al tribunale di Codemotion: l’imputato è l’AI, il cadavere (forse) è quello dello sviluppatore frontend.
L’accusa: il frontend è morto
Il mercato ha già votato
Prima ancora di entrare nel merito tecnico, l’accusa mette sul tavolo la prova più difficile da controbattere: il denaro. Lovable ha toccato qualcosa come 20 milioni di dollari di ricavi ricorrenti annui in due mesi, Bolt.new circa 40 milioni in sei. Non sono numeri da startup che vende un sogno in un pitch deck: sono, rispettivamente, la crescita più rapida mai vista nel software europeo e cifre da categoria ormai consolidata.
Il capitale è un giudice cinico. Non scommette su ciò che fa una bella figura in una demo da conferenza: scommette su ciò che a scala genera valore reale. Se investitori e utenti pagano queste cifre per far scrivere frontend a un modello, è perché quel frontend, per una fetta enorme di casi d’uso, è “abbastanza buono” da bastare. E “abbastanza buono, subito” è quasi sempre ciò che vince, non “perfetto, tra due settimane”.
La UI è diventata una commodity
Per vent’anni il valore del frontend developer è stato in larga parte nella capacità di trasformare un mockup in codice: pixel-pushing, gestione del CSS, design responsive, cross-browser. Era lavoro artigianale, e come tutto il lavoro artigianale traeva valore dalla scarsità di chi lo sapeva fare bene.
Quella scarsità si sta erodendo. La generazione da prompt e i flussi design-to-code (esempio: da Figma al codice) rendono “banale” proprio il passaggio che definiva il mestiere del frontend. Quando chiunque produce un’interfaccia decente descrivendola a parole, la competenza “frontend puro” smette di essere un vantaggio competitivo e diventa un tasto da premere.
Il boilerplate ERA il pane quotidiano
Form, tabelle, modali, loading state, gestione degli errori di validazione, glue code tra componenti: chi lavora in questo campo sa che una fetta enorme delle giornate se ne va lì. Non è lavoro creativo, è lavoro ripetitivo, ed è precisamente il territorio dove i modelli linguistici danno il meglio, perché, dato che sono pattern visti migliaia di volte, i modelli sanno esattamente cosa fare.
Il paradosso è crudele: la parte del lavoro che riempiva le ore è la più facile da automatizzare. Ciò che sembrava “fare frontend” era in buona misura amministrazione di codice noto.
La velocità abbassa l’asticella
C’è poi un effetto più subdolo, che non riguarda la qualità dell’output ma l’economia di chi decide. Perché l’AI vinca non serve che batta il senior sul suo terreno: basta che sposti il punto in cui qualcuno dice “va bene così”.
Quando un’interfaccia decente costa dieci secondi e pochi euro invece di due giorni-uomo, l’asticella di ciò che è accettabile scende insieme al costo. Aziende che non avrebbero mai stanziato un budget per l’artigianato del pixel oggi deployano UI generata senza pensarci, perché la domanda è cambiata: non più “quanto vale farlo bene?”, ma “perché pagare, se questo basta?”. Il frontend developer non viene sconfitto in una gara di bravura. Viene saltato, perché la domanda che giustificava il suo ingaggio non se la pone più nessuno.
I problemi già risolti sono quelli che l’AI padroneggia
L’ecosistema si è consolidato attorno a soluzioni condivise. Le librerie headless, i design system come shadcn/ui, i pattern di composizione ormai canonici hanno trasformato gran parte del frontend in un insieme di problemi conosciuti. E i problemi conosciuti sono quelli su cui un modello, addestrato su milioni di repository, si muove con sicurezza. Non a caso v0 è di fatto una versione AI della filosofia shadcn/ui: genera esattamente ciò su cui è stato ottimizzato.
La stretta si sente sui junior
C’è un effetto secondario più insidioso della semplice automazione. I task entry-level (impaginare, stilizzare, replicare un mockup, scrivere il form dell’ennesima pagina di contatto, ecc…) sono i primi a evaporare. Sono proprio i compiti su cui, storicamente, un junior imparava il mestiere e giustificava il suo stipendio: Se il senior lavorava sull’architettura di un’applicazione frontend, il junior spalava… Il CSS.
Se il gradino d’ingresso si assottiglia, il problema non è solo per chi c’è già: è per chi dovrebbe entrare. Un mestiere che smette di formare junior è un mestiere che, a distanza di un ciclo o due, ha un problema di ricambio strutturale.
Fin qui la tesi. È solida, e chi la liquida come allarmismo non l’ha guardata abbastanza a lungo. Ora l’altro lato.
La difesa: il frontend è vivissimo
Generare non è decidere
Il punto debole della tesi “dell’omicidio del frontend” è che confonde la produzione di codice con l’ingegneria del software. L’AI genera, ma architettura, gestione dello stato, budget di performance, strategia di caching, accessibilità restano decisioni umane con conseguenze misurabili e durature.
Un modello scrive un componente React in dieci secondi. Non dice se quel componente va messo lì, se lo stato debba vivere in quel punto dell’albero dei componenti, se quella scelta reggerà quando la pagina crescerà di un ordine di grandezza. Genera una risposta plausibile a una domanda locale; non prende decisioni di sistema. E il frontend, in un prodotto reale, è un sistema.
Demo non è prodotto: il “technical cliff”
Qui la teoria incontra un dato concreto. Questi strumenti molto spesso vanno a bomba nel primo 80% del lavoro: la demo che funziona, l’interfaccia che si vede bene nello screenshot. È il restante 20% a distinguere un giocattolo da qualcosa che si può mettere in produzione: edge case, comportamento cross-browser, accessibilità, internazionalizzazione, resilienza agli errori, sicurezza.
La proporzione 80 a 20 non vi dice nulla? Eppure dovrebbe.
Non è un timore astratto. Nel 2025 la vulnerabilità CVE-2025-48757 ha esposto i dati di oltre 170 applicazioni Lovable in produzione: Supabase spedisce le tabelle con il Row Level Security disattivato per default, e il generatore non lo attivava. Tradotto: app che sembravano finite, con UI curata e login funzionante, avevano il database aperto a chiunque sapesse dove guardare. Il codice generato sembrava pronto. Non lo era.
È l’esempio da manuale del technical cliff: il momento in cui la magia della generazione incontra la brutalità dell’infrastruttura di produzione. Qualcuno deve conoscere il precipizio per non caderci dentro, e quel qualcuno ha un profilo che assomiglia molto a un frontend engineer esperto.
La responsabilità è legge, e non si genera da un prompt
C’è un piano su cui quel precipizio diventa, alla lettera, un problema legale. Dal 28 giugno 2025 lo European Accessibility Act (Direttiva UE 2019/882, in Italia recepita dal D.Lgs. 82/2022) ha reso l’accessibilità digitale un obbligo di legge per la gran parte delle imprese sopra la soglia di microimpresa, con sanzioni che arrivano a 40.000 euro. Non è più una questione di sensibilità: è conformità normativa, con un’autorità che vigila e multa.
Ora, prova a chiedere a un modello di generarti un’interfaccia conforme alle WCAG in ogni edge case, e poi a rispondere lui davanti al Garante quando non lo è. Non funziona così. L’AI genera, la responsabilità resta umana, e per giunta sanzionabile. Qualcuno deve sapere cosa controllare, garantire che l’output rispetti requisiti che il modello tratta come opzionali, e infine metterci la firma. È esattamente il profilo del frontend engineer esperto: non uno che sparisce, ma uno che diventa il punto in cui il rischio si ferma.
Il problema del contesto
C’è un limite più profondo, e più difficile da superare con un modello più grande. L’AI non conosce la tua codebase, i vincoli di business, la storia delle decisioni architetturali, il motivo per cui tre anni fa avete scelto quel pattern invece di quell’altro. Genera nel vuoto del prompt (o al massimo utilizzando come contesto ciò che gli è stato messo a disposizione).
Qualcuno deve dargli quel contesto, per l’appunto… E capire abbastanza da giudicare se l’output ha senso in quel contesto. Più il progetto cresce, più questo lavoro di contestualizzazione e revisione pesa. Non a caso il consenso, tra chi questi strumenti li usa sul serio, è che oltre una certa soglia di complessità il codice generato diventa più difficile da mantenere, non meno. La velocità iniziale si paga dopo.
Il frontend non è “fare bottoni”
L’errore concettuale di fondo è ridurre il frontend all’implementazione. Il frontend è il livello in cui il prodotto incontra l’utente: coerenza del design system, qualità dell’interazione, accessibilità come requisito e non come ripensamento, performance percepita. Sparisce l’implementazione ripetitiva; non sparisce la disciplina che decide cosa implementare e perché.
Un modello ti dà mille varianti di un bottone. Non ti dice quale sia quella giusta per il tuo utente, il tuo brand, il tuo contesto d’uso. Quella resta una competenza ancora umana.
La struttura serve all’agente quanto all’umano
C’è un ultimo punto che ribalta l’intuizione. Verrebbe da pensare che, se il codice lo scrive un modello, l’organizzazione del progetto (framework, convenzioni, struttura delle cartelle) conti sempre meno. È il contrario. La struttura che un framework impone è ciò che permette all’umano di ragionare su una codebase complessa senza tenerla tutto in testa; ed è esattamente la stessa struttura che permette a un agente di generare codice sensato, perché gli fornisce i vincoli e i pattern entro cui muoversi.
I framework, in altre parole, funzionano come uno strato di compressione cognitiva: comprimono decisioni ricorrenti in convenzioni condivise, e quelle convenzioni sono un vantaggio tanto per chi legge quanto per chi genera. Un progetto ben strutturato non è solo più manutenibile per un umano, è più “generabile” per un modello. Chi conosce a fondo un framework e sa dargli forma non sta diventando meno rilevante nell’era degli agenti: sta costruendo il terreno su cui gli agenti lavorano meglio. Vi dice nulla?
Il paradosso di Jevons: più codice, non meno
Resta l’obiezione economica, quella dei ricavi da record con cui l’accusa ha aperto. E qui la difesa gioca la carta migliore, che ha un secolo e mezzo. Nell’Ottocento l’economista William Stanley Jevons notò che rendere più efficiente l’uso del carbone non ne riduceva il consumo: lo faceva esplodere, perché abbassando il costo si moltiplicavano gli impieghi. È il paradosso che porta il suo nome, e vale per il codice come valeva per il carbone.
Quando generare un’interfaccia costa quasi nulla, non costruiamo la stessa quantità di software spendendo meno: ne costruiamo molto di più. Più superfici, più dashboard, più flussi, più esperimenti che prima non avrebbero mai giustificato un budget. E ogni interfaccia in più è un qualcosa che va deciso, revisionato, mantenuto, reso accessibile, tenuto coerente col resto. Lo stesso mercato che oggi finanzia i generatori è quello che domani si ritroverà sommerso di frontend da governare, e avrà bisogno di più persone capaci di farlo, non di meno. L’AI non prosciuga il lavoro: ne alza il livello.
Il verdetto
Le due tesi non si annullano. Descrivono lo stesso fenomeno da due lati, e hanno ragione entrambe su cose diverse.
Ha ragione la tesi “dell’omicidio” quando dice che un certo profilo sta scomparendo: l’esecutore, l’artigiano del pixel-pushing, chi traeva valore dalla velocità di battitura del boilerplate. Quel vantaggio competitivo è finito, e fingere il contrario è la forma più pigra di consolazione.
Ha ragione la tesi “il frontend è vivo” quando dice che il mestiere non è quel profilo. Il baricentro del lavoro si sposta dalla digitazione al giudizio: dall’implementare al decidere, valutare, contestualizzare, architettare. Meno tempo a scrivere codice, più tempo a stabilire se il codice scritto è quello giusto.
È esattamente lo spostamento che sta facendo emergere una figura ibrida, il product engineer: qualcuno che tiene insieme design, prodotto e ingegneria e usa questi strumenti per testare tre direzioni di UI nel tempo che prima serviva a configurare un bundler. Non è meno tecnico di un frontend developer. È tecnico in un punto diverso della catena del valore.
C’è anche un dettaglio che chi scrive la tesi “omicidio” tende a ignorare: gli strumenti stanno smettendo di essere solo generatori di UI. v0, che per due anni è stato l’archetipo del “frontend-only”, da febbraio 2026 genera anche route API, server action e connessioni a database. Il che, paradossalmente, rafforza entrambe le tesi: l’AI automatizza una fetta ancora più grande del lavoro, e proprio per questo il punto di controllo umano (il giudizio su un output sempre più esteso) diventa più critico, non meno.
Cosa cambia, in concreto, per chi legge?
Se lavori nel frontend, la domanda utile non è “sarò sostituito?”. È: dove si è spostato il valore?
Smetti di considerare un vantaggio competitivo ciò che l’AI fa in dieci secondi: scrivere il boilerplate, replicare un mockup, impaginare una pagina statica. Non perché sia inutile, ma perché non è più una risorsa scarsa.
Investi tempo dove l’AI non arriva:
- Il giudizio architetturale: dove vive lo stato, come si struttura un’app perché regga la crescita, quali trade-off di performance accettare.
- L’accessibilità e gli edge case: quel 20% che separa la demo dal prodotto, e che i modelli sistematicamente trascurano.
- Il contesto di dominio: conoscere il business, la codebase, la storia delle decisioni abbastanza da guidare e correggere l’output generato.
- La revisione critica: saper leggere codice generato e riconoscere il precipizio tecnico prima di caderci. La CVE di Lovable non è un incidente isolato: è la forma stabile del rischio quando si generano app senza qualcuno che sappia cosa controllare.
Il frontend che conoscevi (l’implementatore che traduceva design in codice a mano) è davvero morto. Ma non l’ha ucciso l’AI: l’ha reso obsoleto rendendo abbondante ciò che era scarso. Quello che resta al suo posto (il decisore, il revisore, l’architetto dell’esperienza) vale di più, non di meno, proprio perché lavora sopra uno strato che genera in automatico.
È una muta di pelle. Fa impressione mentre succede, e da fuori sembra la fine di qualcosa. Ma chi cambia pelle non muore.
