L'obiettivo è trasformare un prompt in un artefatto distribuibile, non un esercizio di stile. Vediamo come, passo dopo passo, integrando l'AI in un processo di ingegneria WordPress serio.

Perché serve un metodo, non solo un prompt

Scrivere "creami un plugin WordPress per gestire i preventivi" produce quasi sempre un file singolo, nessuna struttura di namespace, nessuna sanitizzazione, zero test. Il prompt è solo il punto di partenza: ciò che separa un plugin amatoriale da uno distribuibile è la pipeline.

Se hai già letto la nostra guida su come progettare, scrivere e ottimizzare un plugin WordPress con AI, sai che il vero vantaggio competitivo non è la velocità di generazione ma la capacità di ripetere il processo. Un metodo replicabile ti permette di passare da un'idea a un plugin pubblicato in una settimana, non in sei mesi. Lo stesso approccio si applica a temi WordPress complessi e a strumenti di sviluppo locale basati su Docker, dove la standardizzazione fa la differenza.

Le 9 fasi del metodo

Il flusso è sequenziale ma iterativo. Ogni fase produce un output concreto che alimenta la successiva.

Le prime quattro fasi sono dove l'AI dà il massimo vantaggio. Le ultime cinque sono dove il tuo giudizio tecnico diventa insostituibile.

Fase 1: requisiti come user story

Parti sempre da cosa deve fare il plugin, non da come. Una user story ben scritta è: "Come amministratore del sito, voglio poter associare una data di scadenza a ogni post, per visualizzare un countdown nel frontend".

L'AI trasforma questa story in criteri di accettazione, edge case e vincoli non funzionali (performance, compatibilità PHP 8.2+, i18n). Meglio scriverli prima di generare codice: ti serviranno per i test.

Ecco un prompt efficace per la fase 1:

# esempio codice
Agisci come product manager WordPress. Per la user story "[INCOLLA QUI]" genera: 5 criteri di accettazione, 3 edge case, requisiti di compatibilità (versione WordPress minima, PHP minimo, ruoli utente coinvolti), e una lista di hook WordPress da usare. Rispondi in italiano, formato Markdown.

Il risultato diventa l'input della fase 2. Niente codice ancora, niente scelte tecniche premature.

Fase 2: architettura prima del codice

Chiedi all'AI uno schema di alto livello: classi, interfacce, tabelle custom, hook e filtri, file e cartelle. Questo passaggio ti permette di valutare se la struttura proposta ha senso prima di investire tempo nella generazione del codice.

# esempio codice
Dato il plugin "[NOME]" con questi requisiti: [INCOLLA CRITERI DI ACCETTAZIONE]. Proponi: struttura directory, elenco classi con responsabilità, tabelle DB custom (se necessarie), hook WordPress da implementare (action e filter), e dipendenze esterne. Non scrivere codice, solo architettura.

Conferma o modifica lo schema. Una volta validato, diventa il brief per la generazione.

Fase 3: prompt design con vincoli espliciti

Il prompt di generazione è il momento più delicato. Includi sempre: contesto WordPress (versioni supportate, hook da usare), standard di codifica (PSR-12, WordPress Coding Standards), requisiti di sicurezza (sanitize, escape, nonce, capability), e formato di output (un file per volta, con header di plugin completo).

Un prompt ben strutturato produce codice quasi pronto. Uno vago produce spazzatura. Non lesinare sui dettagli.

Fase 4: generazione del codice candidato

Usa l'editor AI (Cursor, Continue.dev, GitHub Copilot) per generare il codice file per file. Chiedi esplicitamente commenti PHPDoc, gestione degli errori e un blocco register_activation_hook per il setup iniziale. La regola d'oro: genera, leggi, correggi, integra. Non accettare mai il primo output senza averlo capito.

Esempio di header plugin generato correttamente:

<?php
/**
 * Plugin Name:       Mio Plugin Preventivi
 * Description:       Gestione preventivi con scadenza e notifica email.
 * Version:           1.0.0
 * Requires at least: 6.5
 * Requires PHP:      8.2
 * Author:            Il Tuo Nome
 * License:           GPL v2 or later
 * Text Domain:       mio-plugin-preventivi
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit; // impedisce l'accesso diretto
}

Nota la riga ABSPATH: senza quella, chiunque può includere il file via URL e bypassare i controlli. È un dettaglio che l'AI spesso dimentica.

Fase 5: code review con PHPStan e AI

Passa il codice generato a PHPStan con il livello 5 o superiore. Poi chiedi all'AI di fare una review incrociata: "Trova bug logici, race condition, memory leak, gestione errori mancante". L'AI è sorprendentemente brava a trovare quello che tu, abbagliato dal codice appena scritto, non vedi.

Un comando utile per la review AI:

# analisi statica PHPStan sul plugin
vendor/bin/phpstan analyse --level=6 includes/ src/

Output tipico: errori di tipo mancanti, parametri non validati, return type inconsistenti. Tutto risolvibile prima ancora di aprire il browser.

Fase 6: checklist di sicurezza WordPress

WordPress ha un modello di sicurezza preciso. L'AI spesso lo ignora o lo applica in modo parziale. Ecco la checklist minima non negoziabile:

• Ogni form ha un wp_nonce_field e verifica wp_verify_nonce lato server.
• Ogni input utente passa per sanitize_text_field, absint, wp_kses_post o equivalente.
• Ogni output passa per esc_html, esc_attr, esc_url o wp_kses_post.
• Ogni capability check usa current_user_can( 'manage_options' ) (o capability più specifica).
• Le query SQL usano $wpdb->prepare() con placeholder %s, %d, %f.
• I file letti/scritti usano WP_Filesystem API, non file_get_contents diretto.

Se uno di questi punti manca, il plugin non è pronto per la distribuzione. Nessuna scusa, nessuna "lo aggiungo dopo".

Fase 7: test con PHPUnit e WP-CLI

Il modo più rapido per testare un plugin è usare wp-cli scaffold plugin-tests. Crea una struttura di test standard con PHPUnit e WP-CLI, inclusi test di integrazione. Scrivi test per ogni criterio di accettazione della fase 1. Se un criterio non ha un test, non è un criterio.

# installa WP-CLI test scaffold nel plugin
wp scaffold plugin-tests mio-plugin

L'output è una cartella tests/ con file di esempio, configurazione PHPUnit e script per lanciare la suite. Da lì in poi scrivi test reali: un test per ogni metodo pubblico della classe principale, un test per ogni hook registrato.

Fase 8: refactoring finale

Dopo i test, chiedi all'AI un refactoring mirato: estrai metodi lunghi, rinomina variabili, aggiungi type hint mancanti, sostituisci array() con [], converte stringhe in costanti di classe se usate più volte. Il refactoring post-test è il momento in cui il codice diventa manutenibile. Non farlo prima dei test: senza test, il refactoring è un terno al lotto.

Un prompt utile per questa fase:

# esempio codice
Refactoring del file [NOME FILE]. Obiettivi: type hint completi, metodi sotto le 30 righe, naming coerente, nessuna duplicazione. Mantieni la logica invariata. Restituisci solo il codice finale con commenti PHPDoc.

Fase 9: distribuzione e manutenzione

Una volta che il plugin è solido, crea lo ZIP e pubblicalo su wordpress.org tramite wp-svn, oppure su GitHub con una release. Il file readme.txt segue il formato standard WordPress: header con metadata, sezione "Description", "Installation", "Frequently Asked Questions", "Changelog", "Upgrade Notice". L'AI può generare un primo draft, ma ricontrolla: wordpress.org rifiuta readme con link a siti di terze parti non autorizzati, con tag non standard, con sezioni mancanti.

# crea zip distribuzione plugin
wp dist-archive /percorso/del/plugin mio-plugin-1.0.0

Dopo la pubblicazione, il lavoro non è finito: monitora il forum di supporto, rispondi ai bug report, rilascia patch. Un plugin senza manutenzione è un plugin che smette di funzionare al primo aggiornamento major di WordPress.

Errori comuni da evitare

Anche con un buon metodo, alcuni errori sono ricorrenti. Ecco i più frequenti osservati su plugin AI-generati pubblicati su wordpress.org e repository privati.

La tabella è un riassunto operativo. L'errore più subdolo è il primo: un file da 2000 righe è facile da generare con l'AI, impossibile da mantenere senza refactoring radicale.

Workflow integrato: dall'idea al repository

Mettiamo insieme le nove fasi in un flusso settimanale realistico. Giorno 1-2: requisiti e architettura, con sessioni AI di 2-3 ore. Giorno 3-4: generazione e code review, con l'AI come pair programmer. Giorno 5: test e refactoring, senza AI generativa ma con PHPStan e PHPUnit. Giorno 6: readme, asset, documentazione. Giorno 7: pubblicazione e annuncio.

Questo ritmo è compatibile con un singolo sviluppatore che lavora part-time. Con un team di due persone (uno sviluppatore, uno reviewer) si scende a 3-4 giorni. Il collo di bottiglia non è mai la generazione del codice: è la review e i test.

Quando l'AI non basta

Ci sono ambiti dove l'intelligenza artificiale generativa non è ancora affidabile come unico input:

• Logica di business complessa con regole fiscali o legali: serve dominio umano per validare i requisiti.
• Integrazione con API di pagamento (Stripe, PayPal): troppe edge case, troppe versioni API, troppe conseguenze economiche di un bug.
• Plugin che gestiscono dati sanitari o personali sensibili: la conformità GDPR richiede revisione legale, non solo tecnica.

In questi casi l'AI è utile per generare il codice candidato, ma serve un dominio umano per validare. Non affidarti mai al 100% all'output AI per aree critiche.

Strumenti consigliati per il workflow

Ecco la mia toolchain attuale, testata su plugin reali pubblicati nel 2025-2026:

• Editor AI: Cursor per la generazione, Continue.dev come alternativa open source, entrambi con supporto a modelli locali (privacy).
• Analisi statica: PHPStan livello 6+ con regole WordPress custom, Psalm come alternativa.
• Test: PHPUnit + WP-CLI scaffold plugin-tests, Brain Monkey per mock delle funzioni WordPress.
• Sicurezza: Plugin "Plugin Check" di wordpress.org per validare submission, PHP_CodeSniffer con WordPress Coding Standards.
• Versionamento: Git con conventional commits, GitHub Actions per CI, wp-env per ambienti di sviluppo riproducibili.

Nessuno di questi strumenti è obbligatorio, ma l'insieme copre le fasi 4-9 con automazione. Il tempo risparmiato in setup si ripaga dal primo plugin in poi.

Riferimenti ufficiali e risorse esterne

Per approfondire i temi toccati in questa guida, queste sono le fonti primarie che uso quotidianamente:

• Plugin Handbook ufficiale di WordPress.org — documentazione canonica su hook, API, sicurezza, internazionalizzazione. È la bibbia: ogni dubbio su un filtro o un action hook si risolve qui.
• WordPress Coding Standards su GitHub — le regole di stile PHP/JS/CSS che ogni plugin su wordpress.org deve rispettare, installabili come standard PHPCS.
• Make WordPress Core — discussione su PHP 8.x e WordPress 7.0 — le release notes ufficiali, le proposte di deprecazione, gli aggiornamenti sui requisiti minimi di PHP che impattano direttamente i plugin moderni.
• Plugin Check su wordpress.org — strumento di validazione pre-submission che verifica automaticamente decine di requisiti tecnici e di sicurezza.
• WP-CLI command reference — ogni comando disponibile, con flag ed esempi, utile per automatizzare test, scaffolding e distribuzione.
• Common APIs — Settings, Options, Transients — pattern consolidati per memorizzare configurazioni, con confronto tra opzioni e transients.

Le fonti terze (blog, tutorial YouTube) sono ottime per imparare pattern, ma quando decidi un'architettura o una regola di sicurezza, il riferimento finale deve sempre essere la documentazione ufficiale. Le AI a volte propongono pattern obsoleti (hook deprecati, funzioni rimosse in versioni recenti): solo leggendo le release notes aggiornate te ne accorgi.

Caso studio: 7 giorni per un plugin reale

Per chiudere con un esempio concreto, ecco come ho applicato il metodo a un plugin reale: un sistema di scadenza post con countdown nel frontend. Il plugin è in produzione su tre siti, tutti aggiornati a WordPress 6.5+ senza conflitti.

Giorno 1: requisiti

Una mattina con sessione AI di 2 ore, partendo dalla user story "voglio una data di scadenza visibile sul post con countdown automatico". Output: 6 criteri di accettazione, 4 edge case (post programmati, post privati, timezone del sito, caching del countdown), decisione di usare un meta box classico per compatibilità con i page builder più diffusi. Tutto scritto in un file requirements.md versionato su Git.

Giorno 2: architettura

Sessione AI con prompt di architettura: output una struttura a tre classi (Main, MetaBox, Frontend), un custom post meta mio_plugin_expiry_date, due hook (uno in admin per il meta box, uno in frontend per il rendering), zero tabelle custom. Ho aggiunto un requirements.md con la sezione "Decisioni di architettura" per spiegare perché niente tabelle custom: i meta post bastano per il caso d'uso, le tabelle custom aggiungono complessità di migrazione e manutenzione non giustificata.

Giorno 3-4: generazione e review

Ho generato il codice file per file in Cursor, con prompt che includevano sempre i requisiti di sicurezza (nonce, sanitize, esc) e i criteri di accettazione come checklist inline. Poi PHPStan livello 6 ha trovato 4 errori di tipo (parametri nullable non gestiti) che ho corretto in 20 minuti. Una seconda passata AI per code review ha pescato 2 bug logici (confronto tra DateTime e stringa in un caso edge).

Giorno 5: test

wp scaffold plugin-tests ha creato la struttura PHPUnit. Ho scritto 8 test, uno per criterio di accettazione. Due test hanno rivelato un bug nella gestione del timezone (il countdown mostrava un'ora di differenza tra backend e frontend in siti con timezone Europe/Rome). Bug risolto passando sempre per wp_date() invece di date() nativo PHP.

Giorno 6: documentazione

Readme.txt, screenshot, changelog iniziale, documentazione del meta box. L'AI ha generato il primo draft, io ho ricontrollato formattazione wordpress.org, licenza, sezioni mancanti.

Giorno 7: pubblicazione

ZIP, invio a wordpress.org, attesa di approvazione (3 giorni per la review). Tempo totale: 7 giorni di lavoro effettivo, di cui circa 2 ore al giorno. Il resto del tempo era sessioni AI, code review, test. Il plugin è ancora attivo, riceve aggiornamenti di compatibilità a ogni release major di WordPress.

Questo caso studio dimostra che il metodo è realistico anche per sviluppatori soli, a patto di non saltare le fasi 5-7 (review, sicurezza, test) per la pressione di rilasciare prima.

Domande frequenti

L'AI può sostituire uno sviluppatore WordPress? No. L'AI accelera la scrittura del codice ma non sostituisce la capacità di progettare architetture, fare scelte tecniche e manutenere nel tempo. Un plugin scritto solo con prompt è un plugin fragile.

Quale modello AI è migliore per PHP WordPress? I modelli addestrati su codice recente (Claude 3.5+, GPT-4o, Gemini 2.5) performano bene su pattern WordPress comuni. Per hook meno documentati, meglio includere esempi di documentazione ufficiale nel prompt.

È legale vendere plugin scritti con AI? Sì, purché il codice sia tuo (o rilasciato con licenza compatibile GPL) e tu possa mantenerlo. La licenza del plugin deve essere GPL v2 o compatibile, come richiesto da wordpress.org per i plugin gratuiti.

Come gestisco la qualità del codice AI su larga scala? Con un sistema di review obbligatorio: PHPStan in CI, code review umana, test automatici su ogni PR. Il codice generato entra in produzione solo dopo gli stessi gate del codice scritto a mano.

Conclusione

Creare plugin WordPress con AI è un vantaggio competitivo reale se lo fai con metodo, non con magia. Le nove fasi descritte qui (requisiti, architettura, prompt, generazione, review, sicurezza, test, refactoring, distribuzione) trasformano l'AI da "trucco per prototipi" a strumento professionale. Parti sempre dai requisiti, mai dal codice. Testa sempre, anche il codice "semplice". E ricorda: il prompt è l'inizio, non la fine.

Se vuoi approfondire il tema dei confronti tra coding assistant AI o le strategie per vendere plugin su WooCommerce, trovi guide dedicate sul blog. Il metodo è trasversale: vale per plugin, temi, integrazioni custom e prodotti SaaS costruiti su WordPress.