Opinionated Frameworks Are Winning
Why Opinionated Frameworks Are Winning the AI Development Era (And What That Means for WordPress)
A conversation worth having: as AI-assisted development reshapes how we build the web, some platforms are better positioned than others. WordPress might need to pay attention.
I’ve been thinking a lot about which tools and frameworks play nicest with AI-assisted development. Not just which ones have the most plugins or the biggest market share, but which ones give tools like Claude Code, Cursor, and Copilot the best chance of actually being useful. And I’ve come to a conclusion that might be uncomfortable for a lot of us in the WordPress world.
It’s not that WordPress is bad. It’s that the way WordPress sites get built doesn’t align well with how AI development tools work. Understanding why might help the community make better decisions going forward.
The Convention Advantage
AI models generate their best code when they can rely on consistent, well-established patterns. This is why working with a framework like Laravel feels almost magical with AI tooling. Blade templating, Eloquent ORM, artisan commands, a clear MVC structure: there’s a shared understanding of how a Laravel project is organized. When you ask an AI to add a feature, it knows where to put the route, where the controller goes, and how to write the view. The pattern is the same across thousands of projects.
WordPress has always celebrated flexibility and choice, and that’s served it incredibly well for two decades. But flexibility means there isn’t one shared pattern for AI to lean on. A WordPress site could be built with classic themes, block themes, Elementor, Divi, headless REST API, or some combination of all of the above. Each approach has its own structure, its own conventions, and its own way of storing and rendering content. An AI has to figure out which WordPress it’s looking at before it can meaningfully help.
A Platform in Transition
This challenge gets more nuanced when you consider where WordPress is heading. Classic theme development, including functions.php, hooks, filters, and the template hierarchy, has years of well-represented training data behind it. AI can work with classic themes reasonably well.
But classic themes are on their way out. Automattic has been clear that the block editor and Full Site Editing are the future. theme.json, block themes, and React-based block development are where things are heading. That’s an exciting evolution, but it creates an awkward gap for AI tooling. The mature patterns are being deprecated, and the new patterns haven’t stabilized enough to build deep, reliable AI knowledge around. Gutenberg is still evolving quickly, and what worked a year ago might not be the recommended approach today.
It’s a transitional moment, and transitions are inherently tricky for AI tools that depend on stable, well-documented patterns.
The Page Builder Question
There’s also the question of page builders, particularly Elementor, which has become the go-to for a huge portion of the WordPress community. Elementor sites are everywhere, and the builder has empowered countless people to create professional websites.
The challenge is that Elementor operates as its own layer on top of WordPress. Layouts live as serialized data in the database rather than as readable template files. The widget system, CSS generation, and rendering pipeline are all Elementor-specific. This means external AI tools, the ones that work by reading and editing code files, don’t have much to work with on an Elementor site. The “source of truth” for the design isn’t in the codebase. It’s in the database.
Elementor can and will build AI features into their platform, and that’s great. But it does mean site owners are relying on one company’s AI roadmap rather than having access to the broader ecosystem of AI development tools. It’s worth being aware of that trade-off.
What Makes Other Frameworks Click
This is where looking at other options gets interesting. Not as a “you should abandon WordPress” argument, but as a way to understand what AI tools are optimized for.
Laravel is the obvious comparison in the PHP world. It has strong opinions about project structure that have been stable for years. Blade has been Blade. Eloquent is Eloquent. Routes, controllers, views, migrations: they all have a clear home. When you point an AI tool at a Laravel project, it can immediately orient itself and start being productive.
But you don’t even need a full framework to see this advantage. Something as lightweight as PHP Slim paired with Twig gives AI a remarkably clean surface to work with. You get a clear routing file, straightforward controllers, and Twig templates with a syntax that’s been stable for over a decade. Your homepage is a template file. Your logic is in handler functions. Everything is in the filesystem, everything is readable, and the patterns are well-known.
Want to tell Claude Code to rearrange sections on a page? It reads the Twig template, understands the HTML structure, and makes the edit. Need a new endpoint? Add a route, write the handler. It’s simple, but the simplicity is exactly the point. AI thrives on predictable, file-based project structures.
The contrast with WordPress is stark. Where does the logic live? It could be in functions.php, a plugin, a block’s JavaScript, a builder’s configuration, theme.json, or a shortcode callback. That’s a lot of places to look, and AI tools need to search through all of them to understand what’s happening.
Structural Legibility: The New Competitive Advantage
The pattern I keep coming back to is what I’d call structural legibility: how easily an AI can open a project and understand its organization, conventions, and intent. The frameworks winning in the AI era aren’t necessarily the most powerful or popular. They’re the most legible.
By this measure, opinionated frameworks have a real edge. Laravel, Rails, Next.js, SvelteKit: they all share a quality of having clear, consistent conventions that AI can learn and apply reliably. WordPress’s flexibility, which was a superpower in the era of human-navigated development, becomes a liability when the navigator is an AI that needs pattern consistency.
Looking Ahead
None of this means WordPress is going away or that it’s a bad choice for every project. WordPress has an extraordinary ecosystem, an enormous community, and use cases where it remains the best option. Content-heavy publishing, quick marketing sites, and projects where non-technical users need to manage content: WordPress still shines there.
But if you’re making technology decisions with an eye toward AI-assisted development workflows, it’s worth honestly evaluating how well your platform of choice plays with these tools. A solo developer with a conventional framework and good AI tooling can increasingly match or exceed the output of larger teams working in less AI-friendly environments. That’s a shift worth paying attention to.
The WordPress community has always been good at adapting. The conversation about AI legibility is one worth having now, while there’s still time to shape how the platform evolves, rather than later when the gap may be harder to close.
As AI reshapes how we build for the web, the platforms that thrive will be the ones AI can most easily understand. That’s a conversation every community should be having, including WordPress.