WordPress just posted its sixth straight quarter of decline.
Everyone blames AI. But HTTP Archive says the peak was July 2022, before modern AI builders existed.
AI didn't start this. What it changed was the argument, not the trend. https://t.co/7lZ1ztE3lc
Shipped this week: prompt caching support in WPPilot's MCP server, so a multi-step agent run against your site costs a fraction of what it used to. Added WP Rocket integration, so the agent reads your actual caching and page speed setup before it proposes anything. And the MCP layer now works with any AI IDE, not just Claude Code, so you can point Cursor, Windsurf, or whatever you use at your WordPress site and ask it to improve page speed directly.
Most AI-generated WordPress pages look the same: centered hero, three cards, done. That's what happens when a prompt pack tells the agent which tool calls to make and never says what a bakery's page should communicate versus a dental clinic's.
WPPilot 1.11.0 replaces the old packs with ten full landing-page briefs, one per industry: bakery, yoga studio, dental clinic, landscaper, bookshop, wedding photographer, plumber, family law firm, pet groomer, brewery taproom. Each carries its own palette, type pairing, and design signature, plus verbatim content facts and a shared WCAG 2.1 AA / real-photography standards block.
Free in the Prompts screen, with a builder picker that writes your chosen editor into the brief.
Since April 2026 new Elementor sites default to the v4 atomic editor, so most existing sites now run v3 widgets and v4 atomic elements side by side. An AI agent editing that site needs to handle both models, not just one. WPPilot's Elementor abilities do, and it's been free since v1.10.0.
@webjuice_ie Fair take if you've already moved to Astro and agents. WPPilot is for the huge share of the web that isn't leaving WordPress anytime soon and just wants an agent that can't quietly break the site while it edits it.
Giving an AI agent your WordPress admin password isn't a permission model. It's a hope.
The safer version: three server-enforced safety profiles (Read Only, Production Safe, Developer Full Access), a preview step that shows a field-by-field diff before anything writes, and a redacted change ledger so you know exactly what changed and can roll back what's reversible.
The agent can still be wrong. The site doesn't have to pay for it.
Good to see, and worth being precise about scope for anyone reading: Studio's agent is local-only by design, nothing ships until you run Studio Sync yourself. That's the right call for a dev tool. The open problem it doesn't try to solve is an agent working directly against a live production site, which is a different risk profile entirely. That's the gap WPPilot's built for: typed permissions, an approval step, and rollback on a real WordPress install, not a local copy.
Agreed, ripping out WordPress to get "tell it what you want, it executes" is solving a problem that's already solved. The part that's actually worth being careful about isn't which MCP server you use, it's that raw tool-call access to WP-CLI and the database is a lot of blast radius for one bad instruction. That's the piece we focus on with WPPilot: typed, scoped tools plus an approval step and rollback, so "agentic" doesn't mean "no undo button."
That "different kind of Friday afternoon problem" line is exactly right, and it's not just a Grok/Figma thing. Same failure mode with Claude on a live Elementor kit: if the agent doesn't read the actual global styles and component structure first, it improvises a second brand. Which is why we built WPPilot's MCP layer to read the site's real design system before proposing anything, plus approval gates and rollback for when it's still wrong. The clean-library point is the whole game either way.
Fable 5.1 and GPT-6 Astra shipped two days apart. Astra is OpenAI's first model rated Critical for cyber capability, it found real zero-days in testing. Real benchmarks, real safety story, and what it means for AI agents on your WordPress site. https://t.co/MW0aLglqUh
https://t.co/3VmTN7iuil shipped its own Plugin Directory MCP Server in March, built on the same Abilities API and MCP Adapter showing up across the ecosystem this year. It gives Claude and other AI tools three tools: validate a readme.txt before submission, check review status, and submit the plugin, running through the exact same review process as a manual submission. The line that matters most in their own docs: developers are responsible for reviewing everything their AI assistant generates before submitting. Core team policy, in writing, that AI output heading toward a distribution channel needs a human checkpoint before it ships. Same principle whether you are submitting a plugin or letting an agent touch a live site.
A smarter model raises the ceiling. It doesn't fix generic AI design on its own. Wrote up why the design-system problem is what actually matters for WordPress, and how WPPilot's MCP layer solves it across Elementor, Gutenberg, WooCommerce, and ACF. https://t.co/DFVtHd3pn5
One concrete one: agents that execute changes on a live production system, not just inside a repo. We use Fable 5.1 in WPPilot to read a live WordPress/Elementor site's actual structure, plan a change, then execute it through typed tools with approval gates and rollback. It scores 55.8% on Terminal-Bench 4.0 agentic coding and defaults to High effort specifically inside Claude Code. The comparison that matters for us isn't really Opus vs Sol vs Kimi in isolation, it's whether the higher-effort tier holds up when the task is long and stateful, and the failure mode is a real customer's site breaking instead of a demo repo.
Anthropic just shipped Claude Fable 5.1, and it defaults to High effort specifically inside Claude Code. Agentic coding on Terminal-Bench 4.0 jumped to 55.8%, and highly agentic workloads get up to 45% cheaper. That's the model doing the actual work behind WPPilot: reading your live WordPress site (Elementor, Gutenberg, WooCommerce, ACF), planning the change, then executing it inside the approval gates, evidence trail, and rollback we built around it. Stronger model, same guardrails.
That two-agent review pattern is the right instinct, but the review agent still needs something real to check against, not just a code diff. This is basically what we built WPPilot around: every action an agent takes on a live WordPress site leaves an evidence trail, before/after state, screenshots, what actually changed, so a reviewer (human or a second agent) can verify the result, not just re-read code that looks correct in isolation. Approval gates before anything ships, rollback if it wasn't.
WordPress 6.9's Abilities API might be a bigger deal than most people realize. Every ability now needs input/output schemas, a permission callback, and explicit capability requirements, and core's own guidance says: avoid __return_true on destructive actions, prefer read-only over HTTP, use a dedicated limited-role user for AI access. That's exactly the permissions problem AI agents create on a live site, and it's now core plumbing instead of every plugin reinventing it.
Yes, that's literally what we built WPPilot for. It's an MCP server that connects Claude (or any MCP client) directly to Elementor, Gutenberg, WooCommerce, and ACF, it reads your actual site structure and existing styles first instead of guessing, then proposes changes for you to approve before anything goes live, with rollback if something's off. Works alongside whatever builder you're already using rather than replacing your workflow.
That's actually the cleaner version of this problem. Claude reading a Figma file for spacing, typography, and component structure, then translating that intent into Elementor's own sections, widgets, and global styles is a much shorter path than converting AI-generated HTML after the fact. With WPPilot, Claude reads your live Elementor structure first, so it can match your existing design system instead of guessing, then proposes the build for you to approve before anything goes live. Worth trying with a real page and seeing how close the first pass gets.