WP-Bench: sådan måler WordPress nu, hvor gode AI-modeller er til WordPress-udvikling

Hvis du bygger plugins, temaer eller custom løsninger på WordPress, har du sikkert allerede testet en eller flere LLM’er (large language models) som “coding assistant”. Men der er en klassisk udfordring: de generelle benchmarks siger noget om programmering bredt, ikke om WordPress specifikt. Derfor har WordPress nu introduceret WP-Bench—et officielt benchmark, der prøver at måle, hvor godt modeller egentlig klarer WordPress-udvikling i praksis.

WP-Bench fokuserer på alt det, der gør WordPress til sit eget økosystem: core APIs, coding standards, plugin-arkitektur, hooks, databasearbejde og sikkerhedsmønstre. Og det interessante er, at det ikke kun handler om “viden”; det handler også om, hvorvidt genereret kode faktisk kan køre og overholde standarder.

Hvorfor et WordPress-specifikt benchmark giver mening

WordPress driver en stor del af internettet, men AI-evalueringer har traditionelt været domineret af brede opgaver: algoritmer, generiske web-frameworks eller leetcode-agtige problemer. Det er netop her WP-Bench forsøger at udfylde et hul: at måle WordPress-kompetence på en måde, der kan sammenlignes på tværs af modeller.

• Bedre valg af værktøjer i dag: Hvis du bruger AI i dit workflow (fx til boilerplate, refactors eller debugging), er det praktisk at vide, hvilke modeller der typisk performer godt på WordPress-opgaver.
• Pres på modeludbydere: Ambitionen er, at AI-labs begynder at bruge WP-Bench som en standardmåling, så WordPress-performance bliver et mål i sig selv og ikke en eftertanke.
• Grundlag for en åben leaderboard: Der arbejdes mod en offentlig leaderboard, hvor model-resultater bliver synlige og kan sammenlignes på WordPress-opgaver.

To akser: Knowledge og Execution

WP-Bench scorer modeller på to dimensioner, som i praksis matcher de to måder, vi bruger AI på som udviklere: (1) Kan den forklare og vælge korrekt? (2) Kan den producere kode, der virker?

1) Knowledge: multiple choice om WordPress

I Knowledge-delen får modellen multiple-choice-spørgsmål, der tester forståelsen af WordPress-koncepter: APIs, hooks, coding standards og sikkerhedsmønstre. Der er også fokus på nyere ting, som Abilities API og Interactivity API, som (ifølge introduktionen) netop er områder, hvor mange modeller kæmper.

2) Execution: generér kode og lad WordPress dømme

Execution-delen er det mest spændende: her skal modellen generere WordPress-kode, og så bliver den evalueret af en rigtig WordPress-runtime. Det betyder, at scoren ikke kun handler om, hvor “pæn” koden ser ud, men om den faktisk kan køre, og om den falder igennem på standards eller sikkerhed.

Sådan bliver opgaverne gradet (højt niveau)

WP-Bench bruger WordPress selv som “grader”. Flowet er i grove træk:

1. Harness (benchmark-runneren) sender en prompt til modellen og beder om WordPress-kode.
2. Den genererede kode sendes til WordPress-runtime via WP-CLI (kommandolinjeværktøjet til WordPress).
3. Runtime kører statiske checks (syntaks, coding standards, sikkerhed).
4. Koden eksekveres i et sandboxed miljø med assertions (forventninger/tests).
5. Resultaterne returneres som JSON med score og detaljeret feedback.

Kom hurtigt i gang: installér og kør en benchmark

WP-Bench er bygget op omkring en Python-baseret harness og en runtime, der kører WordPress som grader. Den korte “happy path” ser sådan ud.

1) Installér harness (Python)

python3 -m venv .venv && source .venv/bin/activate
pip install -e ./python

python3 -m venv .venv && source .venv/bin/activate
pip install -e ./python

2) Læg API keys i en .env

Opret en .env med nøgler til de modeludbydere, du vil teste:

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=...

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=...

3) Start WordPress runtime/grader

cd runtime
npm install
npm start

cd runtime
npm install
npm start

4) Kør benchmark

cd ..
wp-bench run --config wp-bench.example.yaml

cd ..
wp-bench run --config wp-bench.example.yaml

Output bliver skrevet til output/results.json, og der ligger detaljerede logs per test i output/results.jsonl.

Multi-model runs: sammenlign flere modeller i samme kørsel

Hvis du vil teste, hvad der passer bedst til dit WordPress-setup (fx til plugin-udvikling), kan du liste flere modeller i konfigurationen og få en sammenligning. Modelnavne følger LiteLLM-konventioner.

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-flash

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-flash

Konfigurationen: det vigtigste at kende

Du kan starte ved at kopiere wp-bench.example.yaml og tilpasse. Her er de centrale felter: hvor datasættet kommer fra, hvilke modeller der køres, hvordan grader-miljøet startes, samt run-parametre som limit og concurrency.

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.jsonl

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.jsonl

Nyttige CLI-kommandoer

wp-bench run --config wp-bench.yaml          # run with config file
wp-bench run --model-name gpt-4o --limit 5   # quick single-model test
wp-bench dry-run --config wp-bench.yaml      # validate config without calling models

wp-bench run --config wp-bench.yaml          # run with config file
wp-bench run --model-name gpt-4o --limit 5   # quick single-model test
wp-bench dry-run --config wp-bench.yaml      # validate config without calling models

Datasæt og suites: hvad bliver der egentlig testet?

Test cases ligger i datasets/suites/<suite-name>/ og er delt i to mapper: execution/ til kodeopgaver med assertions, og knowledge/ til multiple-choice. Den medfølgende suite hedder wp-core-v1 og dækker bl.a. WordPress core APIs, hooks, database-operationer og sikkerhedsmønstre.

Kør suites fra Hugging Face

Hvis du vil hente datasæt via Hugging Face, kan du pege dataset.source mod huggingface:

dataset:
  source: huggingface
  name: WordPress/wp-bench-v1

dataset:
  source: huggingface
  name: WordPress/wp-bench-v1

Nuancer og begrænsninger (tidlig udgivelse)

WP-Bench er markeret som en tidlig udgivelse, og der er nogle tydelige tradeoffs, man bør kende, før man læser alt for meget ind i scores.

• Relativt lille datasæt: Den nuværende suite er ikke enorm, så der er behov for flere test cases på tværs af WordPress APIs og patterns, før benchmarken bliver rigtig dækkende.
• Feature-bias mod nyere WordPress: Suiten hælder mod WordPress 6.9-funktioner som Abilities API og Interactivity API. Det er delvist med vilje (nye APIs er svære for modeller), men det kan også give skævhed, fordi features kan være nyere end mange modellers træningsdata.
• Saturation på “klassisk” WordPress: Tidlige tests viste meget høje scores på ældre WordPress-koncepter, hvilket gør dem mindre nyttige som signal. Det svære er at finde opgaver, der er reelt udfordrende—ikke kun “nyere end træningsdata”.

Hvordan det kan bruges i en WordPress-hverdag

Som WordPress-udvikler er der to oplagte anvendelser: (1) at vælge model til et konkret team-setup (fx hvilken assistant der giver færrest fejl i hooks, sanitization og WP_Query), og (2) at følge med i, om nyere modeller faktisk bliver bedre til WordPress og ikke kun til generisk JavaScript/Python.

Når benchmarken samtidig prøver at validere i en WordPress-runtime, bliver den også et mere realistisk pejlemærke end “kan den skrive PHP, der ligner WordPress?”—for i produktion er det netop runtime-fejl, sikkerhedsissues og standardbrud, der koster tid.

Ressourcer

• GitHub repo: https://github.com/WordPress/wp-bench
• AI Building Blocks for WordPress: https://make.wordpress.org/ai/2025/07/17/ai-building-blocks/
• #core-ai (Slack): https://wordpress.slack.com/archives/C08TJ8BPULS