AI Can Design a WordPress Site. It Still Doesn't Know Where the Design Should Live.

I've been a WordPress guy for a long time. Long enough to remember when the question wasn't "will AI replace WordPress" but "will WordPress survive the next platform shift, the next CMS war, the next predicted death." It always has. And it will this time, too.

WordPress 7 is coming. The AI features are real. Block-level AI assistance, content generation built into the editor, smarter media handling, better search, and a dozen other improvements that will make the day-to-day experience of running a WordPress site feel meaningfully different than it does today.

But the hardest problem in WordPress isn't content. It's design.

Let me explain why.

The Easy Wins Are Already Here

Most of the AI-in-WordPress conversation right now is about the easy wins. And to be clear: they're real wins. They're just easy.

AI is great at writing alt text. It's great at generating meta descriptions, suggesting internal links, summarizing posts, translating content, and producing first drafts that a human can polish. It's great at indexing pages and recommending SEO improvements. It's great at building little custom features—a calculator here, a quiz there, a form that does something clever.

These features are showing up everywhere. Every SEO plugin has an AI button now. Every page builder has a "generate with AI" option. Every form plugin can explain its own outputs. The marketplace is in full AI-feature land grab mode, and that's fine—competition is good, and the resulting features genuinely help site owners ship faster.

There's a secondary concern about plugin proliferation. Every AI feature you bolt on adds dependencies. Every dependency is a future maintenance burden. The agencies and site owners who win over the next five years will be the ones who treat plugin discipline as seriously as they treat content strategy. But that's a governance problem, not a technology problem. It's solvable.

The harder problem—the one that doesn't get solved by adding another AI plugin to your stack—is design.

Why Design Is Different

Here's the part most AI-WordPress conversations skip. When you ask AI to write content, there's one place the content goes: the post body. When you ask AI to add alt text, there's one place it goes: the alt attribute. When you ask AI to generate a meta description, there's one place: the meta field.

But when you ask AI to implement a design? There are six valid places that spacing value could live.

It could be in theme.json as a global token. It could be in a block's inline attributes. It could be in a child block, or a parent group block. It could be in a global style variation, in a block style preset, or in custom CSS added to the theme. Each of these locations is technically valid. Each renders identically on the front end. And each has different implications for how the site can be edited, maintained, and evolved over time.

This is the part that breaks AI implementation in WordPress. Not the creativity. The architecture.

A creative AI tool can generate a beautiful design. We've seen that. Claude can produce gorgeous layouts. The output looks great. But when that design lands inside WordPress, it has to be implemented somewhere—and the choice of where determines whether the site stays maintainable for the next five years or becomes an unmaintainable mess by month six.

The Drift Problem

Here's what happens to most WordPress sites built without architectural discipline.

Page one is built clean. Spacing comes from theme.json. Colors use design tokens. Patterns are reusable.

Page two gets built a few weeks later, by a different person, using AI (maybe a different LLM or the same one but with different history). They put the spacing inline because it was faster. The color is hardcoded because the LLM made the call, and it worked.

Page three gets edited by the client. You had shown them how to copy a page and change text. But they wanted to tweak a paragraph style, and they did it in a block attribute.

A junior designer on your team took a screenshot of a page, passed it to their ChatGPT or Claude, and told them to use the MCP to create a similar one but with all the designer's changes. It looked good, but padding, spacing, and even custom CSS were all placed in different locations.

Multiply this across 40 pages and a year of edits, and you have a site where the same design decision is encoded in seven different places. The site looks fine on the front end. Renders correctly. Loads fast. Passes accessibility checks.

But the moment you need to change something globally—update the brand color, increase header spacing across the site, swap a font—it becomes archaeology. Some pages respond to the global change. Some have inline overrides that ignore it. Some have parent-block overrides that override the inline overrides. Some have custom CSS from a fix someone made in 2025 to solve a mobile bug nobody remembers.

The cost of inconsistent implementation isn't paid when the site is built. It's paid every time the site needs to change. And sites always need to change.

This was already the dynamic before AI. AI just compresses the timeline. What used to take three years of human drift now takes three months of AI-assisted page generation. The disease was always there. AI is the fever that makes it visible.

Why WordPress 7's AI Features Won't Fix This

The AI features are going to be useful, and a lot of them are going to be excellent. But the design implementation problem isn't a feature gap. It's a foundation problem.

You can add the smartest AI in the world to the block editor. If the block editor still allows spacing values to be set in six valid places with no enforcement of which is canonical, the AI will generate sites that drift just like humans do. Maybe faster, because AI is faster.

What's needed isn't smarter AI. It's a more constrained core. A WordPress environment where there's a single, deterministic answer to "where does this value live"—and where AI implementations are forced to comply with that answer. But that's not going to happen.

This is where the conversation gets interesting. Because two companies are actually solving this. And they're solving it in genuinely different ways, for genuinely different users.

Option One: ByMiles

The first solution is ByMiles. The pitch is simple: you talk to an AI about what you want for your site. It generates several design options. You react to them. It refines based on your reactions. It builds the full site—content and design—and you can keep iterating through chat.

Here's what makes ByMiles work: the AI is a creative partner, not just an implementer. The chat isn't a glorified form. It's a taste-discovery mechanism. Most site owners don't actually know what they want their site to look like. They know it when they see it, but they can't describe it in advance. ByMiles generates possibilities, reads your reactions, and uses that signal to triangulate where your taste actually lives.

This is the right tool for people who are missing taste. Not in a derogatory way—taste is a learned skill, and most small business owners, solopreneurs, and service providers haven't spent ten years staring at design systems. They need creative range without requiring creative skill. ByMiles gives them that. It's a creative collaborator that does the design direction work they can't do for themselves.

The reason it works architecturally is that ByMiles owns the entire stack end-to-end. The AI knows where every value goes because the AI is making every decision inside a system it controls. There's no drift because there's no opportunity for drift—every page is generated by the same coherent process.

Option Two: Ollie and Ollie Pro

The second solution is Ollie. Ollie is a theme. Ollie Pro is the theme plus a plugin. And the latest release adds an MCP server, which means you can connect it to Claude (or any other AI client) and describe what you want in natural language. It comes with an Ollie skill that teaches your AI all about its approach.

What makes Ollie different is the Pattern Library. Each pattern is a pre-resolved set of design decisions. Spacing already lives in the right place. Colors already use the right tokens. Typography already follows the system. When the AI composes a page from patterns, it's not generating block markup from scratch and hoping the architecture comes out clean—it's assembling pieces that were already architecturally correct.

This is the move. The patterns are the design system made executable.

This is the right tool for people who are missing vocabulary. They have taste. They know what looks good. They can tell you "this feels too cold" or "the headings should feel more confident" or "I want more breathing room." But they don't speak the language of padding scales, color tokens, or font weight enumerations. They don't want to. They shouldn't have to.

The MCP becomes a translation layer. The user speaks in outcomes ("make this section feel warmer"), and Ollie's pattern library plus the AI handles the translation into actual primitives. The user never has to learn the vocabulary. The vocabulary stays consistent under the hood.

Two Markets, Two Solutions

Here's the framing that I think most of the WordPress-AI conversation is missing: these aren't competing solutions to the same problem. They're solutions to two different problems, for two different users.

ByMiles is for the user who needs a creative partner. Someone who can't articulate what they want until they see it, and needs an AI that can generate range and read their reactions. The chat is the discovery mechanism. The output is a site that reflects taste they didn't know how to express.

Ollie is for the user who needs a translation layer. Someone who has taste but lacks vocabulary, and needs an AI that can convert outcome-language into implementation-language without ever exposing the implementation language to them. The pattern library is the constraint. The MCP is the interface.

The taste-deficit user wouldn't get value from Ollie's approach—they don't have outcomes to describe yet. They need options to react to.

The vocabulary-deficit user would feel constrained by ByMiles—they already know what they want, they just need a translator, not a creative collaborator.

What This Means for WordPress 7

WordPress 7 is going to ship excellent AI features. They will help. But they will not, on their own, solve the design implementation problem—because that problem isn't a feature gap. It's a question of where the constraints live.

The companies solving it are doing so by putting the constraint somewhere specific. ByMiles puts it inside a closed system the AI fully controls. Ollie puts it inside a pattern library that any AI can compose against.

If you're watching WordPress 7 and wondering whether AI will finally solve design in WordPress, here's my honest answer: WordPress core won't. But the ecosystem is already producing solutions that do—and they look nothing like "another AI button in the editor." They look like opinionated substrates with AI as the interface.

That's the shift worth paying attention to. Not the AI itself. The approach underneath it.