Claude Code and Codex can build a full page from a prompt. Layout, markup, styles, interactions, all of it, in one pass. I do this daily now. It works because of how the sites I build are structured, not because of the AI tool.
Put those same tools in front of a typical WordPress site and they fall apart. Nothing to read, nothing to edit, no way to deploy. The problem isn’t the AI. It’s the setup.
This post covers what a bad setup looks like, what a good one looks like, and an advanced method I’ve been using to let clients generate branded pages from a prompt.
Why Minimal Themes Thrive
AI coding tools work with files. They read a directory, understand the patterns, and write code that fits. That’s the whole workflow.
A basic custom theme gives them exactly what they need:
- A small number of files with a clear purpose
- Standard WordPress template hierarchy they already understand from training
- Markup, styles and scripts living side by side in version control
- A single source of truth for every part of the design
When I ask Claude Code to build a pricing page it looks at page.php, sees how header.php and footer.php are pulled in, checks assets/scss/ for existing patterns, and writes page-pricing.php with a matching partial. It follows what’s already there. The output looks like the rest of the site because it was built from the rest of the site.
The smaller and more standard the theme, the better this works. Less code means less to misread. Standard patterns mean less to explain.
Why Page Builders Suffer
Elementor, Divi, WPBakery and even Gutenberg store layout and design in the database. Every row, column, spacing value and color sits in wp_postmeta or serialized inside post_content. There’s no file for an AI tool to open.
This creates three problems that don’t have good workarounds.
The Design Lives in the Database
An AI coding CLI can’t see it. You can pull it out with MCP or WP-CLI, but what comes back is a blob of JSON or nested block comments, not a page. Asking the model to modify that structure and write it back is slow, fragile and error prone. It’s the opposite of editing a template file.
Nothing Transfers
Code moves through Git. Database content doesn’t. A page built in a page builder on staging has to be exported and imported, or rebuilt by hand, to reach production. Page IDs, media IDs and internal links all shift between environments. Every deployment becomes a manual process.
No Smooth Way to Generate a Full Page
The real power of these tools is generating a complete page in a single request: HTML, CSS and JS together, styled to match the brand. Page builders have no entry point for that. You’d need to translate generated markup into the builder’s own widget format, which loses most of what makes the output good. In practice nobody does this. They paste an HTML widget in and give up on the rest.
What a Bad WordPress Setup for AI Looks Like
I see some version of this on most sites I’m asked to clean up.
Plugins built the whole thing. A theme from a marketplace, a page builder, an addon pack for the page builder, a forms plugin, a slider plugin, a header/footer plugin. No single place where the site’s code lives. The “theme” is a shell. The real site is scattered across a dozen third party codebases and thousands of database rows.
All design and layout logic is in the database. Covered above. AI tools have nothing to work with.
MCP is the only way to make changes. MCP connections to WordPress are useful for content and data work. Pulling posts, updating fields, checking settings. They’re a poor fit for design and code. Every change becomes a series of API calls to update serialized meta. You lose diffs, you lose review, you lose the ability to revert.
Devops is painful or nonexistent. No local environment, no staging, no Git, no deploy process. Changes happen live. This alone makes AI generated code dangerous. There’s no place to test it and no way to roll it back.
If this is your setup, adding AI to the mix won’t help. It’ll generate more of the same mess, faster.
What a Good Setup Looks Like
The good setup is boring on purpose. It’s how WordPress was designed to work before page builders took over.
A Coding CLI
Claude Code or OpenAI Codex, running locally against the theme directory. Not a chat window where you paste code back and forth. A tool that reads your files, writes new ones and runs commands. This is the single biggest change in how I build sites now.
A Basic Custom Theme
A theme that follows the standard WordPress template hierarchy and nothing else. My basic-wp starter on GitHub is what I use. Template files at the root, partials in templates/, SCSS and JS under assets/, a functions.php that includes a few organized files from inc/.
No framework. No build tool complexity beyond compiling SCSS. No abstraction between the template and the HTML it outputs.
This structure is well represented in training data. AI models already know it. You don’t have to teach them your conventions because your conventions are WordPress conventions.
ACF Flexible Content for CMS Controlled Pages
Clients still need to build landing pages without a developer. Flexible content handles this well.
Each layout is a PHP partial in the theme. The client picks rows in the admin, fills in fields, and the theme renders them in order. The design lives in code. Only the content lives in the database.
This is the right split. AI tools can build and modify the row templates. Clients can assemble pages from them. Nobody touches serialized layout data.
A Small Footprint
A custom theme built this way is usually under a few thousand lines of code total. A page builder site can carry hundreds of thousands of lines across its plugin stack, most of it never used.
The ratio of code to actual content matters for AI tools. Less noise means better output. It also means faster pages, fewer security issues and simpler maintenance, which is the same argument I’ve made for custom themes for years. AI just makes the gap wider.
Advanced AI Generation
This is where it gets interesting. Once a site is structured correctly you can go beyond using AI as a developer tool and put generation directly into the CMS.
The setup I’ve been using combines ACF flexible content, a custom page template and the Anthropic or OpenAI API.
How It Works
- A flexible content layout called “AI Section” has one field: a prompt textarea
- The client adds a row, writes a prompt describing the section they want, and saves
- On save the theme sends that prompt to the API along with a system prompt containing the brand’s design system: colors, type scale, spacing, component patterns
- The API returns HTML, CSS and JS for that one section
- The output is stored in a hidden field on the row and rendered on the front end
Each row is one prompt and one generated section. A page is a stack of them.
Isolated Scopes
Generated code can’t be allowed to bleed into the rest of the page. Every section is wrapped in a container with a unique ID, and the returned CSS is scoped to it. Generated JS runs inside an IIFE bound to that same container.
/**
* Render AI section
*
* Output a generated section with scoped styles and script.
*/
function render_ai_section($row) {
$id = 'ai-' . $row['row_id'];
echo '<section id="' . esc_attr($id) . '" class="ai-section">';
echo '<style>#' . esc_attr($id) . ' { ' . $row['css'] . ' }</style>';
echo $row['html'];
echo '<script>(function(root){' . $row['js'] . '})(document.getElementById("' . esc_js($id) . '"));</script>';
echo '</section>';
}
The system prompt tells the model to write CSS without a root selector and to reference root for any DOM work in JS. The wrapper handles the rest. One section can’t break another.
Branded Output
The system prompt is the brand. It includes the SCSS variables from the theme, the existing component classes, and rules about what the model can and can’t do. Generated sections come back looking like the rest of the site because they’re built from the same design tokens.
This is the part page builder sites can’t replicate. There’s no design system in code to hand to the model.
Prompt History and Rollbacks
Every generation is stored as a revision on the row: the prompt, the output, a timestamp. The client can edit the prompt and regenerate, or pick a previous version from a list and restore it.
Nothing is ever overwritten. This makes it safe to let non-developers experiment. The worst case is a bad section that gets reverted in one click.
Safe Publishing
Generated code never runs on the live site until someone reviews it. The row renders in preview mode on the draft, the client or a developer looks at it, and publishing follows the normal WordPress flow. The output is static HTML, CSS and JS with no PHP, so the blast radius of a bad generation is limited to that one section on that one page.
I’ll write up the full implementation in a separate post. It’s more involved than what’s here, but the result is a client facing prompt UI that produces clean, on brand design and code inside a normal WordPress workflow.
Final Thoughts
AI coding tools reward simple, well organized codebases. WordPress sites built the standard way, with a small custom theme and templates in version control, get the full benefit. Sites built on page builders and plugin stacks get almost none of it.
That’s not a new argument. Custom themes have always been faster, more secure and easier to maintain. AI just raises the cost of getting it wrong. If you want these tools to build pages for you, build the site in a way that lets them.