WordPress Needs Separation Between Development And Production
Dear Matt,
I run a small WordPress agency called Lens Digital, based in Ascot. We design websites, build them on WordPress, and look after them long after launch. I’ve been in and around this platform for years, and I want to raise something that I think matters more than most of the debates currently swirling around WordPress.
Before WordPress, I worked in mainframes. It’s a world most web developers never touch, but it taught me one lesson that has never left me: development and production are not the same environment, and they should never be allowed to become the same environment.
In mainframe environments, this is a principal that has been in place for year because it works. You develop in one place, you stage and test in another, and only then does something touch production – the live, real, customer-facing system. Development tools simply do not exist in production. They can’t. There’s separation, and it is there on purpose.
WordPress doesn’t have that separation. It never really has.
For a long time, this didn’t matter much. A theme was a theme. A plugin did roughly what it said on the tin. But that’s changing, and I don’t think it’s changing for the better.
Take Elementor’s AI tool, which now generates layouts and code directly inside the page builder. It’s genuinely useful – I’m not knocking the feature itself. But think about what that actually is: it’s a development tool, generating code, running live inside a production website. Not in a sandbox. Not in a staging copy. On the site your customers are visiting right now.
And Elementor is just one example. As AI gets baked into more and more plugins, this pattern is only going to accelerate. Every plugin author wants to add “AI-powered” to their feature list, and the easiest way to do that is to bolt a development tool onto the live site, because that’s the only environment WordPress really gives them.
The risk here isn’t hypothetical. It’s bloat, it’s security surface area, and it’s fragility – production sites carrying around the weight and risk of tools that were only ever supposed to be used once, by a developer, before anything went live. A production WordPress site should be lean, stable, and predictable. Instead, more and more of them are turning into part-workshop, part-showroom, with the power tools left out on the shop floor where customers are walking through.
In my opinion, WordPress needs a proper answer to this. Not another plugin. Not another setting. A structural one.
What I’d love to see is something like a genuine Staging Mode built into WordPress core – a mode that plugins can register development-only tools against, so that AI layout generators, code builders, and similar tools are only ever active in that context. When a site is in production mode, those tools simply aren’t there. Not hidden. Not disabled. Not present. The same way a mainframe production environment doesn’t have a compiler sitting on it.
This wouldn’t be a small change. It would mean plugin authors need a way to declare “this feature is a dev-time tool,” and it would mean WordPress core needs to take environment separation seriously as a first-class concept, not something left to hosting companies and staging plugins to bolt on afterwards. But I think it’s exactly the kind of unglamorous, structural work that would set WordPress up well for the next decade, especially now that AI is making it easier than ever to add powerful, code-generating tools to a plugin, and easier than ever to forget that they don’t belong on a live site.
WordPress has always prided itself on democratising publishing. I’d argue the next chapter of that mission isn’t about adding more tools – it’s about knowing where those tools should live.
I’d genuinely welcome the chance to talk this through further.
Best,
Andrew Spiers
Lens Digital