Tell me in 2010 that I would be writing production logic with a chat bot in a terminal and I would have laughed you out of the server room. AI WordPress plugin development has stopped being a gimmick for anyone who knows what to ask it for. After 14+ years of wrestling with the wp-content folder, anything that spares me from typing the same register_setting boilerplate again counts as a win.
Claude Code plus WordPress Studio gets you scaffolding, testing and refactoring a plugin in minutes. Below is how I set that stack up, and how to drive it without shipping something insecure or slow.
1. Preparing the local environment
You need somewhere to break things that is not a live site. WordPress Studio is what I use. It is free, and it manages local environments without the weight of the old VM-based tools, so the machine stays fast while you work.
Create a new site once Studio is running, then open the “Overview” tab and find the Terminal option. Opening the terminal from Studio means the environment variables are already set, which is the difference between WP-CLI or an AI assistant running cleanly and drowning you in permission errors.
2. Installing Claude Code
Claude Code is Anthropic’s terminal coding assistant. Unlike the web interface it reads your local file system directly, so it can open your wp-config.php (be careful with that), work through your hooks, and write files straight into the plugins directory.
The official installation guide has the native installer. After that, move to your site’s root directory in the terminal and run claude, then authenticate and trust the folder when it asks. If you want it looking at one new plugin and nothing else, start from /wp-content/plugins/ instead.
3. The reality of AI WordPress plugin development
Most tutorials stop at “prompt and ship,” which is how sites get hacked. In AI WordPress plugin development you are the architect and the model is the junior dev. It writes code quickly. Making sure the code is right is still your job.
Ask Claude for a plugin that shows a custom admin notice and you can get back something like this:
<?php
/*
Plugin Name: Naive Admin Notice
*/
add_action( 'admin_notices', function() {
$user = wp_get_current_user();
echo "<div class='notice notice-success'><p>Hello " . $user->display_name . "</p></div>";
} );
It works, and $user->display_name is also an XSS vector the moment a user with higher privileges edits it. Push Claude to refactor with esc_html() and real nonces on any settings page. I went into where those risks come from in WordPress Plugin Development in 2025.
4. Giving Claude the right context
Results improve a lot when you spell out the WordPress file structure. I say something like: “We are using WordPress Studio. Create a plugin folder named ‘bbioon-custom-logic’. Prefix all functions with ‘bbioon_’. Use a singleton pattern for the main class.” That level of detail keeps it from inventing odd folder layouts. There is more of this in my guide on Mastering Claude Code Context.
5. Blocks, and where Telex fits
For blocks rather than backend logic, Automattic’s Telex is worth a look. It generates blocks with a live preview in WordPress Playground, so you describe a pricing table or a hero section, adjust it visually, then download the plugin zip. It costs nothing, which makes it easy to keep alongside a Claude Code workflow.
If AI-assisted plugin work is eating your dev hours, I can take it on. I have been wrestling with WordPress since the 4.x days.
Where this lands
Claude Code and WordPress Studio speed you up. They do not spare you from knowing how hooks, filters and the database schema work, and they were never going to. What they buy you is more time on the business logic while the boilerplate writes itself. Start small, read every line it produces, and plugins that used to take days start taking hours.