I was talking with one of our devs this afternoon.

I asked if he was running into the same auth error I’d been seeing with Claude. He paused, then gave a thumbs-down emoji. “Haven’t actually used it today. I’m working on a client’s Elementor site.”

Hold up! AI should be making our lives easier. We’re at a point where we use AI to scaffold components and spin up a prototype in minutes. And yet, one of our devs had to set the AI aside entirely. Just fix it! The blocker, the page builder.

If you’ve been doing this long enough, you know why page builders exist, especially in agency work. Page builders all solve the same problem: speed of iteration and ease of access for non-developers.

The marketing team or designer can step in, adjust some padding, change a hero image, and celebrate with the client on the same day. For small teams and clients watching their budgets, this tradeoff is beneficial. Even for developers, adjusting layout, typography, and mobile optimizations can be quick and easy. However, this can also lead to tension. This is particularly true in the ‘last mile’ stage of a project when you are trying to make your designer happy.

The context barrier

AI is good at writing code. That part is settled. You can ask Claude or GPT to generate a clean component, a functioning JavaScript class, or even a whole Elementor widget. And in isolation, it does fine. The problem shows up when the component needs to integrate with the existing Elementor site. That site’s design language doesn’t all live in the codebase. You have layers upon layers of styling and an ongoing selector war, all competing to keep you scratching your head.

It lives in the database.

This is where things fall apart. What used to be the separation of concerns quietly dissolved when we decided styles and structure were better stored in the database and injected directly into the runtime (The magic of page builders):

• Injected CSS Styles
• Class names generated as IDs
• A million ways to add the code to the page (code snippets, page editor, plugins, themes, and appearance)

So the AI hands you something technically correct and visually wrong. And you spend the next hour manually reconciling it with a styling system. Then you burn a ton of tokens, having the AI index the whole project to make all the button interactions the same, and it is still wrong. Or give up on the AI entirely to play Wack-a-Mole with the CSS. Fix one override, break another. Repeat until you pull your hair out.

And then you add environments and config management.

We all want a smooth workflow across Dev, Staging, and Production. Page builders don’t really assist with that. When styling is stored in both the database and the code, every environment can diverge. If someone makes changes directly in production in the morning and you deploy a feature from staging in the afternoon, your boss will wonder where the last set of changes went. But, but.. I tested it locally (insert sad face emoji).

Now your deployment checklist includes manually verifying that database-stored styles don’t regress. You’re diffing config from multiple environments. That three-hour deploy for a one-line fix makes sense. This kind of work feels tiring.

Why headless is appealing for AI

AI tooling didn’t just make page builders feel clunky; it made them feel clunky. It made the logical choice headless. In a headless setup, the AI finally has something it can work with:

• Full control of the markup and styles.
• Code that is fully versioned and reviewable
• Better visibility for Humans and AI

AI-generated components can align with the design system by default. Deployments stop fighting content changes. And iteration speed improves for everyone. Accessibility is overshadowed by how cheap and fast the code is to produce. Accessibility, fallbacks, mobile optimizations, BAM, they are done. The last mile doesn’t feel as painful with the code wack-a-mole, no more selector wars.

Previously, the pitch was: “Headless architecture is cleaner, but page builders are faster for non-developers.” Now, the message has shifted to: “Headless is faster for everyone.” While the flexibility of page builders is still valuable, the drawbacks include increased debugging time and challenges that go beyond AI’s capabilities (though it’s not without its flaws).

It’s frustrating to watch a senior developer sigh and close an AI tab just to wrestle with a page builder, only to end up struggling through a CMS theme. With AI, we all want to move on to bigger and better things.