Something changed in how sites get built, and I do not think page builders have caught up with it. A designer who could not write a template a few years ago can now describe what they want to an AI coding assistant and get working, readable HTML back. That makes the old bargain of page builders, “you do not have to touch code”, much less attractive.

This article looks at why real templates and AI assistants work well together, why static sites are a natural home for that way of working, and where the limits are.

What page builders were for

Page builders became popular because they let people who were not developers change layouts. Drag a column here, drop an image there, adjust spacing in a panel. For a time, that was the only practical way for a designer or marketer to shape a page without waiting on a developer.

The cost was hidden structure. The page you see is generated from settings stored in a database in the builder’s own format. There is no template you can read top to bottom. Every element carries layers of wrappers, classes and inline styles. Small changes mean hunting through panels, and site-wide changes mean repeating the same edit on every page.

Page builders are pre-AI tools. They solved the “I cannot write code” problem by hiding the code. AI assistants solve it by writing the code for you, in a form you can read and keep.

Why real templates suit AI assistants

An AI coding assistant works best when it can see the actual source of what it is changing. A static site gives it exactly that:

Templates are plain files. HTML with a small templating language, CSS and perhaps a little JavaScript. The assistant can read them, change them and explain what it changed.
Content is plain files. Markdown and YAML are easy for both people and models to read.
The structure is visible. A layout file, a set of includes, a stylesheet. The assistant can follow how a page is assembled.
Changes are small and reviewable. A request like “add a testimonial strip under the hero on the services page” becomes a diff of a few lines.

Compare that with asking an assistant to change a page builder layout. The real structure is in the database, in a format the assistant cannot see or edit directly. At best it can tell you which panels to click.

Git as the safety net

Letting an AI assistant change your site would be nerve-wracking without a way to see and undo what it did. Git provides that.

Every change becomes a commit with a clear diff. A developer or designer can review it before it goes live, often through a pull request with a preview build. If something slips through, reverting the commit puts the site back exactly as it was. Over time, the history shows who changed what and why.

This is the same safety net developers have relied on for years. Static sites make it available for design and content changes too, not just code.

Designers as template editors

The most practical shift is for designers. With an assistant, a designer can:

Adjust spacing, type and colour in the stylesheet directly, rather than through a theme options panel.
Build a new section as a reusable include, and use it on several pages.
Try a variation on a branch, see it in a preview build and throw it away if it does not work.
Ask the assistant to explain an unfamiliar template before changing it.

They still benefit from a developer’s review for anything structural, and they need a sensible starting point: a clean set of templates with consistent naming. But the gap between “designer” and “person who edits templates” is much smaller than it was.

Where content editors fit

Not everyone should be prompting templates. Marketing coordinators and other content editors usually want a screen with fields, not a code editor or a chat window that can change the layout.

The healthy split is: designers and developers own templates, with AI help; editors own content, through a CMS that writes to the same repository. Both kinds of change land as commits in git, so they sit in one history. The guide to adding a CMS and editing workflows for teams cover the content side.

Risks and guardrails

AI assistants make mistakes, sometimes confidently. Sensible guardrails:

Review every diff before it goes to the live branch, even small ones.
Use preview builds so a person checks the result in a browser.
Keep the assistant’s access scoped to the repository it needs. Do not hand it production credentials.
Watch for accessibility regressions, such as missing labels, poor contrast or headings out of order. Assistants do not always get these right.
Keep templates tidy. Assistants copy patterns they find. A messy codebase produces more mess.

None of this is specific to AI. It is ordinary good practice that becomes more important as more people can make changes.

What this means for choosing a platform

If your team expects designers and developers to iterate on templates with AI help, choose a platform where templates are real, readable files in git. Static site generators fit that well. A WordPress site built with a clean custom theme can work too, though the database still holds much of the content and configuration. A site built on a page builder fights it at every step.

See static sites vs WordPress for teams for the wider comparison.

My take

I think AI assistants have quietly made page builders obsolete for anyone starting a new site. They promised designers freedom from code, and delivered it by hiding the code behind panels. Now designers can work in the code itself, with help, and keep a clean, reviewable result.

Static sites are a good home for that: templates in files, content in files, everything in git. The remaining job is giving non-technical editors a friendly way to change content without touching templates, which is the gap tools like Mabel are built to fill.