How I Use AI to Extend WordPress Plugins (Without Forking Everything)
A WordPress developer's real workflow for using AI to extend and refactor plugins, including lessons from building WP-AutoInsight with three AI providers.
It’s 2023. I’m trying to learn more about OpenAI’s API. I learn by creating, so I had to create something that could be useful and somehow linked to what I know more: WordPress. Doing some research, I couldn’t find any open-sourced solution, 100% integrated with WordPress, and that had some important features: specific tone controls, category-aware output, and its own publishing schedule. Everything available was either locked-down SaaS or paid tools with no real customization.
So I built my own plugin.
That's how WP-AutoInsight started; as a single-provider, OpenAI-only plugin that handled scheduled post generation.
Version 1 was straightforward: API key in settings, a cron job, and some basic tone options. It worked. I showed it to some clients, and they liked it.
And then the requests came in.
"Can we use Claude instead of ChatGPT?" "Can it generate images too?" "Can it transcribe audio and turn that into a post?"
Each of those features could have been a separate plugin. Instead, I started using AI itself (Claude, Copilot, occasionally Gemini) to help me write, refactor, and extend the code. Version 3.2.0 now supports OpenAI, Claude, Gemini, Perplexity, plus DALL-E 3, Nano Banana, and Stability AI for images, with audio transcription and infographic generation as an extra.
None of that was planned in version 1.
Start With the Right Plugin
Before using AI to extend anything, the first question is whether you're extending the right plugin at all.
This sounds obvious, but it's easy to fall into a trap: you find a plugin that does 60% of what the client needs, decide to close the gap with AI-generated code, and three hours later, you're debugging hooks that weren't designed to be touched externally. The WordPress plugin ecosystem is large enough that another plugin often exists, one that already does 80% of what you need and has documented extension points. Look for that before you start extending.
A practical signal is documentation. Plugins with thorough docs usually have clean hook structures and established patterns that other developers have already figured out. That information is also available to your AI model — either from training data or by pasting relevant documentation directly into your prompt. A plugin with no docs isn't a dead end, but it means more back-and-forth.
Keep Your Code Out of the Plugin Folder You Didn't Write
Once you've identified what to extend, the structural decision matters more than the code itself.
The instinct is to paste custom code into functions.php. That works until you switch themes, and then you're doing manual archaeology trying to find which customizations you need to save. The better pattern, whether you're writing the code yourself or generating it with AI, is a standalone companion plugin that hooks into the target plugin's actions and filters.
AI is useful here because it can scaffold that companion plugin structure quickly. Give it the relevant source code or documentation, describe what you want to intercept, and ask it to write a plugin that uses the right hooks. The output usually lands at 70% usable. You test it, fix the edge cases it missed, handle the environment-specific issues it couldn't know about, and ship it. What would have taken a full day from scratch takes an afternoon.
The companion plugin approach also makes maintenance more tractable. When the original plugin updates, you're checking whether the hooks you're using still behave the same way — not untangling custom code mixed into someone else's architecture.
How AI Can Help, and Where It Falls Down
Using AI to extend WordPress plugins isn't the same as letting AI build plugins. The output requires someone who knows enough about WordPress plugin architecture to evaluate it.
What works well: refactoring. Feed Claude Code a function that grew too complex over six months, ask it to clean up the structure without changing the behavior. It respects WordPress conventions (sanitization, nonce verification, hook placement) well enough that the output is usually a solid starting point. For porting an existing integration to a new API, the pattern is even more straightforward: start from your working implementation, describe the differences in the new API spec, and ask it to adapt the code.
What falls down: edge cases and environment assumptions. AI doesn't know that your client's specific hosting configuration has certain PHP functions restricted. It doesn't know you have a third-party plugin running that conflicts with the approach it's suggesting. It doesn't know the client's WooCommerce install is three major versions behind. You still have to know those things, and you still have to test on staging before anything goes near production.
The value of using AI to expand a plugin is in letting it work on the tedious parts. You still are the developer behind the changes.
The WP-AutoInsight Case
WP-AutoInsight is the clearest example I have of this workflow playing out over time. Adding Gemini support to a plugin that already had OpenAI and Claude integrations meant starting from an existing provider implementation and adapting it — the API calls, the error handling, the model selection UI, and the way responses get formatted into post content. Claude handled the structural adaptation. I handled the routing bugs, the model-specific response format differences, and the fact that Gemini's streaming behavior isn't identical to OpenAI's.
The plugin now has features I never planned in the first version. That expansion was possible in a reasonable timeframe because AI absorbed the scaffolding work, and I focused on the parts that actually required judgment.
It's a sustainable ratio.
One Thing Worth Saying
AI-generated WordPress code needs a security review the same way any code does. Sanitize inputs. Verify nonces. Validate capabilities before touching data. AI models know these patterns and will usually apply them, but "usually" isn't good enough when the code runs on a client's production site. Spend the extra few minutes checking.
The WordPress Maintenance Strategy post I wrote covers some of the broader context around keeping customized installs stable over time — worth a read if you're regularly doing this kind of extension work for clients.
If you're working with WordPress plugins that need custom extensions, be it new integrations, refactoring inherited code, or adding AI capabilities, that's the kind of work I do.