← All field notes
Workflow

From chat to committed: a repeatable AI WordPress workflow

A five-stage pipeline that turns a chat window into shippable WordPress — with the review and test gates that make it safe to move fast.

Ad-hoc prompting produces ad-hoc results: a good function here, a security hole there, and no way to tell which is which until something breaks. The fix is to treat AI-assisted development as a pipeline with named stages and gates, not a conversation. Here's the loop that turns a chat window into code you'd sign your name to.

Stage 1 & 2: spec, then scaffold

Start with the spec — hooks, post types, meta, capabilities, REST routes — because it's the artifact that keeps the model honest across the whole session and doubles as your review checklist later. Then generate the scaffold in small pieces, one component at a time, so each output is small enough to actually read. Resist the urge to request the whole plugin at once; large single generations are where both hallucination and hidden state drift thrive.

Stage 3: review against a fixed checklist

This is the stage most people skip and the one that pays for the whole pipeline. Read every generated file against the same list, every time, so quality doesn't depend on how alert you feel:

REVIEW CHECKLIST (per file)
[ ] capability check on every state change (current_user_can)
[ ] nonce on every form + privileged AJAX/REST
[ ] input sanitized (sanitize_*, absint, (float))
[ ] output escaped (esc_html / esc_attr / esc_url)
[ ] $wpdb only via prepare()
[ ] correct hook + timing (init / wp_enqueue_scripts / rest_api_init)
[ ] no deprecated functions

Stage 4: test in a real environment

Never let generated code's first real run be on a client's site. Spin up a disposable environment and exercise the plugin there. wp-env makes this a one-command affair:

# .wp-env.json in the plugin root
{ "core": "WordPress/WordPress", "plugins": [ "." ] }

# then:
npx @wordpress/env start
npx @wordpress/env run cli wp plugin activate your-plugin

Stage 5: commit in small, legible units

Commit each reviewed, tested piece on its own, with a message that says what changed and why. Small commits give you a bisectable history when the model's later work contradicts its earlier work — which, over a long session, it will. The commit log becomes the durable memory the chat window lacks: a record of decisions that survives after the context has drifted away.

Five stages, two gates, one principle: the model supplies speed, you supply judgment and memory. Run the loop and AI-assisted WordPress stops being a gamble and starts being a process — faster than hand-coding, and safer than trusting a chat window on vibes.

Why models drift

Half of "the AI wrote bad code" is really the model losing track of your constraints mid-session. That failure mode has a name and a research home: Hidden State Drift ↗.

More field notes

WorkflowPrompt-to-Plugin: shipping a working WordPress plugin from a single specDebuggingWhere AI-generated WordPress code quietly breaks — and how to catch itBlocksVibe-coding a Gutenberg block with an LLM in the loop