See the light!
build a WordPress blog with AI

How I built my WordPress blog with an AI agent

I rebuilt this blog from an old 2016-era site on an outdated version of WordPress. I did it with an AI agent, without a page builder and without hand-coding a theme from scratch. The core of the blog came together over a single weekend, with touch-ups and content checks over the following week.

A note on how this post was made: an agent drafted it, and I reviewed and published it. This post covers the build. For the overall way I work with the agent, start with my primer on the agentic workflow.

What stack did I choose, and why?

I used WordPress with its own default block theme as the parent and a child theme on top, plus a small plugin for my site-specific code. That choice keeps the parent theme updatable and keeps my customisations portable if I ever change themes.

  • A child theme, never an edited parent. Everything I change lives in the child, so updates to the parent cannot overwrite my work.
  • A small site-specific plugin. Custom code goes here, not in the theme, so it survives a theme change.
  • Lean plugins. I add a plugin only when a real need shows up. Two earned their place: Yoast SEO for search metadata and Redirection for sending old addresses to the new ones.

The rule behind all of it: secure, fast and cheap by design, and do not reinvent something that already exists.

How does the agent build the site?

The agent builds locally first, through a command line tool, working from a written spec. Each of those three choices makes its work safer and easier to check.

  • Local first. I build in a development copy of the site on my own machine. It is the safe place to break things.
  • Through the command line, not the dashboard. The agent drives WordPress with WP-CLI. Every change is a command it can repeat, script and check, which a series of clicks is not.
  • Spec first. Before it builds anything, I give it a written brief: wireframe mockups for each page and a design guide covering colours, type and layout. It builds to the mockup and then compares its own output against it.

One structural decision shows how this plays out. The blog has three content sections, Lifestyle, Tech and Finance, and they all share a single archive template. WordPress already puts the section name on the page as a class, so the colours, labels and placeholder images for each section come from CSS alone. There are no three separate templates to keep in step.

What do I direct, and what does the agent run?

I direct the design, the structure and the question of whether something feels right. The agent does the implementation and the measuring.

The agent is also confidently wrong at times, mostly on anything visual. I once asked for a decorative page-curl effect on a corner hover. Six attempts missed, and one was rejected as nowhere near a real page curl. Only when I supplied a reference image did it get there. So a reference now comes first, before the first attempt, not after the sixth.

The same thing happened with spacing and positioning. A screenshot looked fine while the measured numbers were off, so the agent now measures the page instead of eyeballing it.

How does it get from my laptop to the live site?

The live blog runs on a small cloud server behind a CDN, and there is no separate staging server. I write content directly on the live site, which makes the live database the source of truth. My local copy stays for code and theme work only, and I never copy its database over the live one.

The move to the live server, including the old-address redirects and the cutover itself, is its own story. I will cover it in the next post in this series.

What would I tell someone doing the same?

  • Write the spec before the agent builds. A mockup and a design guide beat a vague description every time.
  • Make it measure. Ask for numbers, not a verdict that it looks right.
  • Keep local and live roles separate. Decide which copy holds the content, and stick to it.
  • Keep plugins minimal. Each one you add is more to update and more to trust.

That is the build. Next in the series: how I migrated the old blog onto it, including the old addresses. If you have not read it yet, the primer is the best place to start.