Get Started 
Key Takeaways
Surface-level interfaces represent only 20% of web development. The remaining 80% consists of critical infrastructure, security boundaries, and ongoing maintenance. Ungrounded AI code generation frequently bypasses essential architectural safeguards, creating severe operational risks.
Replacing proven Software-as-a-Service applications with custom internal AI tools introduces unpredictable financial and operational overhead for businesses. Organizations risk trading a dependable $100 monthly software subscription for thousands of dollars in compounding costs and ongoing maintenance liabilities.
Reliable AI web development requires specialized architectures governed by Model Context Protocol (MCP) contracts. Open-source platforms like WordPress provide an ideal framework, combining data ownership with built-in guardrails across design, content, and hosting.
Leaders and agencies should evaluate governed agentic workflows within established platforms instead of replacing infrastructure with unvetted code. Anchoring AI in proven environments eliminates operational and security liabilities while preserving system stability.
Every six to twelve months, like clockwork, another tech CEO or Silicon Valley influencer takes to social media to proclaim the imminent death of software engineering, custom websites, and SaaS. Dario Amodei at Anthropic regularly re-ups the claim that AI will render software engineers obsolete within a year or so.
Meanwhile, developer forums, Reddit, and LinkedIn are flooded with hot takes declaring that WordPress®1 is doomed and that an autonomous agent just rebuilt an entire enterprise digital presence from scratch in forty-eight hours.
I have always been a skeptic. But lately, my skepticism hasn’t been about whether AI can transform web development. In my own work, I’ve seen firsthand how remarkably far this technology can go when properly directed.
The problem isn’t that LLMs lack potential, but that the people promising the end of coding and the death of platforms don’t seem to understand how software gets built, shipped, and maintained in the real world.
There is an enormous gulf between throwing together a flashy weekend demo and running production-grade web infrastructure. If we want to bridge that gap, we have to look past the hype, confront the realities of software development, and embrace an architecture built on specialization, clear contracts, and platform-level governance.
The iceberg problem: Why “vibe coding” isn’t software engineering
Like any complex software project, building for the web suffers from the classic iceberg problem. A clean UI, responsive layout, some CSS, and basic form handling are just the 20% visible above the waterline. But the remaining 80% submerged below the surface is where a digital product actually lives, scales, or dies:
- Design systems and UX: Consistent design tokens, accessible interaction patterns, responsive typography, and layout hierarchy that don’t fall apart across devices.
- Content architecture: Structured taxonomies, custom fields, and editorial workflows that marketing and content teams can actually operate without calling a developer.
- Operational engineering: Caching layers, state management, authentication boundaries, edge delivery, and reliable rollback strategies.
- Lifecycle maintenance: Dependency updates, performance monitoring, security hardening, and evolving the codebase alongside the business over years.
We’re already seeing what happens when teams confuse raw vibe coding with shipping production-ready software.
Security researchers and automated scanners are having a field day catching AI-generated codebases committing private .env files and live API keys directly into public repositories. In other cases, automated deployment scripts configured by an LLM have dumped entire .git trees straight into public web roots, exposing commit histories and server configurations to the open internet. When you tell an ungrounded agent to “deploy to my server,” it doesn’t intuitively understand environment isolation or least privilege; it just moves files.
Then there was a story making the rounds about a company that vibe-coded an eCommerce shop where the AI left product editing, including pricing, unauthenticated.
Customers quickly realized they could edit product prices to a few cents and complete checkout, leaving the store owner pleading in the comments for people to stop editing prices.
Whether that particular story was a real launch or a satirical commentary on current events, missing authorization boundaries are very real, documented failure patterns when software is generated without architectural guardrails.
Production readiness isn’t about whether an AI can write functional syntax on a random Tuesday. It’s about how that code scales under load, how it handles failover, how it monitors exceptions, and how it evolves over years without collapsing. An LLM has no innate awareness of your deployment pipeline, your SOC 2 compliance obligations, or your database index efficiency unless you give it the explicit tools and boundaries to manage them.
The widget company dilemma and the SaaS delusion
The corollary to the “coding is dead” narrative is the claim that SaaS is dead: “Why pay a vendor when an AI can generate your own custom CRM or project management tool in an afternoon?”
This is the biggest load of hooey circulating in tech today.
Consider a mid-sized company that manufactures industrial widgets or a small regional carpet cleaning operation. Their competitive advantage lies in making durable widgets or cleaning carpets efficiently. They have never wanted to be a software company. Does the advent of accessible AI suddenly mean they want to recruit six internal staff members to babysit language models, debug custom codebases, and maintain homebrewed internal software tools? Absolutely not.
The classic “build vs. buy” calculation has always been about trade-offs: cost, control, support, and liability. When you buy software from a trusted vendor, you aren’t just paying for code execution. You are paying for someone else to carry the operational burden. You are paying for someone else to be on call at 2:00 AM when a server crashes, to patch zero-day vulnerabilities, to guarantee an uptime SLA, and to evolve the product over time.
Furthermore, the “AI replaces everything for free” argument completely ignores the raw financial reality of compute. Running multi-step agentic workflows and heavy model inference requires significant compute that scales rapidly with token volume.
Swapping a predictable $100-a-month SaaS subscription for thousands of dollars in monthly API bills, unpredictable inference costs, and hours of frustrating prompt engineering is a terrible trade for virtually any business.
AI will disrupt business software by empowering domain experts, such as veteran auto shop owners and specialized logistics managers, to build hyper-verticalized SaaS products tailored to the nuances of their industries. AI lowers the barrier to prototyping and building, but the resulting business is still a software company that must deliver secure and scalable products.
The realistic architecture: Specialization, intent, and MCP
If relying on a single, monolithic LLM to write, deploy, and govern production web applications is a fantasy, what does a realistic future look like?
It looks like specialization. We do not need gigantic language models trying to be architects, full-stack engineers, Linux administrators, and UI designers all at once. Instead, we need a managerial model.
Think of an LLM as a coordinator or manager in an organization. A good manager doesn’t personally crawl under a house to lay plumbing or configure an enterprise firewall. The manager understands the high-level objective, coordinates the workflow, and delegates execution to specialized workers with deep domain knowledge and specialized tooling.
In the agentic ecosystem, those specialized workers are powered by the Model Context Protocol (MCP).
| User intent (“Publish new product page”) | ||
| ↓ | ||
| LLM coordinator Translates intent and goals | ||
| (MCP contract) ↙ | (MCP contract) ↓ | (MCP contract) ↘ |
| Design MCP Enforces design system tokens | Content MCP Generates content and meta | Hosting MCP Handles deploying, caching, etc. |
MCP provides standardized, predictable “contracts” between AI agents and external systems. Instead of praying that an LLM remembers not to push API keys over raw FTP, an MCP server for hosting provides a strict operational boundary. The agent says, “I have an approved build ready to deploy.” The hosting MCP server responds, “Here is the contract: provide the build payload to this secure staging environment, run verification, and wait for human approval before promoting to production.”
The LLM doesn’t have to know how to provision a secure Linux kernel, configure Nginx, or tune an edge CDN. The platform handles that reliably under the hood, and the MCP defines the bounds in which the agent can work.
Translating intent into deterministic action
This architecture works because it aligns directly with what AI is uniquely capable of: translating human intent.
Most business owners and content creators don’t think in technical execution parameters. They don’t approach a web team asking for a PHP 8.3 runtime, an isolated container, or a specific CSS flexbox layout. Their intent is fundamentally commercial: “I launched a new service, and I need prospective clients to understand my service offering and contact me for a quote.”
Today, software often forces users to deal with mechanical knobs they don’t care about. In modern block editors, users are frequently confronted with design tokens, like whether a button should be pink or green. But a content editor doesn’t generally care about raw color values. Their intent is to make an action primary and urgent.
A properly tooled agentic stack bridges this gap:
- The human expresses the intent: “Draft a landing page highlighting our new maintenance service and prompt visitors to schedule an inspection.”
- The AI leverages a content MCP to map the content into structured post types, semantic taxonomies, and clear metadata.
- The agent grounds the layout in the design system: The agent doesn’t invent styling from scratch. Instead, the agent queries a design MCP for grounding. The MCP server exposes the pre-defined component library and design system tokens, allowing the agent to select the correct primary button and layout components while strictly adhering to established brand rules.
- The hosting tooling handles operational logistics: Once human reviews and testing are complete, the agent calls a hosting MCP. The MCP enables the agent to operate within the platform’s bounds to stage the build, execute the deployment pipeline, clear edge caches, scale resources, and more.
The AI translates the nuance of intent. The specialized MCP tooling allows agents to act on it deterministically, reliably, and safely.
WordPress and the specialized agentic stack
This architecture of specialized tooling is why the predictions proclaiming the “death of WordPress” miss the mark.
The critics seem to assume that WordPress won’t adapt and that the future belongs to monolithic AI site builders that spin up a disposable codebase inside a closed black box. But WordPress is adapting. More importantly, WordPress has something that it’s always had that Wix, Squarespace, Loveable, etc. never will. Open-source transparency and data ownership.
We are already seeing the pieces fall into place across the ecosystem:
- Design and layout tools: Products like Ollie AI and modern block-based design systems are already enabling creators to generate and refine layouts that strictly adhere to clean, accessible block markup rather than unmaintainable spaghetti code.
- Standardized interfaces: The emerging WordPress Abilities API and native WordPress MCP servers mean that an AI agent doesn’t need to guess how a database works. It has structured, programmatic contracts for reading content, updating custom fields, and safely managing taxonomy.
- Content and discovery tooling: Specialized tools now ground models directly in site context, formatting content for structured discovery (GEO and search) without requiring hacky plugin workarounds.
The one critical gap in this chain has been hosting.
You can have specialized AI design tools and standardized WordPress content APIs, but if deployment and infrastructure management still require raw terminal commands, manual SFTP pushes, or fragile scripts, the loop breaks.
That’s why a hosting MCP layer is the missing link (or not). A managed platform that exposes standardized MCP servers for staging environments, backups, cache purging, and edge security allows AI to orchestrate the entire development lifecycle safely. The agent isn’t left alone to guess how to configure a server; the platform carries the operational complexity under the hood.
With specialized tools at the design, content, and hosting layers, WordPress becomes the ideal structured environment for the agentic web.
Building on what works
The fundamental reality of how businesses operate online isn’t going to change just because an AI model can generate code.
A business owner running an auto repair shop or an accounting practice is never going to spend their evenings arguing with an AI to build their own software. They don’t want to become AI managers, and they have no interest in shouldering the technical debt and security liabilities associated with home-brewed code. They will continue to rely on agencies and developers who can deliver real value, technical reliability, and business outcomes.
For those agencies and developers, the path forward isn’t to abandon two decades of web standards in pursuit of the latest vibe-coded demo.
WordPress isn’t going anywhere. It remains the most flexible, battle-tested open platform for building digital experiences without reinventing the wheel. By connecting specialized design systems, robust content APIs, and managed hosting infrastructure through MCP, we get the best of both worlds: the speed and intent-translation of AI, anchored by the stability, ownership, and governance of a proven platform.
The goal of the agentic era was never to make software engineering obsolete. It was to give us better tools to build things that actually last.
- WP Engine is a proud member and supporter of the community of WordPress® users. The WordPress® trademark is the intellectual property of the WordPress Foundation. Uses of the WordPress® trademarks in this website are for identification purposes only and do not imply an endorsement by WordPress Foundation. WP Engine is not endorsed or owned by, or affiliated with, the WordPress Foundation. ↩︎
