We let an AI build our own product site. Here is the HTML.

Vendors love saying "built with AI." Almost nobody shows you the markup, which is a bit like a chef refusing to let you see the kitchen. So here's ours.

Plain HTML in your own database, which sounds like marketing until you look at it. This is a real section from the live /ai-design/ page, copied out of view source:

<section id="ppd-section-2" class="ppd-section" data-ppd-type="aid-trust">
  <section class="aid-trust">
    <div class="aid-trust__inner">
      <p>…</p>
    </div>
  </section>
</section>

(Paragraph text elided, since it's the structure that matters here.)

That's the whole thing. One wrapper carrying an id and a type, and inside it the markup the agent wrote. No builder classes, no data-elementor-* attributes, no serialized blob getting unpacked at render time.

In the database that section is stored as four fields. The markup, with {{placeholder}} markers:

<section class="aid-phead">
  <span class="aid-phead__badge">{{badge}}</span>
  <h1 class="aid-phead__title">{{title}}</h1>
  <p class="aid-phead__desc">{{description}}</p>
</section>

The values, kept separately from the markup:

{ "badge": "Documentation", "title": "Documentation",
  "description": "Everything you need to install NoLeemits AI Design…" }

And the bit that makes it survivable, a schema describing each field:

{ "badge":       { "label": "Eyebrow",         "type": "text" },
  "title":       { "label": "Page title (H1)", "type": "text", "required": true },
  "description": { "label": "Intro",           "type": "textarea" } }

That last block is why a non-developer can edit this page. It generates labelled inputs instead of dumping someone into a code editor.

The agent read the site's design tokens before writing any of it, which is what keeps every page on the site looking related:

{ "colors": { "primary": "#667eea", "secondary": "#764ba2", "accent": "#f093fb" },
  "fonts":  { "heading": "'Space Grotesk', sans-serif", "body": "'Inter', sans-serif" },
  "spacing":{ "section-y": "80px", "gap": "2rem" } }

Plenty, and this is the most useful section in the post.

The screenshot caught something every automated check passed. On the previous post, the intro paragraph got folded into the first section, which pushed that section's actual answer down to the third paragraph. Every DOM assertion passed. One look at a screenshot made it obvious. Automated checks confirm what you thought to ask about.

Two installs, two versions, nearly one wrong number. There are two WordPress installs on the build machine running different plugin versions. I counted a figure off the running server, which was the older one, and very nearly published it under the newer version's heading. The number turned out to be identical in both, so nothing shipped wrong, but it was luck rather than process.

A dead link nobody noticed. The navigation on every product page pointed at a blog index that didn't exist yet. It had been silently whitelisted in the link checker as a known gap, which is a great way to stop seeing a problem.

A schema field that saved nowhere. One section type declared an editable "heading" field it didn't actually have, which would render an input in the admin that quietly discarded whatever you typed into it.

None of these are AI problems. They're the ordinary problems of building a site, which is rather the point. The agent didn't produce mysterious output that resisted debugging. It produced normal output with normal bugs.

Yes, and the honest version is that it's less magical than it sounds.

Install the plugin, generate a bearer token, point an MCP client at your site, and ask it for a page. It reads your design tokens, picks images from your media library, and writes sections into your database. Your editors then maintain those sections through labelled inputs without touching code.

Start at Getting Started, then MCP Setup for the connection itself.

Did the AI write the CSS too, or just the content? Both. Every section carries its own scoped CSS, written by the agent, referencing the site's design tokens for colour and spacing. Nothing is picked from a theme's stylesheet, which is why these pages render the same on any theme.

What stops it inventing facts about your product? Nothing automatic, and that's the honest answer. The agent can leave a comment pinned to a section flagging a claim it wasn't sure about, which is genuinely useful, but a human still checks the claims. On the previous post three of them got cut for being unsourceable.

Could someone non-technical edit these pages now? Yes, that's the entire point of the field schema shown above. An editor gets labelled inputs for text, images, icons and colours. They never see the markup and can't accidentally break the layout by editing a headline.

Is the post I'm reading also built that way? Yes. It's a WordPress post whose body is NoLeemits AI Design sections, built from a markdown draft through the same validation and verification steps described above.

What happens if I don't like what it built? Every change is a revision that records who made it, whether human or AI, and through which client. Roll back to any earlier version, or export the page as JSON or HTML and take it elsewhere.

The build described here ran on 2026-08-10 against noleemits.com. Verification output is quoted from that run. Current version and release history live on the release notes, which are generated from the plugin itself.