I’ve been building WordPress plugins for over six years. For the last year or so, Claude has been part of my daily workflow. Not in the “AI does everything” way you see in Twitter threads — more like having a senior developer available at any hour who’s read every piece of WordPress documentation and has strong opinions about code quality.
This post is about what actually works, what doesn’t, and how I’ve set things up so Claude is genuinely useful rather than just fast at producing plausible-looking code I then have to fix.
Let me be direct about where Claude earns its place in my workflow and where I’ve stopped bothering.
Starting a new plugin used to mean copying from an old one and spending 20 minutes cleaning up the parts that don’t apply. Now I describe what the plugin needs to do and ask Claude to scaffold the folder structure, main plugin file, and class skeleton. The output isn’t always exactly how I’d write it, but it gets me to 80% in two minutes instead of twenty.
The prompt I use for this:
I'm building a WordPress plugin called "Plugin Name" with these requirements:
- PSR-4 autoloading, namespace PluginNamespace\
- Main plugin file: mainfile.php
- Admin settings page using the Settings API
- A REST API endpoint to serve the feed as XML
- Freemium structure (free core, pro features behind a license check)
Generate the folder structure and main plugin file with proper plugin headers,
autoloading setup, and singleton pattern. Use WordPress coding standards.That level of specificity matters. Vague prompts get vague scaffolding. The more context you give — namespace, architecture decisions, specific WordPress APIs you want used — the less cleanup you do afterward.
This is where Claude saves me the most time. WordPress has thousands of hooks, and remembering the exact signature, priority, and accepted arguments for each one is genuinely tedious. I’ll describe what I need to happen and ask for the hook implementation:
I need to add a custom column to the WooCommerce orders list that shows a custom
meta field called _feed_export_status. The column should display "Exported" or
"Pending" based on the meta value. Use the correct HPOS-compatible hooks.Claude knows the HPOS column hooks versus the legacy post-based ones, which order the filter arguments come in, and that I need to handle both admin and AJAX contexts. I still review the output — I’ve caught wrong priority numbers and the occasional deprecated function — but the structure is always right.
This is the one I was most skeptical about. Pasting an error log into a chat window felt like a long shot. In practice it works better than I expected, especially for errors in WooCommerce or WordPress core where the stack trace points to a function I didn’t write.
What I do: paste the full error with stack trace, then paste the relevant section of my code, then ask what’s wrong. The key is not asking “what’s wrong with my code” in the abstract — Claude needs the actual error text and the actual code. Half the time it spots something I was looking right at and missing.
Where it fails: when the bug is in how two plugins interact, or when the error is caused by something upstream in WordPress core that my code is reacting to. For those I still rely on Query Monitor and old-fashioned var_dump().
Before I ship any form handler or AJAX endpoint, I paste it into Claude and ask specifically: “Review this for missing nonce verification, unsanitized input, and unescaped output.” Not a general “is this secure” question — a specific checklist. The response catches things. Not everything, but enough that I now do this as a standard step.
I wrote a full guide on WordPress plugin security covering nonces, sanitization, and escaping — Claude helped me review every code example in that post before publishing.
PHPDoc blocks, README files, inline comments. I write the code, then ask Claude to document it. I give it the actual function and tell it the audience — “write PHPDoc for this, the audience is developers extending this plugin via filters.” The output is good and I spend maybe two minutes editing it rather than ten minutes writing it from scratch.
The biggest improvement to my results came from using Claude Skills. A Skill is a markdown file that loads into Claude’s context before you start working — essentially a reference document it can consult while helping you. I have a WordPress development skill that contains my preferred conventions: namespace patterns, how I structure plugin files, which sanitization functions to use for which data types, my preferred hook registration pattern.
Before I set that up, Claude would occasionally suggest patterns that work fine in generic WordPress but don’t fit how I actually build things. After — the scaffolding matches my conventions, the security patterns match what I use, and I spend less time saying “actually I prefer it this way.”
I’ll cover Skills properly in a separate post — what they are and how to build one — but the short version is: if you use Claude regularly for a specific type of work, a Skill is worth the hour it takes to write.
I want to be honest about the limitations because most AI content skips this part.
Claude doesn’t know your codebase. Every conversation starts fresh. For anything that requires understanding how your specific plugin’s classes relate to each other — a refactor that touches eight files, a bug that spans multiple systems — you have to paste a lot of context and even then it’s working with an incomplete picture. Claude Code (the CLI tool) handles this better because it can read your actual files, but in the chat interface you’re always manually providing context.
It sometimes hallucinates WordPress functions. Not often, but it happens — usually with less common APIs or very recent additions. I’ve been given a function name that doesn’t exist, a hook that fires in a different place than described, an argument order that’s wrong. The fix is simple: always test the code before shipping it. But if you’re copying Claude’s output directly to production without checking, you will eventually have a bad day.
It’s not great at architectural decisions. “Should this be a custom post type or a custom database table?” is a question where I want a developer who knows my project, my scale, and my client’s technical team. Claude will give you an answer but it’s necessarily based on incomplete information. For decisions that are hard to undo, I trust my own judgment or ask a human developer.
A few things I’ve learned that changed my results significantly:
Give it the context it needs to care about. “Write a WordPress function” is almost useless. “Write a WordPress function for a commercial plugin targeting WooCommerce stores on PHP 8.1+, following WordPress coding standards, with proper sanitization and a nonce check” is what actually produces code I can use.
Ask for one thing at a time. “Build me a complete settings page with AJAX saving, a custom REST endpoint, and email notifications” produces worse code than asking for each piece separately. Claude tries to do everything at once and cuts corners. Break it up.
Tell it what you don’t want. “Don’t use jQuery, don’t use deprecated functions, don’t add inline styles” cuts out a surprising amount of cleanup.
Ask it to explain before it writes. For anything non-trivial, I ask “before writing the code, explain how you’d approach this.” If the approach is wrong, I correct it before it writes 100 lines I have to redo. This sounds slower but it isn’t.
Here’s a prompt that produced code I used almost unchanged:
I need a meta box for a custom post type called 'event'. The meta box should:
- Appear on the event edit screen, titled "Event Details"
- Have three fields: event_date (date picker), event_location (text), event_capacity (number)
- Save the fields on post save with nonce verification and sanitization
- Load saved values when the edit screen loads
Use add_meta_box(), a class-based approach with the constructor registering
hooks, proper nonce field naming, absint() for capacity, sanitize_text_field()
for location, sanitize_text_field() for date. No jQuery — use the browser's
native date input.The output needed one small fix (it used get_post_meta without the third argument defaulting correctly) but otherwise went straight into the plugin. Total time: about 90 seconds. Writing that from scratch would have taken 10–15 minutes.
The meta box pattern itself is covered in detail in the WordPress custom meta box guide if you want to understand what Claude produced before using it.
For WordPress plugin development specifically: yes, with caveats. It’s fastest for things with clear patterns — hooks, settings pages, meta boxes, REST endpoints — where WordPress has a defined way to do something and Claude knows it. It’s slower than just doing it yourself for things that require judgment, project-specific knowledge, or architectural thinking.
I’d estimate it saves me two to three hours per week on a typical plugin project. Not because it writes all the code, but because it eliminates the friction of looking up exact API signatures, writing boilerplate I’ve written a hundred times before, and doing a first pass on documentation.
The developers I know who get the most out of it treat it like a capable junior who needs supervision rather than an oracle who’s always right. You review the work. You catch the mistakes. The difference is you’re catching them in 30 seconds instead of writing the original code from scratch over 15 minutes. That’s the actual value — not intelligence, just speed on the boring parts.
Claude Sonnet 4 is my default — it’s fast enough that the wait doesn’t break your flow, and the code quality is good for most WordPress work. For complex architectural questions or code reviews where I want it to think harder, I’ll switch to Claude Opus. For quick lookups (“what’s the hook for X”) Sonnet is more than enough.
They’re different tools. Copilot works inline in your editor — it autocompletes as you type. Claude is better for longer conversations: “here’s my class, here are the requirements, write the next method.” I use both. Copilot for line-by-line autocomplete, Claude for anything that needs context or explanation. Trying to pick one over the other misses that they solve different friction points.
It has a knowledge cutoff, so very recent releases may not be fully covered. For anything that changed in the last six months — HPOS order storage, the Interactivity API, new block editor APIs — I verify against the official docs rather than taking Claude’s output on faith. For established patterns (hooks, the Settings API, WP_Query) the knowledge is solid.
Yes, and it’s quite good at it. WooCommerce has well-documented patterns and Claude knows them — WooCommerce hooks, the WC_Product class API, payment gateway structure, the order data model. The same caveat applies: anything that changed very recently needs verification against WooCommerce’s developer docs.
I’m Kamal, a WordPress developer focused on plugins, APIs, and scalable products.
Learn More