AI Doesn't Drive the CMS — It Unbundles It

A CMS fuses a human translation layer with an operational control plane. AI makes the first an extra step and decomposes the second — turning the plugin bazaar into a mineable integration textbook.

Scott Farrell · LeverageAI · August 2026

Putting AI into WordPress keeps failing for a structural reason, not a tooling reason. The CMS was never one product. It was two jobs fused: a translation layer for humans who could not operate the web substrate, and an operational control plane for publishing, roles, forms, payments and plugins. AI does not “modernise” that fusion. It dissolves the first job and forces the second to unbundle.

The future website is not built for a business owner to administer. It is built for the business owner’s AI to operate.

That is the thesis of CMS Unbundling. This piece walks the full argument: the two-job decomposition, the head-to-head between an agent-native stack and a page-builder tunnel, the transaction-depth rule that decides remove versus retain, and the second movement that answers the question the first cannot ignore — if the CMS goes, what replaces the plugin ecosystem?

Two jobs, not one product

WordPress, Squarespace and page builders solved two different problems at once.

The old path was a chain of specialists and representations:

Business expert → marketer or web developer → CMS concepts
  → theme or block representation → rendered website

The emerging path collapses the chain:

Business expert → conversational and visual AI → source artefact → test → deploy

The expert moves closer to the coalface. AI is the thin shim — hands, eyes and technical execution — not another specialist who must re-express intent in Elementor or Gutenberg vocabulary. That is AI as Interface applied to websites: intention replaces menus as the primary interaction surface.¹

A compiler between two compilers

A CMS was effectively a compiler for humans who could not safely manipulate HTML, CSS, JavaScript, PHP, hosting and databases. AI is now an intention compiler that can manipulate those things.² Placing a CMS between the expert and the AI often creates this stack:

Human intention → AI-generated instructions → CMS representation
  → theme representation → HTML

The AI then reverse-engineers a block schema, manipulates database records, hunts REST endpoints, operates wp-admin or writes a custom plugin — merely to produce something it could have written as HTML or PHP. That is not modernisation. It is a machine tunnelling through a human abstraction.

Head-to-head: same intent, two architectures

I ran both sides of this experiment myself.

The Elementor experiment (negative result)

On a dental practice’s WordPress site, the stock page endpoints returned rendered Elementor HTML. They did not expose the editable _elementor_data post-meta blob. Scraping the headline would find visible text; it would not give Elementor’s source document. The spike built a private REST plugin that reached directly into wp_postmeta, snapshot the JSON, patch it with raw string replacement, and hope Elementor still understood the result. Backup files existed; full validation of the resulting JSON did not. That is the CMS-as-tunnel architecture: conversation → custom API → database-backed blob → hope.

Our Perfect Employee (positive partial proof)

Our Perfect Employee reduced the owner interface to a request box. Claude Code changed small Git-addressable PHP files. Ordinary code handled repository synchronisation, diffs, commits, deployment, uploads and rollback. The repository became the content store; the conversation became the admin interface. Same class of intent — change the site — without reverse-engineering a page builder.

Honest limits matter. The agent’s file boundary was partly prompt-enforced rather than hard-contained. Detected changes deployed automatically. The displayed diff was a receipt, not an independent pre-production gate. The mature design is not “give Claude the server.” It is an open-ended AI worker inside a narrow deterministic shell.

Design-time AI, deterministic runtime

The AI operates the website. The website does not need AI at runtime. The public site can stay boring, fast and deterministic: static HTML or generated output, small PHP or serverless endpoints for forms, normal CDN caching, no model call when a visitor opens a page, no stochastic behaviour in the customer journey.

AI lives in the owner and production interface: replace this paragraph, make the hero less corporate, crop the photograph, add a service page, create a HubSpot contact and notify the office manager, show me what changed, undo yesterday. The resulting artefact is conventional software. That is safer and cheaper than a chatbot on every visitor session — and it is the design-time side of the design-time/runtime boundary: reviewable artefacts before consequence.

What replaces the CMS

The successor is not “a website generated once by AI.” That is AI-assisted web development. The successor is an agent-operable website control plane — the Post-CMS Stack:

Business owner or expert
          ↓
Conversational + visual AI interface
          ↓
Git-native content, design rules and source files
          ↓
Deterministic control plane
auth · permissions · tests · diff · approval · deploy · logs · rollback
          ↓
Static site + small dynamic endpoints
          ↓
Commodity services
payments · email · CRM · identity · booking · analytics

Acceptance test for every layer: can the agent code, test, deploy and diagnose it? Without that loop you do not have a replacement. You have FTP with a chatbot — an AI with production credentials.

Transaction depth sets the boundary

WordPress is not merely a writing tool. It accumulated a plugin economy because sites need payments, catalogues, carts, stock, tax, shipping, accounts, subscriptions, bookings, CRM sync, forms, spam protection, analytics, redirects and SEO. For a brochure or lead-generation site, most of that is unnecessary. For genuine ecommerce, WooCommerce or Shopify is a transactional state machine — not an inconvenient page editor. Rebuilding all of that because AI can write HTML is a category error.

Remove the CMS where it is translating intention. Retain or buy the systems that are carrying durable operational state and commodity risk.

That is Composable Bespoke applied to websites: buy infrastructure that benefits from scale; generate the application layer that needs to fit the business. Buy the capability; own the join.

The incumbent site is the oracle

The existing website is not “design inspiration.” It is layered specification: visual, content, behavioural, integration and operational clues. A migration agent crawls public URLs, metadata, headings, links, forms, destinations, screenshots and consent behaviour, then turns those into characterisation fixtures. The replacement is compared until every difference is corrected or deliberately accepted. That method is characterisation testing and Sunk Cost as Spec applied to the public web surface — extract fields, workflows and integrations as portable requirements before you decide what survives.⁴⁵ The same logic applies to HubSpot: do not declare it obsolete by copying a contact form; extract lifecycle stages, workflows and attribution first.

The open question movement one cannot answer

If you unbundle the CMS, you lose install-and-run plugin convenience. That looks like the downside. It is not the whole story. The plugin bazaar is also the largest public corpus of solved integration problems on the web. WordPress.org’s directory advertises over 69,000 free plugins;⁶ in 2025 alone the Plugins Team reviewed more than twelve thousand submissions.⁷ That corpus is more valuable as tuition than as a runtime.

Movement two is the answer to that open question: Ecosystem Decompilation.

A plugin is a fossilised integration investigation

A Stripe plugin contains far more than “create a payment”: configuration expectations, product and currency representation, when a payment record is created, webhook verification, success and failure states, retries and idempotency, abandoned checkouts, refunds, email confirmations, reconciliation, error recovery, secrets and permissions, API-version drift, and years of edge cases. Architecturally ugly code can still hold compressed experience. That is Legacy as Tuition at ecosystem scale: the durable asset is the learning, not an obligation to preserve the implementation.

Never copy one plugin

Copying a single plugin imports its compiled North Star — WordPress hooks, database tables, WooCommerce order models, wp-admin screens, cron assumptions, PHP compatibility baggage, ten years of backwards compatibility, and commercial upsell architecture.⁸ Even excellent code can be organised around the wrong mission. The sharp rule from open-source consumption after the inversion applies perfectly: copy discoveries, not destiny.⁹

Many implementations reveal the invariant

One implementation misleads. Several independent ones discriminate. When multiple Stripe plugins separately store the provider payment identifier apart from the local order id, verify signed webhooks, treat webhook receipt as authoritative over browser return, make handlers idempotent, keep a pending state between checkout and confirmation, and record the event before fulfilment — that convergence is signal about the shape of the integration. When five plugins present five different admin UIs, the interface is local choice, not invariant.

Present this as method, not fabricated survey: name a checkable set of plugins, read them for the same concerns, mark each row invariant or local choice, then verify every candidate invariant against the current Stripe contract and encode it as a test. The corpus is evidence, never authority.

Stripe end-to-end: the narrow adapter

Stripe is the ideal decompilation case because the provider surface is already agent-operable: APIs and SDKs, clear object models, test mode and test cards, webhooks, documentation, and an official MCP server at https://mcp.stripe.com with tools for API search, read/write, documentation search and an implementation planner.¹⁰

Intent: “Take a $250 deposit for this booking.”

Current truth:  Stripe API, SDK and MCP
Prior experience: WordPress / WooCommerce / framework integrations
Local truth:    this site’s booking and customer model
Implementation: one checkout endpoint + one webhook endpoint
Verification:   Stripe test mode + replayed webhook fixtures + browser test

The generated integration need not inherit a full ecommerce ontology. A deposit flow can stay seven fields wide:

quote_id
customer_email
amount
currency
checkout_session_id
payment_status
paid_at

A client quote-to-payment flow is already a primitive specimen of that shape. No product catalogue, cart, coupons or inventory engine unless the business actually needs them.

Construction hierarchy

1. Use the provider directly — MCP, SDK, OpenAPI, CLI, sandbox, webhooks.
2. Mine existing implementations — standard flow, edge cases, lifecycle, quirks.
3. Recover incumbent behaviour — amount, timing, returns, emails, CRM updates, refunds, staff alerts.
4. Generate the narrow local adapter — only the business-specific join.
5. Generate tests before production — the corpus nominates cases; the sandbox and incumbent behaviour make them executable.

From plugin bazaar to pattern bazaar

Today a plugin vendor sells: install our code into WordPress and configure it through our screens. The AI-native successor sells: give your agent our maintained integration package — domain model, current API interpretation, pattern card, security rules, fixtures, edge cases, test suite and update feed, perhaps an MCP server for authoritative current information. AI generates the customer-specific implementation. The vendor’s asset migrates from one executable plugin to maintained integration knowledge and proof. That fits the inverted reuse hierarchy: North Star → domain distinctions → schemas and eval cases → bounded libraries → complete application code. Complete plugins fall in relative value; accumulated integration discrimination rises.

What this argument leaves alone

The cut is deliberate. Platform Escape Path and Don’t Buy Software already own general SaaS escape economics; this piece only needs them where the CMS is the category under the knife.¹¹ Hunting consulting opportunities from public intake surfaces is a different job — here the incumbent site shows up only as a characterisation oracle, never as a prospect list. Tax, inventory and fulfilment stay bought as commodity state machines; rebuilding them is not the claim. Visitor-facing chatbots and personalisation are a different product class with different governance, and this argument is about design-time operation of a deterministic site, not intelligence in the public journey. Semantic decompilation shares a word with ecosystem decompilation, not a mechanism — one reverse-engineers idea systems in prose; the other mines integration implementations for verified invariants. Connector ecosystems beyond the web (AppExchange, Zapier, ERP adapters) can inherit the same loop; the proof here stays where the corpus and the evidence are thickest.

WordPress may die as the operating system while surviving as the world’s largest open integration textbook. That is not a eulogy for plugins. It is a promotion — from shelf of components to corpus of experience — under a rule that keeps the work honest: several historical implementations suggest a distinction; you verify it against the current provider contract and encode it as a test before you trust it.