I’ve spent 15 years in digital agencies designing, torturing, and pushing WordPress to its absolute limits. From monolithic gas factories to complex Headless architectures, I’ve seen it all. Then, the AI wave hit.
Over the last few months, I dove headfirst into the agentic AI ecosystem, RAG architectures, and local models executed via WebLLM. I had a moment of vertigo. I stopped, stared at my terminal, and thought about my first love: WordPress.
I asked myself: "Where does it fit in this revolution? Are we clinging to a tool of the past, considering its market share just dropped to 41.5% in 2026 according to W3Techs, eaten away by AI site generators?"
The short answer is no. WordPress isn't dead; it still powers nearly 60% of all CMS-based websites. In fact, it is undergoing its most exciting mutation yet. But to understand how to use it intelligently today, we first need to face technical reality.
The State of Play: WordPress in the Agent Era
The biggest problem AI agents (like Claude Code, Cursor, or Copilot) have with the traditional web is "fat". Sending kilos of nested HTML tags, inline CSS, and legacy scripts to an LLM costs a fortune in tokens and completely ruins its reasoning capabilities.
Today, the modern WordPress ecosystem solves this problem by becoming machine-readable:
- Markdown Content Negotiation: Through new infrastructure layers, WordPress can detect whether a visitor is a human or an AI, and serve a stripped-down Markdown version on the fly. Token savings: 90%.
- Model Context Protocol (MCP): WordPress now integrates MCP adapters. The CMS exposes its native capabilities (create a post, modify a menu) as standardized "Tools" that an external agent can call autonomously.
The overall plumbing is ready. But the real question is: how do we apply this to custom client projects in an agency?
The Brutal Copy-Paste Syndrome
In an agency, the golden rule is cruel: the biggest friction point to changing habits is time. When you are deep in production, taking a step back to rethink your technical foundations is a rare luxury.
Today, the overwhelming majority of WordPress developers integrate AI in a "brutal" way via their IDE. They highlight a block of code, press CMD+K, and ask the machine: "Make me a slider". The problem? The AI has zero architectural context. It will generate spaghetti code, import obsolete jQuery, or break the theme's conventions. The developer then wastes an hour debugging the generated code.
And let's not even talk about page builders (Divi, Elementor). Yes, they've all integrated "AI" recently. But they did it on the editing side (generating text, images, or layouts directly inside the visual builder). That’s a fun gimmick for the end-user or the DIY hobbyist, but it absolutely does not solve the core problem for the engineer who needs to architect the underlying codebase of a custom agency project.
Meanwhile, the WP world has found itself stuck with "Framework" themes (like Sage or Flynt) that use complex abstractions (Twig, Blade)—beautiful for humans, but severely prone to making LLMs hallucinate.
The Philosophy: AI must adapt to your habits
That’s when it clicked for me. We shouldn't change our dev habits for AI; we should make AI adapt to our habits.
A theme shouldn't impose anything; it should slot frictionlessly into an agency's workflow. So I opened my IDE with one idea in mind: create a native skeleton deliberately designed for developer-side Prompt Engineering. An environment where the repository itself becomes the prompt.
That is how Vibrisse Core was born.
The Technical Foundations of Vibrisse Core
The architecture relies on a principle of Inversion of Control, designed to constrain the AI before it writes a single line of code:
1. The .ai/ directory (The project's brain)
At the root of the theme, this folder contains natural language files. When a developer opens the project, the AI (Cursor/Cline) ingests these files. I no longer have to guide it with every prompt; the project educates it natively.
Example of my .ai/AGENTS.md (the development contract):
# Absolute Rules for AI
- Stack: FSE (Full Site Editing), ACF Pro, Tailwind v4, Vite.
- Total ban on using CSS classes outside of Tailwind.
- No abstract templating files (no Twig, no Blade). Native HTML/PHP only.
- Security: All dynamic data must pass through `esc_html()` or `wp_kses_post()`.
2. The Return to Native (Gutenberg + ACF Pro)
I deliberately banned wrappers and abstraction layers. Blocks live in their own subfolders with their block.json, their native render.php, and their fields.json. Why? Because an LLM almost never makes mistakes when generating standard PHP/HTML.
3. Project-Init Headless Mode
Via a simple constant, the starter switches from a classic monolithic mode to a full Headless mode (headless.php), exposing ACF blocks via the REST API. One single starter to cover both small monolithic budgets and decoupled Next.js/Nuxt architectures.
4. Hijacking "Skills" for Dev Productivity
This is the most exciting part for a technical team. Inside the .ai/skills/ folder, we inject automated development workflows. Instead of copying and pasting snippets or prompting the AI for 10 minutes to make it respect your standards, you just trigger a "Skill".
Example of a .ai/skills/new-block/SKILL.md file to enforce the agency's quality contract:
---
name: new-block
description: Generates a new ACF block according to agency standards
---
# Block Creation Process
1. Structure: Create a subfolder in `blocks/custom/` with `block.json`, `render.php`, and `fields.json`.
2. Accessibility: Any accordion MUST use native tags (`<details>`). Do NOT generate unnecessary JavaScript.
3. Performance: Any image (except Hero) MUST include the `loading="lazy"` attribute.
4. Style: Exclusively use Tailwind v4 variables mapped from the parent `theme.json`.
Result: The developer simply writes "Trigger new-block for a service card" in their IDE. The AI instantly generates a perfect, accessible PHP/ACF block that respects the agency's architecture, all on the first try.
Conclusion: From Text Editor to "Intent-Driven" OS
I am open-sourcing this Starter Theme because I know how hard it is for an agency to find the time to rethink its foundations. More than a finished product, Vibrisse Core is an idea—a proposed architecture that is open to improvements and community feedback.
We are moving from WordPress as a "text editor" to WordPress as an "intent-driven operating system". The plumbing is ready, the AIs are here. All that was missing was a technical skeleton capable of bridging the gap between over 20 years of WordPress legacy and the blazing speed of LLM generation.
The first commit is pushed. See you on GitHub.
What about you? Are you still prompting from scratch every time, or have you started structuring your repos to natively guide your AIs?
Proudly developed in Beauce, Québec 🇨🇦. Interested in the alliance between immersive web engineering and local AI sovereignty? Let's connect via Vibrisse Studio!
Top comments (0)