WP-Bench: il benchmark ufficiale per misurare quanto l’AI capisce davvero WordPress
Nel 2026 usare un language model per scrivere codice è diventato normale: autocompletamento, refactor, scaffolding di plugin, perfino snippet “pronti per production”. Il problema è che quasi tutte le valutazioni che leggiamo in giro sono generiche (algoritmi, LeetCode-style, framework mainstream) e dicono poco su un ecosistema con le sue regole implicite come WordPress.
Per colmare questo vuoto, il progetto WordPress ha presentato WP-Bench: un benchmark ufficiale pensato per misurare in modo strutturato quanto un modello sappia lavorare con WordPress, tra API core, hook, standard di codice, architettura plugin e pratiche di sicurezza.
Perché un benchmark “WordPress-specific” cambia le carte in tavola
WordPress alimenta una fetta enorme del web, ma le metriche con cui si confrontano i modelli raramente includono task tipici del nostro lavoro: usare correttamente hook e capability, evitare query insicure, rispettare le coding standards, interagire con WP-CLI, o implementare pattern che in WordPress sono quotidiani.
- Capire i modelli di oggi: se stai costruendo feature basate su AI (o semplicemente scegliendo un assistente di coding), ti serve capire quali modelli performano davvero su WordPress, non solo su JavaScript “da manuale”.
- Influenzare i modelli di domani: l’obiettivo dichiarato è far diventare WP-Bench un riferimento che anche i provider useranno nelle valutazioni pre-release, così che WordPress non resti un caso d’uso marginale.
- Verso una leaderboard open source: il team sta lavorando a una classifica pubblica con risultati trasparenti, utile sia alla community sia al progetto WordPress per dialogare con i provider su dati concreti.
Com’è fatto WP-Bench: Knowledge ed Execution
WP-Bench valuta le capacità del modello su due dimensioni complementari:
- Knowledge: domande a scelta multipla su concetti WordPress (API, hook, pattern di sicurezza, coding standards). C’è attenzione anche per API più recenti, come Abilities API e Interactivity API, dove i modelli tipicamente faticano di più.
- Execution: task di generazione codice valutati eseguendo davvero lo snippet in un runtime WordPress, con analisi statica e assert a runtime.
Il punto interessante, soprattutto per noi sviluppatori, è che la parte di Execution non si ferma al “sembra corretto”: il codice generato viene passato a un ambiente WordPress che lo analizza (sintassi, standard, aspetti di sicurezza) e poi lo esegue in sandbox con test.
Il grading “con WordPress come giudice”
Il flusso di valutazione è pensato per essere ripetibile e strumentabile:
- L’harness invia un prompt al modello chiedendo codice WordPress.
- Il codice generato viene inoltrato al runtime WordPress tramite WP-CLI.
- Il runtime esegue analisi statica (sintassi, coding standards, controlli di sicurezza).
- Il codice gira in sandbox con assert e verifiche di comportamento.
- I risultati tornano in JSON, con punteggi e feedback dettagliato.
Quick start: provarlo in locale
WP-Bench è organizzato con una parte Python (l’harness, installabile via pip) e una parte runtime (il “grader” WordPress basato su un progetto wp-env). A livello pratico, il setup iniziale segue quattro passaggi.
1) Installazione dell’harness (Python)
python3 -m venv .venv && source .venv/bin/activate
pip install -e ./python2) API key dei provider (file .env)
L’harness parla con i provider via API: crea un file .env con le chiavi per i servizi che vuoi testare.
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=...3) Avvio del runtime WordPress (grader)
cd runtime
npm install
npm start4) Esecuzione del benchmark
cd ..
wp-bench run --config wp-bench.example.yamlL’output finisce in output/results.json e i log per test in output/results.jsonl, così puoi fare analisi successive o riportare risultati in modo consistente.
Confrontare più modelli nello stesso run
Una delle funzionalità più utili, se stai valutando quale modello adottare per un progetto (o per un team), è il multi-model benchmarking: elenchi più modelli nella config e l’harness li esegue in sequenza producendo una tabella comparativa.
models:
- name: gpt-4o
- name: gpt-4o-mini
- name: claude-sonnet-4-20250514
- name: claude-opus-4-5-20251101
- name: gemini/gemini-2.5-pro
- name: gemini/gemini-2.5-flashI nomi dei modelli seguono le convenzioni di LiteLLM (utile se già usi un layer di astrazione tra provider).
Configurazione: cosa conviene guardare subito
Il file wp-bench.example.yaml è il punto di partenza: lo copi e lo adatti. Gli snodi principali sono dataset, lista modelli, grader (Docker + path del progetto wp-env), parametri di run e output.
dataset:
source: local # 'local' or 'huggingface'
name: wp-core-v1 # suite name
models:
- name: gpt-4o
grader:
kind: docker
wp_env_dir: ./runtime # path to wp-env project
run:
suite: wp-core-v1
limit: 10 # limit tests (null = all)
concurrency: 4
output:
path: output/results.json
jsonl_path: output/results.jsonlCLI: tre comandi pratici
wp-bench run --config wp-bench.yaml # run con file di config
wp-bench run --model-name gpt-4o --limit 5 # test rapido su un solo modello
wp-bench dry-run --config wp-bench.yaml # valida la config senza chiamare i modelliDataset e suite: come sono organizzati i test
Le suite vivono sotto datasets/suites/<nome-suite>/ e sono separate per natura del test:
execution/: task di generazione codice con assert (JSON, uno per categoria).knowledge/: domande a scelta multipla per verificare conoscenza (JSON, uno per categoria).
La suite di default, wp-core-v1, copre API core, hook, operazioni DB e pattern di sicurezza. In alternativa, la config può puntare a un dataset su Hugging Face.
dataset:
source: huggingface
name: WordPress/wp-bench-v1Stato attuale e limiti dichiarati (da tenere a mente)
WP-Bench è rilasciato in fase iniziale e gli autori sono espliciti su alcuni punti che, se fai benchmark seri, devi considerare per interpretare i risultati.
- Dimensione del dataset: la suite attuale è ancora piccola; servono più casi per coprire davvero la varietà dell’ecosistema WordPress.
- Copertura versioni: oggi c’è un bias verso feature recenti (WordPress 6.9), incluse Abilities API e Interactivity API. È in parte voluto (sono aree dove i modelli arrancano), ma può penalizzare modelli addestrati prima che queste API fossero diffuse.
- Saturazione del benchmark: nei test iniziali alcuni modelli ottengono punteggi molto alti su concetti “classici”; quindi serve aumentare la difficoltà con problemi realmente discriminanti, non solo “più nuovi”.
Quando WP-Bench è utile nel lavoro quotidiano
Se lavori su plugin, temi o infrastrutture WordPress con un minimo di automazione, un benchmark del genere diventa utile in tre scenari tipici:
- Selezione del modello: scegliere tra modelli “grandi” e “mini” basandosi su task reali (hook, sanitizzazione, REST endpoint, query) invece che su impressioni.
- Regressioni nel tempo: ripetere gli stessi test quando cambi modello o quando il provider aggiorna il backend, per capire se la qualità sul codice WordPress migliora o peggiora.
- Valutazione di sicurezza e standard: in WordPress i dettagli contano (escaping, nonce, capability checks). Un grading che include controlli statici e assert riduce l’autoillusione del “sembra ok”.
Risorse ufficiali
- Repository: WP-Bench GitHub Repository
- Contesto sul lavoro AI in WordPress: AI Building Blocks for WordPress
- Canale community: #core-ai Slack channel
Riferimenti / Fonti
Marco Bianchi
Sviluppatore di giochi e programmatore grafico. Unity e WebGL sono il mio campo. Amo i progetti visivamente spettacolari e la programmazione creativa.
Tutti gli articoli
