Separating themes from plugins let people change a site’s design without losing its functionality. It also gave developers clearer responsibilities.

But it makes some tasks harder for users.

The User Experience Gap

Someone looking for a contact form in the block inserter wants a form. They shouldn’t have to work out which part of WordPress should provide it.

But adding a block can mean leaving the editor, finding and evaluating a plugin, installing it and coming back. On Squarespace, the block may already be in the inserter.

The separation optimizes for architectural purity over user flow.

The Coordination Cost

Every boundary creates a handoff. Theme developers can’t guarantee functionality. Plugin developers can’t guarantee their blocks will look right in your theme. When something breaks or looks off, users become detectives trying to figure out which piece failed. The clean separation on the development side becomes messy confusion on the user side.

What AI changes

AI can now help generate blocks on demand. That changes how people get functionality that once needed a developer to build it separately.

But in a world where a user can say “give me a testimonials block that matches my site” and AI just… makes it? The boundaries become arbitrary barriers rather than helpful structure.

AI doesn’t care about theme versus plugin. It cares about solving the user’s problem. WordPress’s architecture should evolve to match.

What I’d change

I’d like a theme’s contact form, testimonials and pricing-table blocks to be styled and available in the inserter when someone starts using it.

The portability concern? AI solves that too. Switching themes could trigger an intelligent migration that rebuilds blocks to match new designs rather than breaking them.

We can keep the separation in the code and make blocks easier to find in the editor.

Users should be able to add what they need without learning the architecture first.