Every few weeks someone posts to r/WordPress asking whether anyone is actually using Claude Code or Cursor for real WordPress development. Not prototyping. Not generating boilerplate. Actually using it as part of a daily workflow on real plugins, real themes, real client sites. The post always gets a lot of responses, most of them vague. “I tried it, pretty good.” “It hallucinated some hooks.” “Works better for React.”
This is not that kind of answer. I have been running Claude Code as my primary development environment for WordPress for about eight months. We maintain over 100 WordPress plugins. I use Claude Code on production codebases every day. Here is what the actual workflow looks like, what it does well, what it does not, and how it compares to Cursor for WordPress specifically.
What Claude Code Actually Is (Briefly)
Claude Code is a terminal-based AI coding agent. You run it in your shell, it reads your files, runs commands, edits code, and operates in an agentic loop, meaning it can plan and execute multi-step tasks without you approving each individual action. It is not a chat interface where you paste code. It is closer to a junior developer who has access to your entire codebase and can run commands.
That distinction matters for WordPress developers. Most AI coding tool comparisons benchmark it on React or Python projects. WordPress has a different set of challenges: a global function-based architecture, hooks and filters as the primary extension mechanism, PHPDoc everywhere, 20 years of backwards-compatible code patterns, and a codebase that spans procedural PHP, REST API endpoints, Gutenberg blocks, and WP-CLI commands. Claude Code handles this significantly better than tools that were primarily trained on modern framework code.
Setup: The Part Most Tutorials Skip
Most write-ups about Claude Code show you the installation command and then jump straight to demos. The setup that makes it actually useful for WordPress takes about 30 minutes the first time and makes every subsequent session dramatically more productive.
The CLAUDE.md File
This is the most underused feature. CLAUDE.md is a markdown file you place at the root of your project. Claude Code reads it at the start of every session. It is your way of giving the AI persistent context about how this codebase works, what conventions to follow, and what to avoid.
For a WordPress plugin, a good CLAUDE.md includes:
- The plugin’s architecture, main class name, how hooks are registered, what the folder structure means
- WordPress version and PHP version targets
- Coding standards in use (WPCS, PSR-12, custom rules)
- What the plugin does and what it explicitly does not do
- Any known quirks, deprecated functions still in use for backwards compatibility, third-party library versions, build tool setup
- How to run tests
- Forbidden patterns, things the AI should never do, like using
extract(), using$_REQUESTdirectly, or modifying global$wpdbqueries without proper table prefix handling
Without CLAUDE.md, every session starts from scratch. With it, you skip the “explain this codebase to me” phase entirely. For a complex WordPress plugin with 50+ files, that is not a small thing.
Here is what a practical CLAUDE.md looks like for a mid-complexity WordPress plugin:
This file takes about 20 minutes to write for an existing codebase. It saves that time back on the first Claude Code session and every session after.
Permission Mode and Tool Configuration
Claude Code has permission modes that control how autonomously it operates. For WordPress development I use a semi-autonomous mode: it can read files and run safe commands (tests, linting, WP-CLI read operations) without asking, but it prompts before editing files or running anything with side effects. This matters when you are working on a plugin that has a WP-CLI integration, you do not want the agent accidentally running wp option update against a real site.
Set up your allowed/denied command lists explicitly. For WordPress work, I allow: php, composer, phpcs, phpunit, WP-CLI read commands (wp option get, wp post list, wp plugin list). I deny: wp option update, wp user create, wp db query on anything that is not a local database, git push, git reset.
Real WordPress Use Cases That Actually Work
1. Reading and Extending Unfamiliar Plugins
This is the use case that converted me. When a client asks you to extend a plugin you have never seen before, the usual workflow is: read through the code, find the relevant hooks, figure out the data model, write the extension. That first phase, understanding the plugin, used to take an hour minimum for a medium-complexity plugin.
With Claude Code, I drop into the plugin directory and ask for a codebase walkthrough: what hooks are registered, what the data model looks like, what the main extension points are. It reads every file and gives me a structured answer in two to three minutes. Then I ask targeted questions: “where does the plugin store user preferences?” or “what hook fires after a form submission is processed?” It finds the answer by searching the actual code, not by guessing.
This alone recovered enough hours in the first month to pay for itself.
2. Hook and Filter Debugging
WordPress debugging is largely a process of tracing execution through hooks. Something is not firing at the right priority. A filter is being overridden by another plugin. An action is running before the data it needs is available. Claude Code is good at this because it can hold the full hook chain in context and reason about ordering.
My prompt pattern for hook debugging: “Here is the problem I am seeing [describe symptom]. Here is the hook I am using [show code]. Here are the other plugins active on this site that might interfere [list them]. Walk me through why this might be failing and what I should check.” It almost always identifies the right diagnostic direction on the first pass, usually a priority conflict, a conditional that is evaluating incorrectly, or a callback running in the wrong context (front-end vs admin).
3. Cross-Plugin Conflict Analysis
This is where the large context window becomes genuinely useful. With 1 million tokens of context, Claude Code can hold multiple plugin codebases simultaneously and reason about how they interact. We covered what the 1M context window means for WordPress developers in depth previously, for conflict analysis specifically, it means you can ask “why does this WooCommerce checkout extension conflict with this membership plugin” and have it actually trace the shared hooks, shared database tables, and overlapping output buffers that create the conflict.
Before this, conflict debugging meant manually diffing hook priorities and running bisection tests. Now I describe the conflict, give it both plugin files, and get a diagnosis in minutes. Not always correct on the first pass, but correct often enough to cut conflict resolution time by half.
4. Security Auditing Existing Code
Ask it to audit a plugin for common WordPress security vulnerabilities: missing nonce verification, direct user input in SQL queries, unescaped output, capability checks on AJAX handlers. It does this methodically and flags the right things. It also explains each issue in enough context that you understand why it is a vulnerability, not just where it is.
I pair this with PHPCS/WPCS automated scanning. The automated scanner catches patterns. Claude Code catches reasoning failures, places where the code follows the pattern but the logic is wrong, like a nonce check that is present but checks the wrong action string, or a capability check that gates the wrong operation.
5. Writing Tests for Legacy Code
Most WordPress plugins do not have tests. Writing tests for untested legacy code is tedious work: you have to understand every branch condition, mock WordPress globals, and write assertions for behavior that was never formally specified. Claude Code is unusually good at this.
Give it a function, ask for unit tests using Brain Monkey or WP_Mock, and it generates tests that cover the main paths and most edge cases. The tests are not always perfectly structured and sometimes need adjustment, but they are a genuine starting point rather than a blank file. For a team trying to add test coverage to an existing codebase, this is one of the highest-value uses of the tool.
What Claude Code Does Not Do Well for WordPress
Honest answer required here because most AI tool write-ups skip this section.
Gutenberg Block Development
Block development straddles PHP and JavaScript in ways that trip Claude Code up regularly. It handles the PHP side of block registration well. The JavaScript side, React-based block edit/save components, block.json configuration, the @wordpress/* package imports, is workable but needs more supervision. It sometimes generates block attributes that do not match the schema, or misuses deprecated block API patterns from older WordPress versions. You need to know the block API well enough to catch these errors.
WooCommerce Custom Checkout Flows
WooCommerce checkout is a minefield of overlapping hooks, JavaScript events, and session state that changes between WooCommerce versions. Claude Code can work in this area but makes more errors than elsewhere. Checkout hooks changed significantly in WooCommerce 8.3 with the blocks-based checkout, and the model’s training data is a mix of old and new patterns. Always verify checkout-related code against the current WooCommerce version’s documentation.
Multisite-Specific Logic
WordPress Multisite has its own set of functions, capabilities, and execution contexts that the model handles inconsistently. It knows the functions exist, but does not always use them correctly in context, for example, getting confused about when to use switch_to_blog(), or generating capability checks that work on single-site but break in network admin context. Multisite work needs careful review.
Long Autonomous Tasks Without Checkpoints
When you give Claude Code a large open-ended task, “refactor this entire plugin to use a service container pattern”, it will attempt it, but the result is often a mix of well-done sections and sections where it lost context about what it had already changed. Long autonomous tasks produce better results when broken into explicit phases with human review at each checkpoint, rather than run end-to-end.
MCP Servers: The Underrated Multiplier
Claude Code supports MCP (Model Context Protocol) servers, external tools that extend what the agent can access and do. For WordPress developers this is worth paying attention to because it means Claude Code can reach beyond the local filesystem.
The MCP servers that have made the most concrete difference for WordPress plugin work:
- GitHub MCP, lets Claude Code read issues, create PRs, check workflow run results, and search across repositories without you pasting anything. In practice: describe a bug, it finds the relevant issue, reads the linked PR, and checks whether the fix was actually merged.
- Filesystem MCP, extends read access beyond the current project directory. Useful when you need to compare implementation patterns across multiple plugins without switching directories.
- Playwright MCP, browser automation inside the agent loop. Lets Claude Code navigate to a WordPress admin page, click through a workflow, and screenshot the result. I use this for verifying that an admin settings page renders correctly after changes without manually loading a browser.
- Local database MCP, direct SQL query access to a local WordPress database. Ask “what does the current option value for this setting look like in the database” and get the answer immediately rather than running WP-CLI manually.
MCP servers are configured once in Claude Code’s settings and then available in every session. The setup is lightweight and the productivity gain is real, especially the GitHub integration, which removes the constant context-switching between terminal and browser when you are debugging against a specific reported issue.
Claude Code vs Cursor for WordPress Development
This is the comparison the Reddit thread was actually asking about, so a direct answer: they solve different problems and are not real substitutes for each other.
We have compared these tools in full detail previously, but for WordPress specifically: Cursor is better when you want inline AI assistance as you write code in a GUI editor. If you are actively writing a new plugin feature and want completions and inline suggestions, Cursor’s editor integration is superior. You stay in your familiar IDE environment, the completions are fast, and the context is whatever is currently in your editor window.
Claude Code is better for investigation and multi-file reasoning. When you are not writing new code but understanding existing code, debugging across files, auditing for issues, or executing a multi-step task that requires reading and editing multiple files in sequence, Claude Code’s agentic model handles it better. It can run WP-CLI commands, execute PHPCS, check test results, and edit files in a single loop. Cursor requires you to orchestrate those steps manually.
My actual setup: both. Cursor for active feature writing. Claude Code for debugging sessions, codebase audits, generating tests, and anything that requires reasoning across multiple files simultaneously. They complement each other more than they compete.
The Workflow That Stuck After Eight Months
Here is the actual daily pattern, not the idealized version:
Morning: Triage and Planning
I start Claude Code in the project directory with the bug or feature I am addressing. I do not paste a ticket, I describe what I am trying to accomplish and ask for a brief investigation: what is the current state of the relevant code, are there any obvious issues I should know about before starting, what approach would it suggest. This takes about five minutes and usually surfaces something I would have discovered 30 minutes into the work anyway.
During Development: Targeted, Not Autonomous
I use Claude Code for specific subtasks, not end-to-end feature implementation. Write a function that does X. Explain why this filter callback is receiving an unexpected value. Generate tests for this class. Add PHPCS-compliant docblocks to these functions. These targeted prompts produce reliable results. Open-ended prompts like “implement this feature” produce results that need heavy review.
Code Review: Pre-Commit Pass
Before committing, I run a quick audit: “review the changes in this working tree for security issues, WPCS violations, and anything that would break on PHP 7.4.” It catches things that PHPCS misses (logic errors, incorrect use of WordPress functions) and rarely produces false positives in this use case because it has the full context of what the change is supposed to do.
Managing Token Costs
This is a real consideration. Agentic Claude Code sessions that read large codebases use significant tokens. Practices that keep costs reasonable:
- Specify files explicitly. Instead of “look at the plugin and tell me why X is happening,” say “look at includes/class-my-plugin-api.php and explain why the request handler is returning null.” The second prompt uses a fraction of the tokens.
- Front-load context in CLAUDE.md. Every token you spend in prompts re-explaining architecture is a token you could have saved with a better CLAUDE.md. Treat it as a one-time investment that pays off across every future session.
- Match model to task. Use smaller, faster models for mechanical work, generating docblocks, reformatting arrays, adding missing return types. Reserve the main model for reasoning tasks that actually need it: debugging, cross-file analysis, security audits.
- End sessions cleanly. Long conversations with accumulated context get expensive. Start a new session when you switch to a different task rather than continuing one session across unrelated work.
Quick Start: First 30 Minutes
If you want to evaluate Claude Code for WordPress work without committing to a full workflow change, here is the fastest path to a genuine test:
- Install Claude Code and run it in an existing plugin directory you know well.
- Write a CLAUDE.md with the plugin’s architecture and forbidden patterns, take 15 minutes on this, it matters.
- Ask it to audit the plugin for WPCS violations and missing nonce verification. Compare the output to what PHPCS caught. The delta is what you are evaluating.
- Ask it to explain one hook registration chain in the plugin. If the explanation is accurate, the codebase understanding is working.
- Ask it to write one unit test for a function you know well. Review the test against your own mental model of what should be tested.
That sequence takes 30 minutes and tells you more about whether the tool fits your workflow than any benchmark or comparison article, including this one.
The Honest Summary
Claude Code is a genuinely useful tool for WordPress development. It is not magic and it is not a replacement for understanding WordPress internals, if you do not know how WordPress hooks work, Claude Code will not save you, because you will not be able to tell when it is wrong. But if you already know the platform well, it functions as a force multiplier for investigation, debugging, and the mechanical parts of development that slow down the work.
The developers who get the most out of it are the ones who treat it as a specialist tool with specific strengths rather than a general-purpose assistant. Ask it to do things it is good at, codebase analysis, security review, test generation, multi-file debugging, and it returns the investment. Ask it to autonomously implement complex features from scratch and you will spend as much time reviewing and fixing as you would have spent writing it yourself.
After eight months, it is the tool I reach for first when I am trying to understand something, and second when I am trying to build something. That is probably the right order.
AI Coding Assistants AI Coding Tools AI in WordPress AI Tooling
Last modified: March 22, 2026
