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.”

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. The blocker was 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. 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—it lives in the database. You have layers upon layers of styling and an ongoing selector war, all competing to keep you scratching your head.

This is where things fall apart. What used to be separation of concerns quietly dissolved when we decided styles and structure were better stored in the database and injected directly into the runtime: injected CSS styles, class names generated as IDs, and a million ways to add code to the page through snippets, the page editor, plugins, themes, and appearance settings.

So the AI hands you something technically correct and visually wrong, and you spend the next hour manually reconciling it with a styling system. You burn tokens having the AI index the whole project to make all the button interactions consistent, and it’s still wrong. Or you give up on the AI entirely to play whack-a-mole with the CSS—fix one override, break another, repeat.

Environments and config management

We all want a smooth workflow across Dev, Staging, and Production, but 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.

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 starts to make sense, and this kind of work gets tiring.

Why headless is appealing for AI

AI tooling didn’t just expose how clunky page builders are, it made headless the obvious choice. In a headless setup like we built for Linkwell Health, the AI finally has something it can work with: full control of the markup and styles, code that is fully versioned and reviewable, and better visibility for both humans and AI.

AI-generated components can align with a documented component system by default. Deployments stop fighting content changes. Iteration speed improves for everyone. Accessibility, fallbacks, and mobile optimizations get handled because the code is cheap and fast to produce. The last mile doesn’t feel as painful without the 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.” The flexibility of page builders is still valuable, but the drawbacks—increased debugging time and challenges that go beyond what AI can help with—are harder to justify. It’s frustrating to watch a senior developer set aside AI tooling just to wrestle with a page builder when we could all be moving on to more interesting problems.