My colleague told me a funny story about AI and the block editor.
One of our clients wanted to post some YouTube videos on their site, but they wanted a sort of carousel- one video in the hero section with the option to click thumbnails that would swap out which video is loaded. Their strategy? Have ChatGPT write the code and then paste it all into an HTML block in WordPress (including the JavaScript and CSS).
The thing is… it mostly worked. There were accessibility issues and bugs- switching to a new video left the old video playing somewhere in the background- but for the most part it worked. The biggest gap was that once they had the code inside WordPress, it was really hard to add or rearrange the videos, or to update the functionality. In other words, it was just the frontend code. It didn’t come with an editing experience.
Last week I spoke in-depth with Matt Medeiros about what AI was about to do to the WordPress ecosystem, when non-developers and even non-technical users suddenly have the ability to summon functional code as if by magic. He recently built an RSS feed aggregator on a platform called Replit, where an AI agent wrote all React/Next.js code for him and connected it to a database.
This is the sort of thing that traditionally would’ve been perfect for a CMS like WordPress, but it would’ve required testing different plugins, messing around in settings screens, and even finding proper hosting. An AI agent on a hosted platform like Replit solves a lot of that.
But as Matt learned, there’s more to just generating the code, there’s also the user admin experience, something you don’t get out of the box with other developer frameworks.
Here’s an (edited for clarity) transcript of our conversation around the 38 minute mark, where Matt starts to explain some of the shortcomings of the AI agent approach:
Matt:
I didn’t have a dashboard to see the feeds. I would just prompt it and say, add this feed. I didn’t need a dashboard. But obviously what happened was, oh, all of a sudden I need to rename the feed. Or I was running into feeds with errors. So I had to spend time like educating the feed parser to find errors and if there’s errors, report them to me.And then, I used to have the AI prompts in the code. The code would have the prompt that I generated and it would just shoot it out to my API and summarize the articles that way. And I was like, I don’t like what I’m getting back from that prompt, but I don’t wanna be in the code every single time. So make me a settings dashboard that allows me to go in and create my own prompts and I can change these out at will.
Now I store all the article content, summaries and social posts in the database. It’s got five hundred and thirty-ish articles in the database. So when I launched a new categorization feature, it doesn’t know to actually go back and label all the articles. So I had to create a “bulk generation” feature that started creating the categories.
Brian:
You’re living my day job experience. Somebody wants a feature and you have to explain to them, okay, well you don’t want just that feature. You actually want 10 features because we need to log it. We need to manage it. It’s not just the feature. There’s so much more that goes into it.
AI is fantastic at prototypes, at new development, at quick and dirty code. AI tends to build from scratch.
There’s no reason to assume it won’t keep getting better, but ultimately there are always going to be limits that aren’t solved by more blind coding. Those limits are the user experience, the maintenance, the reliability and scalability, security, and simply just knowing what to ask it to build in the first place.
Sure, plenty of people want to build their own website as a DIY project, but most of those websites are not high value. They aren’t going to attract high traffic or make money with optimized conversion rates, etc. Similarly, everyone will have the ability to create new software applications, but they will still be limited by their own understanding of what makes a successful app. For more critical websites and apps, experts will be needed, experts who know what to build, even if they use AI to do it.
I believe WordPress should do what it always does: focus on building out the foundational tools, for DIYers and experts alike. I believe this is where WordPress has a huge competitive advantage, if it understands where it currently falls short.
Imagine if instead of custom HTML, AI could generate new custom Gutenberg blocks on the fly- blocks built properly for accessibility and performance. Imagine if instead of using a tool like Replit to build an RSS aggregator app, an AI built it on top of WordPress, with all the user authentication, admin UI, and content management structure that comes for free in WordPress.
I think it’s possible, but I’ve outlined a few key areas that I think we need to focus on. This list is fluid and I would love to hear from others who’ve thought about this more deeply.
Rigid HTML/CSS Structures
To make sure that WordPress content is editable in the block editor, we have a rigid HTML structure for blocks. Inline HTML comments that include serialized JSON, very specific attributes, rules for structure and nesting. Most AI apps just spit out pretty generic markup, usually with a CSS library like Tailwind. The block editor doesn’t have a unified design system, and the class-based styles we do have are confusing and contradictory, and often differ from theme to theme.
It takes extra work to get AI to understand the nuances of writing and designing block markup, so the AI-generated landing pages in WordPress are still pretty limited and rely on pulling from pre-built templates. It’s going to be time for WordPress to consider including a more unified design system than what theme.json
currently offers.
Serving JavaScript
It’s been interesting to see that many of these tools lean on JavaScript over PHP (React over Laravel, for example) when it comes to building apps. It makes sense. Most people think in terms of frontend- the UI, the interactivity, the app-like experience. I like to think that PHP is more powerful, but it often handles more of the server logic, with the frontend powered by JavaScript.
This is not how the frontend of a WordPress site works, though. A purely JavaScript app is served differently than traditional WordPress. A lot of what you’re seeing in these no-code tools are deployed on node.js servers. When WordPress uses React in the block editor, we typically use a local development environment and a build process to prepare it to run clientside. Even writing a custom block requires a combo of different PHP and JS files bundled and built and enqueued into the block editor. Add to that the ACF Block experience, which might have block field definitions in the database or an acf-json file somewhere else.
We’re going to need a simplified approach to custom blocks that deals with the fact that in a CMS, there’s an interplay between code and database content.
Revisions & staging sites
Most AI code platforms come with a built-in revisions system. But so does WordPress! The flip side is that revisions in WordPress only work for content, not code.
In a tool like Bolt or Replit, you can continually iterate on your code, but you don’t have to publish it until you’re ready. With WordPress, a user might want to generate a new block or landing page, so we need new code written AND new content, but we need to be able to test it out without breaking our live website.
This might be an infrastructure issue, or it might be a problem that could be solved by WordPress Playground. In either case, revisions needs to get a lot more powerful.
Thin documentation
The Block Editor Handbook feels exhaustive, but most WordPress developers would agree that it’s not comprehensive. Unlike classic WordPress, there is a LOT of functionality in the block editor that is undocumented or poorly explained.
There’s been an argument that because WordPress is open source, AI will be better at writing code for it. So far, that hasn’t proven true. There’s a lot of bad and inconsistent WordPress code out there, and every AI has already been training on it. There’s not nearly enough “modern” (Gutenberg) WordPress code either.
On the flip side, I would bet that we could focus on using AI to generate the documentation and examples that it needs to better understand the block editor, and perhaps we could build a community database of proper code examples that we could all benefit from.
Limited extensibility
Earlier I said that having an existing user interface is a benefit for WordPress, and it is. But it’s also a bit of a curse. Right now with a JavaScript apps you build everything from scratch, meaning anything feels possible. In WordPress, you can’t even add new screens or UI elements to Gutenberg. You can’t add to the menu to build a Gutenberg-powered settings page, or tweak the user interface around the content area. You can’t register content types or add custom fields or metadata. This lack of extensibility is only going to make it even less likely that AI can build what people are imagining, often sending them back and forth between modern and classic WordPress for basic settings pages.
This is further compounded by the file structure. With WordPress, functionality is spread between the legacy code, custom plugins, custom themes, and even stuffed in the database with plugins like ACF or Code Snippets. You can’t edit most of WordPress, but the code isn’t hidden away in a node_modules
or vendor
folder – it is the foundational structure. I assume this is just another layer of training that we’re going to need to build specifically for WordPress, another hurdle in our path.
So there we have it! This is a bit of a rushed-off stream of consciousness article. There’s probably a lot more I’m not thinking of, and there’s probably smarter people than me working on it (Felix Arntz and James LePage, you’re my only hope!).
I think these are solvable problems, but they need solving. A few top level areas I’d be focusing on:
- Unified design system in the block editor (remember that?)
- Writing JavaScript & PHP and serving it all effectively
- Handling revisions and easier staging environments.
- Better documentation/code examples to train on
- Gutenberg extensibility (even just custom settings pages/routes)
Please sound off in the comments below. Am I underestimating AI or am I missing something else? Let’s get the block editor ready for AI.
Leave a Reply