Which WP Theme Is Better for AI-Assisted WordPress Developments: Classic or FSE?

I got into this research to find out which kind of theme should I use for my new WordPress site. I am planning to use AI heavily in building this new site.

So thought of sharing my findings to you as well!

The main factors are:

1. AI can’t use page builders – AI agents cannot generate the complex, proprietary JSON layouts required for Elementor, Divi, etc. And, using AI in browsers is slow and painful. It also is not good enough yet to navigate those complicated page builder interfaces.

2. AI finds it difficult to create native block pages that are editable in the backend. But is great at creating short codes to use in the blocks.

3. If you are only planning to generate fully custom pages with no need to make them editable in the WP backend, then Classic theme is the safest option.

4. If you want to make pages editable at the backend without touching code, the only option is FSE block pages or use Classic theme with Guttenberg blocks.

5. My Recommendation: Use FSE theme and short code heavy patterns inside standard page templates to build your new pages.

If these main points do not make things a bit clearer, please read the answers to all the questions I initially had about this issue.

1. The Core Question: If I want to rely heavily on AI Agents to build my site, which theme architecture is better?

The Verdict

If your primary workflow involves using AI Agents (like Claude Code, Antigravity, Cursor, etc.) to write code and build features, Classic Themes (like Neve) currently offer a significantly smoother and more reliable workflow than Full Site Editing (FSE) themes.

The Reason: AI Speaks PHP, Not “Block Grammar”

The fundamental issue isn’t about which theme is “newer” or “better” for humans; it is about which language your AI partner speaks fluently.

1. The “Native Language” of AI is PHP: AI models (like GPT-4, Claude 3.5, and Gemini) were trained on over 20 years of open-source WordPress code. They have seen millions of functions.php files, standard CSS stylesheets, and PHP hooks.

If you ask an AI to “Add a conditional banner before the header if the user is logged out,” it can instantly write a standard PHP hook (add_action). It knows exactly where to place it, and the code will work 99% of the time because the logic is standard and robust.

2. The Struggle with “Block Grammar”: FSE themes do not use standard HTML for their templates; they use Block Grammar. This is a rigid syntax that wraps JSON data inside HTML comments.

• Standard HTML (Easy for AI): <div class="hero">...</div>

• FSE Block Grammar (Hard for AI): <!– wp:group {“layout”:{“type”:”constrained”}} –>

This syntax is verbose and incredibly fragile. If the AI misses a single closing bracket, forgets a quote in the JSON object, or hallucinates an attribute that doesn’t exist in your specific version of Gutenberg, the entire Site Editor can break. The AI often “guesses” attributes that sound logical but aren’t valid, leading to the dreaded “This block contains unexpected or invalid content” error.

3. The “Training Data” Gap: LLMs work best with “famous” codebases. A theme like Neve has a massive footprint in the AI’s training data. The AI likely knows Neve’s specific CSS class names and hook locations by heart. In contrast, FSE patterns are newer (~3 years old) and change frequently, meaning the AI is often working with outdated or incomplete knowledge of how the specific blocks should be structured.

2. Can AI Agents effectively build “Patterns” and “Templates” for FSE themes?

The Nuance

Yes, they can—but only if you adopt a “Pattern-First” strategy that plays to the AI’s strengths. If you ask an AI to “build a whole page template,” it will likely fail. If you ask it to “build a PHP Pattern,” it will likely succeed.

The Strategy: PHP Patterns over HTML Templates

The secret to making FSE work with AI is to bypass the HTML template files (which use fragile Block Grammar) and instead ask the AI to generate PHP Pattern files.

• HTML Templates (The Trap): FSE templates are essentially HTML files filled with JSON comments. As we discussed, if the AI misses a single closing bracket or invents a block attribute that doesn’t exist in your specific WordPress version, the entire editor breaks with a “Recovery Mode” error.
• PHP Patterns (The Solution): A PHP pattern allows the AI to use standard logic and dynamic elements. You simply ask the AI to generate a PHP file to drop into your theme’s patterns/ folder.

Why This Works

When you use a PHP pattern, you are working with a format the AI understands deeply. If the AI makes a small syntax error in PHP, it’s usually easy to debug (or the AI can fix it itself). If it makes a syntax error in Block Grammar, the visual editor simply refuses to load, giving you zero feedback on what went wrong.

3. Why do AI Agents almost always prefer using Shortcodes inside Block Patterns?

The Observation

You have likely noticed this behavior: You ask an AI agent to “Create a Hero Section pattern with a Call to Action.” Instead of giving you a complex structure of wp:cover and wp:buttons blocks, it hands you a pattern file that contains a single line: [hero_section_shortcode].

The Explanation

This isn’t laziness; it is a statistical safety mechanism.

1. Training Data Imbalance: Shortcodes have been a core part of WordPress since version 2.5 (2008). The AI has trained on millions of examples of reliable, working shortcodes. In contrast, stable Block Markup has only existed for a few years, and the syntax changes frequently. The AI “knows” that a shortcode is a solved problem.
2. Token Efficiency & Complexity:
   • The Native Way: A native button block requires nested divs, specific CSS classes (wp-element-button), and JSON attributes. It is verbose and fragile.
   • The Shortcode Way: [button] is simple, robust, and impossible to “break” structurally.
3. The “Hybrid” Loophole: The AI is clever. It knows that FSE supports a “Shortcode Block.” By wrapping its logic in a shortcode, it bypasses the risk of generating invalid block JSON while still delivering a compatible component for your FSE theme.

4. Does using Shortcodes create a “Separation of Concerns” problem?

The Trade-off

Yes, absolutely. The “Shortcode in Pattern” approach fragments your single component into three distinct locations, which can be frustrating for human developers:

1. Placement: The Pattern file (patterns/hero.php) says where the component goes.
2. Logic: The functions.php file contains the actual code for how it works.
3. Style: The style.css file contains the instructions for what it looks like.

The Silver Lining

While this separation is annoying for humans (who have to context-switch between files), it is actually safer for AI agents.

• Reduced Cognitive Load: The AI can write the PHP logic in isolation without worrying about HTML layout structure. It can write standard CSS without worrying about JSON syntax.
• Safety via Isolation: Because the pattern file essentially just says [shortcode], there is almost zero chance of a syntax error breaking the editor.
• The “Context Switching” Solution: Since you are using an AI agent, you can turn this weakness into a workflow. Instead of manually jumping between files, you simply prompt the agent to treat it as a “Three-Part Component”:“Create this feature. Give me the PHP for functions.php, the CSS for style.css, and the Pattern file to register it.”

By accepting this separation, you gain stability. You lose the “Visual Editing” of the component (it appears as a grey box in the editor), but you gain a robust, AI-generated feature that won’t crash your site.

5. “But I can force the AI to generate native Blocks (HTML/JSON) instead of Shortcodes. Doesn’t this make FSE the winner, since AI can’t use Page Builders at all?”

The Theoretical Win

You are absolutely right. If you can successfully prompt an AI to generate valid native block markup, you have achieved the “Holy Grail” of WordPress development.

If you prompt the AI with: “Create a Hero section using core wp:group and wp:heading blocks,” and it works, you get the best of both worlds: a component that is fully visually editable in the Site Editor, requires no extra plugins, and uses zero PHP.

The Practical Nightmare: “Block Validation Errors”

While valid in theory, in practice this approach often leads to a frustration loop known as “Block Validation Hell.”

1. The Syntax Trap: Native blocks rely on extremely precise JSON data embedded inside HTML comments.
   • Example: If the AI misses a single closing brace, forgets a quote around a key, or nests the comment incorrectly, the entire block breaks. The editor will display the dreaded message: “This block contains unexpected or invalid content,” forcing you to attempt a “Recovery” that rarely works.
2. The Versioning Problem: The Block Editor (Gutenberg) evolves rapidly. Attributes that were valid in WordPress 6.3 might be deprecated in 6.5. Since AI models have a training cutoff, they often use outdated block attributes.
   • Result: The AI generates code that was correct two years ago but causes a validation error on your modern site.
3. The “Hallucination” Risk: AI models are linguistic, not technical documentation parsers. They often “guess” block attributes that sound logical but do not exist in the official specification.
   • Example: An AI might write “. Ideally, it should be {"align":"center"}. This tiny semantic difference is enough to break the visual editor, leaving you to debug minified JSON strings.

The Verdict: High Risk, High Reward

Comparing the three main ways to build a layout with AI, the success rates tell the story:

• Page Builders (Elementor/Divi): 0% AI Success. AI simply cannot generate the complex, proprietary JSON blobs these builders use.
• Native Blocks (FSE): ~70% AI Success. It works often, but about 30% of the time you will spend more time debugging the AI’s JSON syntax than it would have taken to build the block manually.
• Shortcodes/PHP (Classic/Hybrid): ~95% AI Success. Because PHP and standard HTML are stable languages, the AI rarely fails. It is the “safe bet” for automated coding.

6. Are there performance penalties when using the “Shortcode Method” in FSE?

The Myth

“Shortcodes are old technology, so they must be slower than modern Blocks.”

The Reality

In many cases, the Shortcode method is actually faster and cleaner for the browser to render than native FSE blocks.

The Details

When you use a native FSE Block (like a Group or Query Loop), WordPress automatically wraps your content in multiple layers of <div> tags to handle alignment, colors, and layout constraints. A simple list of three posts might result in a DOM tree that is 10-15 levels deep before you even get to the content.

• Bloat Factor: Deep DOM trees increase memory usage and slow down rendering in the browser.

In contrast, a custom Shortcode outputs exactly the HTML you tell it to.

• The Clean DOM Advantage: You can write a PHP function that outputs a simple <ul> list with zero wrapper divs.
• Server-Side Speed: The do_shortcode() function in PHP is extremely optimized. As long as your custom code isn’t running 500 database queries, the time it takes to parse the shortcode is microseconds—often faster than the Block Editor’s process of parsing and rendering a massive JSON object.

7. Native Query Blocks vs. Custom Shortcode Loops: Which is better for AI?

The Comparison

• Native Query Loop Block: To configure this block programmatically, an AI has to manipulate complex JSON attributes nested deep within the block comment.
  • The AI Struggle: Asking an AI to “Show posts from the ‘News’ category, exclude the current post, and order by modified date” via block attributes is a nightmare. The AI often hallucinates setting names or fails to nest the query properly.
• Custom Shortcode Loop: This relies on WP_Query, the bedrock of WordPress development.
  • The AI Strength: If you ask an AI to “Write a WP_Query loop for ‘News’ excluding current post,” it will give you 10 lines of perfect, standard PHP code instantly.

The Winner: The Shortcode Loop

For complex logic, code beats configuration.

• Precision: You can easily add “Meta Queries” (e.g., “Show posts with a custom field ‘featured’ set to true”) or “Taxonomy Queries” that are impossible or very difficult to configure in the native block UI.
• Reliability: The AI is far less likely to “break” a PHP loop than it is to malform a JSON query object.

8. The Classic Theme Myth: Are you locked into editing raw PHP files?

The Fear

“If I choose a Classic Theme like Neve, I’m stuck in 2015. I’ll lose the ability to visually edit my pages and have to hand-code every template in PHP.”

The Reality

Absolutely not. Classic Themes fully support the Gutenberg Block Editor for content.

The Workflow

You get a “Hard Shell, Soft Center” architecture:

1. Soft Center (The Content): For your Pages and Posts, you use the modern Block Editor (just like in FSE). You can drag, drop, and style blocks visually. The AI can help you write HTML or CSS for these areas, and you can see the results instantly.
2. Hard Shell (The Structure): Your Header, Footer, and Page Templates are controlled by PHP files.
   • Why this is a Pro: In FSE, it is dangerously easy for an AI (or a client) to accidentally delete the header template from the visual editor. In a Classic theme, the header is “hard-coded” in PHP. It is unbreakable from inside the dashboard.

The Best of Both Worlds

You get the visual flexibility where you need it (content creation) without the structural fragility where you don’t (site layout).

9. The Page Builder Dilemma: “If I use a Classic Theme, am I stuck coding PHP templates manually since AI can’t use Page Builders?”

The Fear

Many developers assume that if they abandon a visual Page Builder like Elementor or Divi, their only remaining option is to hand-code every single page template in raw PHP. This feels like a massive step backward in efficiency.

The Reality

No. You have a powerful third option that acts as the perfect middle ground: The Native Block Editor (Gutenberg).

The Solution

• AI + Page Builders = ❌ Fail. AI agents cannot generate the complex, proprietary JSON layouts required for Elementor or Divi. If you ask an AI to “Build a pricing table for Elementor,” it cannot give you a file you can simply import.
• AI + PHP Templates = ⚠️ Hard. Writing raw PHP templates is effective, but it requires you to edit files on the server, manage FTP access, and debug code. It is a slow, “pro-code” workflow.
• AI + Gutenberg = ✅ Success. You can simply ask the AI to write standard HTML and CSS for a section (e.g., “Create a hero section with 3 columns using Bootstrap classes”).
  • The Workflow: Paste that code into a “Custom HTML” block in the editor.
  • The Magic: You can often hit “Convert to Blocks” to turn that AI-generated HTML into native, editable blocks. This gives you visual editing without the Page Builder lock-in.

10. Classic + Gutenberg vs. FSE: Aren’t they basically the same thing?

The Distinction

Superficially, they look identical: you open a page, you see blocks, you edit text. But structurally, they offer a fundamentally different Site Building experience.

The “Soft Shell” vs. “Hard Shell”

• FSE (Soft Shell): In Full Site Editing, your entire site structure—headers, footers, sidebars—is editable within the visual editor.
  • The Risk Factor: An AI agent (or a clumsy client) can accidentally delete your Header Template while trying to edit a menu. Since the structure is just “data” in the database, it is fragile.
• Classic Theme (Hard Shell): In a theme like Neve, the header and footer are hard-coded in PHP files.
  • The Safety Factor: The AI cannot accidentally “delete” your header from the visual editor because it doesn’t exist there. It is part of the immutable theme code. This makes Classic themes significantly more robust against accidental AI errors.

11. The “Container Trap”: Why Shortcodes behave differently in FSE vs. Classic

The Gotcha

You might paste a perfectly good shortcode into an FSE theme, only to find it looks squashed, centered, or misaligned—even though the exact same shortcode looked perfect in your Classic theme.

The Cause: “Layout Constraints”

FSE themes rely on a configuration file called theme.json that enforces “Global Layout Constraints.”

• The Behavior: When you drop a generic block (or a shortcode) into an FSE template, the theme often wraps it in a container class like .is-layout-constrained.
• The Result: Your shortcode, which you designed to be 100% width, is forcibly restricted to the “Content Width” (e.g., 650px).

The Fix

You must fight the theme’s default behavior.

1. Select the Shortcode Block.
2. Group It: Click the “Group” icon in the toolbar.
3. Force Full Width: Select the parent Group block and toggle the alignment setting to “Full Width.”This manually overrides the theme.json constraints and allows your AI-generated shortcode to behave as expected.