In short: The future of WordPress with AI isn't a flood of AI-generated plugins — it's the opposite. As AI eats the long tail of single-purpose add-ons, the winning pattern is fewer, more complete solutions built on WordPress as a core application framework: custom tables, built-in users and access control, and platforms that solve whole workflows instead of stacking a dozen fragile dependencies.
Austin Hinder lit the fuse with a claim that human-coded plugins are headed for obsolescence and that the most popular plugins will soon be AI-generated. The r/WordPress thread that followed split three ways, and only one branch holds up under weight. This is the case for that branch.
Why did 40 plugins on one site ever become normal?
Walk into almost any inherited WordPress site and count the plugins. Forty is common. Sixty is not rare. Each one arrived to solve a single problem — a contact form, a redirect, a schema tag, a slider nobody uses anymore — and each one stayed. The admin fills with upsell banners. The front end ships a slurry of stacked scripts and styles that drags Core Web Vitals down. The database carries options nobody audits.
Practitioners who clean this up report a consistent result: client stores drop from 40–60+ active plugins down to 3–7 without losing a single feature that mattered. The bloat was never load-bearing.
Scale is what makes this worth arguing about. WordPress still runs north of 40% of the web in 2026, so one default habit — reach for a plugin, any plugin — compounds across millions of sites into weight they never needed to carry. It helps to know where WordPress stands in 2026 before betting on where it goes next.
Is AI really going to generate all our plugins?
Hinder's prediction assumes the shape of the future matches the shape of the past: many small plugins, just generated by a model instead of typed by a human. Flip that assumption and the picture inverts.
James Giroux makes the sharper call in "When N=1": the long tail of single-purpose plugins is exactly what personal and AI-generated software eats first. Why install and trust a stranger's redirect plugin when you can generate the forty lines it takes? The survivors won't be the tiny utilities. They'll be larger, focused products that own real business logic — commerce, membership, listings — the categories where the plugin market will consolidate because correctness and maintenance are worth paying for.
So the future isn't more plugins. It's fewer, and more complete. WordPress stops being a CMS you decorate with add-ons and becomes what it has quietly been for years: a core application framework you build on.
One nuance the debate keeps flattening deserves a flag. Reusing a mature, maintained plugin is not the anti-pattern. Advanced Custom Fields, custom post types, WooCommerce — these are battle-tested primitives, and reaching for them is good engineering. The anti-pattern is vibe-coding a fresh, worse copy of something that already exists and is already maintained. Reuse before you regenerate.
| Dimension | Plugin soup (40–60+ add-ons) | Core application framework (one complete build) |
|---|---|---|
| Dependencies & maintenance | Dozens of update cycles on conflicting schedules; one bad release cascades | One codebase you version, test, and ship on your own terms |
| Performance | Stacked JS/CSS, duplicate queries, an overloaded wp_posts table | Custom tables and targeted queries; HPOS-style read/write cuts |
| Security surface | Every plugin is another entry point and another maintainer to trust | Fewer doors; code you reviewed and can actually audit |
| Handoff & portability | Tribal knowledge of which fifty toggles matter | Documented, native-pattern code the next developer can read |
| Cost | Recurring licenses across many vendors plus firefighting hours | Higher upfront build, far lower ongoing drag |
What does WordPress-as-application-framework actually look like?
WordPress already ships the pattern; most sites just decline to use it. Look at how WooCommerce handles orders now. High-Performance Order Storage moves order data out of the overloaded wp_posts table into dedicated custom tables — wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data — cutting JOINs and trimming read/write operations.
For stores past 10,000 orders, that consolidation delivers roughly 70% faster order queries. That is the framework thesis running in production: native custom tables beating the everything-lives-in-posts default.
The rest of the toolkit is already in the box. User accounts. Roles and capabilities. Nonces and form validation. An HTTP API, a cron system, a REST layer. You don't bolt an access-control plugin onto a platform that has shipped access control for two decades — you use what's there.
Stack those primitives and the model changes. AI-powered platforms can solve an entire workflow — intake, storage, permissions, output — inside one well-architected build instead of a dozen dependencies wired together with hope. This is the shift from decorating a CMS to running WordPress as a business platform. And when your data lives in clean custom tables with documented code around it, CMS lock-in starts to fade; the logic is portable because it was written like software, not assembled like furniture.
Can you actually trust an AI-built plugin?
Here is the strongest counter-argument, and it is a good one: if anyone can generate a plugin, anyone can generate a vulnerable one — at scale, and fast.
The data backs the worry. Patchstack's 2026 State of WordPress Security report names vibe coding as a direct contributor to accelerating vulnerabilities, a documented security warning rather than a hunch. Speed of output turns out to be a poor proxy for safety of output.
The CVE numbers make it concrete. AI-attributed CVEs climbed from 6 in January 2026 to 15 in February to 35 in March — a near-sixfold jump in two months, with 74 tracked in the AI-generated code surge. Veracode's March 2026 measurement found the security pass rate for AI-written code stuck flat near 55%, even as the same models' coding benchmarks kept climbing. Faster did not mean safer.
Then there is trust in what you install. On April 5, 2026, dormant backdoors switched on across 30-plus plugins with more than 400,000 combined installs — the EssentialPlugin suite — writing into wp-config.php and serving cloaked SEO spam. The lesson isn't "AI wrote bad code." It's that installing code you never reviewed, from a maintainer you can't vouch for, was always the risk. AI just lowers the cost of producing more of it.
Which loops straight back to the thesis. Generation speed was never the bottleneck. Architecture, security review, and long-term maintenance are — and those still need a human who understands the system. A few moving parts you actually reviewed beat a pile of generated ones you didn't.
How do you build for the post-plugin-soup era?
Build as though the plugin-soup era is ending, because for anyone paying attention it is.
Start from the platform's own primitives and write the custom code that fills the specific gap in front of you — not a general-purpose plugin for a problem you have exactly once. Plugin soup is only mandatory when you refuse to write a hundred lines you understand. Reuse the mature dependencies that earn their place; regenerate nothing that already exists and works.
Guard the one real risk this creates: handoff. Custom code done badly is a trap for the next developer, and easy handoff is one of WordPress's genuine selling points. So write native-pattern, documented code a stranger can pick up — the opposite of a clever black box. Portability is a feature you engineer on purpose, not a lucky side effect.
None of this means hand-coding every workflow forever. The same shift that thins the plugin count is what makes AI-agent automation worth adopting for the repetitive work — content operations, publishing pipelines, routine maintenance — on top of a lean, well-built core. That's the argument for automating the busywork with HiFi-WP agents once the foundation is sound.
Key takeaways
- The AI future for WordPress is fewer, more complete solutions — not a bigger pile of generated plugins.
- WordPress already works as a core application framework: custom tables (HPOS), built-in users, roles, and validation.
- HPOS custom tables cut queries by roughly 70% at 10,000+ orders — native primitives beating the posts-table default.
- Reusing mature plugins is smart; vibe-coding a worse copy of what already exists is the anti-pattern. Reuse before you regenerate.
- AI raises output speed, not code safety — the ~55% pass rate and the CVE surge mean review and maintenance still belong to humans.
- Custom code is only a win if it stays handoff-friendly: write documented, native-pattern code the next developer can read.
FAQ
Will AI-generated plugins make human developers obsolete?
No. Generation speed was never the constraint. AI can write forty lines in seconds, but architecture, security review, and years of maintenance are where the real work lives — and the numbers show why. AI-written code's security pass rate has held flat near 55% while AI-attributed CVEs surged nearly sixfold in two months. Faster output raises the volume of code that still needs a human to vet it. The role shifts toward judgment, not away from developers.
Is it safe to install AI-built WordPress plugins?
Treat them exactly like any unvetted code, because that's what they are. The April 5, 2026 incident — dormant backdoors triggered across 30-plus plugins with 400,000+ combined installs — and Patchstack's warning about vibe coding both point to the same truth: who or what wrote the code matters less than whether anyone reviewed it and whether you trust the maintainer. Review it, or use code from a source you can vouch for.
What does "WordPress as a core application framework" mean?
It means using WordPress's native primitives — custom database tables (as HPOS does for WooCommerce orders), built-in users, roles and capabilities, nonces, and form validation — to deliver a full solution inside one well-architected plugin, instead of stitching a dozen single-purpose add-ons together. The platform already ships the parts of an application framework; the shift is choosing to build with them rather than around them.
Should I stop using plugins like ACF or WooCommerce?
No — and this is the distinction the debate keeps missing. Reusing mature, maintained plugins like Advanced Custom Fields or WooCommerce is good engineering; they are tested primitives that handle hard problems well. The anti-pattern is vibe-coding a new, weaker version of something that already exists and is already maintained. Reuse before you regenerate.
Does building custom make my site harder to hand off?
It can, and that's the real risk to manage. Custom code written as a clever black box strands the next developer. The fix is to favor clear, documented, native-pattern code that another developer can read and take over — which is itself one of WordPress's core selling points. Engineer portability on purpose and custom builds stay just as handoff-friendly as an off-the-shelf stack.
If you're ready to treat WordPress as the application framework it already is, the next move is automating the repetitive work on top of it — that's where a lean stack of purpose-built AI agents earns its keep.