Last year I spent a lot of time in the “Getting Started” documentation for Woo developers. It made sense, since in many ways I was just getting started with Woo myself. Fast forward a year and with AI changing the developer landscape so much, it still feels like we’re all just “getting started” anew every single day.
Do templates and scaffolds still matter?
One place I focused attention on was cleaning up some of our templates for setting up things like admin pages and screens for Woo extensions. These are all currently built on top of the wordpress/create-block tool for scaffolding blocks, which was my top choice over the last few years for spinning up new projects in WordPress/Woo.
The downside of creating templates for create-block is that you build everything with these mustache files (so it can do things like string-replacements as it creates everything). That makes the scaffold itself a real pain to test and iterate on because you’re constantly jumping between the generated code and the fake templates with names like $slug.php.mustache. The template source doesn’t look and function like real code.
Now that we have coding agents, I still think templates are critical for showcasing good examples, but we really don’t need to worry about things like replacing strings in files or filenames. AI is great and doing that kind of automated labor. I’m reaching for create-block a lot less often now, but I’m always pointing my agent towards some repository or tutorial and saying “just do it like I/they did here!”
Personalized software
To stay fresh on my developer skills, I’ve been building a lot of small-purpose Woo extensions for my wife’s store. It’s all “personalized software” that’s mostly just useful to running her business more efficiently, calculating food costs, triaging orders by pickup dates, printing labels, stuff like that. It’s a lot of content management, only very personalized. After all, every app in the world is primarily some input fields, a list view, and a database somewhere.
Only some of these extensions need to run on Woo or WordPress, if they’re extending product functionality or adding frontend blocks. Others are the types of helper UIs I could “vibe code” and deploy anywhere. But why would I deploy things through a random SaaS like Replit, when I have Claude Code on my machine and I’m paying for a web server with a nice auth layer, content modeling, and database built in?
So I build a lot of my single-purpose apps on WordPress. I get to own the code completely and use the same tools and git deployment I’m already using. Plus it’s all there inside her store where everything else is managed. Even for smaller personal scripts I’m just opting for PHP over bash or Python, just in case I want to deploy it to a WordPress install.
How I’m using templates now
For the last few plugins I’ve built, I kept telling the agent to go look at my other plugins to learn how to set up this or that feature. It made me wish I did have a starter that fit my exact workflow, with the tools I reach for the most:
- React-based admin screens, preferably registered through Woo’s settings page API or as WP settings pages
- DataViews for managing some sort of list of things, usually hooked up to a private CPT or taxonomy so I can use core’s JavaScript data layer and REST API endpoints without writing my own
- Dynamic blocks with the Interactivity API are my default when I need frontend content on the site
- WordPress Scripts for the build process, with dependency extraction for WordPress and Woo, and the ability to build both admin screens and multiple blocks at once or as separate build commands
There’s a lot of stuff AI is already great at (registering post types, meta fields, API endpoints, testing that your JavaScript is building correctly), so there’s not a lot in those areas. I mostly focused on the areas it struggles with. The new stuff. The React stuff.
I’ll add two caveats:
- I’m aware there’s some newer stuff missing, like the new build tools and routing under the experimental “extensible site editor” feature, but unfortunately that’s just a bit too far into the future to reliably use right now. It looks like it’ll be much more opinionated about how things are built in the future (nice!), so I am keeping an eye on it.
- Even when it comes to DataViews, there’s not a lot of best practices out there, so this setup might be wrong. I just know it works for me, but would love to see more “official” examples to learn from. And the same for DataForms, which I’m hoping to add, too.
Now when I start a new plugin, I can just copy down the repo, launch Claude Code or Codex, and tell it what I want to build and what I’m going to call it. The repo includes agent instructions for where things go, what files to change, etc. (If you’re not using Woo, just tell an agent to update it to a regular WordPress admin screen.)
And I can always return to this scaffold and add to it, because it’s not a bunch of mustache syntax, it’s a fully functional plugin that I can tweak and test. If I find a cool new way to do something, I’ll just tell an agent to ‘look at how I’m doing this thing now and update my scaffold to match’.
I’ve published it on GitHub with the hope that anyone can use it or even fork and change it to suit their preferences. Or tell me all the ways I’m _doing_it_wrong.
I love create-block but I think we’ll have to reevaluate whether it’s the best approach for agentic coding, or if WordPress should just have an ‘agent code library’ with indexable (and functional) examples that eventually make their way into the training data. That’s one of the things we’re missing when compared to other frameworks, there’s just not a lot of good example repos/tutorials for modern WordPress admin and block development. And it’s not in a central location.
Can WordPress be a vibe-coding platform?
It’s gotten me thinking about what would need to happen for WordPress to truly be a ‘vibe-coding’ platform of the future.
To be clear: I don’t think WordPress should try to compete with tools like Replit or Lovable. The ‘blank slate’ advantage of those tools is their competitive advantage. WordPress has a different competitive advantage, which is that it’s a fantastic content management system and e-commerce platform that can handle complexity and integrate with pretty much anything.
WordPress- and especially the block editor- has always had the harder job of being both a front-end presentation (landing pages! blog posts!) and an application itself that provides a user-friendly UI for non-technical content managers. Everything you build on WordPress typically needs to address those two uses (just like the old WordPress Plugin Boilerplate separated code into public and admin). It’s a lot of context to carry around in your head.
A lot of hosting companies are building bespoke, hosted AI site and block builders, and I understand that these are really targeted to onboarding new users. Because I’m more of a ‘developer’ than a ‘user’ of WordPress, those tools just don’t speak to me. I’m also wondering what it looks like in six months: does a novice user even go to a landing page to build a new site through someone else’s AI, or do they just ask the agent they’re already working with to go build it for them?
The difference here is between asking “what can I do for this AI client to make it interact with WordPress more successfully” and “what can we do for WordPress itself to make any agent with it more successfully.”
In terms of interacting with WordPress data and functionality from an external connection, the Core AI team has been doing a fantastic job. What I’m more narrowly focused on is any LLM’s ability to create new user interfaces and designs using the tools of WordPress (as easily as it can with some generic React + Tailwind). AI can write me a fantastic WP-CLI command, but man it struggles to build an interactive admin screen or a block-based page.
As tools like Claude Code and Codex are becoming more mainstream- and their underlying models become more powerful- it’s hard to see if a “site building AI” is even a moat worth building. I’d rather see everyone in WordPress work to make sure core’s UI components (blocks, patterns, and all the admin components) are dead simple for any model to use successfully- through strong documentation and a more robust library of common examples. That will benefit our ecosystem more broadly by focusing on empowering existing users to supercharge their sites, who become our biggest cheerleaders.
Anyway, that was a long tangent that should probably get its own post. Here’s my current starter Woo extension if you want to fork it or open it in WordPress Playground. Let me know what you think and what you typically include in your boilerplates.
Leave a Reply