Una regola di review ben scritta ha fatto emergere il 98% delle violazioni attese in un test OpenAI, contro il 58,3% della review senza istruzioni specifiche. Per chi usa Codex su plugin e temi WordPress, il punto non è aggiungere un prompt più lungo: è trasformare gli errori che il team ripete in pochi controlli locali, verificabili e difficili da fraintendere.

Il problema non è il prompt

Quando un assistente AI modifica un repository WordPress, una richiesta come «controlla sicurezza e qualità» sembra prudente ma non definisce cosa debba bloccare la consegna. Il modello può notare uno stile incoerente e ignorare il rischio che conta davvero: un input non sanitizzato, un output senza escaping, una query non preparata oppure una versione del plugin non aggiornata. La review diventa quindi estesa ma poco utile, perché tratta allo stesso modo preferenze cosmetiche e invarianti di progetto.

Il caso Cult.fit pubblicato da OpenAI mostra il vantaggio operativo della standardizzazione: repository, istruzioni, test e feedback seguono convenzioni comuni invece di cambiare con ogni strumento o team. Per una PMI non serve replicare quel modello su scala enterprise. Basta partire dal repository che genera più correzioni manuali e identificare tre errori che un reviewer umano deve spiegare quasi a ogni consegna. Quelli sono i candidati giusti per una regola persistente.

Scrivi tre regole verificabili

Apri l’AGENTS.md del repository e descrivi ogni regola con tre elementi: ambito, rischio e percorso sicuro. Un esempio concreto per un plugin è: «Nel codice che riceve dati da form o REST, sanitizza l’input in base al tipo, verifica nonce e capability quando richiesto, ed esegui escaping solo al momento dell’output». Un secondo controllo può imporre query con $wpdb->prepare(); un terzo può richiedere il bump della versione prima di creare lo ZIP distribuibile. La formulazione dice sia cosa proteggere sia come intervenire, senza legarsi al nome di una funzione interna destinata a cambiare.

Le indicazioni ufficiali sulle regole personalizzate di Code Review consigliano set piccoli, circoscritti e dedicati a invarianti non ovvie. Mantieni invece formattazione, lint e test ripetibili nella CI: sono controlli deterministici e non richiedono giudizio. In questo modo Codex usa la review per ciò che il test automatico non sa esprimere, mentre la pipeline continua a bloccare in modo oggettivo errori di sintassi, regressioni e standard di codice.

Prova una violazione e un caso sicuro

Non considerare la regola pronta perché suona bene. Prepara un diff minimo che la violi, uno che usi il percorso sicuro e un cambiamento estraneo al suo ambito. La review deve segnalare il primo, lasciare in pace il secondo e non produrre rumore sul terzo. Se commenta tutti e tre, la regola è troppo ampia; se non intercetta il primo, mancano un rischio concreto o un criterio osservabile. Questo test richiede pochi minuti e impedisce di trasformare il repository in una raccolta di divieti generici.

Prima della prova esegui comunque i controlli locali previsti dal progetto e registra il risultato. Una review AI non sostituisce test, branch protection o approvazione umana: aggiunge contesto dove il diff da solo non racconta la storia. È lo stesso principio del gate per i workflow AI: l’output accelera il lavoro solo quando esistono evidenze separate per correttezza tecnica e decisione finale.

L’errore da evitare è accumulare istruzioni

Il rischio più comune è copiare nell’AGENTS.md ogni convenzione del team. Il file cresce, le priorità competono e la review comincia a produrre osservazioni irrilevanti. Parti invece da tre regole con impatto reale, assegna quelle specifiche a una cartella tramite un file annidato e rimuovi ciò che non cambia mai l’esito della review. Una regola utile protegge un contratto, un confine dei dati o un passaggio di rilascio; non riscrive la documentazione del progetto.

Il take operativo è semplice: misura una correzione ripetuta, trasformala in una regola con alternativa sicura e testala su tre diff. Solo dopo aggiungine un’altra. Per un team WordPress piccolo, questo riduce il tempo speso a spiegare sempre gli stessi rischi senza delegare all’AI l’ultima decisione. Codex prepara e controlla; test e reviewer autorizzano il deploy.