WordPress AI debugging workflow: risolvere bug in metà tempo

Il mio workflow di debugging è cambiato 4 volte dal 2024. L'ultima riscrittura l'ho fatta 6 settimane fa, dopo che Claude Code e Composer hanno cambiato le regole del gioco. Oggi ti dico cosa funziona davvero, in quale ordine, e perché il 70% dei consigli che leggi in giro sono fuffa travestita da "usa l'AI".

Se ti interessa solo il workflow finale, salta in fondo. Se vuoi capire perché la maggior parte di chi debugga con AI si sta solo rendendo la vita più complicata, leggi i 3 casi reali.

Perché il workflow tradizionale è morto

Fino al 2023 il debugging WordPress era: apri il log, cerca la riga, vai su Stack Overflow, copia-incolla la risposta, prega. Per i bug banali funzionava ancora. Per i bug moderni no.

Il problema è specifico: i bug del 2026 sono di integrazione, non di sintassi. Un deadlock tra WP-Cron e un'API AI non lo risolvi cercando "wordpress cron not running". Devi capire il flusso asincrono, vedere il timing, e sapere dove l'AI ti sta mentendo (sì, capita).

La prima versione del workflow AI che ho provato, nel 2024, era un disastro. Chiedevo all'AI "fix this bug" incollando 200 righe di log. Risultato: risposte vaghe, peggioramento del codice, 3 ore perse per rollbackare. Il workflow vero che uso oggi è radicalmente diverso.

I 4 strumenti che uso davvero (e perché gli altri no)

Ho provato 11 tool AI per debugging. Ne tengo 4. Gli altri sono inutili o dannosi.

1. Claude Code (Composer)

È un tool che lavora in CLI dentro il tuo progetto. Capisce il contesto del file system, può leggere 50+ file per decidere, e propone fix con diff.

Perfetto per: leggere stack trace complessi, suggerire fix con diff applicabile, fare code review di un PR.

Limite reale: su bug molto grandi (>500 righe di log o >20 file coinvolti) si perde. Il context window ha un limite fisico e quando lo saturi comincia a inventare.

Costo: $20/mese Pro, $200/mese Max. Per un freelance medio il Pro basta.

2. Continue.dev (open source)

Plugin open source per VS Code e JetBrains. Self-hosted, usi il modello che vuoi (Claude, GPT-4, Llama locale).

Perfetto per: chi non vuole dare il codice ad Anthropic o OpenAI per policy aziendale. Lavora tutto in locale con Ollama + Llama 3.1 70B, qualità leggermente inferiore ma accettabile.

Limite: la qualità del suggerimento dipende dal modello scelto. Con Llama 3.1 70B locale hai circa il 70% della qualità di Claude Sonnet. Con GPT-4 via API sei vicino al 90%.

3. WP-CLI + script custom con AI

Ho un wrapper bash che prende l'output di wp debug-bar, wp cron event list, e query log di SAVEQUERIES, e lo passa a Claude via API con un prompt strutturato.

Perfetto per: bug che richiedono log di produzione, dove non puoi replicare l'ambiente locale. Esempio: deadlock su WP-Cron che si verifica solo in produzione sotto carico.

Lo script è 40 righe, lo trovi come gist su GitHub cercando "wordpress cli ai" se ti serve.

4. PHPStan livello 6+ (no AI)

Static analysis PRIMA di chiedere aiuto all'AI. PHPStan livello 6 o 8 trova il 30% dei bug senza AI. Su bug di tipi sbagliati, variabili non inizializzate, dead code, è imbattibile.

Workflow: prima PHPStan in CI (fallisce il PR se trova errori), poi AI per i bug residui. In questo ordine l'AI lavora su roba già filtrata e i suoi suggerimenti sono 10x più utili.

Strumenti scartati: GitHub Copilot Chat (troppo legato al singolo file, non vede il progetto), Cursor composer (ottimo ma troppo costoso per uso occasionale, $40/mese quando Claude Code Pro fa il 90%), Replit Ghostwriter (non integrabile in WordPress stack).

Caso 1: memory leak su plugin AI custom

Un cliente ha un plugin custom che fa AI inference on-prem (Ollama 7B in locale). Dopo 2 ore di attività il sito va in OOM (out of memory) e tutti i worker PHP-FPM muoiono.

Step 1 - Misura: htop sul server. Il processo PHP-FPM sale a 1.8GB resident set dopo 2 ore. Confronto con baseline: a freddo il sito usa 180MB.

Step 2 - Conferma: wp eval 'echo memory_get_peak_usage(true);' restituisce 1.7GB. È il processo PHP che tiene la memoria, non Ollama (Ollama era stabile a 4.2GB).

Step 3 - Stack trace: installo xdebug con xdebug.mode=profile, riproduco, e guardo il profile. La funzione WP_Embeddings_Queue::process ha un loop che tiene in memoria un array di 47mila oggetti embedding (1536 dimensioni float32 = 6KB per oggetto, totale 280MB).

Step 4 - Prompt strutturato all'AI:

# Contesto: plugin custom WordPress, classe WP_Embeddings_Queue
# Sintomo: memory leak, PHP-FPM sale a 1.8GB dopo 2 ore
# Misurazione: memory_get_peak_usage(true) = 1.7GB, array di 47k oggetti in loop
# File: includes/class-embeddings-queue.php, metodo process()
# Tentativo già fatto: nessuno
# Domanda specifica: come rifattorizzo il loop per non tenere in memoria
#   47k oggetti? Vorrei passare a generator + batch.

Step 5 - Risposta AI: Claude Code propone un diff con generator + batch di 100 oggetti. Suggerisce anche unset() esplicito dopo ogni batch.

Step 6 - Implementazione e test: applico il diff, memory peak scende a 280MB. Test di carico per 8 ore consecutive: stabile.

Tempo totale: 38 minuti. Senza AI avrei passato 4 ore a capire dove fosse il leak e probabilmente avrei optato per un workaround (restart PHP-FPM ogni ora) senza risolvere la causa.

Lezione: il debugging con AI funziona se hai già i dati. Se gli dai solo "il sito è lento", non ti aiuta. Misurare è il 70% del lavoro.

Caso 2: race condition in REST API con caching

Un endpoint custom /wp-json/myplugin/v1/sync viene chiamato in parallelo da 4 webhook Stripe. Risultato: 3 chiamate su 4 generano duplicati nel DB (INSERT concorrenti sulla stessa tabella).

Step 1 - Riproduco: ab -c 4 -n 100 sull'endpoint, 100 richieste con concorrenza 4. Vedo nei log: 3 INSERT su 4 chiamate vanno in deadlock MySQL (errore 1213).

Step 2 - Isolo: il problema è specifico di wp_remote_post + 4 chiamate parallele + scrittura su tabella custom. Disattivo il caching di Redis → il problema persiste. Disattivo il plugin AI che gestisce la chiamata → il problema scompare. Conferma: il bug è nella funzione myplugin_sync_handler.

Step 3 - Prompt a Continue.dev:

# Contesto: REST endpoint WordPress, 4 chiamate parallele da webhook Stripe
# Sintomo: INSERT concorrenti sulla stessa riga, deadlock MySQL 1213
# Misurazione: 3 INSERT su 4 falliscono con deadlock
# File: includes/rest-sync-handler.php
# Domanda: come gestisco la concorrenza? Transient lock o ON DUPLICATE KEY UPDATE?

Step 4 - Risposta: Continue.dev propone due soluzioni: transient lock con TTL, oppure INSERT ... ON DUPLICATE KEY UPDATE. Spiega il trade-off: transient lock più sicuro, ON DUPLICATE più performante.

Step 5 - Implemento: transient lock con TTL 60 secondi. La prima chiamata che arriva crea il lock, le altre 3 ricevono 409 Conflict e Stripe ritenta.

Step 6 - Test: ab -c 4 -n 100, zero duplicati. Zero deadlock. Tempo medio di risposta: 240ms (contro 1.8s con i retry su errore).

Tempo totale: 22 minuti.

Lezione: l'AI ti propone la soluzione canonica, ma devi già aver isolato il problema. Senza il benchmark non sapresti nemmeno che è una race condition.

Caso 3: deadlock in WP-Cron con AI inference

WP-Cron che chiama un'API AI ogni 5 minuti per sincronizzare articoli. Se l'API va in timeout (>60 secondi), il cron si blocca e non esegue più gli eventi successivi. Dopo 14 ore il sistema è in stallo totale.

Step 1 - Sintomo: wp cron event list mostra l'evento ai_sync come "missed" da 14 ore. wp cron event run ai_sync → errore "could not connect to api.openai.com".

Step 2 - Misura: wp eval 'echo get_option("cron");' mostra code di eventi in attesa, ma WP-Cron non li processa perché il worker singolo è bloccato dal timeout.

Step 3 - Prompt a Claude Code:

# Contesto: WP-Cron event ai_sync, chiama wp_remote_post a OpenAI
# Sintomo: se API va in timeout >60s, cron si blocca, eventi successivi non girano
# Misurazione: 14 ore di eventi missed, worker PHP singolo
# File: includes/cron-ai-sync.php
# Domanda: come gestisco timeout API in WP-Cron senza bloccare il worker?

Step 4 - Risposta: Claude Code propone wp_remote_post con timeout esplicito di 15 secondi + retry con backoff esponenziale (max 3 tentativi). Spiega: il default di WordPress per wp_remote_post è 5 secondi, ma spesso non basta per API AI.

Step 5 - Fix: timeout 15s esplicito, retry 3 volte con backoff 2-4-8 secondi, logging delle risposte. Inoltre aggiunto uno spawn di sicurezza: se il worker muore, il prossimo cron prende il lock.

Step 6 - Test: simulazione con API mockata in timeout per 3 ore. WP-Cron continua a girare, eventi processed normalmente, zero stalli.

Tempo: 18 minuti.

Lezione: la maggior parte dei bug cron sono timeout mal gestiti. L'AI ti dice cosa fare in 30 secondi, ma devi prima aver confermato che è un timeout e non altro.

Le 4 trappole dell'AI debugging

L'AI è un leverage, non una sostituzione del cervello. Ecco i 4 errori che vedo fare ogni settimana.

1. L'AI ti dice "il fix è X" ma X rompe Y

Senza test di regressione, un fix AI può rompere altro. Mi è successo: ho chiesto all'AI di ottimizzare una query, mi ha proposto un JOIN con subquery. Funzionava. Ma rompeva il caching di WP_Query. Persi 6 ore a capire perché i post meta erano vuoti in produzione.

Regola: dopo ogni fix AI, fai test di regressione. Sempre.

2. Ti propone di refactorizzare tutto

L'AI tende a riscrivere intere classi. Se chiedi "fix this function", spesso risponde "ecco la classe rifattorizzata". 800 righe di diff. Tu hai paura a chiedere il rollback.

Regola: nel prompt metti "voglio solo il fix minimo, no refactoring". L'AI rispetta l'istruzione.

3. Non legge il contesto che gli dai

Se incolli 800 righe di log, l'AI si perde. Risponde con generalità tipo "controlla la connessione al DB".

Regola: dai all'AI il minimo necessario. 20-50 righe di log mirate, una porzione di codice, una domanda specifica. Il prompt strutturato che vedi sopra è un esempio.

4. Genera test che passano ma non testano niente

L'AI scrive test che chiamano la funzione e basta, magari con assert vuoti. Test che passano sempre, ma non verificano il comportamento.

Regola: tu scrivi i test prima (anche solo i casi limite che ti vengono in mente), poi l'AI li rifinisce. Mai fargli scrivere i test da zero.

Come strutturare il prompt per debugging

Dopo 18 mesi di tentativi ho trovato il template che mi fa risparmiare più tempo. È diviso in 6 sezioni, e ognuna ha uno scopo preciso.

# Contesto: [plugin/tema/funzione specifica, versione WordPress, versione PHP]
# Sintomo: [cosa vedi, in quale condizione, da quando]
# Misurazione: [numeri: memory peak, latenza P95, codice errore, query count]
# Tentativo già fatto: [cosa ho provato, perché non ha funzionato]
# File rilevante: [path completo + 20-50 righe di codice]
# Domanda: [specifica, no "come risolvo", no "è un bug di WordPress?"]

La sezione Misurazione è quella che fa la differenza. Senza numeri l'AI sta indovinando. Con i numeri ragiona.

Esempio reale: se scrivi "il sito è lento" l'AI ti chiede "quanto lento? in quali pagine? da quando?". Se scrivi "TTFB P95 = 4.2 secondi sulla home page, da ieri mattina, nessun cambiamento di plugin", l'AI parte con ipotesi già mirate.

Questo template mi fa risparmiare il 30-40% del tempo di indagine. Non è magia, è forzare l'AI a ragionare invece di generare.

Il workflow finale in 5 step

Eccolo. Questo è quello che uso oggi, dopo 18 mesi di tentativi ed errori.

1. Misura: htop, log di sistema, query counter, TTFB reale. Numeri, non sensazioni.
2. Isola: riproduci il bug in locale o in staging. Se non riesci a riprodurlo, non è ancora debuggabile.
3. Prompt strutturato: usa il template sopra. Misurazione inclusa.
4. Applica il fix minimo: solo il fix, no refactoring. Diff piccolo = rollback facile.
5. Test di regressione: fai girare la suite di test su tutto il progetto. Se qualcosa rompe, rollback immediato.

Senza AI questo workflow richiede 4-8 ore per un bug medio. Con AI ben guidata, 30-90 minuti. Non è magia: è leverage. L'AI fa in 30 secondi quello che tu fai in 30 minuti (leggere codice, correlare log, generare ipotesi), ma tu devi sempre guidarla con dati reali.

Cosa NON fare (le 3 cose che vedo ogni settimana)

Se vuoi perdere 3 ore ogni volta, ecco cosa fare.

• Non incollare 5000 righe di log nell'AI e aspettarti la risposta. Non succede. L'AI legge 20-50 righe e poi generalizza, sbagliando.
• Non chiedere "fix this" senza dargli il contesto. L'AI non può leggere la tua testa. Senza contesto, propone fix generici che peggiorano le cose.
• Non fidarti del primo suggerimento se non hai test. Il primo suggerimento è spesso corretto al 70%. Il 30% di possibilità che rompa qualcosa vale la pena di un test di 5 minuti.

L'AI debugging non sostituisce l'esperienza: la amplifica. Se non sai cos'è una race condition, l'AI non ti può insegnare in 30 secondi. Se lo sai, ti fa risparmiare 3 ore di Stack Overflow.

Se vuoi vedere un altro esempio di workflow pratico, dai un'occhiata a come si scrive un plugin AI production-ready nel 2026, dove il debugging di edge case è una parte fondamentale del lavoro. Oppure, se il tuo problema è cron-related, WordPress cron performance e background tasks copre i pattern di monitoraggio.

Riferimenti utili per approfondire

• Claude Code - Composer per sviluppatori - il tool che ha rivoluzionato il mio workflow
• Continue.dev - AI open source per VS Code - alternativa self-hosted
• PHPStan - static analysis per PHP - livello 6+ obbligatorio in CI
• Xdebug profiler - per memory profiling serio, non sensazioni
• WP-CLI handbook - per wrapper bash + AI su log di produzione
• mrtux.it - strumenti AI per sviluppatori WordPress 2026 - panoramica completa
• mrtux.it - WordPress AI Bridge layer plugin - workflow completo di sviluppo
• mrtux.it - plugin AI WordPress costi nascosti - complemento su costi reali dei plugin AI