I gave this talk at WordCamp Asia 2026 — remotely, from my home office, which wasn’t the plan but ended up working out surprisingly well. The topic is something I’ve been thinking about: why WordPress’s history of open extensibility is actually a structural advantage in the AI era, not just a nostalgic footnote.
Here’s the written version to accompany the slides.
Once upon a time, we edited WordPress core directly
I’ve been in the WordPress ecosystem for over 20 years, and I’ll admit: I remember a time when people, myself included (embarrassing!), would routinely make changes directly to WordPress core to get what we needed. The extensibility was there — hooks and filters existed — but editing core felt easier somehow, more immediate. You knew exactly where the code was and you just… changed it. This was of course bad practice, but we were doing it anyway.
That was all fine until it really wasn’t. An update would come out and write over all your changes. And eventually, enough people went through that enough times that the community started to really get it: the hooks system wasn’t just a nice-to-have. It was the right way to work with WordPress. Not because editing core was impossible, but because extending it through the shared system was so much better for everyone — including yourself.
What the shift to WordPress hooks produced
That move wasn’t just a technical decision. It was a cultural one. The community collectively decided that the future of WordPress development and customization should be the shared protocol, not the shortcut. And what came out of that decision was one of the most successful open-source ecosystems in the history of the web.
Tens of thousands of plugins. Thousands of themes. Hosting companies, page builders, ecommerce platforms — all interacting with each other without coordinating in advance, without requiring permission, without needing to even know each other. We just needed to agree on the interface.
When Elementor was built, we didn’t ask anyone’s permission to integrate with WordPress. We didn’t need a special partnership or a licensing agreement. We just used the hooks. And this carries on to the world of plugin extensions: by adopting this mindset of extensibility ourselves, when third-party developers want to add custom functionality to Elementor today, they register through our extension API and the widget appears in the editor right alongside everything we built natively — no involvement from us required.
Now let’s say someone wants a solution for WooCommerce sites that are also using Elementor? No problem. This type of cross-product development happens all the time and compounds the innovation flywheel even further.
The core insight: product teams don’t need to predict every use case. They build solid infrastructure and get out of the way. The ecosystem takes it from there — without having to ask for permission or sign contracts. More use cases meant more users, which meant more developers building more plugins, which meant even more use cases. The flywheel spun because the infrastructure was open, the extension points were well-defined, and no single entity controlled who could participate. People could innovate freely, without barriers or friction.
We’re at that moment again
That shared interface — that common protocol — is what I wanted to talk about at WordCamp Asia. Because I think we’re standing at a very similar moment, except this time it’s not about plugins talking to WordPress. It’s about AI agents talking to your WordPress site, and we’re uniquely positioned to grab this opportunity and continue to be a leading platform.
It’s interesting that the WordPress core AI team is responding to this moment in exactly the same way the WordPress project responded to the extensibility challenge decades ago. They’re building shared protocols and open infrastructure, accompanies by common standards that no single company controls.
Specifically, three things are either shipping or in progress:
The Abilities API — shipped in WordPress 6.9. A machine-readable registry of what WordPress can do, so AI agents and automation tools can discover and interact with everything WordPress and its plugins are capable of.
The MCP Adapter — shipping in WordPress 7.0, which is schedule for release later this month. This exposes those Abilities through Model Context Protocol, the open standard for how AI agents communicate with external systems.
The WP AI Client — also in WordPress 7.0. A provider-agnostic SDK in core, so plugins can access AI models through one shared interface instead of building separate integrations for OpenAI, Anthropic, Google, and whoever comes next.
Sound familiar? It should. This is the “hooks” system for AI.
Why open source has a structural advantage here
Ok so WordPress is ready for AI — but what about all the vibe coding tools out there?
Many of them are impressive. But think about what they’re actually offering: a managed environment, a proprietary data format, a platform that controls what you can build and how you can extend it. The AI is very capable, but the ecosystem is a walled garden. And the people building on those platforms are siloed from each other. Everyone is solving the same problems independently. Nobody is building on what the person next to them figured out. Why should each of us reinvent the wheel every single time? That’s not just frustrating, it’s wasteful — in time, in energy, in the very real compute resources that go into running these things.
WordPress’s open-source model offers a structural advantage against that. Right now there are over 60,000 plugins in the WordPress repository. If each of those plugins eventually exposes its capabilities through the Abilities API, every single one of those capabilities becomes something an AI agent on a WordPress site can discover and use. The network effects of an open ecosystem, where tens of thousands of independent developers are each extending the surface area that AI can interact with, compounds in a way that a single company’s roadmap never will.
But beyond the technical architecture, there’s something deeper here that I think is one of our strongest advantages, and it’s harder to quantify. It’s the culture.
Many of us who came up in open source learned by reading other people’s code. We figured out how things worked by digging into plugins someone else had built, by seeing how a problem we were wrestling with had already been solved by someone in a different country who published their solution for free. That’s how this community has always grown — and it’s how human progress works in general. Every generation builds on the breakthroughs of the one before it. You can’t advance by starting from zero every time.
That culture of sharing, learning from each other, and building on top of what already exists can’t be manufactured. You can’t force it into existence in an industry that wasn’t built around it. It’s either there, encouraged and celebrated, or it isn’t. In WordPress it is, and it has been for over 20 years. That’s not a feature you can copy. It’s a compounding advantage that the vibe coding world simply doesn’t have yet, and may never have in the same way.
What this looks like in practice
I’ve been working on MCP integrations from the ecosystem side, and the dynamic I’ve seen firsthand is almost identical to what hooks created in the plugin ecosystem. I’ve been in conversations with teams from companies that are technically competitors, working through MCP integrations together because the protocol makes it the logical thing to do. Our shared users benefit when we collaborate. The protocol makes collaboration easier than the alternative.
What all this means practically is that the opportunity is right in front of us. The new “hooks” are here — the Abilities API, the MCP Adapter, the WP AI Client. The same instinct that drove developers to learn hooks, share what they figured out, and build plugins that solved problems nobody else had thought to solve yet — that instinct is exactly what’s needed now. Start learning this infrastructure. Experiment with it. When you figure something out, share it, because someone in this community will build on it, just like we’ve always done.
The rails are going in
Now it’s the ecosystem’s turn to do what it has always done. Expose your plugin’s capabilities through the Abilities API. Build for the use cases your audience needs — the niche, the edge case, the very specific problem that nobody else has thought to solve. Share what you learn. Put it somewhere people can read it. Let the next person build on what you figured out.
That’s how 60,000 plugins happened. Not because one company planned it all out, but because thousands of people, over 20 years, kept extending the platform one use case at a time and sharing what they built.
The AI era doesn’t change that dynamic. It accelerates it, and it gives us a much bigger surface area to work with.
WordPress is positioned to lead in the AI era — not despite how we’ve always worked, but because of it.
