Il codice WordPress generato dall'AI rende essenziale la revisione umana
Il codice WordPress generato dall'AI, cioè codice prodotto con l'intelligenza artificiale, può accelerare lo sviluppo, spiegare sistemi poco conosciuti, risolvere errori e trasformare richieste formulate in linguaggio comune in prototipi. Non può decidere autonomamente se una modifica sia adatta a un production website, il sito online utilizzato da visitatori e clienti. Questa decisione richiede ancora una persona che conosca WordPress, il progetto e l'attività su cui si basa.
Kinsta ha basato la propria analisi su conversazioni con quattro sviluppatori WordPress che utilizzano l'AI nel loro lavoro. Le loro testimonianze mostrano che generare codice è solo una parte dello sviluppo. Uno sviluppatore deve considerare anche l'architettura, ossia il modo in cui sono organizzate le parti di un sistema, insieme a prestazioni, sicurezza, accessibilità per le persone con disabilità e manutenzione a lungo termine. Il codice proposto deve essere compatibile con i plugin del sito, che aggiungono funzioni, con il suo tema, che ne controlla la presentazione, e con eventuali APIs, ossia interfacce di programmazione delle applicazioni che consentono ai componenti software di comunicare.
Questa supervisione è importante perché gli strumenti di AI possono suggerire funzioni o APIs inesistenti, interpretare erroneamente i requisiti, basarsi su presupposti sbagliati e introdurre bug difficili da individuare. Il codice generato può inoltre omettere l'input validation, che verifica se le informazioni inviate sono accettabili, la sanitization, che rimuove o modifica i dati non sicuri, e l'output escaping, che impedisce ai dati visualizzati di essere interpretati come codice attivo della pagina. Questi controlli continuano a far parte delle linee guida di sicurezza di WordPress, indipendentemente da chi o da cosa abbia scritto il codice.
Una dimostrazione pratica di Kinsta ha evidenziato il rischio durante l'utilizzo di strumenti di AI per creare un plugin WordPress destinato a un ruolo utente con restrizioni. Quando è stato chiesto a Cursor di rimuovere il link Quick Edit, a volte lo strumento ha rimosso anche la normale funzione Edit. La modifica richiesta all'interfaccia sembrava funzionare, ma gli utenti interessati avevano perso anche una funzionalità che avrebbero dovuto conservare. Questo tipo di malfunzionamento involontario è noto come regression. Ripetere il prompt non è sufficiente, perché lo sviluppatore deve verificare sia la modifica richiesta sia il comportamento che dovrebbe rimanere invariato.
Il lavoro inizia quindi prima della generazione del codice. Gli sviluppatori devono tradurre i requisiti aziendali in decisioni tecniche, stabilire cosa costruire e scegliere un approccio che possa continuare a essere supportato. Ciò comporta la valutazione dei compromessi, la pianificazione del modo in cui i componenti si integrano e la previsione delle future esigenze di manutenzione. Uno sviluppatore intervistato da Kinsta ha descritto il passaggio dal lavoro visivo sulle pagine all'utilizzo dell'AI per creare applicazioni aziendali più complesse. L'obiettivo non era semplicemente produrre più rapidamente un sito web, ma scegliere la combinazione di tecnologie più adatta ad affrontare il problema aziendale.
Un altro sviluppatore ha descritto l'impiego dell'AI per esaminare i dati del server e mettere in evidenza schemi che richiederebbero più tempo per essere individuati manualmente. Uno schema proposto da uno strumento rimane soltanto un'indicazione. Deve essere confrontato con il comportamento effettivo del sito prima che qualcuno modifichi l'applicazione o la configurazione del relativo hosting. Si tratta di una distinzione importante nelle analisi delle prestazioni, in cui una spiegazione plausibile non costituisce automaticamente la diagnosi corretta.
Poiché gli strumenti producono modifiche più rapidamente, la code review può diventare il collo di bottiglia. I revisori devono stabilire se il codice si comporta come previsto, rispetta i WordPress coding standards, ossia le regole concordate dal progetto per scrivere codice coerente, si integra nell'applicazione nel suo complesso ed è sicuro da rilasciare. Il fatto che il codice venga eseguito senza generare immediatamente un errore non significa necessariamente che soddisfi queste condizioni.
La stessa responsabilità vale per i contributi a WordPress. Le linee guida di WordPress sui contributi realizzati con l'AI impongono ai collaboratori di comprendere il codice che inviano, esaminarlo e convalidarlo, nonché eseguire i test pertinenti. Tale obbligo inizia prima che una patch, ossia una modifica proposta al codice, arrivi al responsabile della manutenzione del progetto. L'AI può contribuire a creare la patch, ma non trasferisce la responsabilità del collaboratore.
Gli sviluppatori utilizzano l'AI anche all'interno del processo di revisione. Kinsta riferisce che uno sviluppatore usa Claude Code e Copilot come strumenti complementari, chiedendo talvolta a uno di esaminare il lavoro prodotto con l'altro, pur mantenendo il controllo delle decisioni tecniche. Un altro utilizza la code review automatizzata e il test-driven development, un approccio nel quale il comportamento previsto viene definito tramite test prima di scrivere l'implementazione. In questo flusso di lavoro, la persona scrive i test e l'AI produce l'implementazione che deve superarli.
Il superamento dei test costituisce una prova utile, ma non dimostra che una modifica sia pronta per la produzione. I test possono non coprire una situazione importante, mentre un revisore basato sull'AI può non rilevare un difetto reale oppure segnalare un problema inesistente. Analogamente, le indicazioni di GitHub per Copilot affermano che la revisione automatizzata deve affiancare, non sostituire, quella umana. Un processo di rilascio responsabile combina quindi test, ispezione manuale e verifiche del comportamento complessivo del sito.
La sola capacità di scrivere prompt non risolve questi limiti. Gli sviluppatori devono sapere quale contesto fornire, quali vincoli applicare e come riconoscere un risultato soddisfacente. Uno sviluppatore definisce il proprio approccio strutturato AI Operating System, o AIOS. Questo comprende file contenenti informazioni aziendali, principi di sviluppo, cronologie dei clienti e altre conoscenze specifiche del progetto. Fornire questo materiale offre allo strumento un contesto più pertinente rispetto a un prompt generico, ma il codice ottenuto deve comunque essere compreso e valutato.
Per i proprietari dei siti, la tutela pratica consiste in uno staging environment, una copia separata del sito web in cui è possibile verificare le modifiche senza influire immediatamente sui visitatori. La revisione deve comprendere controlli di sicurezza, autorizzazioni degli utenti, prestazioni, accessibilità e funzionalità esistenti, non soltanto l'attività indicata nel prompt. Prima della distribuzione devono essere disponibili anche copie di backup, in modo da poter ripristinare il sito online se una modifica già esaminata dovesse comunque causare problemi.
Per i proprietari dei siti che devono scegliere dove eseguire le modifiche esaminate, AEU Hosting è un servizio di hosting WordPress gestito e protetto end-to-end; ciò non sostituisce la code review umana. L'AI può aiutare a implementare una soluzione più rapidamente, ma l'esperienza in WordPress rimane necessaria per definire i requisiti, mettere in discussione i presupposti dello strumento, verificare il risultato e decidere se sia opportuno applicarlo al sito online.