AI for WordPress Developers: The Playbook

The developer role is where AI on WordPress projects pays the biggest throughput dividend. Not as a replacement for the developer (the experienced WordPress dev's judgment about architecture, ACF design, plugin trade-offs, and edge cases is what determines whether the output ships well). As a multiplier on the boring middle of every task: typing the field group registration, writing the migration script, scaffolding the template partial, parsing the log file. This is the deep playbook for that role specifically.

Jump to:

• The mental model
• Workflow 1: ACF field group scaffolding
• Workflow 2: plugin and theme debugging
• Workflow 3: WP-CLI orchestration with checkpoints
• Workflow 4: code review on inherited plugins
• Workflow 5: migration scripts
• Workflow 6: Figma to component
• The senior-review discipline
• What I will not delegate

The mental model

The right way to think about AI on the developer side of WordPress work: the AI is a fast, well-read junior developer who has never seen your specific codebase. It knows WordPress, ACF, WP-CLI, PHP, JavaScript, and CSS well. It does not know your conventions, your plugin ecosystem, your client-specific quirks, or the eight months of context that explain why a particular file is structured oddly.

That junior developer becomes useful when you:

• Tell it your conventions (via CLAUDE.md or per-prompt context).
• Give it scope-limited tasks with explicit success criteria.
• Review its output the same way you would a junior's pull request.

It becomes dangerous when you:

• Hand off without context and trust the output.
• Skip the review.
• Let it take destructive actions on production.

The playbook below assumes you treat AI like a fast junior who needs supervision, not like a senior who can ship alone.

Workflow 1: ACF field group scaffolding

The single highest-impact workflow. Described in detail in Using Claude CLI to Manage WordPress Sites. The pattern: describe the schema in natural language, get back working acf_add_local_field_group PHP.

Sub-patterns within this workflow:

• New field group for a new post type. Best done after the post type exists; the AI reads the post type registration and produces a fitting field group.
• Adding a field to an existing field group. Read the existing group's JSON export, ask for a single new field with matching conventions.
• Refactoring an existing field group. Describe the change (split into two groups, rename a field, change a Repeater to a separate post type), get the migration script plus the new field group registration.

For naming conventions, see ACF Field Naming Conventions That Actually Scale. The AI will follow them if you include the conventions in the prompt.

Workflow 2: plugin and theme debugging

The pattern from Using Claude CLI to Manage WordPress Sites: give the AI the file tree and the symptom, ask for diagnosis BEFORE any edit.

The "diagnose before edit" instruction matters. It forces the AI to articulate its theory of the bug, which you then accept or correct. The AI that jumps straight to edits often fixes the wrong thing.

Concrete prompt template:

The [feature] is [misbehaving in this way]. The relevant code is at
[file path]. The error in debug.log is [error message].

Read the file, trace the logic, tell me where you think the bug is
and why. Do not edit yet.

About 80% of the time the diagnosis is correct. The other 20% gives me enough to find the real bug myself in the next read.

Workflow 3: WP-CLI orchestration with checkpoints

The multi-step plan with approval gates. Covered in detail in Using AI with WP-CLI for Faster WordPress Operations.

The pattern that makes this safe at scale:

On staging:

1. Take a database snapshot.
2. [READ-ONLY step: count something].
3. [READ-ONLY step: list something].
4. [WRITE step: do something based on what we learned].
5. [VERIFY step: confirm the write took effect].

Pause for approval between steps 1 and 2, and between 3 and 4.

Read-only steps run without pause. Write steps require explicit confirmation. Verify steps catch failures before they cascade.

Workflow 4: code review on inherited plugins

The agency reality: you inherit a client site with 30 plugins, three of them custom, two of them apparently abandoned. Before relying on any of them, an AI-assisted security review:

Read /wp-content/plugins/custom-plugin/custom-plugin.php and every
file it includes. Flag any code patterns that look suspicious:
- eval() or assert() calls on dynamic strings.
- base64_decode() of remote content.
- Remote includes via curl or file_get_contents.
- Custom update servers in non-trivial places.
- Direct $_POST or $_GET usage without sanitization.
- SQL queries built with string concatenation.
- File uploads without MIME validation.
- Capability checks that look suspect.

Output a report grouped by severity (critical, suspicious, worth-noting).

The AI is good at this. It catches the obvious "this plugin is sketchy" patterns and surfaces the subtle ones for human review. Faster than a manual line-by-line audit, and the discipline of "always do this on inherited plugins" catches problems before they bite you.

Workflow 5: migration scripts

WP-CLI migration scripts that used to take 90 minutes to write and test now take about 20. The pattern is in How to Update ACF Fields Programmatically and the broader workflow in Using AI with WP-CLI for Faster WordPress Operations.

The leveraged time is not in the typing; it is in the test cycles. Each AI-generated script gets:

1. Dry-run on staging.
2. Real run on staging.
3. Verification of result on staging.
4. (Possibly) AI-generated additional checks based on what you saw.
5. Deployment to production through normal CI/PR flow.

The AI compresses steps 1-4 by 70-80%. Step 5 is the same as it ever was; do not skip it.

Workflow 6: Figma to component

Covered in detail in Turning Figma Designs Into WordPress Components Using AI. The dev's role: describe the design, review the AI's structural suggestions (which ACF field types, which template part conventions), iterate on the CSS until pixel-precise.

This workflow has the longest ramp on a new project because the AI needs to learn your CSS conventions, your Tailwind config (if you use it), and your design system tokens. Once it has them, subsequent components are fast.

The senior-review discipline

The single biggest pitfall: junior devs shipping AI-generated code without senior review, because the AI's output "looks fine." This is the exact failure mode that takes down agency quality reputation.

The rule that works:

• AI-generated code goes through the same code review as human-written code.
• The senior reviewer reads the diff line by line, not just skims.
• The reviewer asks "does this fit our patterns" not just "does this work."
• Any AI-generated code in security-sensitive paths (auth, payment, file upload, user data handling) gets extra scrutiny.

This is more discipline than was needed before AI, not less. The AI produces more code faster; the review burden goes up, not down.

What I will not delegate

• Architectural decisions. Should this be a Repeater or a separate post type? Should this be a Flexible Content layout or a custom block? The AI's first answer is often defensible but not always right; the developer chooses.
• ACF field group design decisions for new content models. The AI scaffolds; the developer designs.
• The senior-review pass on any code that ships.
• Production deploys without a pull request review.
• Security-sensitive code without line-by-line human review.

For the broader role-by-role agency view, see How Small WordPress Agencies Can Use AI in 2026, by Role. For the sysadmin side, see AI for WordPress Sysadmins. For SEO, see AI for WordPress SEO. For content workflows, see AI for WordPress Content Teams.