Se fai il nostro mestiere, la domanda te la sei già posta. Magari mentre aggiornavi per l’ennesima volta i plugin di un WordPress, o mentre aspettavi che un’istanza DNN completasse un deploy. Poi hai visto qualcuno generare un sito intero con Lovable in 20 minuti e hai pensato: “Ma io perché sto ancora qui?”

È una reazione comprensibile. Ma come per tutte le rivoluzioni tecnologiche, la risposta corretta non è né “cambia tutto subito” né “non cambiare niente”. La risposta è: dipende. E in questo articolo proviamo a capire da cosa dipende.

Il vero problema dei CMS tradizionali nel 2026

Non si tratta di dire che WordPress o DNN “non funzionano”. Funzionano, eccome. WordPress alimenta ancora circa il 40% del web mondiale. Il punto è un altro: il rapporto costo/valore di quello che ti porti dietro.

Quando installi un WordPress per un sito semi-statico con un blog, stai deployando un’applicazione PHP con database MySQL, un sistema di plugin con una superficie d’attacco che fa rabbrividire qualsiasi esperto di sicurezza, e un ciclo infinito di aggiornamenti che non puoi rimandare. Per un sito da 5-10 pagine più un blog, è come noleggiare un TIR per andare al supermercato.

DNN (ex DotNetNuke) soffre dello stesso problema amplificato: un ecosistema in contrazione, una community sempre più ridotta, costi di hosting .NET che non si giustificano per progetti semplici, e una curva di aggiornamento che può essere dolorosa.

Ma attenzione: “costoso da mantenere” non significa “da buttare”. Significa che per i nuovi progetti, oggi abbiamo alternative che prima non esistevano.

Il Vibe Coding: cos’è e perché cambia le regole

Il termine “vibe coding” è stato coniato da Andrej Karpathy, ex direttore AI di Tesla, per descrivere un modo di programmare in cui si descrive ciò che si vuole ottenere e l’intelligenza artificiale genera il codice. Strumenti come Lovable, Bolt, Claude Code e Cursor hanno reso questo approccio accessibile a chiunque abbia esperienza tecnica sufficiente per guidare il risultato.

Per i siti web semi-statici — landing page, siti vetrina, blog aziendali — il vibe coding offre vantaggi concreti e misurabili.

Velocità di delivery

Quello che con WordPress richiede scegliere un tema, configurare plugin, personalizzare template e testare compatibilità, con il vibe coding si ottiene in ore. E il risultato è codice tuo, pulito, senza dipendenze da plugin di terze parti che potrebbero essere abbandonati domani.

Costo operativo vicino a zero

Un sito statico deployato su Vercel, Netlify o Cloudflare Pages costa letteralmente zero per volumi normali. Niente server da mantenere, niente database da backuppare, niente aggiornamenti di sicurezza urgenti alle due di notte.

Performance e SEO nativi

Un sito generato staticamente parte da un Lighthouse score sopra 95 senza interventi. Con WordPress si devono installare tre plugin di caching, un ottimizzatore di immagini e un minificatore CSS per avvicinarsi allo stesso risultato.

La trappola del “Sembra facile”

Ed ecco dove il discorso si complica, e dove l’esperienza conta più dell’entusiasmo.

Chi ha qualche anno di sviluppo alle spalle conosce bene la regola dell’80/20: il primo 80% del progetto consuma il 20% del tempo. È l’ultimo 20% che ti mangia vivo. Il vibe coding è fenomenale per quel primo 80% — il “wow, ho un sito in due ore”. Ma poi arrivano i dettagli.

Ognuno di questi “piccolissimi dettagli” può costare ore o giorni. Un CMS maturo li gestisce da anni senza che nessuno ci pensi. È il classico costo nascosto che non vedi finché non sei nel mezzo del progetto.

La terza via: backend CMS + frontend vibe-coded

C’è però un approccio che permette di avere il meglio dei due mondi, ed è quello che nell’industria si chiama architettura “headless”: separare nettamente il backend (dove si gestiscono i contenuti) dal frontend (quello che l’utente vede).

L’idea è semplice nella sua eleganza. Si utilizza una piattaforma low-code come backend — con la sua interfaccia di gestione contenuti, le sue API REST, le sue automazioni integrate — e si costruisce il frontend con strumenti di vibe coding, ottenendo un sito velocissimo e moderno che consuma i dati via API.

Piattaforme come PlantAnApp, Strapi o Sanity possono fungere da backend. Il vantaggio delle piattaforme low-code è che offrono non solo la gestione contenuti, ma anche automazioni, trigger, task schedulati e workflow completi — funzionalità che con WordPress richiederebbero l’ennesima collezione di plugin.

I vantaggi concreti dell’approccio ibrido

Multi-tenancy naturale. Un’unica istanza backend può servire più siti frontend diversi. Ogni cliente ha il suo spazio dati e la sua interfaccia di amministrazione, ma l’infrastruttura è condivisa. Il costo operativo per cliente diminuisce drasticamente.

Autonomia editoriale per il cliente. Il pannello di gestione è già pronto e intuitivo. Il cliente entra, modifica i contenuti, salva. Il frontend si aggiorna automaticamente. Nessuno deve toccare codice.

Frontend sostituibile. Se tra due anni gli strumenti di vibe coding producono risultati ancora migliori, o se cambia il framework di riferimento, si rifarà il frontend in un giorno. Il backend, i dati, le automazioni restano intatti. Questo è un valore enorme nel tempo.

Automazioni native. Vuoi che il blog mandi una notifica quando pubblichi un nuovo articolo? Che un form contatti attivi un workflow automatico? Con un backend low-code, queste automazioni sono già integrate nella piattaforma. Non servono plugin aggiuntivi.

Le criticità da considerare

L’approccio ibrido non è privo di sfide. La più significativa riguarda la latenza: se il frontend deve chiamare il backend ad ogni caricamento di pagina, l’esperienza utente ne risente. La soluzione è usare un approccio di rigenerazione statica (SSG o ISR): il frontend genera le pagine al momento del build, e si rigenera solo quando i contenuti cambiano, tipicamente tramite un webhook dal backend. Il risultato è un sito con la velocità di un sito statico e i contenuti sempre aggiornati.

Altra criticità: se il backend è condiviso tra più clienti e va offline, tutti i pannelli di amministrazione si fermano. I siti pubblici restano raggiungibili (sono statici), ma nessuno può modificare i contenuti finché il backend non torna operativo. Servono backup, monitoring e un piano di emergenza.

Quando usare cosa: una guida pratica

Dopo mesi di sperimentazione e ragionamento, ecco la matrice decisionale che propongo.

La regola d’oro

Per decidere se usare vibe coding o CMS classico, la domanda giusta non è “Riesco a rifarlo?” — certo che riusciamo, siamo sviluppatori. La domanda giusta è: “Il valore che guadagno giustifica il rischio di tutti i dettagli che dovrò risolvere a mano?”

Per un sito nuovo da zero, senza legacy e senza SEO da preservare, il vibe coding è la scelta giusta nel 2026. Per un sito esistente con contenuti, URL indicizzate e funzionalità mature, aggiornare il CMS è quasi sempre la scelta più intelligente — a meno che non si voglia cambiare radicalmente la natura del prodotto.

E per chi vuole il meglio di entrambi, l’architettura ibrida backend low-code + frontend generato è probabilmente la scelta strategica più lungimirante. Richiede un investimento iniziale per costruire il pattern, ma una volta pronto diventa un asset riutilizzabile per ogni progetto futuro.

Una nota sulla prudenza

Il 2026 è un anno in cui tutto si muove velocemente. Ogni settimana esce uno strumento nuovo che promette di rendere obsoleto quello della settimana prima. In questo contesto, la tentazione di riscrivere tutto con il tool del momento è fortissima.

Ma chi ha visto abbastanza progetti nella propria carriera sa che il refactoring “perché posso” è uno dei modi più eleganti per buttare tempo e soldi. La saggezza sta nel distinguere tra ciò che merita di essere rifatto e ciò che merita di essere migliorato. Il vibe coding è uno strumento potentissimo. Ma resta uno strumento. E come tutti gli strumenti, dà il meglio di sé quando lo si usa al momento giusto, per il progetto giusto.