AI for WordPress Development: Plan, Build, and Review

AI assistants can draft WordPress theme templates, write plugin functions, and generate block editor code faster than you can type them. The quality depends almost entirely on how well you brief them. WordPress is opinionated about how it expects code to behave, and code that skips sanitization, escaping, or nonce checks is a security problem regardless of how cleanly it reads.

Keeping the architecture decisions and testing requirements for a WordPress project in a shared record means each development session starts with the same constraints. Tools like fenbs store those decisions outside any one chat, so they apply whether you are working in Claude, Cursor, or another connected assistant. The AI brain overview explains why an external record matters across sessions.

Brief the assistant on your WordPress setup

Before the assistant writes anything, tell it the setup it is working in. A WordPress version, PHP version, and active plugins all affect what code is safe and correct. An assistant that assumes the latest WordPress and a clean install will produce code that conflicts with your actual environment.

• WordPress version and whether the site is on Classic Editor or the block editor.
• PHP version. PHP 8.x has strict typing rules that break code written for 7.x.
• Active plugins that the new code will interact with, extend, or depend on.
• The theme architecture: parent and child theme if relevant, or the base block theme.
• Any coding standards you follow, such as the WordPress Coding Standards for PHP.

Paste relevant function names or class structures from your existing codebase when the new code needs to extend or call them. Do not assume the assistant can infer your architecture from a description. Show it the relevant code.

Specifying themes and plugins

For theme work, tell the assistant which template hierarchy file you are editing, what the design requires, and whether the output will be in Classic PHP templates or block JSON. For block development, include the block name, the attributes it registers, and whether it is a dynamic block rendered in PHP or a static one.

For plugin work, describe the hook you are adding to, what the callback does, and any dependencies it needs. WordPress hooks fire in a specific order; a function hooked to the wrong priority or the wrong action produces subtle bugs that are hard to find without knowing the order.

For custom post types and taxonomies, give the full registration arguments you want, including capabilities, labels, and whether the type should appear in the REST API. The assistant will guess at defaults; tell it the ones that matter.

Security requirements

WordPress security is not optional, and it has a specific vocabulary. Every piece of code that outputs data must escape it with the right function for the context: esc_html(), esc_attr(), esc_url(), or wp_kses(). Every form must include a nonce. Every AJAX handler must verify the nonce and check the capability before acting.

Tell the assistant these requirements explicitly before it writes any output or form handling code. Ask it to explain which escaping function it chose for each output and why. If it cannot explain a choice, do not trust the output. Security issues that reach production in WordPress code are indexed by vulnerability scanners and exploited at scale.

Check the output of any AI-generated code against the WordPress security documentation before merging. The WordPress developer documentation has a security section with examples of the correct patterns; use that as your reference.

Reviewing generated WordPress code

Read every generated function before you run it. Check that hooks use the right priority, that database queries use $wpdb->prepare() for user-supplied data, and that REST endpoints register correct permission callbacks. A WordPress site with public-facing REST endpoints and missing permission checks is exploitable without authentication.

Test in a local environment before staging, and on staging before production. Use a local WordPress install or a container-based setup for initial tests. Browser-based testing catches rendering issues; code-level testing catches logic errors and security gaps. See the WordPress MCP guide for connecting your assistant directly to a WordPress environment.

Keeping architecture decisions across sessions

WordPress development produces a stream of small architectural decisions that compound over time. Which approach to use for custom fields. Whether to register a new post type or add a taxonomy to an existing one. How to structure the REST API namespace. Each choice constrains future choices.

When a decision is not recorded, a later session may choose differently, producing inconsistent code in the same codebase. Record each architectural choice with its reason as you make it. "We use a custom table rather than post meta for performance at this data volume" is the kind of decision that prevents a future session from reverting to post meta and creating a data model split.

How to do this with fenbs

1. Create a free account. Add a WordPress project with your version, PHP version, and the plugins the new code will interact with.
2. Write the security requirements as standing rules in Decisions and rules: nonce checks, escaping functions, capability checks. These apply to every session.
3. Add a task for each piece of work: the template to create, the plugin function to write, the security review to complete.
4. Connect your AI assistant over MCP from Integrations. Ask it to read the project context before each session.
5. At the end of each session, save progress: which tasks were completed, what was tested, and what the next session should tackle. Carry forward any open questions as tasks rather than leaving them in chat history.