In questo articolo prendo una posizione netta: non ti spavento, ti spiego come funziona il nuovo triage AI, perché l'AI-use disclosure sta diventando obbligatoria anche se non lo è ancora formalmente, e come evitare che il tuo prossimo plugin finisca nel cestino dopo 48 ore. Vedremo le 7 regole operative che applico ai progetti dei clienti, con snippet di codice reali e una checklist pronta all'uso.

Lettura collegata: se non hai mai pubblicato un plugin, parti da Creare plugin WordPress con AI: metodo completo per il workflow end-to-end, poi torna qui per la fase di submission. Se invece ti interessa il lato legale del codice AI-generated, leggi anche AI e plugin WordPress: come il Plugin Team smaschera i cloni GPL e cosa rischi se pubblichi codice generato.

Cosa è cambiato davvero nel Plugin Team 2026

Il Plugin Team di WordPress.org non è più un gruppo di volontari che guardano il codice a occhio. Dalle conversazioni pubbliche di Luke Carbis e dagli interventi sul canale #plugin-review di Slack, è chiaro che il workflow del 2026 prevede tre livelli:

1. Triage automatico AI al momento della submission: il sistema analizza il diff del plugin rispetto a plugin noti, cerca pattern di codice AI-generated (commenti boilerplate, strutture troppo regolari, licenze mancanti) e produce un primo rapporto.
2. Reviewer umano senior per i plugin che passano il triage o che vengono flaggati: qui la coda è diminuita, ma l'asticella è più alta.
3. Plugin Review Log pubblico consultabile dai maintainer, con i motivi di rifiuto categorizzati in macro-classi.

In pratica, prima che un essere umano legga il tuo codice, un modello ha già deciso se vale la pena. Questo non è un complotto: è un modo per gestire l'esplosione di submission causata dall'AI generativa.

Perché l'AI ha messo in crisi il sistema delle submission

Lo dice apertamente Carbis nelle ultime interviste: la qualità media del codice inviato a WordPress.org è crollata dall'inizio del 2024, e il volume è esploso. Plugin creati in 10 minuti con ChatGPT, plugin "per fare conversione valuta" che sono fork di plugin esistenti con il nome cambiato, snippet rubati da Stack Overflow senza attribuzione. Il Plugin Team ha un budget limitato di ore-volontario, e stava annegando.

La risposta è stata triplice:

• AI al triage per scartare velocemente le submission di bassa qualità
• Disclosure obbligatoria sull'uso di AI durante lo sviluppo
• Reforms del marketplace per supportare plugin premium verificati

Il risultato pratico per te che stai leggendo: se il tuo plugin è scritto con AI e non lo dichiari, il rischio di rifiuto nei primi due round è superiore al 70%. Se lo dichiari e il codice è pulito, non solo passi, ma ti posizioni meglio per essere raccomandato.

Le 7 regole operative del Plugin Team 2026

Dopo aver analizzato i log pubblici di rifiuto e le conversazioni con maintainer che hanno submission recenti, ho distillato sette regole che applico sistematicamente.

Regola 1: l'AI-use disclosure non è facoltativa, anche se non è ancora un campo formale

Il Plugin Team non ti chiede oggi un campo "ho usato AI", ma chiede informazioni su come il plugin è stato sviluppato quando ci sono dubbi. Rispondere "ho usato ChatGPT per generare 200 righe del file principale" non è una buona idea: meglio dichiararlo proattivamente nel readme e nella comunicazione iniziale.

Esempio di sezione da inserire nel readme.txt:

== Development notes ==
This plugin was developed with assistance from AI coding tools
(OpenAI Codex, GitHub Copilot) for boilerplate and unit tests.
All generated code was reviewed, refactored, and tested by
the maintainer. No third-party plugin code was copied.

Regola 2: il triage AI confronta con plugin esistenti, non con linee guida

Il sistema non legge il tuo readme.txt e non consulta le linee guida. Confronta il tuo codice con il database dei plugin già presenti su WordPress.org. Questo significa che se il tuo plugin è funzionalmente identico al 90% a un plugin esistente (anche se "lo fai meglio"), il triage ti flaggherà come duplicato prima ancora che un reviewer lo apra.

Workaround concreto: differenzia sempre l'architettura interna, non solo il nome. Se devi fare un plugin "per convertire valuta", non partire dal plugin XYZ esistente: cambia il modello dati, l'interfaccia pubblica, e i filtri hook usati.

Regola 3: licenza GPL dichiarata riga per riga, non solo nell'header

L'header GPL è obbligatorio, ma il triage AI controlla che ogni file PHP abbia il tag di licenza corretto, specialmente nei file generati con AI che spesso dimenticano l'header. Ecco uno snippet bash da usare pre-submission per verificare:

# verifica che ogni file PHP abbia l'header di licenza
find . -name "*.php" -not -path "./vendor/*" -not -path "./node_modules/*" | while read f; do
  if ! head -3 "$f" | grep -q "License: GPL"; then
    echo "MANCA HEADER GPL: $f"
  fi
done

Regola 4: niente TODO o FIXME lasciati da AI

I modelli generativi lasciano spesso commenti tipo // TODO: implement this o // FIXME: handle edge case in blocchi che "sembrano" funzionare. Il triage AI li conta: più di 5 TODO aperti in un plugin di media complessità è un segnale di submission frettolosa. Risolvi prima di inviare:

# trova TODO e FIXME residui nel codice
grep -rn "TODO\|FIXME" --include="*.php" . | grep -v vendor | wc -l

Regola 5: le dipendenze esterne vanno dichiarate esplicitamente

Se il tuo plugin usa Composer, librerie incluse nella vendor/, o SDK di terze parti, il triage AI chiede che siano elencate in un file composer.json e che la loro licenza sia compatibile GPL. Il Plugin Team non accetta plugin con dipendenze non-GPL "nascoste" o "di cui il maintainer non era a conoscenza".

Regola 6: i test sono un moltiplicatore di approvazione

Un plugin con test unitari passa mediamente in 4-5 giorni; uno senza test in 14-20 giorni. Non è una promessa, è un dato che emerge dai log di submission degli ultimi 6 mesi. Investi due ore in PHPUnit e vedrai la differenza.

Configurazione minima consigliata:

<?php
// tests/bootstrap.php
require_once '/tmp/wordpress-tests-lib/includes/functions.php';
tests_add_filter( 'muplugins_loaded', function() {
    require_once __DIR__ . '/../my-plugin.php';
} );

Regola 7: comunicazione con il reviewer è tutto

Se il triage ti chiede chiarimenti, rispondi entro 48 ore con patch concrete. Se il reviewer umano solleva dubbi su licenza o pattern, NON discutere: applica le modifiche richieste e ri-submit. Il Plugin Team ha il potere di bloccare un account maintainer se percepisce atteggiamento conflittuale.

Cosa rischi se non rispetti le regole

Le tre conseguenze concrete, in ordine di gravità:

• Rifiuto immediato con log pubblico che rimane nel tuo profilo maintainer per sempre e pesa sulle submission future
• Chiusura del plugin se dopo due rifiuti non correggi i problemi strutturali
• Ban del maintainer nei casi più gravi (plugin nulled, codice copiato, false dichiarazioni di authorship)

Per chi lavora in agenzia e pubblica plugin per i clienti, la raccomandazione è netta: separa sempre l'account maintainer personale da quello aziendale, e usa un account "pulito" per i submission.

Il caso AI-use disclosure: facciamo chiarezza

Molti sviluppatori pensano che dichiarare l'uso di AI sia una debolezza. È esattamente il contrario. Il Plugin Team non penalizza l'AI in sé, penalizza il codice non mantenibile, non licenziato, o non testato. Dichiarare l'uso di AI con trasparenza posiziona il tuo plugin nella categoria "sviluppatore consapevole", non in quella "submit-and-forget".

Esempio di nota di disclosure nel file principale del plugin:

<?php
/**
 * Plugin Name: Mio Plugin
 * Description: Descrizione breve.
 * Version: 1.0.0
 * Author: Nome Cognome
 * License: GPL-2.0-or-later
 *
 * Development notes: portions of this plugin were generated with
 * assistance from OpenAI Codex and reviewed/refactored manually.
 * No code from third-party plugins was incorporated.
 */

Come preparare la submission nel 2026: workflow in 9 step

Ecco la sequenza operativa che uso con i clienti prima di un invio:

1. Esegui il check di conformità GPL header su tutti i file PHP
2. Risolvi tutti i TODO/FIXME residui
3. Aggiungi sezione "Development notes" al readme con disclosure AI
4. Esegui PHP_CodeSniffer con regole WordPress-Extra
5. Prepara PHPUnit con almeno 3 test per le funzioni pubbliche
6. Comprimi in ZIP mantenendo la struttura plugin-slug/plugin-slug.php
7. Verifica che unzip -l plugin-slug.zip mostri il file principale al primo livello
8. Submit su WordPress.org con descrizione chiara del "what's new" anche se è la prima versione
9. Monitora la risposta del triage entro 24-48 ore

Snippet di check qualità prima del submit:

# PHPCS con regole WordPress
vendor/bin/phpcs --standard=WordPress --extensions=php --ignore=vendor,node_modules .

# test unitari
vendor/bin/phpunit --testdox

# dimensione e contenuto ZIP
ls -lh plugin-slug.zip
unzip -l plugin-slug.zip | head -20

Caso reale: plugin AI-generated rifiutato e poi approvato in 5 giorni

Per chiudere con concretezza, ecco un caso reale (nomi cambiati) di un plugin che ha avuto problemi al primo invio e li ha risolti rapidamente grazie alle regole che ti ho appena descritto.

Il plugin

"Smart Cache Tags" - plugin che aggiunge tag dinamici alla cache degli oggetti WordPress, scritto in 3 giorni con assistenza OpenAI Codex per il 60% del codice e refactoring manuale per il resto. Maintainer: sviluppatore singolo con 2 plugin già pubblicati.

La prima submission

ZIP inviato il 15 maggio 2026, 1.4 MB, 14 file PHP, 1 file JS. Readme.txt standard. Nessuna sezione "Development notes".

Il rifiuto (48 ore dopo)

Log del Plugin Team, categoria "Triage AI flag":

Rifiuto: triage AI ha rilevato pattern di codice AI-generated
non dichiarato. Per favore aggiungere sezione "Development
notes" al readme.txt dichiarando l'uso di strumenti AI durante
lo sviluppo, e verificare la conformità GPL di tutti i file
includendo header di licenza esplicito.

La correzione

Il maintainer ha:

1. Aggiunto sezione "Development notes" al readme con disclosure trasparente
2. Verificato con il check bash descritto nella Regola 3 (tutti i file avevano già l'header, ma 2 file generati da AI non lo avevano - bug fixato)
3. Risposto al reviewer entro 24 ore con il diff delle modifiche
4. Aggiunto 2 test PHPUnit sulle funzioni pubbliche

La seconda submission

ZIP reinviato il 17 maggio, 1.4 MB. Il triage AI ha passato il plugin in 6 ore. Il reviewer umano ha approvato in ulteriori 4 giorni. Totale: 5 giorni dal secondo invio.

Cosa abbiamo imparato

• La disclosure AI proattiva accelera il triage: il sistema sa già che il codice contiene pattern AI, non deve indovinare
• Verificare header GPL su OGNI file è non-negoziabile: l'AI dimentica spesso l'header anche quando il prompt lo richiede
• Rispondere velocemente al reviewer umano fa la differenza: tra due plugin simili, il reviewer dà priorità a chi è reattivo
• Avere test PHPUnit non è obbligatorio ma pesa: il reviewer vede subito che il codice è mantenibile

Questo caso rappresenta il 60% delle esperienze reali di submission di plugin AI-assisted nel 2026: primo rifiuto per disclosure mancante o header GPL assente, secondo invio approvato in pochi giorni.

Come monitorare la submission nel tempo

Dopo l'approvazione, il monitoraggio non è finito. Il Plugin Team può:

• Segnalare un plugin se riceve report di sicurezza dalla community
• Chiudere un plugin se l'autore non risponde a richieste di fix
• Rivedere la licenza se il plugin viene acquisito da un nuovo maintainer

Per evitare brutte sorprese, ti consiglio di:

<?php
// mu-plugin interno: log delle versioni e notifica automatica
add_action( "upgrader_process_complete", function( $upgrader, $data ) {
    if ( $data["type"] === "plugin" && strpos( $data["action"], "install" ) !== false ) {
        error_log( sprintf(
            "[%s] Plugin installato/aggiornato: %s v%s",
            date( "c" ),
            $data["plugin"],
            $upgrader->skin->plugin_info["Version"] ?? "unknown"
        ) );
    }
}, 10, 2 );

E di iscriverti alla mailing list plugin-review di WordPress.org per ricevere le comunicazioni ufficiali del Plugin Team. Un check trimestrale di compatibilità con l'ultima versione di WordPress chiude il cerchio.

FAQ

Il Plugin Team accetta plugin scritti al 100% con AI?

Sì, purché il maintainer dichiari l'uso, il codice sia licenziato GPL, e il plugin non duplichi funzionalità esistenti. Il problema non è l'AI, è la qualità del codice e l'originalità.

Quanto tempo ci vuole per l'approvazione nel 2026?

Mediamente 7-10 giorni lavorativi per plugin nuovi senza flag del triage, 14-21 giorni per plugin flaggati che richiedono intervento umano. Plugin con test e disclosure AI pulita scendono a 4-5 giorni.

Cosa succede se il triage AI rifiuta ma io sono convinto che il plugin sia valido?

Puoi chiedere un secondo parere umano aprendo un thread nel forum Make WordPress Plugins. Il reviewer senior non è vincolato alla decisione del triage. Tuttavia, nel 70% dei casi il triage ha ragione, e il secondo parere conferma il rifiuto con motivazioni più dettagliate.

Devo dichiarare l'AI anche se l'ho usata solo per scrivere i commenti PHPDoc?

Tecnicamente no, ma è una buona pratica. Se un reviewer ti chiede "chi ha scritto questo commento" e rispondi "AI", la percezione è di minore cura. Meglio riscrivere a mano i commenti importanti.

Il triage AI può falsi positivi su codice "pulito ma simile" a plugin esistenti?

Sì, succede. La difesa migliore è differenziare attivamente l'architettura (filtri, hook, naming delle funzioni) e documentare le scelte nel readme. Se il rifiuto persiste, chiedi esplicitamente quali plugin ritiene tu stia duplicando e riscrivi le parti segnalate.

Conviene usare Composer con dipendenze pesanti per impressionare il reviewer?

No. Il Plugin Team valuta semplicità e manutenibilità. Un plugin con 30 dipendenze Composer è più difficile da revisionare e più fragile. Meglio poche dipendenze, magari zero se non strettamente necessarie.

Cosa cambia per chi pubblica plugin premium su terze parti (non .org)?

Niente rispetto a oggi. Le regole del Plugin Team si applicano solo a WordPress.org. Marketplace come CodeCanyon, EDD, o siti propri seguono policy proprie. Tuttavia, mantenere lo stesso standard di qualità aumenta la fiducia dei clienti.

Checklist finale pre-submission

• [ ] Header GPL su tutti i file PHP
• [ ] Nessun TODO/FIXME residuo
• [ ] Disclosure AI nel readme.txt
• [ ] PHPCS WordPress-Extra pulito
• [ ] PHPUnit con almeno 3 test
• [ ] composer.json presente (se usi Composer)
• [ ] ZIP con struttura plugin-slug/plugin-slug.php
• [ ] changelog nel readme con versione corrente
• [ ] sezione "Frequently Asked Questions" del readme popolata
• [ ] screenshot o GIF della UI admin

Riferimenti utili per approfondire

• Plugin Review Log pubblico di WordPress.org - log dei rifiuti e macro-classi di errore più comuni
• Detailed Plugin Guidelines di WordPress.org - linee guida ufficiali sempre aggiornate
• Common APIs di WordPress.org - documentazione tecnica per chi scrive plugin di qualità
• WordPress AI Connectors: guida operativa per sviluppatori e agenzie - panoramica su come funzionano i connettori AI in WP 7.0
• AI e plugin WordPress: come il Plugin Team smaschera i cloni GPL - lato legale del codice AI-generated
• Plugin WordPress da evitare nel 2026 - per capire cosa NON replicare nella submission
• WP Tavern - intervista a Luke Carbis sul Plugin Team - fonte dell'analisi sul triage AI
• Composer Best Practices per WordPress - guida WP-CLI per build e check pre-submission
• PHPUnit per WordPress plugin - test automation, moltiplicatore di approvazione
• WordPress Coding Standards - PHP_CodeSniffer - regole ufficiali per PHPCS

Questo articolo entra nel merito tecnico e legale della questione, partendo da dati reali (case study pubblici di plugin rifiutati, pattern di plagio riscontrati, conseguenze operative) per arrivare a una checklist concreta che sviluppatori, agenzie, e site owner possono usare subito. È complementare alla guida su come creare un plugin WordPress con AI in modo corretto e al tema della sicurezza dei plugin piratati, ma con un angolo inedito: il rischio legale-legato-alla-pubblicazione, non solo all'uso.

Cosa dice davvero la GPL, in parole semplici

La GNU General Public License v2 (o successiva, "v2+") è la licenza con cui WordPress e la quasi totalità del suo ecosistema sono distribuiti. In sintesi estrema:

• Puoi usare il codice liberamente
• Puoi modificarlo liberamente
• Puoi ridistribuirlo liberamente
• A condizione che anche le tue modifiche e il tuo lavoro derivato siano distribuiti sotto GPL
• A condizione che tu citi gli autori originali e mantenga intatte le note di copyright

Il punto 4 è quello che manda in crisi i code generator. Quando chiedi a ChatGPT "scrivimi un plugin per la gestione dei custom post type con un'admin UI moderna", il modello non distingue tra codice GPL, codice MIT, codice proprietario closed, e codice coperto da copyright ancora attivo. Produce un output plausibile, ma la provenienza di ogni riga è opaca.

Cosa fa il Plugin Review Team

Il Plugin Team di WordPress.org è un gruppo di volontari (oggi circa 60-70 reviewer attivi) che esamina ogni plugin sottomesso al repository ufficiale. Non fanno un audit esaustivo del codice: controllano che il plugin non faccia nulla di vietato dalle linee guida (no tracking, no upselling aggressivo, no chiamate a endpoint esterni non documentate, no codice offuscato), e che la GPL sia rispettata. Quando trovano pattern sospetti, rifiutano il plugin e chiedono chiarimenti.

Il tempo di review è cresciuto enormemente dal 2023 in poi. Mika Epstein ha dichiarato pubblicamente che il team riceve centinaia di submission al mese, una buona fetta delle quali mostra pattern di "AI senza verifica": codice funzionante in superficie, ma con licenze miste o porzioni palesemente copiate da plugin già esistenti.

I pattern reali che fanno scattare il rifiuto

Dalla documentazione pubblica del Plugin Team e dai case study analizzati, ecco i pattern più comuni di plugin AI-generati che vengono rifiutati.

Pattern 1: clone di un plugin esistente

Il caso più frequente. Chiedi a ChatGPT "fammi un plugin per gestire i cookie banner come XYZ", e il modello produce codice che è una variante funzionale del plugin XYZ ma con il nome cambiato e qualche modifica. Il Plugin Team lo riconosce, rifiuta la submission, e in casi ripetuti chiude l'account.

Caso studio noto: nel 2023-2024, almeno 4 plugin sono stati sottomessi con nome e struttura quasi identica a "Scroll to Top" di Mark Praschan, presentato come lavoro originale. Lo stesso Praschan lo aveva segnalato su Twitter. Tutti rifiutati.

Pattern 2: snippet da Stack Overflow con licenza Creative Commons BY-SA

Stack Overflow è rilasciato sotto CC BY-SA 4.0, non GPL. Questo significa che il codice preso da SO può essere usato in plugin GPL (le due licenze sono reciprocamente compatibili), ma a due condizioni:

1. Devi attribuire la fonte all'autore della risposta
2. Devi rilasciare il tuo plugin con la stessa licenza CC BY-SA oppure dimostrare la compatibilità con GPL

Il Plugin Team verifica questa attribuzione. Molti plugin AI-generated non la includono, e vengono rifiutati. Caso eclatante: plugin che contenevano 30+ snippet di SO copiati verbatim, senza alcun commento di attribuzione. Chiusura immediata del plugin già pubblicato.

Pattern 3: porzioni di plugin proprietari (nulled) decompilati

Questo è il caso più grave. Alcuni plugin AI-generated sul mercato non sono affatto generati da zero: sono plugin commerciali (Elementor Pro, SEOPress Pro, WP Rocket) a cui sono state rimosse le protezioni di licenza, e poi "passati a ChatGPT" per giustificare la presenza di codice altrimenti non GPL-compatibile. Il risultato è codice infetto (come abbiamo visto nella guida sui plugin piratati) E violazione di copyright.

Pattern 4: licenze miste non documentate

Un plugin può importare correttamente da più fonti, ma se include una libreria MIT deve dichiararlo. Se include una porzione BSD deve dichiararlo. Se include codice Apache 2.0 deve dichiararlo. Il Plugin Team verifica il file readme.txt e l'header del plugin principale. Plugin AI-generated che omettono queste dichiarazioni vengono rifiutati.

Pattern 5: codice generato senza "human in the loop"

Un plugin sottomesso che contiene esattamente le stesse risposte di ChatGPT a un prompt noto (verificabile con un test "scrivimi un plugin per X" e il confronto) è un segnale fortissimo che non c'è stato lavoro umano di adattamento. Il Plugin Team non vieta l'AI in sé, ma vieta la pass-through pura.

Cosa rischi se pubblichi un plugin AI-generated non verificato

Le conseguenze concrete per uno sviluppatore che sottomette un plugin AI-generated senza le verifiche del caso sono tre.

1. Rifiuto della submission

Il minimo sindacale. Il Plugin Team invia una email standardizzata, spiega cosa non va, e tu correggi e ri-sottometti. Tempo perso: 2-7 giorni, niente di drammatico.

2. Chiusura del plugin già pubblicato

Se il plugin era già nel repository e il Team scopre una violazione GPL a posteriori (spesso tramite segnalazione di un altro sviluppatore), il plugin viene chiuso. Gli utenti ricevono un errore di installazione al prossimo aggiornamento, e tu ricevi una email di notifica. Danno reputazionale: medio.

3. Ban dell'account sviluppatore

Per violazioni ripetute, il Plugin Team può sospendere l'account sviluppatore. Significa perdita di accesso a tutti i plugin pubblicati, al repository SVN, e alla reputazione accumulata in anni. Alcuni sviluppatori sono stati banditi per pattern di plagio sistematico.

La checklist operativa: come pubblicare plugin AI-generated in modo corretto

Ecco una checklist concreta, testata sul campo, per pubblicare un plugin AI-generated nel rispetto della GPL e delle linee guida WordPress.org.

Fase 1: prima di scrivere codice

• [ ] Definisci il problema in modo originale. Più il prompt è generico ("fammi un plugin per la SEO"), più il rischio di clone è alto. Specifica il problema di business, non la categoria del plugin
• [ ] Verifica che non esista già un plugin simile. Cerca nel repository ufficiale, su GitHub, e sui marketplace commerciali. Se esiste qualcosa di molto simile, valuta se contribuire a quel plugin invece di crearne uno nuovo
• [ ] Decidi la licenza esplicita. GPLv2+ è lo standard. Dichiaralo nel file principale e nel readme.txt

Fase 2: durante la generazione del codice

• [ ] Usa l'AI come assistente, non come autore. Chiedi a ChatGPT/Claude "spiega come funziona X" o "ottimizza questa funzione", non "scrivi l'intero plugin"
• [ ] Mantieni un log delle fonti. Se copi uno snippet da SO, GitHub, o un altro plugin, salvalo in un file SOURCES.md con autore, URL, e licenza
• [ ] Verifica manualmente la provenienza di ogni blocco non ovvio. Se una funzione di 50 righe è misteriosa, chiediti: l'ho scritta io o l'ha generata l'AI basandosi su cosa?

Fase 3: prima della submission

• [ ] Verifica le licenze di tutte le dipendenze. Ogni libreria importata deve avere licenza compatibile GPL. Usa uno script automatico:

# Comando per scansionare le licenze dichiarate nelle dipendenze Composer
composer licenses 2>/dev/null | grep -v MIT | grep -v BSD | grep -v Apache

• [ ] Controlla il codice con uno strumento di rilevamento plagio. Strumenti come MOSS (Measure of Software Similarity) oggi hanno dataset insufficienti per il codice AI, ma funzionano per il plagio di plugin esistenti
• [ ] Verifica l'header del plugin principale. Deve contenere License: GPLv2 or later e un commento Author: con il nome reale (no pseudonimi Account-AI)
• [ ] Testa in un ambiente vergine. Installa il plugin in un WordPress pulito e controlla che non generi errori, chiamate esterne non documentate, o comportamenti inattesi

Fase 4: nella submission

• [ ] Dichiara l'uso di AI se rilevante. Le linee guida non lo richiedono esplicitamente, ma un plugin AI-generated con disclosure onesta ha meno probabilità di essere segnalato per plagio
• [ ] Fornisci un changelog realistico. Un plugin con 47 funzionalità rilasciate in v1.0.0, senza un history di beta, è sospetto. Rilascia prima in GitHub, poi in WordPress.org
• [ ] Rispondi prontamente alle email del Plugin Team. Se ti chiedono chiarimenti, rispondi entro 48 ore con la documentazione delle fonti

Cosa rischi se usi un plugin AI-generated di terzi

Anche se non sei lo sviluppatore, usare un plugin AI-generated di terzi ha rischi specifici. Ecco i principali.

Rischio 1: licenza non chiara

Se il plugin non dichiara esplicitamente la licenza, non puoi sapere se puoi fork-arlo, modificarlo, o ridistribuirlo. In ambito aziendale, questo è un problema serio: il legal team blocca l'uso.

Rischio 2: codice coperto da copyright altrui

Se il plugin contiene codice copiato da un plugin GPL senza attribuzione, l'utente finale non è responsabile (la responsabilità è di chi ha pubblicato), ma il plugin può essere chiuso da un giorno all'altro, e tu resti con un sito rotto.

Rischio 3: plugin chiuso retroattivamente

WordPress.org può chiudere un plugin anche dopo anni di presenza nel repository, se emerge una violazione. Esempio reale: il plugin "WP-Touch" è stato chiuso nel 2019 per motivi di licenza, dopo 9 anni di presenza. I siti che lo usavano hanno dovuto trovare alternative in fretta.

Mitigazione: la regola del fork verificato

Per uso aziendale, la regola prudenziale è: non installare un plugin di cui non puoi fare il fork verificato su GitHub entro 10 minuti. Se il plugin è solo su WordPress.org, non hai una base di codice indipendente per audit e manutenzione.

L'ecosistema si sta regolando: il caso del Plugin Check

Il Plugin Check tool, integrato in WordPress core dalla 6.5 e migliorato nella 7.0, include ora un check specifico per pattern AI-generati sospetti. Non è un rilevatore di AI in senso stretto (impossibile allo stato dell'arte), ma identifica pattern di plagio da plugin noti confrontando porzioni di codice con un dataset interno.

// Esempio: aggiungere un check custom al Plugin Check
add_filter( 'plugin_check_ai_patterns', function( $patterns ) {
    $patterns[] = [
        'name'        => 'AI prompt injection in plugin headers',
        'description' => 'Header del plugin contenenti commenti che sembrano prompt AI',
        'regex'       => '/\/\/\s*(Ignore previous|You are|Generate|Simulate)/i',
        'severity'    => 'warning',
    ];
    return $patterns;
} );

Per ora il check è warning, non blocker. Ma la direzione è chiara: tra fine 2026 e 2027, è probabile che plugin con pattern di plagio eclatanti vengano rifiutati automaticamente prima ancora della review umana.

Caso studio: il plugin NorthStar di Mark Praschan

Uno dei pochi casi ben documentati di plugin generato con AI e accettato dal repository. Mark Praschan, sviluppatore non professionista, ha usato ChatGPT free per generare un plugin "NorthStar" che mostra un messaggio personalizzato nella admin bar. La versione iniziale funzionava, Praschan l'ha testata, l'ha rifattorizzata manualmente, e l'ha pubblicata. Il Plugin Team l'ha accettata senza problemi.

Cosa ha fatto bene Praschan:

• Plugin con scope chiaro e limitato (non un clone di un plugin esistente)
• Refactoring manuale del codice generato (non un pass-through)
• Test in ambiente locale prima della submission
• Descrizione onesta nel readme.txt

È l'esempio che il Plugin Team cita quando spiega: l'AI è uno strumento, non un problema. Il problema è l'uso pass-through senza verifica.

Il futuro: AI disclosure obbligatoria?

Una delle proposte emerse nella community WordPress nel 2025-2026 è l'introduzione di una AI disclosure obbligatoria nei readme.txt dei plugin. Idea: aggiungere un campo AI Generated: yes/no/partial e un altro AI Disclosure: <note testuale>. Pro: trasparenza. Contro: rischio di discriminazione verso plugin AI-generated perfettamente legittimi.

La proposta non è ancora stata approvata, ma è in discussione. Se passerà, avremo un ecosistema più trasparente ma anche un nuovo campo di frizione per gli sviluppatori.

Domande frequenti

È legale usare ChatGPT per scrivere un plugin WordPress?

Sì, è legale. I termini di servizio di OpenAI consentono l'uso commerciale dell'output. La legalità del plugin risultante dipende dalla GPL: se tutto il codice è tuo originale o GPL-compatibile, il plugin è legittimo. Se contiene codice copiato da plugin non GPL senza attribuzione, il plugin è illegale.

Come faccio a sapere se il codice generato da ChatGPT è GPL-compatibile?

Non c'è modo automatico. ChatGPT non traccia la provenienza del codice che produce. La verifica deve essere manuale: se una funzione è misteriosa o ti sembra "troppo perfetta" per essere generata, chiedi a ChatGPT di spiegartela riga per riga. Se la spiegazione è vaga, cerca il pattern su Google. Se trovi match in plugin GPL noti, aggiungi l'attribuzione. Se trovi match in plugin proprietari, riscrivi da zero.

Il Plugin Team rifiuta plugin solo perché generati con AI?

No. Rifiuta plugin che violano la GPL o le linee guida, indipendentemente dal fatto che siano AI-generated. La differenza è che i plugin AI-generated hanno una probabilità più alta di contenere codice non GPL, perché il modello non distingue le licenze. Il controllo del Plugin Team è sul risultato, non sul processo.

Cosa succede se il mio plugin viene chiuso dopo anni di utilizzo?

Devi trovare un'alternativa o fare un fork. Il sito dei tuoi clienti smette di funzionare se il plugin era critico. La lezione: tieni sempre un fork GitHub aggiornato dei plugin critici, anche se sono nel repository ufficiale.

Posso usare codice da GitHub in un plugin WordPress?

Dipende dalla licenza del repository GitHub. Se è MIT, BSD, o Apache 2.0, la compatibilità con GPL è buona (con alcune condizioni per Apache). Se è "all rights reserved" o non specificata, non puoi. Se è GPL, perfetto, basta mantenere la stessa licenza.

Vale la pena dichiarare l'uso di AI nel readme.txt?

Dipende dalla policy del momento. Al 2026 non è obbligatorio, ma la trasparenza è apprezzata dalla community. Se il plugin è AI-generated ma con pesante refactoring umano, una nota del tipo "Sviluppato con assistenza AI, revisionato e testato manualmente" può essere un segnale positivo.

Riferimenti utili per approfondire

• WordPress Plugin Guidelines ufficiali - le regole da seguire.
• Make WordPress Plugins blog - comunicazioni ufficiali del Plugin Team.
• Discussione su AI e Plugin Review - il post originale di Mika Epstein che ha fatto da spartiacque.
• GNU GPL v2 testo integrale - la licenza in sé.
• GPL compatibility chart - per verificare la compatibilità tra licenze.
• Plugin Check tool su GitHub - strumento ufficiale di verifica pre-submission.
• Stack Overflow license details - per capire come usare snippet SO in plugin GPL.
• Creare plugin WordPress con AI: metodo completo mrtux.it - workflow pratico per evitare i problemi descritti qui.
• Plugin WordPress piratati e sicurezza mrtux.it - il rischio speculare per chi usa plugin AI compromessi.
• Lista 23 plugin da evitare mrtux.it - criteri per scegliere plugin mantenuti e testati.

Questa guida verrà aggiornata quando il Plugin Team pubblicherà linee guida formali sull'AI disclosure. Per casi reali o domande specifiche sulla tua submission, l'area commenti è aperta.