TL;DR: per i flussi ripetitivi e critici sceglierei Playwright: il percorso è esplicito, gli errori sono tracciabili e ogni scrittura può avere un’asserzione. Un agente AI al browser serve quando l’interfaccia cambia spesso o il compito richiede interpretazione, ma va chiuso in un ambiente isolato e fermato prima delle azioni irreversibili. Per una PMI la soluzione più solida è ibrida: automazione deterministica per eseguire, agente per gestire le eccezioni.
Il criterio: affidabilità sul processo reale
Agente browser e Playwright possono entrambi aprire una pagina, compilare un form e premere un pulsante. La somiglianza finisce qui. Un agente osserva l’interfaccia, interpreta l’obiettivo e decide la prossima azione. Uno script Playwright segue invece un percorso definito dal codice, con locator e condizioni attese.
Il confronto utile non è quale dei due completa la demo più spettacolare. Conta quale approccio rende prevedibile un processo reale: ripetibilità, controllo dei permessi, diagnosi degli errori, costo di manutenzione e capacità di fermarsi. Su un sito WordPress questa differenza separa un test di staging da una modifica involontaria in produzione.
Agente browser: forte quando il percorso non è noto
Un agente che usa il browser è adatto ai compiti in cui il percorso cambia da caso a caso. Può leggere una pagina, riconoscere un avviso, cercare una voce di menu e adattarsi a un’interfaccia che non conosce in anticipo. La guida OpenAI a Computer use descrive proprio questo ciclo: il modello osserva lo schermo, restituisce azioni strutturate, il sistema le esegue e invia una nuova schermata fino al completamento.
Questa flessibilità riduce il lavoro iniziale su attività lunghe e poco frequenti. Penso a un audit di dieci back office diversi, alla raccolta di informazioni da portali senza API o alla verifica manuale assistita di una migrazione. Scrivere e mantenere uno script per ogni variante potrebbe costare più dell’attività stessa.
Il prezzo è la variabilità. L’agente può interpretare male una pagina, scegliere un elemento simile a quello corretto o seguire istruzioni ostili contenute nel sito. OpenAI raccomanda browser o VM isolati, allowlist di domini e azioni, contenuti della pagina trattati come input non attendibile e supervisione umana per flussi autenticati o difficili da annullare. La documentazione Anthropic su Computer use aggiunge lo stesso punto: accesso minimo, ambiente dedicato e attenzione alla prompt injection presente nelle pagine o nelle immagini.
Playwright: meno libertà, più controllo
Playwright richiede di definire il percorso. Devi stabilire quale pagina aprire, quale campo compilare, che risultato aspettarti e quando considerare il flusso fallito. È lavoro in più all’inizio, ma produce un contratto verificabile.
I locator di Playwright possono agganciarsi a ruoli, etichette e testo visibile invece che a fragili catene CSS. Prima di un clic, l’auto-waiting controlla che l’elemento sia unico, visibile, stabile, abilitato e in grado di ricevere eventi. Le asserzioni completano il percorso: dopo “Salva bozza” posso pretendere lo stato draft, un ID post e l’assenza di errori.
Quando qualcosa si rompe, la diagnosi è meno ambigua. Il Trace Viewer registra azioni, snapshot DOM, rete, console e punto esatto del fallimento. Per una PMI senza un team SRE, poter riprodurre l’errore vale più di una automazione che tenta strade diverse finché sembra aver finito.
Playwright non elimina la manutenzione. Un’etichetta rinominata, un consenso cookie o un nuovo passaggio di autenticazione possono bloccare lo script. La differenza è che il blocco è esplicito. È un difetto sano quando il processo pubblica, invia email o modifica ordini.
Sicurezza: entrambi usano credenziali, ma non allo stesso modo
In Playwright lo stato autenticato può essere riutilizzato, ma la guida ufficiale sull’autenticazione avverte che il file può contenere cookie e header capaci di impersonare l’account. Va escluso dal repository, cifrato o rigenerato e limitato a un utente con i privilegi necessari.
Con un agente browser la superficie è più ampia: oltre alle credenziali, bisogna controllare ciò che il modello può vedere, interpretare e fare. Una pagina esterna è contemporaneamente interfaccia e input. Per questo non darei mai a un agente generalista una sessione WordPress amministratore con libertà di navigazione. Userei un ruolo dedicato, domini consentiti, rete limitata e conferma esterna prima di publish, delete, acquisti o invii.
La regola resta quella già utile nelle integrazioni MCP e REST per WordPress: discovery e interpretazione possono essere flessibili; la scrittura deve attraversare un confine versionato, validato e registrato.
WordPress e automazioni: chi fa cosa
Per pubblicare articoli userei REST o Playwright su un percorso stretto: carica media, crea bozza, verifica i campi, esegui i gate, pubblica. Ogni passaggio restituisce uno stato e il successivo parte solo se quello stato è corretto. Lo stesso vale per test di form, aggiornamenti plugin e controlli dopo una migrazione.
L’agente entra dove il codice rigido costa troppo: analizza una pagina che ha cambiato struttura, propone un nuovo locator, classifica un errore o raccoglie evidenze da più pannelli. Non dovrebbe correggere da solo il flusso in produzione. Può preparare una patch o un piano; test e gate decidono se usarli.
Un’architettura ibrida è semplice: Playwright esegue il percorso normale, salva trace e screenshot in caso di errore, poi l’agente legge quelle evidenze e suggerisce la causa. Se serve una deviazione, la esegue in staging con permessi ridotti. Solo dopo una verifica il percorso deterministico viene aggiornato.
La mia take: deterministico prima, agente sulle eccezioni
Per una PMI partirei da Playwright o, meglio ancora, dall’API ufficiale quando esiste. Sono strumenti meno autonomi, ma rendono visibili le responsabilità. Aggiungerei un agente browser soltanto quando le varianti del processo rendono il codice rigido troppo costoso.
La scelta netta è questa: Playwright per tutto ciò che deve riuscire nello stesso modo cento volte; agente browser per capire cosa fare quando la centunesima volta è diversa. Se l’agente può pubblicare o cancellare senza un gate esterno, non hai costruito un’automazione intelligente. Hai spostato l’incertezza dentro una sessione autenticata.