Build a WordPress Plugin with AI: Why It Takes More Than Cursor
AI (and Cursor) wrote the code—but making TLDRWP a great WordPress plugin took experience, taste, and user insight.
Subscribe with your favorite RSS reader:
Last year, I wrote this article about using AI to prototype a WordPress plugin. It was exploratory—curious about how far AI could take you from idea to code. At the time, it felt like magic, but also a little chaotic.
Fast forward to today: I’ve built a real, working plugin using AI—TLDRWP.
A WP plugin to allow viewers of a post click an AI button to generate a TLDR summary with your custom CTA messaging.
It generates short summaries for your posts using OpenAI. But unlike last time, I wasn’t just poking at possibilities. This was about building a product I’d actually use—and share.
I email once a week about my writings, it’s unique content you won’t get anywhere else, and I reply to every email I receive from those emails. If you’d like to hear more from me, subscribe here and let’s chat about how you can be more successful in your WordPress product business.
Subscribe
I used Cursor to do it. And while Cursor got me to the finish line, the final product only came together because I knew where to steer it.
How to Get Started
Want to build your own AI-powered WordPress plugin? Here’s how I kicked things off:
- Scaffold the boilerplate: I used OpenAI Codex to generate a basic plugin structure. This was my prompt:
Create a basic WordPress plugin boilerplate environment. It should include the ability to create a dynamic Gutenberg block, and the frontend will have an AI interaction, and I'd like it to require the AI Services plugin in order to hook into the AI of their choice- Version control: I created a GitHub repo to track progress from the beginning. I use Github Desktop for ease of use.
- Local dev environment: I pulled the code into a WP Studio site so I could work alongside my existing plugin stack.
- Tooling matters: I built the whole plugin from there with Cursor. In contrast to coding from AI prompts, Cursor has access to your whole project in order to pull directly from WordPress Core, your theme, or other plugins like in my case the AI Services plugin. That context is the game-changer when it comes to accurate and functional code.
I chose Cursor because of one thing: context. It holds onto the entire picture of your WordPress environment—theme files, plugin folders, helper libraries, the whole stack. That makes it far more useful than chat-based AI. Cursor is basically a fork of VS Code, so you’re working in a familiar IDE, but now your assistant sees everything you see. That context is what lets it write code that actually fits where you’re working.
If you’ve been wondering whether AI can actually help you build a real WordPress plugin—not just prototype one—this is for you.
From blank slate to working prototype in Cursor
The first step wasn’t AI. I used OpenAI Codex to scaffold a basic boilerplate plugin. It gave me a starting point—but that boilerplate tried to embed AI directly instead of creating a dependency on the AI Services plugin. Nevertheless, I had a decent plugin boilerplate to start from.
That’s when Cursor came in. With a bit of cleanup, I handed it the starting code and started prompting: “Make this plugin dependent on the AI Services plugin,” “Add these settings to the Settings → Reading screen,” and so on.
Cursor delivered. The plugin worked—and fast. It understood what I meant and implemented features accordingly.
But… the whole thing lived in a single PHP file. Over 1,200 lines long. No separation of concerns. No object-oriented structure. It was the definition of over-engineered spaghetti.
Lesson: AI will give you what you ask for—exactly. You still have to know what good looks like.
Getting feedback from humans (and the Plugin Check plugin)
Cursor wasn’t going to stop me from shipping bad code—it had no guardrails.
So first I fed Cursor the official best practices and asked, “Is this plugin overengineered?” It agreed—and mapped out a refactor plan. It was like a huge 7-step refactor! It took quite a bit of time even with AI’s help to get the plugin into a more common and performant file structure and to be more lean and object oriented.
That’s when the real work started: I spent hours migrating the code to a better architecture, leaning on Cursor to walk me through OOP refactors. Here’s a decent example showing how it hooked into the AI Services plugin:
/**
* Get the selected AI model or fallback to first available.
*
* @return string
*/
public function get_selected_ai_model() {
$selected_platform = $this->get_selected_ai_platform();
if ( empty( $selected_platform ) ) {
return '';
}
$available_models = $this->get_available_ai_models( $selected_platform );
// If no model is selected or the selected model is no longer available
if ( empty( $this->plugin->settings['selected_ai_model'] ) || ! isset( $available_models[ $this->plugin->settings['selected_ai_model'] ] ) ) {
// Return the first available model, or empty string if none available
return ! empty( $available_models ) ? array_keys( $available_models )[0] : '';
}
return $this->plugin->settings['selected_ai_model'];
}
Next, I ran the plugin through the Plugin Check plugin. Keep in mind, any new plugin submitted to the Plugin Directory now has to pass the Plugin Check tests, so might as well see if AI can do that!
Sure enough, I ran the test and “Boom”: lack of proper escaping issues, internationalization issues, and more. The Plugin Check plugin really has come a long ways and has become extremely useful – every product owner should leverage this on their plugin regularly.
Lesson: AI doesn’t know the WordPress way unless you tell it. You need guardrails and context.
Building features is easy—building products isn’t
[Video: walkthrough of TLDR]
Adding features with AI is like snapping LEGO bricks together.
But here’s the twist: when I asked friends and followers what they’d actually want, the answers weren’t what I built. Quite a few folks didn’t want TLDRs generated on the frontend—they preferred a static version created in the admin.
Some users on X giving initial feedback to the TLDR concept
That insight didn’t come from Cursor. It came from real humans.
Along the way, I added a few human touches Cursor didn’t suggest—but they made a big difference:
- I added custom action hooks in the TLDR output so others could extend or customize the behavior in their own plugins.
- I triggered a custom JavaScript event when a TLDR is generated. That way, developers can hook into analytics platforms like Google Analytics or Plausible. I even included example snippets for both.
- To track TLDR interactions without using cookies or bloating the database, I used
localStorage. It prevents users from triggering the same TLDR multiple times and conserves API usage—a small but meaningful privacy win.
These weren’t just afterthoughts—they’re the kind of decisions that come from building with users in mind, not just building what’s possible.
Lesson: AI doesn’t interview users. You do.
Tiny choices, big impact: Making it feel like WordPress
AI could’ve built me a top-level menu for settings. But I chose to put the TLDRWP settings under Settings → Reading.
Why? Because WordPress users have “admin menu fatigue.” Seriously. Not every single tiny plugin you install needs it’s own root-level admin menu item!
In this case, I felt I could even skip being a sub-menu under the general “Settings” menu. Afterall, TLDRs affect how content is read—not written, not managed.
Being in the “Settings → Reading” screen felt important. That little decision makes the plugin feel like it belongs in WordPress. Of course, that’s a little bit of a subject call, you might not find that very intuitive, but there’s other things I’ve done to help steer users to the right place regardless.
This type of product decision is something you do because of your experience with common WordPress users, not because of AI. Cursor would never make that call on its own.
Lesson: Great plugins aren’t just functional—they feel right. That takes taste, discernment, and experience with real users.
What I’d tell someone who wants to build plugins with AI today
If you’re reading this today because you want to build WordPress plugins with AI, then I have some quick tips for you:
- Use AI to accelerate and prototype, not ship. Treat it like a power tool, not a polishing and finishing tool
- Start with a solid idea, and prompt with detail. With Cursor I very often start a prompt saying “Don’t code anything, first tell me X”.
- User test every single thing Cursor does before committing it locally. There’s plenty of time when it’s undone something previously or had accidental side effects because the changes were too massive.
- Don’t ask Cursor to do too much at once, keep your prompts very narrowly focused.
- Bring in real users early—and other devs for review.
- Expect to refactor. Expect to revise. That’s not failure—it’s design.
Most importantly, consider what you built a prototype at best. It’s not a “real” plugin until you get a REAL developer to audit and improve it.
Lesson: AI can be your power tool—but you still need craftsmanship to build something people want.
🧠 Want to build your own TLDR plugin? Start here:
- Fork the TLDRWP GitHub repo: mathetos/tldrwp
- Key file:
includes/class-tldr-generator.phpshows the AI integration - Plugin Check: Use it early and often → Plugin Check plugin
The real magic is AI + experience
Cursor helped me build TLDRWP. But my experience building WordPress products is what made it usable.
Knowing what features to include, how to structure the code, where to place settings, and how users would actually use the plugin—that didn’t come from AI.
It came from doing the work, asking questions, and listening.
And that’s the secret: AI gets you there faster. But only if you already know where you’re going.
I send one email a week with original content I don’t publish anywhere else. I read and reply to every response—so if you’re growing a WordPress product business, subscribe and let’s talk.
Subscribe
Subscribe with your favorite RSS reader:
