Using AI Coding Agents on Real WordPress Projects: Workflow, Guardrails, Lessons

I use AI coding agents on real WordPress work — client projects, my published plugin, this site. Not autocomplete: agents with terminal access that read the codebase, run WP-CLI, query the database and edit files. After months of daily use, I have a workflow that reliably produces production-quality WordPress code, and a short list of guardrails learned the hard way. Both are below.

The mental model: junior hands, senior judgment

An agent types faster than me, holds more files in its head than me, and never gets bored of escaping output. What it doesn’t have is my accountability or my scar tissue. So the division of labour is: the agent executes, I specify and verify. Every productivity win I’ve had comes from moving effort out of typing and into those two activities.

Workflow: what actually happens

1. Brief like you’d brief a senior dev. My prompt for this site’s theme specified theme.json v3 tokens, patterns over custom blocks, an mu-plugin for the CPT, idempotent WP-CLI seeders, escaping and i18n. Vague brief, vague code — the model mirrors your standards back at you.
2. Keep a project memory file. A CLAUDE.md in the repo tells the agent the architecture, conventions and gotchas. It’s onboarding documentation, except it gets read every single session — the doc pays rent.
3. Give it a real environment, not a sandbox. Local site, WP-CLI, database access. Agents that can run wp post list catch their own mistakes; agents writing code blind ship guesses. The corollary: dev environment only. Nothing points at production.
4. Demand verification, not vibes. “Done” means the agent fetched the page, checked the rendered HTML, ran the seeder twice to prove idempotency. If it can’t show the check, it isn’t done.
5. Review the diff like a PR from a new hire. Fast scan for the WordPress-specific failure modes: unescaped output, missing nonces, direct DB writes, post functions used on WooCommerce orders, options written without prefixes.

Guardrails, each one earned

• Point it at source, not memory. Asked to write copy about my plugin, an agent described v1 features that no longer existed. Fixed by pointing it at the v2 source tree. Models remember the past; your codebase is the present.
• Destructive operations get named checks first. Before any delete/overwrite: what exists, what collides. A seed script re-run once silently overwrote a real post that shared a slug with sample data. The agent added the guard flag afterwards — but I should have demanded the collision check up front.
• Idempotency claims get tested twice. Literally: run it, run it again, diff the state.
• Taste stays human. Naming, tone, what goes in the nav — every time I delegated a judgment call I got a plausible-but-wrong default. Now I decide those explicitly and let the agent implement.

Does the code hold up?

The block theme this site runs on was built this way in a day — patterns, a custom Interactivity API block, seeders, migration from the old site’s data, SEO wiring. I reviewed all of it, redirected plenty of it, and would put it through a WordPress.org-style review without flinching. The full build story is on the blog.

The skill that’s becoming valuable isn’t “can you use AI” — it’s whether you know your platform deeply enough to direct the AI and catch it being confidently wrong. WordPress knowledge didn’t get less important. It became the steering wheel. If your team is figuring out this workflow, I’m happy to compare notes.