How an AI agent builds a complete website — and why a human can still edit every pixel of it

Last month we migrated a 24-page corporate WordPress site to Element Node. The agent build took about one hour. A human then spent a short review pass in the visual editor adjusting spacing and swapping two photos. The client edits the site themselves today, in an interface that feels like the page builder they already knew.

This post explains the architecture that makes that possible — and why we think "AI builds it, humans keep editing it" is the design constraint that actually matters for CMSs in the agent era.

The gap nobody was filling

Web tooling split into two camps a long time ago. Page builders (WordPress + Elementor, Wix, Squarespace) optimize for non-technical humans: great visual editing, but an internal representation so tangled that automating it reliably is painful. Headless CMSs (Strapi, Contentful and friends) optimize for developers: clean APIs that agents can drive — but when the agent is done, the client can't touch anything without a developer in the loop.

AI agents broke this truce. An agent can now produce an entire site in one session, which makes the "who edits it afterwards?" question the whole game. If the answer is "a developer", you've built a code generator. If the answer is "nobody, it's locked in a SaaS", you've built a demo. We wanted the answer to be: the same person who edited sites before — visually.

One representation, two interfaces

Element Node's core decision is that a page is a single JSON tree: sections contain columns, columns contain widgets. There are 51 widget types, each with a TypeScript schema — heading, text, gallery, contact form, counters, tabs, nav drawer, and so on. Global header and footer live in theme blocks with display conditions, which is also how multilingual sites work natively.

That one tree gets two interfaces:

• For humans: a 3-panel visual editor — widget library, canvas, properties — with drag & drop, inline text editing, undo/redo and revisions. If you've used Elementor, your hands already know it.
• For agents: the same tree as structured data, through three doors — an official Claude Code skill, an MCP server, and a REST API with scoped keys.

Because both interfaces read and write the same representation, there is no handoff, no export step, no "regenerate and lose your changes". The agent's output is the human's input, and vice versa.

Whole sites as one JSON document

The unit of agent work isn't a page — it's a site. Element Node has a Site Blueprint format: pages, theme, navigation, forms and settings serialize to a single JSON document that can be imported (merge or replace) and exported through one endpoint.

This is what makes agent workflows practical. The agent composes a blueprint locally, imports it in one call, looks at the result, patches, re-imports. Provisioning a new site — including the server-side install — can be driven by a single prompt.

The visual-diff loop, with real numbers

The most interesting agent workflow we run is pixel-accurate site cloning (used for migrations — your own site, moving off WordPress). The skill orchestrates a loop: screenshot the original, screenshot the clone, have a vision model diff them section by section, emit patches against real widget capabilities, re-import, repeat.

The numbers from a real production run, cloning a React SPA: the first iteration scored 76/100 on automated visual fidelity; by iteration five it converged at 95/100. Wall-clock: about two hours of agent time. The remaining 5 points are things a human fixes in minutes in the editor — which is exactly the division of labour we're designing for.

Other real datapoints from our own sites (agent build time, human review on top): that 24-page WordPress migration in ~1 hour; a complete bilingual site in half a day. Our public demo — demo.elementnode.cloud, a fictional brand-studio site — was built end-to-end by an agent, images included.

The MCP server

The skill is Claude Code-specific. For everything else — Cursor, Windsurf, Codex, Gemini CLI, any MCP client — there's an official MCP server, published on npm as element-node-mcp (MIT, runs via npx). Twelve tools: pages, theme, media, full blueprint import/export, and always-fresh widget documentation served straight from the repo, so the agent never works against stale docs.

No plugins is a feature

Element Node ships everything native: forms, SEO, cookie consent, custom post types, redirects, popups, media optimization, roles, 1-click self-updates with automatic pre-update database backups. There is no plugin ecosystem — deliberately.

For agents, this means the widget vocabulary is closed and typed: the agent can't produce a page that depends on a plugin you don't have. For security, it removes the single largest attack surface of the WordPress world — the overwhelming majority of reported WordPress vulnerabilities are in plugins, not core (Patchstack's yearly reports put it above 90%). For performance, it means React Server Components and ISR caching with no plugin tax: no render-blocking scripts you didn't choose.

What stays human

We're deliberately not building "type a prompt, get a business". Agents are excellent at assembling structure, migrating content, and iterating against a visual target. Humans are still better at judging whether the result actually represents a business — and clients justifiably want to fix a typo at 11pm without filing a ticket.

So the human parts are load-bearing, not decorative: everything the agent makes lands in the editor as ordinary, editable widgets. No generated blobs, no locked regions. Built by agents, owned by people.

Try it

The core is open source (AGPL-3.0; the skill and MCP server are MIT). Self-hosted on your own server, one-line install:

bash <(curl -fsSL https://elementnode.cloud/install.sh)

Live demo built by an agent: demo.elementnode.cloud · Source: github.com/LorenzArtik/element-node · Site: elementnode.cloud