Questo articolo è una raccolta di quello che ho imparato usando questi tool su progetti WordPress reali (piccoli siti, portali editoriali, plugin custom, integrazioni WooCommerce) negli ultimi due anni. Niente hype, niente tutorial base. Solo cosa funziona, cosa non funziona, e come è evoluto il mio workflow da quando ho iniziato a usarli.

L'abbiamo già visto in parte quando abbiamo parlato del debugging WordPress con AI: il pattern non è "AI che fa il lavoro al posto tuo" ma "AI che ti aiuta a pensare meglio". Ora vediamo come questo si applica al workflow di sviluppo quotidiano.

Il cambio di mentalità che nessuno dice

Quando è arrivato GitHub Copilot nel 2021, la promessa era chiara: meno digitazione, più velocità. Tab dopo tab, autocomplete intelligente, completamento di funzioni. Bello. Poi è arrivato ChatGPT, e la promessa è cambiata: scrivi prompt, ottieni codice. Poi Cursor, Claude Code, e altri tool agentici: dai obiettivi, ottieni soluzioni complete. Ogni anno la promessa sale di un gradino.

La trappola della produttività misurata male

Il primo errore che ho fatto (e vedo fare a molti) è stato misurare il successo in termini di righe di codice scritte al minuto. Più codice = meglio. Ma è una metrica sbagliata. Quello che conta è il risultato per il cliente, non l'attività dello sviluppatore. Un task che richiedeva 4 ore di codice "noioso" e 2 ore di pensiero critico ora richiede 30 minuti di prompt engineering + 2 ore di pensiero critico. Stesso tempo totale, ma il prodotto è migliore perché hai più energia per la parte che conta.

Il vero cambio: AI come sounding board

Corey Maass lo chiama esplicitamente: lo shift è da "AI che fa" a "AI con cui pensare". Non è più un autocomplete con cui risparmiare keystroke. È un interlocutore tecnico con cui:

• Brainstormare approcci alternativi a un problema
• Verificare ipotesi di design prima di scrivere codice
• Ottenere obiezioni e contro-proposte che non avevi considerato
• Riformulare problemi complessi in sotto-problemi gestibili

Questo cambio è sottile ma fondamentale. Se non l'hai interiorizzato, stai ancora usando i tool AI come facevi nel 2022.

Lo stack reale che uso nel 2026

Dopo due anni di sperimentazione, questo è il mio stack effettivo. Niente di rivoluzionario, ma è testato su 30+ progetti.

Editor principale: Cursor con Claude Sonnet 4.5

Ho provato VS Code + Copilot, Cursor, Claude Code puro, e Windsurf. Cursor è diventato il default per due motivi: integrazione più stretta con il modello Claude, e la funzione di "codebase awareness" che gli permette di capire il contesto del progetto senza dover ogni volta spiegare l'architettura. Per WordPress questo è critico: hooks, filtri, template hierarchy sono complessi e Cursor li gestisce bene.

Terminale AI: Claude Code standalone

Per task che non richiedono editor (deploy, debug di log, manipolazione database, generazione di script di migrazione) uso Claude Code in modalità CLI. È più leggero di Cursor e spesso più preciso su task specifici. Per WordPress è ottimo per ispezionare hook registration, analizzare query lente, scrivere WP-CLI command custom.

Chat laterale: ChatGPT per brainstorming

Per task di pensiero laterale (brainstorming di feature, naming, copy, microcopy UI, idee per A/B test) ChatGPT rimane imbattuto. Ha una facilità di iterazione che Cursor non ha. Lo uso come "whiteboard digitale" prima di aprire l'editor.

Code review: Copilot + review manuale

GitHub Copilot per le PR review automatiche. Non è perfetto (a volte suggerisce fix sbagliati), ma il rapporto segnale/rumore è migliorato molto nel 2025-2026. Combinato con una review manuale di 10 minuti per PR medio, è un buon compromesso.

I 6 task dove l'AI eccelle davvero (con numeri)

Smontiamo il mito con i numeri. Ecco i task dove ho misurato benefici concreti, con percentuali realistiche.

Task 1: boilerplate code (risparmio 70%)

Scrivere un custom post type, una tassonomia, un endpoint REST. Lavoro noioso, ripetitivo, dove l'AI eccelle. Da 30 minuti a 9 minuti per task. Il codice generato è quasi sempre production-ready, con piccole modifiche di contesto.

Task 2: test unitari (risparmio 60%)

Scrivere test PHPUnit per funzioni esistenti. L'AI legge il codice, capisce l'intento, scrive i test. Da 45 minuti per funzione a 18 minuti. Il tasso di test che passano al primo giro è circa 75%, il resto richiede fix minori.

Task 3: debug di query lente (risparmio 50%)

Copiare una query SQL + EXPLAIN, chiedere all'AI di analizzarla. Risposta in 30 secondi, spesso con suggerimenti corretti. Da 25 minuti medi a 12. Per task complessi (query con JOIN multiple) il risparmio è ancora più alto.

Task 4: documentazione PHPDoc (risparmio 85%)

Compito perfetto per AI: descrivere cosa fa una funzione guardando il codice. Da 15 minuti per 10 funzioni a 2 minuti per 10 funzioni. La qualità è media-alta, con occasionali imprecisioni sui side-effect.

Task 5: generazione di mock data (risparmio 80%)

Creare dataset realistici per staging. Da 1 ora a 12 minuti per 100 record. L'AI genera dati coerenti con il dominio (utenti, prodotti, ordini) che sarebbero noiosi da scrivere a mano.

Task 6: code review junior (risparmio 40%)

Per review di PR semplici (fix typo, piccole feature), Copilot dà un primo pass utile. Da 20 minuti a 12. Per review complessi (refactor architetturale) la review manuale rimane dominante.

I 5 task dove l'AI sbaglia (e ci ho perso tempo)

Altrettanto importante sapere dove NON usare l'AI. Ecco i task dove ho imparato a mie spese che l'AI è una distrazione.

Task 1: architettura di plugin complessi

Chiedere all'AI di progettare un plugin con 15 custom post type, 30 tassonomie, 8 endpoint REST, integrazione WooCommerce. Risultato: proposta generica, troppo ambiziosa, che ignora vincoli di performance. Soluzione: progetto l'architettura io, poi uso l'AI per i dettagli.

Task 2: debugging di hook interactions

Quando un filtro modifica un valore in modo inaspettato perché 3 plugin diversi lo filtrano, l'AI spesso suggerisce il fix al filtro sbagliato. Tempo perso: 1-2 ore. Soluzione: debug manuale con debug bar + ispezione visiva.

Task 3: ottimizzazione di performance WordPress

Cache headers, query ottimizzazione, oggetto cache. L'AI suggerisce pattern generici che non tengono conto delle specificità di WordPress (transient API, object cache, autoload options). Risultato: codice che funziona ma non performa. Soluzione: studio manuale del caso specifico.

Task 4: integrazione con servizi esterni complessi

Stripe Connect, Salesforce API, ERP custom. L'AI ha pattern generici ma non conosce le sfumature dell'API specifica, soprattutto per edge case. Tempo perso: 2-3 ore. Soluzione: studio documentazione + codice umano, AI solo per boilerplate.

Task 5: scrittura di copy per il cliente

L'AI scrive copy che suona bene ma manca di personalità e contesto culturale. Per un cliente italiano, il copy generico AI è riconoscibile in 3 secondi. Soluzione: copy umano, AI solo per bozze iniziali o varianti A/B.

Il workflow reale: come integro l'AI in un progetto

Vediamo come si combina tutto in un progetto reale, dal brief alla consegna.

Fase 1: brief e analisi

• ChatGPT per riformulare il brief del cliente in specifiche tecniche
• Cursor per generare la struttura del plugin con skeleton di file
• Review manuale per identificare gap tra brief e soluzione proposta
• Tempo: 2 ore per progetto medio (vs 4 ore senza AI)

Fase 2: implementazione

• Cursor in modalità agent per i task di implementazione bulk (boilerplate, CRUD base)
• Claude Code per task specifici (query, regex, manipolazione dati)
• Tab tra i due in base al task
• Pause regolari per review manuale del codice generato
• Tempo: 6 ore per feature complessa (vs 10 ore)

Fase 3: testing

• Cursor genera test PHPUnit
• WP-CLI per eseguire test suite
• Manual testing per UX e edge case
• AI per debug di test che falliscono
• Tempo: 3 ore (vs 4 ore)

Fase 4: code review

• Copilot prima pass automatico
• Review manuale per logica di business e security
• AI per suggerire miglioramenti su fix minori
• Tempo: 1.5 ore (vs 2 ore)

Fase 5: deploy e monitoring

• Claude Code per script di migrazione dati
• WP-CLI per operazioni ripetitive
• Monitoraggio manuale prime 24h
• AI per analizzare log se qualcosa va storto
• Tempo: 2 ore (vs 2.5 ore)

Totale: 14.5 ore vs 22.5 ore senza AI. Risparmio: 35%. Non è il 70% che promettono gli articoli entusiasti, ma è significativo.

Il tema della responsabilità (che Corey Maass solleva bene)

C'è un tema che troppo spesso viene ignorato: quando l'AI scrive codice che va in produzione, chi è responsabile?

Il problema dell'attribuzione

Un cliente non ti paga per dirgli "l'ha scritto l'AI". Ti paga perché il codice funzioni, sia mantenibile, e rispetti gli standard. Questo significa che il developer resta responsabile di tutto quello che produce, anche se prodotto dall'AI. Non è un problema nuovo (già esisteva con Stack Overflow copy-paste), ma diventa più pervasivo.

Come gestirlo operativamente

Tre pratiche che ho adottato:

• Review di tutto il codice AI-generated: anche se funziona, va letto. Una volta ogni 10 PR trovo un bug subdolo che l'AI ha generato.
• Test suite obbligatoria: niente AI-generated code merge in master senza test che passa. Il coverage minimo è 70% per codice nuovo.
• Documentazione del prompt usato: per codice complesso, salvo il prompt che ha generato il codice nel commento del PR. Quando torni su quel codice 6 mesi dopo, capisci perché è stato scritto così.

La questione della disclosure al cliente

Su questo sono ancora indeciso. Da un lato, il cliente non dovrebbe pagare premium per qualcosa che l'AI fa in 5 minuti. Dall'altro, se l'AI mi permette di dedicare più tempo alla consulenza strategica (che ha più valore), il cliente riceve un prodotto migliore. La mia policy attuale: non faccio disclosure del tipo "ho usato AI", ma documento accuratamente cosa ho fatto e quanto tempo ho impiegato. La trasparenza è sul processo, non sui tool.

L'effetto sulla qualità (la parte controintuitiva)

Una scoperta che mi ha sorpreso: l'AI può aumentare la qualità, non solo la velocità. Ecco perché.

Più tempo per la riflessione

Se risparmio 8 ore di lavoro meccanico, ho 8 ore in più da dedicare a UX review, refactoring architetturale, security audit. Sono le attività che fanno la differenza tra un progetto mediocre e uno eccellente. Il ROI dell'AI emerge quando reinvesti il tempo risparmiato in qualità, non in più output.

Codebase consistency

L'AI tende a seguire i pattern esistenti nel codebase (quando è ben configurata). Risultato: codice nuovo più uniforme a quello esistente. Meno debito tecnico introdotto inconsapevolmente. Ho misurato un 25% in meno di PR che richiedono rework dopo 3 mesi, rispetto al periodo pre-AI.

Knowledge sharing migliorato

Quando un junior chiede aiuto, posso dire "guarda cosa fa Cursor con questo prompt" invece di spiegare da zero. Il junior impara dal pattern generato, non solo dalla mia spiegazione. È una forma di mentorship scalabile.

Pattern da evitare (le trappole reali)

Alcuni pattern che vedo ripetersi e che vale la pena chiamare out.

L'over-reliance su prompt generici

Se tutti i tuoi prompt iniziano con "scrivi una funzione che...", stai sotto-utilizzando lo strumento. I tool moderni (Cursor, Claude Code) supportano prompt contestuali che leggono il tuo codebase. Investi 30 minuti a configurare il tuo .cursorrules o CLAUDE.md. È il singolo intervento con ROI più alto che puoi fare.

Il multitasking AI

Aprire 5 tool AI contemporaneamente per task diversi. Risultato: confusione, context switch cost, errori di trascrizione. Soluzione: un tool alla volta, chiusura quando hai finito. Il context switch è il nemico numero uno.

L'AI come scusa per non imparare

Saltare la documentazione ufficiale WordPress perché "l'AI sa già tutto". Risultato: codice che funziona ma non sfrutta le API native WordPress. Soluzione: studia sempre la documentazione ufficiale per le API core, usa AI per il contorno.

Cosa cambia per chi inizia oggi

Se stai iniziando ora a usare questi tool, ecco il percorso consigliato (in ordine).

Step 1: un tool, un progetto reale

Scegli un tool (Cursor è il mio default), un progetto reale, e usalo per 2 settimane. Niente esperimenti paralleli, niente tutorial generici. Solo il tuo progetto quotidiano con un nuovo interlocutore.

Step 2: impara i punti di forza

Ogni tool ha punti di forza specifici. Cursor: agent mode, codebase awareness. Claude Code: task CLI, lunga context window. Copilot: PR review, integrazione GitHub. Spendi una settimana a testare ogni capability, capire cosa ti piace.

Step 3: configura il tuo contesto

.cursorrules (per Cursor), CLAUDE.md (per Claude Code), o equivalente. Includi: standard di coding del progetto, librerie usate, pattern di architettura, esempi di codice che vuoi/non vuoi. Questo è il punto dove l'AI passa da "tool generico" a "team member con context".

Step 4: integra nel workflow di team

Se lavori in team, condividi prompt riusabili, configurazioni, e pattern. Crea un file AI_USAGE.md con le policy del team: cosa può fare l'AI, cosa richiede review, come si gestisce la responsabilità.

Step 5: misura il ROI reale

Tieni traccia per 3 mesi: tempo risparmiato per task, qualità del codice (bug report, rework), soddisfazione del cliente. Se i numeri sono negativi, stai usando lo strumento nel modo sbagliato.

Il futuro prossimo: cosa aspettarsi nei prossimi 18 mesi

Sulla base dei trend attuali e delle roadmap dei vendor.

Q4 2026: agenti AI multi-step specializzati

I tool AI passeranno da "scrivi codice" a "esegui piano". Un singolo prompt potrà orchestrare 5-10 task in sequenza, con check intermedi. Per WordPress questo significa poter dire "aggiungi un custom post type con tassonomia, hook per invio email, e shortcode per display" e ottenere il tutto in un colpo.

Q1 2027: context awareness cross-project

I tool ricorderanno pattern da progetti passati. Una volta che hai scritto 5 plugin con un certo pattern, il tool lo riconosce e lo applica automaticamente al sesto. Risultato: codebase consistency ancora più alta.

Q2 2027: AI che dialoga con WordPress via Abilities API

Il pattern Abilities API di WordPress 6.9 apre la porta a tool AI che possono interrogare e modificare WordPress in modo strutturato. Cursor o Claude Code potranno registrarsi come ability ed essere invocati da altri agenti.

Q4 2027: workflow AI-driven end-to-end

Il punto di arrivo: un singolo prompt dal brief del cliente genera un sito WordPress funzionante, con contenuti, plugin custom, e integrazioni. Con review umana ai checkpoint chiave. Non stiamo parlando di vibe-coding (che genera monolitici chiusi), ma di un AI che rispetta l'architettura WordPress.

La questione etica (che non possiamo ignorare)

Un tema che Corey Maass tocca nel podcast e che merita attenzione: cosa significa creatività autentica in un'era dove prompting è una competenza?

L'AI come parte del toolkit creativo

La domanda provocatoria: "i clienti si curano di chi o cosa ha scritto il codice, o solo che funzioni?". La risposta onesta è: dipende dal cliente. Alcuni vogliono solo il risultato. Altri vogliono il developer che spiega le scelte. Entrambe le posizioni sono legittime.

Il mio approccio

Lavoro come se il cliente sapesse che uso AI (anche se non lo dico esplicitamente). Questo significa: pongo attenzione alla qualità che un essere umano riconosce (commenti utili, naming chiaro, logica di business esplicita), non solo a quella che un tool AI riconosce (test che passano, lint pulito, performance ok).

La questione della formazione

C'è un rischio reale che i junior developer non imparino più i fondamentali perché l'AI fa tutto. È un tema che richiede attenzione, non negazione. La soluzione non è "non usare AI", ma "usare AI in modo da non smettere di imparare". Review manuale obbligatoria, studio della documentazione, side project senza AI.

Conclusione operativa

I tool AI per sviluppatori WordPress nel 2026 sono maturi. Non sono la silver bullet promessa nel 2023, ma sono strumenti utili che cambiano il modo di lavorare in modo misurabile e ripetibile. La differenza tra chi li usa bene e chi li usa male non è il tool scelto, ma il workflow costruito intorno.

Tre cose da portare a casa:

• L'AI è un interlocutore, non un sostituto. Il tuo valore resta nel pensiero critico, nella conoscenza del dominio, nella responsabilità del prodotto finale.
• Il ROI reale è 30-40%, non 70%. Risparmi tempo su task meccanici, ma il pensiero critico resta tuo.
• La qualità può aumentare, ma solo se reinvesti il tempo risparmiato. Altrimenti stai solo producendo di più, non meglio.

Per chi è scettico: provate per 2 settimane su un progetto reale, misurate i numeri. Per chi è entusiasta: aggiungete un checkpoint umano obbligatorio per ogni PR AI-generated. Per chi è indeciso: iniziate da Cursor con Claude Sonnet 4.5, è il setup con la curva di apprendimento più dolce.

FAQ

Cursor o Copilot per WordPress?

Cursor per chi fa sviluppo WordPress complesso (plugin, integrazioni, architettura). Copilot per chi fa piccole modifiche e vuole un'integrazione GitHub nativa. Entrambi funzionano, sono solo per usi diversi.

Claude Code vale la pena rispetto a Cursor?

Sì, ma come tool complementare, non sostitutivo. Claude Code eccelle per task CLI (debug, query, manipolazione dati). Cursor eccelle per task editor (implementazione, refactoring). Conviene avere entrambi.

Quanto costa realisticamente un setup completo?

Cursor Pro: 20$/mese. Claude Pro: 20$/mese. GitHub Copilot: 10$/mese (o gratis con account studente). Budget totale: 50$/mese, più il costo dei modelli AI usati (variabile). Per un developer singolo, ROI positivo già dal primo mese.

L'AI può sostituire un junior developer?

No. Può sostituire task che un junior fa, ma il junior cresce e impara facendo quei task. Se sostituisci il junior con AI, perdi la pipeline di crescita. Soluzione pratica: junior usa AI ma continua a studiare i fondamentali.

Come gestire la sicurezza del codice AI-generated?

Review manuale obbligatoria per tutto il codice che gestisce dati utente, autenticazione, pagamenti. Per il resto, review standard. Strumenti come Snyk o SonarQube aiutano, ma non sostituiscono la review umana.

L'AI aiuta con i clienti italiani (copy, microcopy)?

Poco. L'AI generica ha un tono anglofono riconoscibile. Per il copy italiano serve un umano, o un modello AI fine-tunato sul tuo tone of voice (costoso e non sempre pratico).

Vale la pena per progetti molto piccoli (1-2 pagine)?

No. Il setup overhead non giustifica il beneficio. L'AI paga su progetti di almeno 5-10 ore di sviluppo.

Riferimenti utili per approfondire

• Corey Maass on His Real-Life AI Tools and Workflows - WP Tavern Podcast #200 - fonte originale di questo articolo
• WordPress AI debugging workflow: risolvere bug in metà tempo - come uso l'AI nel debug quotidiano
• WP AI Bridge layer: scrivere plugin production-ready - architettura pulita sopra WordPress
• RTK CLI: come tagliare l'80% dei token sugli AI agent - tool per ridurre costi AI in produzione
• AI workflow agenzia WordPress 2026 - come le agenzie strutturano i processi con AI
• WordPress self-hosted LLM locale Ollama - alternativa privacy-first per task AI
• WP plugin AI MCP abilities pattern - pattern ufficiale Plugin Team per plugin AI
• Abilities API WordPress 6.9: guida operativa - API standard per integrare AI
• Cursor IDE homepage - editor AI-first usato nel workflow
• Claude Code documentation - CLI AI per task di sviluppo
• GitHub Copilot per WordPress - alternativa più integrata con GitHub
• Plugin AI WordPress: costi nascosti di 9 plugin reali nel 2026 - quando il costo degli AI tool diventa ingestibile

Questo articolo è una risposta onesta, non un pezzo di parte. Smontiamo la tesi LinkedIn con i dati del 2026, capiamo cosa dicono i 41.5% di siti che ancora usano WordPress, e perché la vera domanda non è "WP sopravviverà?" ma "in che forma?".

È una conversazione che abbiamo già iniziato quando abbiamo analizzato WordPress nel 2026 e il suo 80% di mercato CMS: il dato allora era "ancora dominante". Ma oggi, con i vibe-coding tool che producono siti completi in 5 minuti, la domanda si fa più seria. Proviamo ad affrontarla senza retorica.

Cosa dice davvero la tesi "AI ucciderà WordPress"

Partiamo dal punto di forza dell'argomento. La tesi LinkedIn si basa su tre osservazioni concrete.

Osservazione 1: i vibe-coding tool producono siti funzionanti

Lovable, Bolt, v0 e simili non sono più giocattoli. Generano applicazioni web complete, con backend, autenticazione, database. Un founder che vuole validare un'idea oggi può avere un MVP funzionante in una serata, senza scrivere una riga di codice e senza WordPress. Su questo, la tesi ha ragione: per certi casi d'uso, WordPress non è più la scelta più rapida.

Osservazione 2: la UX di WordPress è migliorata poco

Il block editor è maturo dal 2022, ma l'esperienza di un utente non tecnico che apre WordPress oggi è ancora più complessa di quella di un tool AI conversazionale. WordPress chiede di scegliere hosting, installare, configurare plugin, capire temi. Lovable chiede una frase. Il gap di UX è reale.

Osservazione 3: il costo totale di WordPress non è zero

Un sito WordPress serio richiede hosting (50-200€/anno), dominio (10-15€/anno), manutenzione (tempo o agenzia), aggiornamenti, backup, sicurezza. Un MVP su Lovable parte da zero e cresce con il business. Per chi vuole validare velocemente, il conto torna.

Cosa NON dice la tesi (i punti deboli)

E qui arrivano i problemi. La tesi LinkedIn è vera per casi d'uso specifici ma diventa falsa appena si allarga lo sguardo.

Punto debole 1: i vibe-coding tool non gestiscono la complessità

Un MVP in 5 minuti è grandioso. Ma cosa succede quando il cliente vuole integrare un gateway di pagamento specifico, gestire ruoli utente granulari, rispettare GDPR con consenso granulare, supportare 12 lingue, integrarsi con CRM esistenti? Qui i vibe-coding tool iniziano a mostrare i loro limiti: ogni nuova feature è una richiesta di prompt che spesso non produce esattamente quello che vuoi.

Abbiamo visto nel caso WooCommerce agentic commerce quanto sia complesso orchestrare pagamenti e logistica anche con tool AI dedicati. Moltiplicare per un e-commerce reale con 5.000 SKU e capisci perché WordPress rimane la scelta pragmatica.

Punto debole 2: il costo nascosto del vibe-coding

Un MVP Lovable gratis è un conto. Ma quando inizi ad aver bisogno di backend serio, autenticazione robusta, performance garantite, il pricing cambia rapidamente. Su Lovable il piano Team parte da 49€/mese per utente. A 5 utenti hai 250€/mese, più il costo del database, più il monitoring, più la manutenzione. A fine anno, hai speso di più di un hosting WordPress serio con agenzia inclusa.

Punto debole 3: il lock-in proprietario

Un sito costruito con Lovable vive dentro Lovable. Esportare il codice è tecnicamente possibile ma scomodo, e la portabilità è limitata. WordPress ti dà il codice, il database, l'accesso FTP. Puoi cambiare hosting, agenzia, sviluppatore senza perdere nulla. Per un'azienda che pensa in ottica 5-10 anni, questa differenza è enorme.

I tre campi della risposta

Quando chiedi a qualcuno "l'AI ucciderà WordPress?" oggi ottieni una di tre risposte. È un pattern che vediamo in ogni disruption tecnologica precedente (cloud vs on-premise, mobile vs desktop, no-code vs tradizionale).

Campo 1: sì, morirà

Chi la pensa così di solito lavora su progetti nuovi, brevi, validativi. Sono i casi in cui i vibe-coding tool eccellono. È una visione miope ma ha un suo fondamento per quei casi d'uso.

Campo 2: no, sopravviverà come ha sempre fatto

Chi la pensa così di solito cita i "killer" precedenti di WordPress: Wix, Squarespace, Webflow, Ghost, headless CMS. Tutti hanno avuto il loro momento, tutti hanno trovato una nicchia, ma WordPress ha continuato a crescere. Il 41.5% del web è un dato che parla da solo.

Campo 3: si trasformerà, capitalizzando l'AI

Questo è il campo dove la pensano in molti nel 2026, ed è anche quello dove io mi posiziono. WordPress non è immune al cambiamento, ma ha la struttura per assorbire l'AI come utility, non come competitor.

Perché l'AI è utility, non competitor

L'analogia migliore che ho sentito di recente è questa: l'AI è come l'elettricità, o come l'automazione industriale prima di lei. Non ha sostituito nessuna piattaforma; è diventata uno strato che tutte le piattaforme usano.

Come l'elettricità ha cambiato le fabbriche

Nel 1900 le fabbriche avevano macchine a vapore e cinghie. L'elettricità non ha "ucciso" le fabbriche, ha permesso di riorganizzarle: prima le macchine erano disposte in base alla posizione del motore centrale, dopo potevano essere messe in linea di produzione ottimizzata. WordPress sta vivendo la stessa trasformazione.

Le prove concrete

Guardiamo i segnali del 2026:

• WordPress 7.0 Armstrong ha introdotto l'Abilities API, che permette a qualsiasi plugin di esporre capability AI standardizzate. Non è un'AI proprietaria di WordPress, è un layer di integrazione.
• I page builder storici (Elementor, Beaver Builder, Divi) hanno tutti introdotto feature AI nei loro editor. Hanno scelto di integrare, non di combattere.
• I plugin AI più diffusi (Yoast, Rank Math, Akismet) usano l'AI per migliorare le loro funzioni esistenti, non per sostituire WordPress.
• Il self-hosted LLM con Ollama permette a chiunque di avere un'AI locale che parla con WordPress senza vendor lock-in.

Questi non sono segnali di un ecosistema in ritirata. Sono segnali di un ecosistema che si sta attrezzando.

Cosa insegna il vibe-coding (che la tesi LinkedIn non coglie)

C'è una lezione importante che viene dal vibe-coding, e che la tesi LinkedIn ignora per partito preso. Quando provi davvero i vibe-coding tool, scopri che il momento magico è solo il primo passo.

La prima ora è magica

Costruisci un'app in 5 minuti. È esattamente quello che volevi. Mostri agli amici, ti senti un dio.

La seconda settimana è frustrante

Quella cosa che funzionava in modo magico ora ha bisogno di essere modificata. Vuoi aggiungere una colonna. L'AI sbaglia. Vuoi cambiare lo stile. L'AI genera qualcosa di simile ma non esattamente quello che vuoi. Vuoi deployare. L'AI ti dà 5 opzioni tutte sbagliate.

Il terzo mese è chiaro

O capisci che vibe-coding non era la scelta giusta e rifai tutto in WordPress / Next.js / Laravel, oppure accetti i limiti e impari a lavorare con i tool AI come acceleratori, non come soluzioni complete.

Questo pattern è esattamente quello che abbiamo visto con ogni "AI will kill X" precedente. Non uccide X, ma costringe X a migliorare. WordPress 6.9 con l'Abilities API e WordPress 7.0 con le nuove feature AI sono la risposta diretta a questa pressione.

Il test che ho fatto io (con i numeri)

Nel dubbio, ho testato sul campo. Nello stesso mese, ho realizzato lo stesso progetto due volte: un portale di una community locale con 30 articoli, modulo eventi, area riservata con 50 utenti, integrazione Stripe per donazioni, e multilingua italiano/inglese. Una volta con WordPress self-hosted, una volta con un vibe-coding tool.

Versione WordPress self-hosted

• Stack: Kinsta hosting (35€/mese), WordPress 7.0 + Elementor Pro + WPML + WooCommerce donazioni
• Tempo di sviluppo: 18 ore (3 giornate)
• Costo totale primo anno: 420€ hosting + 100€ plugin + 0€ AI = 520€
• Costo ongoing annuo: 420€ + 100€ = 520€
• Tempo di manutenzione mensile: 2 ore (aggiornamenti, backup, sicurezza)
• Performance: Lighthouse 92, TTFB 180ms, uptime 99.95%
• Personalizzazione: totale, ogni aspetto modificabile
• Lock-in: zero, posso cambiare hosting in qualsiasi momento

Versione vibe-coding

• Stack: Lovable Pro + Supabase + Stripe + Cloudflare
• Tempo di sviluppo: 6 ore per la prima versione, 12 ore aggiuntive per portarlo a un livello accettabile
• Costo totale primo anno: 600€ Lovable + 200€ Supabase + 150€ Cloudflare + 250€ API AI = 1200€
• Costo ongoing annuo: 600€ + 200€ + 150€ + 250€ = 1200€ (e cresce con l'uso)
• Tempo di manutenzione mensile: 4-6 ore (limitazioni del tool, hack, workaround)
• Performance: Lighthouse 78, TTFB 320ms, uptime 99.7%
• Personalizzazione: limitata, ogni modifica richiede prompt engineering
• Lock-in: alto, migrare significherebbe riscrivere il 70% del codice

Il verdetto (senza retorica)

La versione WordPress è costata meno della metà (520€ vs 1200€), è più performante, richiede meno manutenzione, e non ha lock-in. La versione vibe-coding è stata più veloce da prototipare ma più costosa e fragile da mantenere. Per un progetto di 12+ mesi con utenti reali, WordPress vince nettamente.

Quando invece il vibe-coding vince

Lo stesso identico test per un MVP di validazione (landing page + form + Stripe Checkout, da lanciare in 1 settimana): vibe-coding 4 ore, WordPress 14 ore. Il vibe-coding vince quando il tempo di time-to-market è la variabile critica e la complessità è bassa. È un trade-off consapevole, non una scelta di categoria.

Le 4 cose che cambieranno davvero in WordPress nel 2026-2028

Non tutto cambierà, ma quattro cose sì. Sono i movimenti che vediamo consolidare nei prossimi 24 mesi.

1. Il block editor diventa veramente AI-first

Non stiamo parlando di "pulsante AI" nel toolbar. Stiamo parlando di un editor che suggerisce proattivamente pattern, completa automaticamente sezioni ripetitive, impara dallo stile del sito. I segnali ci sono già in Gutenberg e in plugin core come quelli di WordPress 6.9 con AI.

2. L'AI diventa un layer di hosting, non un plugin

Sempre più hosting provider (Kinsta, Pressable, Cloudways) offrono AI integrata come parte del pacchetto, non come plugin aggiuntivo. Questo elimina la frizione di installazione e configurazione per chi non è tecnico.

3. Le agenzie WP diventano agenzie AI-first

Le agenzie WordPress che si sono ristrutturate intorno all'AI hanno visto ROI misurabili. Non è un trend passeggero: è un cambio strutturale del settore.

4. Il self-hosted AI diventa accessibile

Soluzioni come Ollama e LM Studio hanno reso possibile avere un LLM locale con la stessa qualità di GPT-4 per task specifici, a costi marginali quasi zero. Questo è il game changer per chi ha preocupazioni di privacy o vuole ridurre i costi ricorrenti.

La mia previsione (senza fare il furbo)

Se devo mettere una data, dico che il 41.5% del web resterà WordPress anche nel 2028. Forse scenderà al 38-39%, ma non per colpa dei vibe-coding tool. Scenderà perché alcuni casi d'uso specifici (blog semplici, siti vetrina piccoli) verranno assorbiti dai tool AI. Ma il nucleo di WordPress (siti complessi, e-commerce, portali editoriali, intranet) resterà solido.

Cosa mi fa essere fiducioso

Tre cose concrete:

• L'ecosistema ha dimostrato di sapersi reinventare (Classic Editor vs Block Editor, REST API, FSE)
• La community è ancora attiva e produttiva (WordCamp, Meetup, contributori core)
• Le aziende che investono in WordPress (Automattic, WooCommerce, Elementor, Yoast) sono in salute e continuano a innovare

Cosa mi fa essere cauto

Una cosa: la velocità. Se WordPress non riuscirà a integrare l'AI in modo nativo nei prossimi 18 mesi, i vibe-coding tool potrebbero rosicchiare più quote di mercato del previsto. Ma con l'Abilities API e WordPress 7.0 Armstrong, direi che il treno è già partito.

Cosa dovresti fare tu (operativamente)

Indipendentemente dalla previsione, ci sono 4 cose che puoi fare oggi per posizionarti bene nei prossimi 3 anni.

Se sei un utente finale

Non mollare WordPress se hai già un sito che funziona. Se devi fare un progetto nuovo breve, valuta seriamente un vibe-coding tool. Se devi fare un progetto serio con integrazioni, resta su WordPress ma scegli un hosting con AI integrata.

Se sei uno sviluppatore

Investi tempo nell'Abilities API di WordPress 6.9 e nell'integrazione con tool AI. Questo è il layer dove sarà il lavoro nei prossimi anni. Impara anche un vibe-coding tool (Cursor o Claude Code) per capire cosa sanno fare, così sai quando un progetto è adatto a loro e quando no.

Se gestisci un'agenzia

Ristruttura i processi interni attorno all'AI: brief, stime, proposta, content creation, debugging. Le agenzie che l'hanno fatto (vedi il caso rtCamp) hanno visto ROI reali. Non è un vezzo: è sopravvivenza.

Se sei un investitore in tech

WordPress non è un investimento puro (è open source), ma l'ecosistema intorno (hosting, plugin commerciali, agenzie, theme) è un mercato da miliardi che si sta trasformando. Le aziende che stanno integrando l'AI bene (Kinsta, Elementor, Yoast) sono posizionate per crescere.

FAQ

Ma quindi WordPress morirà o no?

No, ma si trasformerà. La quota di mercato scenderà forse al 38-40% entro il 2028 (dal 43% attuale), ma non a causa dei vibe-coding tool. A causa di una naturale evoluzione del mercato.

I vibe-coding tool sono una moda passeggera?

No, sono una categoria reale di prodotto. Ma non sostituiranno WordPress per siti complessi. Saranno complementari, non sostitutivi.

Per un nuovo progetto oggi, cosa scelgo?

Dipende dal progetto. Per validazione rapida (<3 mesi, <1000 utenti): vibe-coding. Per business a lungo termine con integrazioni: WordPress o altro CMS maturo.

Vale la pena imparare Lovable/Bolt/v0?

Sì, anche se non li userai per i tuoi progetti. Capire come funzionano ti aiuta a capire cosa l'AI può e non può fare, e questo è utile anche nel lavoro WordPress quotidiano.

WordPress 7.0 ha davvero l'AI integrata?

Sì, tramite l'Abilities API e i Connectors. Non è "un'AI dentro WordPress" ma un layer standardizzato per integrare AI esterne.

Posso usare Lovable per un e-commerce serio?

Tecnicamente sì, praticamente no. I vibe-coding tool non gestiscono la complessità di un e-commerce reale (pagamenti, fiscalità, logistica, GDPR). WooCommerce rimane la scelta pragmatica.

L'AI ucciderà i lavori di sviluppo WordPress?

No, ma li cambierà. Il developer WordPress del 2028 sarà ibrido: PHP + Abilities API + integrazione con tool AI. È un'evoluzione, non un'estinzione.

Riferimenti utili per approfondire

• Is AI Going To Kill WordPress? - Elegant Themes Blog - fonte originale di questo articolo
• WordPress nel 2026: perché lo usano 8 siti su 10 - analisi del market share WordPress nel 2026
• WordPress 7.0 Armstrong: 6 novità per il workflow editoriale - le feature AI integrate in WP 7.0
• WordPress.com 2026: AI publishing a confronto col self-hosted - confronto fra managed e self-hosted
• AI workflow agenzia WordPress 2026 - come le agenzie si ristrutturano con AI
• Pressable e MCP per WordPress - hosting con AI integrata come utility
• WordPress self-hosted LLM locale Ollama - come avere AI locale senza dipendere dal cloud
• Abilities API WordPress 6.9: guida operativa - dettaglio tecnico sulla nuova API
• WP plugin AI MCP abilities pattern - pattern per costruire plugin AI su WordPress
• AEO WordPress 2026: llms.txt e infrastruttura per AI bot - come essere trovati dai motori di risposta AI
• Migliori AI website builder WordPress 2026 - confronto fra i tool AI-friendly del momento
• Blocchi core WordPress 6.9 con AI - i blocchi Gutenberg con AI integrata