WordPress ha ancora senso nell'era degli agenti AI?

C'è un paradosso interessante nel Web moderno. Per decenni abbiamo costruito astrazioni sopra altre astrazioni con uno scopo perfettamente ragionevole, permettere a più persone possibile di creare e gestire un sito senza dover conoscere HTML, CSS, JavaScript, PHP, database, server, API e infrastruttura. WordPress è probabilmente il risultato più riuscito di questa filosofia.

Poi è arrivata l'intelligenza artificiale generativa, e improvvisamente si apre una domanda che fino a pochi anni fa sarebbe sembrata quasi assurda: se posso descrivere a un agente AI il sito che voglio, farglielo costruire direttamente, modificarlo parlando in linguaggio naturale e chiedergli di integrare qualsiasi servizio esterno, ho ancora bisogno di un CMS come WordPress?

La risposta breve è che oggi, in alcuni casi, sì, ma molto meno di ieri, e domani probabilmente ancora meno. Il punto interessante, però, non è stabilire se WordPress morirà. Il punto è capire che l'AI potrebbe rendere obsoleto il motivo stesso per cui WordPress e molti altri CMS sono diventati necessari.

Prima di tutto: che cos'è WordPress, spiegato in modo semplice

WordPress è un Content Management System, cioè un sistema che permette di gestire un sito attraverso un'interfaccia grafica. Invece di scrivere direttamente il codice di una pagina, entri in un pannello amministrativo, crei una pagina, inserisci testi e immagini, scegli un tema grafico e aggiungi funzionalità installando plugin.

Serve un modulo di contatto, un sistema SEO, un negozio online, delle traduzioni, statistiche, caching, un cookie banner, una newsletter, un sistema di prenotazioni, backup, sicurezza, slider o ottimizzazione delle immagini? Quasi sempre esiste un plugin.

Tecnicamente, nella sua configurazione tradizionale, WordPress utilizza PHP sul server e un database, normalmente MySQL o MariaDB, dal quale recupera contenuti e configurazioni per generare dinamicamente le pagine richieste dagli utenti. È la documentazione ufficiale di WordPress stessa a descrivere questa architettura. Ed è un modello che ha funzionato straordinariamente bene.

Perché WordPress domina ancora il Web

Perché ha risolto un problema enorme, ha abbassato drasticamente la barriera d'ingresso alla creazione di siti Web. Per realizzare un sito tradizionale servivano competenze tecniche, mentre con WordPress è diventato possibile comprare un dominio, installare la piattaforma con un click, acquistare un tema, importare una demo, sostituire testi e fotografie, installare qualche plugin e pubblicare. E il sito era online.

Non era necessario essere software engineer, e spesso non era nemmeno necessario conoscere realmente HTML, CSS o JavaScript. Questa non è una critica, è precisamente il successo di WordPress: ha democratizzato il Web, ha permesso a freelance, designer, piccole agenzie, aziende e professionisti non tecnici di creare qualcosa che, vent'anni prima, avrebbe richiesto un programmatore.

Il rovescio della medaglia è che si è sviluppato un enorme segmento di mercato nel quale "sviluppare un sito" significa, in realtà, assemblare componenti sviluppati da qualcun altro, cioè un tema, un page builder, un plugin, il plugin del plugin e qualche snippet copiato online. Esistono naturalmente sviluppatori WordPress estremamente competenti e progetti ingegnerizzati in maniera eccellente, quindi il problema non è WordPress in sé. Il problema è che il suo modello economico e operativo rende possibile produrre siti anche senza comprendere realmente ciò che accade sotto il cofano. E per il mercato di massa questo era esattamente ciò che serviva.

Il risultato è una gigantesca monocultura tecnologica

Si cita spesso il dato secondo cui WordPress alimenterebbe il 43% del Web. Era sostanzialmente corretto negli anni precedenti, ma oggi il dato più interessante è un altro. Al 25 agosto 2026 W3Techs rileva WordPress sul 40,7% di tutti i siti Web analizzati e sul 58,9% dei siti dei quali è identificabile un CMS. È ancora una quota semplicemente enorme, ma qualcosa sta cambiando.

Dopo aver raggiunto e mantenuto per anni valori intorno al 43%, nel 2026 la quota ha iniziato a diminuire in maniera più evidente: a gennaio 2026 era circa il 43%, a maggio era già scesa intorno al 41,9%, fino all'attuale 40,7%. Non significa che WordPress stia per sparire, significa però che il suo dominio non è più una legge naturale del Web. Ed è proprio adesso che arriva una tecnologia capace di attaccare il presupposto fondamentale sul quale quel dominio è stato costruito, l'intelligenza artificiale.

L'AI cambia il problema alla radice

Fino a ieri avevamo bisogno di WordPress perché programmare direttamente un sito aveva un costo elevato. Bisognava sapere cosa scrivere, conoscere la sintassi, sapere dove mettere il codice, comprendere frontend, backend, database, deploy e configurazione del server. WordPress trasformava tutto questo in pulsanti. Ma cosa succede quando il codice non devi più scriverlo tu?

Immaginiamo di poter dire a un agente:

Crea un sito responsive per uno studio di architettura. Voglio cinque sezioni, animazioni leggere, una gallery, un form che invia i lead al CRM e una pagina progetti alimentata da questi dati. Ottimizzalo per mobile, accessibilità, SEO e performance.

L'agente genera il progetto. Poi dici:

Sposta questa sezione sopra. Riduci lo spazio. Quando arriva un contatto invialo anche a questo webhook. Cambia la gallery così. Aggiungi una pagina in inglese. Fai in modo che il menu diventi trasparente sopra la hero.

Non stai utilizzando un CMS. Il linguaggio naturale è diventato il CMS. Questa è la trasformazione fondamentale: WordPress ha sostituito il codice con un'interfaccia grafica, mentre l'AI sta iniziando a sostituire sia il codice sia l'interfaccia grafica con l'intenzione dell'utente.

Il CMS era un'astrazione, e ora quell'astrazione potrebbe diventare superflua

Prendiamo un normale sito aziendale. Ha una homepage, una pagina chi siamo, i servizi, il portfolio, i contatti, qualche articolo, un modulo contatti, analytics e un'integrazione CRM. Per offrire queste funzioni con WordPress possiamo ritrovarci con una catena fatta di web server, PHP, WordPress Core, tema, child theme, page builder, plugin, database, caching, plugin di caching e CDN.

Ogni livello esiste per risolvere un problema reale, ma ogni livello introduce anche codice, dipendenze, aggiornamenti, configurazioni, possibili incompatibilità, consumo di CPU, query, memoria, spazio disco e superficie d'attacco. Con un agente AI una soluzione equivalente potrebbe invece ridursi a HTML, CSS e JavaScript con le poche API necessarie servite da una CDN, oppure a un frontend statico con una piccola funzione serverless per il modulo. Non sempre sarà possibile, ma per una percentuale enorme dei siti Web attuali sì. Ed è qui che la discussione diventa molto più interessante della semplice domanda "WordPress è lento?".

Il vero spreco è fare lavoro dinamico per contenuti che dinamici non sono

Un visitatore apre la pagina "Chi siamo", e il testo magari non cambia da sei mesi. Eppure in un'installazione WordPress tradizionale può esserci un'applicazione PHP pronta a partire, recuperare configurazioni, eseguire hook, interrogare il database, caricare tema e plugin e produrre infine dell'HTML.

Naturalmente WordPress può essere ottimizzato enormemente attraverso caching, CDN e object cache. Ma è interessante leggere cosa dice la stessa documentazione ufficiale: memorizzare le pagine come file statici permette di ridurre il carico di elaborazione del server e, per contenuti abbastanza statici, il caching può produrre miglioramenti prestazionali di diversi ordini di grandezza. In altre parole, dopo avere costruito una gigantesca infrastruttura dinamica, una delle migliori ottimizzazioni consiste spesso nel fare in modo che quella infrastruttura non venga eseguita per ogni visita. È un indizio importante, perché per moltissimi siti la soluzione più efficiente potrebbe essere semplicemente non avere quell'infrastruttura dall'inizio.

CPU: produrre ogni volta qualcosa che potremmo già avere

Un sito statico distribuito attraverso una CDN richiede pochissimo calcolo lato server per servire una pagina: il file esiste già, arriva la richiesta, il file viene consegnato, fine. Un CMS dinamico deve invece essere progettato per gestire un universo molto più grande di possibilità, cioè utenti, autorizzazioni, plugin, query, filtri, temi, shortcode, REST API, commenti, revisioni, hook e moltissimo altro. Quella generalità ha un costo. Per un grande portale editoriale può essere perfettamente giustificato, per il sito di un ristorante con sette pagine molto meno.

Storage e database: quando l'astrazione accumula storia

Un WordPress appena installato non occupa gigabyte di database, ed è importante essere precisi su questo. Ma siti reali mantenuti per anni possono accumulare una quantità considerevole di dati attraverso revisioni, autosave, transients, log, statistiche, submission dei form, dati WooCommerce, sessioni, cache, metadata, plugin SEO, plugin di sicurezza, sistemi di analytics e tabelle personalizzate.

WordPress permette esplicitamente ai plugin di creare nuove strutture nel database e memorizzare dati che aumentano durante l'utilizzo del sito, e anche il sistema di revisioni può essere limitato attraverso configurazione proprio perché queste vengono conservate. Non è quindi assurdo incontrare installazioni apparentemente semplici con database da centinaia di megabyte o, in casi particolari, diversi gigabyte. Il punto non è sostenere che WordPress occupi necessariamente gigabyte, il punto è un altro: un sito composto da 30 pagine HTML non ha bisogno di un database da interrogare per ricordarsi cosa contengono quelle 30 pagine.

Poi arrivano i plugin, e con loro arriva il debito operativo

I plugin sono contemporaneamente il più grande vantaggio e uno dei maggiori problemi di WordPress. Permettono di aggiungere una funzione senza svilupparla, ma ogni plugin è anche una nuova dipendenza. Con un sito professionale è normale ritrovarsi con plugin per SEO, form, SMTP, backup, cache, sicurezza, cookie, traduzioni, immagini, page builder, custom fields, redirect, analytics e negozio online.

A quel punto non possiedi più semplicemente "un sito", possiedi un piccolo ecosistema software formato da componenti mantenuti da organizzazioni differenti, con cicli di release differenti, modelli commerciali differenti e livelli qualitativi differenti. E devi mantenerlo, cioè aggiornare Core, tema, builder, plugin e PHP, rinnovare le licenze, testare e fare backup. Qualcosa si rompe e si fa rollback. Un plugin viene abbandonato, un altro cambia prezzo, uno diventa incompatibile, un altro introduce una vulnerabilità. Il costo non è soltanto il prezzo delle licenze, è la complessità permanente del sistema.

E la sicurezza mostra bene il problema

Bisogna evitare una semplificazione frequente: WordPress Core non è necessariamente software "insicuro". Anzi, una parte molto significativa dei problemi arriva dall'ecosistema esterno. Secondo il rapporto Patchstack relativo al 2025 sono state individuate 11.334 vulnerabilità nell'ecosistema WordPress, il 42% in più rispetto al 2024, circa il 91% delle quali riguardava plugin, mentre 2.008 sono state classificate ad alta priorità.

Ed è un dato importante, perché non stiamo parlando soltanto della sicurezza di WordPress, stiamo parlando della sicurezza della composizione, cioè WordPress più il tema più il plugin A più il plugin B più il plugin C. Ogni componente aumenta la superficie possibile.

Alcuni esempi reali, aggiornati ad agosto 2026

Non serve tornare indietro di anni. Nelle sole settimane precedenti alla pubblicazione di questo articolo sono emersi casi significativi.

WordPress Core: wp2shell

Il 17 luglio 2026 WordPress 7.0.2 è stato pubblicato per correggere due problemi di sicurezza, uno Critical e uno High. La gravità è stata tale da portare WordPress ad attivare aggiornamenti forzati per le installazioni interessate. Le vulnerabilità CVE-2026-63030 e CVE-2026-60137, concatenate, potevano consentire Remote Code Execution senza autenticazione in determinate versioni di WordPress. F5 Labs ha successivamente osservato tentativi reali di sfruttamento automatizzato, ed entrambe le vulnerabilità sono finite nel catalogo CISA delle vulnerabilità note come attivamente sfruttate. Ed è esattamente il concetto di monocultura in azione, perché una volta costruito un exploit è possibile cercare automaticamente migliaia o milioni di sistemi con caratteristiche simili.

CVE-2026-64638: XSS2Shell

Poche settimane più tardi è emersa CVE-2026-64638, soprannominata XSS2Shell. CERT-AGID l'ha classificata High con CVSS 8,9. La vulnerabilità coinvolgeva il Core e interessava numerosi rami di WordPress, fino alle release della serie 4.7, e in determinate condizioni poteva diventare parte di una catena capace di arrivare all'esecuzione di PHP sul server. Questo non significa che ogni sito vulnerabile potesse essere compromesso automaticamente, perché la catena completa richiedeva condizioni aggiuntive e interazione, ma mostra l'estensione potenziale di una vulnerabilità quando un'unica base software è presente su una parte enorme del Web.

Forminator: 600.000 installazioni

CVE-2026-15748, relativa a Forminator Forms, è stata classificata Critical con CVSS 9,8. Le versioni fino alla 1.56.1 consentivano, in determinate configurazioni del form, l'upload arbitrario di file da parte di utenti non autenticati, con possibilità di arrivare all'esecuzione di codice. Il plugin conta oltre 600.000 installazioni attive e la correzione è arrivata con la versione 1.56.2.

Pods: possibile takeover amministrativo

Nell'agosto 2026 anche Pods, utilizzato da oltre 100.000 siti, è stato interessato dalla CVE-2026-19598, CVSS 9,8. La vulnerabilità permetteva una privilege escalation fino ai privilegi amministrativi ed è stata corretta nella serie 3.3 con la versione 3.3.9.1. Patchstack la segnala inoltre come vulnerabilità conosciuta come sfruttata.

TranslatePress: 400.000 siti potenzialmente coinvolti

Ancora più recente è CVE-2026-19632, pubblicata il 26 agosto 2026 e relativa a TranslatePress. CVSS 9,8, versioni interessate fino alla 3.3.1, oltre 400.000 installazioni attive. In determinate configurazioni un attaccante non autenticato poteva recuperare il link di reset password di un amministratore e arrivare al takeover dell'account. La patch è nella versione 3.3.2.

WP Compress: CVSS 10

La CVE-2026-73343 relativa a WP Compress è stata classificata da Patchstack con il massimo punteggio, CVSS 10.0. Le versioni precedenti alla 7.20.01 risultavano vulnerabili a una Remote Code Execution senza autenticazione, e il plugin conta oltre 10.000 installazioni attive.

Ma attenzione: "custom" non significa automaticamente "sicuro"

Qui è necessario evitare l'errore opposto. Un sito generato da un'AI può contenere vulnerabilità, perché un agente può scrivere autenticazione sbagliata, SQL injection, XSS, controlli insufficienti, segreti lasciati nel repository, API mal protette e dipendenze vulnerabili. Un'applicazione su misura mal progettata può essere molto meno sicura di un WordPress ben mantenuto.

La differenza riguarda soprattutto la correlazione del rischio. Se viene scoperto uno zero day in un plugin presente su 5 milioni di installazioni, un attaccante ha un incentivo economico enorme a costruire un exploit automatico: scrive una volta l'attacco, scansiona Internet e riutilizza lo stesso exploit milioni di volte. Questo fenomeno è ben conosciuto nella ricerca sulla monocultura del software, dove utilizzare la stessa implementazione su un numero enorme di sistemi crea il rischio di guasti correlati, perché una singola vulnerabilità può essere condivisa dall'intera popolazione. La diversità del software può ridurre questa capacità di propagazione, anche se non garantisce automaticamente maggiore sicurezza.

L'eterogeneità potrebbe diventare una forma di difesa

Ed è qui che l'AI introduce una conseguenza particolarmente interessante. Se in futuro dieci milioni di siti non saranno dieci milioni di istanze della stessa piattaforma, ma dieci milioni di piccoli sistemi generati specificamente per il proprio scopo, uno zero day diventa potenzialmente molto meno scalabile. Non meno pericoloso per il singolo sistema vulnerabile, ma molto meno riutilizzabile.

Attaccare un percorso come /wp-content/plugins/nome-plugin/vulnerable.php è estremamente conveniente se sai che quell'URL e quella funzione esistono identici su centinaia di migliaia di server, e diventa molto meno conveniente se ogni applicazione ha struttura, endpoint e implementazione differenti, perché l'attaccante deve spendere più risorse per capire il singolo bersaglio. In termini economici cambia il rapporto: un exploit che valeva milioni di vittime può diventare un exploit che raggiunge un insieme molto più piccolo di vittime. È una differenza enorme.

Ma non eliminerà le monoculture completamente. Se milioni di siti generati dall'AI utilizzeranno tutti lo stesso framework JavaScript, la stessa libreria di autenticazione, lo stesso servizio cloud o la stessa dipendenza npm vulnerabile, il problema semplicemente si sposterà di livello. L'obiettivo quindi non dovrebbe essere personalizzare tutto, ma ridurre le dipendenze inutili e condividere soltanto ciò che vale davvero la pena condividere.

Il vantaggio forse più importante dell'AI: sviluppare solo ciò che serve

Questo è il vero ribaltamento. Nel vecchio modello compravamo una piattaforma generalista e poi cercavamo di adattarla al nostro problema, mentre nel nuovo modello possiamo partire dal problema e generare soltanto il software necessario a risolverlo.

Supponiamo che il sito abbia bisogno di un form che raccolga nome ed email, controlli i dati, li invii a HubSpot, mandi una notifica e restituisca un messaggio. Con WordPress potremmo installare un plugin per i form, un componente aggiuntivo per il CRM, un plugin SMTP, eventualmente Zapier, e poi configurazioni e aggiornamenti. Con sviluppo diretto possiamo avere una funzione da poche decine o centinaia di righe che invia i dati direttamente all'API necessaria.

E se domani cambia il requisito, dici all'agente:

Prima di inviare il lead controlla il dominio dell'email, assegna il paese in base al prefisso telefonico e invialo a questa pipeline quando l'azienda ha più di 50 dipendenti.

Il software viene modificato, e non devi aspettare che esista il plugin giusto.

Le integrazioni diventano molto più semplici

Una delle ragioni storiche per scegliere WordPress era "esiste già il plugin per X". Ma nell'era degli agenti AI la domanda potrebbe diventare "X ha un'API?". Se la risposta è sì, un agente può leggere la documentazione, implementare OAuth, creare il webhook, costruire il mapping dei dati, gestire gli errori e integrare direttamente il servizio, che si tratti di CRM, ERP, Stripe, un gestionale proprietario, sistemi di prenotazione, un database aziendale, newsletter, automazioni, AI, ricerca, storage o servizi cloud. L'integrazione non deve necessariamente passare attraverso un adattatore commerciale sviluppato da una terza parte, e questo elimina un ulteriore strato.

Anche il concetto di manutenzione cambia

Oggi la manutenzione di molti siti consiste principalmente nel mantenere viva la piattaforma, cioè aggiornare componenti, controllare compatibilità, rinnovare licenze, pulire database, monitorare plugin e fare backup prima dell'ennesimo update. In un'architettura nativa per l'AI il lavoro potrebbe spostarsi verso qualcosa di diverso, cioè repository Git, dipendenze ridotte, test automatici, vulnerability scanning, deploy automatici, rollback, infrastruttura dichiarativa e osservabilità.

E soprattutto l'agente potrebbe comprendere il progetto nella sua interezza. Non più "installa plugin X", ma qualcosa come:

Questo progetto ha una dipendenza vulnerabile. Aggiornala, correggi le rotture, esegui i test e mostrami cosa è cambiato.

È una forma completamente diversa di gestione del software.

E sul fronte energetico?

Anche qui serve equilibrio. Generare codice con modelli AI ha un costo computazionale significativo, quindi sarebbe scorretto raccontare l'AI come una tecnologia intrinsecamente green. Ma bisogna separare il costo della costruzione dal costo dell'esecuzione permanente.

Spendere capacità computazionale una volta per generare e aggiornare un'applicazione molto semplice può avere senso se quella applicazione, durante milioni di visite successive, richiede pochissima elaborazione. È lo stesso principio della compilazione, spendiamo calcolo prima per fare meno lavoro dopo. Per siti prevalentemente informativi, spostare il sistema verso file statici, CDN ed elaborazione su richiesta significa potenzialmente ridurre drasticamente CPU, RAM e infrastruttura necessaria durante tutta la vita del progetto. Moltiplicato per milioni di siti, non è una questione marginale.

Quindi WordPress è morto?

No, e probabilmente sarebbe ingenuo sostenerlo. WordPress possiede vantaggi enormi che non scompaiono con un prompt, cioè vent'anni di ecosistema, milioni di utenti, hosting ovunque, una comunità globale, workflow editoriali maturi, gestione utenti, revisioni, permessi, media library, API, plugin, WooCommerce, multilingua ed esperienza consolidata. Inoltre WordPress stesso sta evolvendo e può incorporare sempre più AI. E soprattutto esistono problemi nei quali un CMS è realmente la soluzione corretta.

Quando WordPress continuerà ad avere perfettamente senso

Un grande magazine con cinquanta redattori ha bisogno di un sistema editoriale. Un'organizzazione con ruoli, approvazioni, bozze, revisioni e migliaia di contenuti ha bisogno di un backend strutturato. Un negozio online articolato potrebbe trovare nell'ecosistema WooCommerce un vantaggio enorme. E un'azienda che ha già centinaia di migliaia di contenuti su WordPress non ha alcun motivo razionale per riscrivere tutto soltanto perché oggi esistono gli agenti AI.

In questi casi WordPress può continuare ad avere moltissimo senso, magari non necessariamente come piattaforma monolitica tradizionale. Potrebbe diventare un content repository affiancato da un frontend generato e ottimizzato dall'AI, cioè un'architettura headless o ibrida, nella quale il CMS continua a fare ciò che sa fare bene, gestire contenuti e persone, mentre il frontend viene realizzato nel modo più efficiente possibile.

Dove invece il cambiamento potrebbe essere brutale

Landing page, siti aziendali, portfolio, siti di ristoranti, siti di hotel, micrositi, siti evento, presentazioni di prodotto, cataloghi relativamente semplici, siti personali e piccole applicazioni verticali. È difficile giustificare tecnicamente una piattaforma generalista composta da core, database, tema e dieci plugin quando un agente può costruire esattamente quello che serve. Qui WordPress non compete più soltanto con Wix, Webflow, Squarespace o Shopify, compete con una cosa completamente nuova, il software generato su richiesta.

E questa volta il software su misura potrebbe costare meno del template

Storicamente lo sviluppo su misura era la soluzione premium, e WordPress era economico perché riutilizzava il lavoro fatto da altri. Un tema da 70 euro era più conveniente di una settimana di frontend developer, e un plugin da 100 euro era più conveniente dello sviluppo di una funzione dedicata. Economicamente era imbattibile.

L'AI può invertire questa equazione. Se costruire una funzione specifica richiede pochi minuti di lavoro agentico, perché installare un plugin da 200.000 righe che risolve altri cinquanta problemi che non abbiamo? Se generare il frontend richiede poche iterazioni, perché comprare un tema generalista e poi combattere contro le sue opzioni? E se modificare il software significa descrivere ciò che vogliamo, perché mantenere un page builder soltanto per evitare di toccare il codice? È qui che l'intero paradigma inizia a incrinarsi.

Dal nascondere il codice all'eliminare l'astrazione

Negli ultimi dieci anni l'industria ha celebrato il no code. Ma il no code non eliminava realmente il codice, lo nascondeva, perché dietro ogni pulsante continuavano a esserci framework, database, workflow, runtime e piattaforme.

L'AI suggerisce qualcosa di diverso, non soltanto nascondere la complessità ma generare direttamente la soluzione più semplice compatibile con il problema. Potremmo chiamarlo sviluppo senza astrazioni, non perché non esistano più astrazioni, ma perché non siamo più obbligati ad adottare una gigantesca astrazione generalista per evitare di programmare. L'agente può programmare per noi.

La vera rivoluzione potrebbe essere la sottrazione

Per anni l'evoluzione del Web è stata soprattutto additiva, cioè più framework, più librerie, più plugin, più API, più microservizi, più layer, più dashboard e più middleware. L'AI potrebbe produrre un effetto apparentemente opposto, non necessariamente più software ma meno software, software più specifico, meno dipendenze, meno dati inutili, meno runtime, meno database, meno aggiornamenti, meno componenti da mantenere e meno superficie d'attacco condivisa.

E forse questa sarà una delle conseguenze più profonde dell'intelligenza artificiale nello sviluppo software: non permetterci di costruire sistemi sempre più complessi, ma permetterci finalmente di costruire sistemi semplici senza che la semplicità costi una fortuna.

WordPress ha ancora senso, quindi?

Sì, ma non più automaticamente. Per vent'anni la domanda tipica di un nuovo progetto è stata "quale CMS utilizziamo?". Tra qualche anno potrebbe sembrare una domanda strana, e la domanda potrebbe diventare "abbiamo davvero bisogno di un CMS?". In moltissimi casi la risposta potrebbe essere no.

Non perché WordPress sia improvvisamente diventato cattivo software, ma perché potrebbe venir meno il compromesso che lo ha reso dominante. Abbiamo accettato complessità computazionale, database, plugin, aggiornamenti, compatibilità e dipendenze perché l'alternativa, sviluppare tutto direttamente, era troppo costosa. Quando un agente AI può sviluppare, modificare, testare e integrare il software attraverso il linguaggio naturale, quel costo crolla. E quando crolla il costo dello sviluppo su misura, crolla anche il valore economico di una parte delle astrazioni create per evitarlo.

WordPress potrebbe quindi non morire. Potrebbe succedergli qualcosa di più interessante, potrebbe smettere di essere la risposta di default e tornare a essere uno strumento da scegliere quando il problema richiede davvero un CMS, invece della piattaforma installata automaticamente ogni volta che qualcuno pronuncia la parola "sito Web".

Ed è probabilmente un bene, per WordPress, per gli sviluppatori, per la sicurezza, per l'infrastruttura e, soprattutto, per un Web che dopo vent'anni di stratificazioni potrebbe finalmente iniziare a chiedersi non soltanto "cosa possiamo aggiungere?" ma anche "cosa possiamo eliminare?".