How AI Agents Are Changing WordPress Development

The single most useful thing I can tell you about AI agents and WordPress is a sentence about what is missing. Across the documentation for Claude Code, OpenAI Codex, OpenCode, Cursor, GitHub Copilot, Devin and Antigravity, a search for WordPress, WooCommerce, WP-CLI and PHP returns nothing. Not a tutorial, not a supported-languages table, not one line in a changelog. Nobody in the AI tool business has written a page for the people who make their living in wp-content.

That absence confuses the argument. It gets read as "these tools cannot do PHP", which is wrong, or as "these tools are not for you", which is wronger. What it means is that every WordPress-specific workflow in existence right now was built by someone other than the agent vendors. Most of it was built by WordPress.

That inversion is the change worth understanding. The agents themselves got better at PHP in the ordinary way models get better at anything: more public code, longer context windows, tool use that can actually run a command. What changed on the WordPress side is that the project started publishing things an agent can consume, and those things did not exist eighteen months ago.

No vendor targets WordPress, so WordPress published the tooling itself

Start with what the researcher found when checking the vendor documentation directly, because it sets the frame for everything below. Claude Code: no mention of WordPress, none of PHP. Codex: the same. OpenCode, Cursor, Copilot: the same. Devin, which is what Windsurf became: the same. Antigravity, which replaced Gemini CLI: the same.

There is one partial exception and it is worth stating precisely because it is the only case. Aider lists .php in its supported-language table, with tree-sitter tags and repo-map support. Aider also has not shipped a release since August 2025, and its widely cited polyglot benchmark covers C++, Go, Java, JavaScript, Python and Rust. PHP is not in it. So the one agent that names PHP at all has no PHP benchmark, and the benchmark the ecosystem quotes when comparing agents has no PHP in it. If you have been looking for a number that tells you which agent writes better WordPress code, it does not exist. Nobody has published one.

What exists instead is a set of artifacts published by WordPress.org, the WordPress project and Automattic over the last year. Each one looks small on its own. Together they are the reason a WordPress developer can now point an agent at a plugin and get something back that survives contact with the Plugin Directory.

The plugin directory now has an official MCP server

The WordPress Plugin Handbook documents an MCP server at npx -y @wporg/mcp. It exposes the plugin guidelines, readme validation and submission status to an agent, and it configures itself into the MCP clients it knows about. The list of those clients is the interesting part: Claude Desktop, Claude Code, Cursor and VS Code. Two of the vendors on that list have never written the word WordPress in their own documentation. The integration is official in the direction that matters, which is that WordPress is the party declaring support.

Setup needs a WordPress.org account and Node 18 or newer. Two documented constraints are easy to trip over. The server is a workflow aid, not a fast lane: plugins submitted through it go through the same review as plugins submitted through the web form, and the Plugin Guidelines apply in full. And there is exactly one MCP application password per account at a time, so authorising again later revokes the previous password. If you have ever had a plugin rejected over a readme header, the readme validation alone is worth the setup.

WordPress wrote down what it will not accept from an agent

On 1 February 2026 the WordPress project published official AI contribution guidelines, maintained in the AI handbook on make.wordpress.org. Read them properly, because they are blunt in a way that corporate AI policies rarely are.

The first principle is that you are responsible for what you contribute: AI tools can assist, but they are not contributors, and AI output should be treated like code from an unknown external contributor. The second is disclosure: meaningful AI assistance gets declared in the pull request description or the Trac ticket. The third is licence compatibility, which for WordPress means GPLv2-or-later, including anything AI-assisted. Do not use a tool whose terms forbid using its output in a GPL-licensed project.

The fifth principle is the one to read twice. It is titled quality over volume, and it names the failure modes rather than gesturing at them: generic pull request descriptions that do not reflect real testing, large unreviewed code dumps, over-architected code where a simple solution would do, and hallucinated references to APIs, hooks, functions, tickets or links that do not exist. The consequence is stated without hedging either. Maintainers may close or reject contributions that appear to be AI slop.

The repositories now explain themselves to an agent

The third piece of WordPress-side tooling is the plainest: AGENTS.md files in WordPress's own repositories. The convention is a markdown file at the repository root that tells an agent how the project actually works. It is now stewarded by the Agentic AI Foundation under the Linux Foundation.

WordPress/gutenberg ships a 104-line AGENTS.md, a CLAUDE.md containing exactly one line (@AGENTS.md), and a .agents/skills/ directory with eight skills. The file is a good template because it records the things an agent would otherwise invent: the three editor layers where lower layers must not depend on higher ones, the site-editor parity rule that v1 and v2 routes have to change together, and the styles cascade that runs WordPress defaults, then theme.json, then user preferences.

It also contains a warning that applies to your plugin as much as to Gutenberg. The build never fails on type errors, so npm run build succeeding tells you something narrow, and you have to run the type check separately to learn anything about correctness.

wp-cli/wp-cli has a 140-line AGENTS.md and no CLAUDE.md. For anyone building a plugin this is the most directly useful WordPress-specific agent file in existence. It maps file changes to commands: a PHP file gets the coding standard and PHPStan, logic with unit coverage gets PHPUnit with a filter. It warns that the full test suite installs WordPress from scratch once per scenario and takes tens of minutes, so you should not run it to check a two-line change. And it says the thing every agent-driven workflow learns the hard way: a green test run is not the same as green CI, because other checks run on every pull request.

The real bottleneck is the feedback loop, not the model

Everything above is documentation. The part that decides whether this works on your site is whether the agent can run what it wrote.

The clearest evidence is a failure I keep coming back to. Asked to build a Gutenberg block plugin, one agent wrote its own test harness with hand-rolled stubs of wp_kses_post() and get_block_wrapper_attributes(), ran them, reported green, and then admitted in its own summary that it could not run its WP-CLI command because no WordPress was present. The stubs were faithful in that instance. The method is still broken, because an agent that stubs the framework is testing its beliefs about the framework, and it will confirm a wrong belief with the same confidence as a right one.

WordPress closed that gap deliberately. On 30 January 2026 WordPress News announced wp-playground, an official agent skill for running WordPress through the Playground CLI. On launch it starts WordPress, works out whether the repository holds a plugin or a theme by looking for a plugin header or a style.css, and mounts the code in the right place. It can log in automatically for admin work. The stated purpose is the honest one: agents work better when they have a clear feedback loop.

That is the piece to copy into your own setup, whatever agent you use. A mounted Playground, a wp-env instance or a local install with WP-CLI available turns "the agent says it works" into "the block rendered over HTTP and the CLI command returned the right row". The mechanisms for building that loop properly, from mounting the site to giving the agent error output worth reading, are what the course on WordPress development with AI agents works through module by module.

What has actually been demonstrated is narrower than the claims

The honest state of the art is one run. A researcher pointed OpenCode at a prompt describing a Gutenberg block plugin called Acme Notice, with no follow-up corrections, and got 14 files back. The plugin activated cleanly in real WordPress 7.1.3. The block registered. The WP-CLI command returned the correct row. The front end rendered over HTTP. Escaping held against a deliberately hostile attribute set: a CSS injection attempt was rejected by the generated colour validator and fell back to the default, and a <script> tag was stripped while <strong> survived.

That is a real result, and it is the best-documented WordPress agent run I can point at. It is also one run, one model, one task type. The task was a Gutenberg block with a dynamic render callback, close to the most-represented WordPress pattern in public code. The editor was never opened in a browser. WordPress Coding Standards were never run, because PHPCS and PHPStan were not installed on the machine. No theme was attempted, and theme.json is exactly the kind of fast-moving, low-volume schema where an agent is most likely to invent a key that was valid two releases ago.

Meanwhile WordPress's own scaffolder hands you a classic theme. wp scaffold _s produces 20 PHP template files, no theme.json, and a style.css header still declaring "Tested up to: 5.4". wp scaffold plugin is a fine modern starting point; the theme command is not.

What to do on Monday

1. Write an AGENTS.md for your repository, and start from wp-cli/wp-cli's rather than a generic template. Add the WPCS and PHPStan commands, the text domain, the prefix rules, and the exact command that proves a change works.
2. Give the agent a WordPress it can execute against. Playground, wp-env or a local install with WP-CLI is the highest-value hour you will spend on this.
3. Install WPCS and PHPStan as Composer dev dependencies and wire them into the agent's loop. PHP will not catch a wrong capability name for you, but a coding standard and a static analyser will catch more than php -l ever will.
4. Read the WordPress AI contribution guidelines once, even if you never open a pull request against core. Their failure list is the review checklist you want.
5. Treat a generated plugin as a pull request from someone who has never used WordPress, because that is the accurate model. Then verify it the way you would verify that pull request: on a running install, not in a test harness the agent wrote.