MHMunir Hassan

Engineering · AI

Moving my blog off WordPress with an AI agent: what I delegated, and what I didn't

MHMunir Hassan//4 min read

For years this blog ran on WordPress, and for years I got the same emails: a plugin has a vulnerability, a core update is available, please update now. The site had fifteen posts. It was costing me more attention than it was worth.

This afternoon I moved it to a static site, working with an AI agent. The whole thing, from the WordPress export to the new site live on my domain, took one afternoon. That’s the headline, but it isn’t the interesting part. The interesting part was deciding what to hand over, and noticing where the agent stopped and I had to step in.

The first idea was the wrong one

My opening request was an agent that would watch the WordPress site, apply security updates and publish new posts for me. The pushback was immediate, and it was right. Giving an AI admin access to patch a live site doesn’t remove the risk; it adds a new one. The better move was to remove the thing that needed watching.

A static site has no plugins, no database and nothing to patch on the server. So instead of automating the maintenance, we deleted it.

It’s a familiar lesson in a new setting. The best fix for an operational burden is often to design it out rather than to staff it, with people or with agents.

What the agent did well

Once the direction was clear, the agent moved fast, and most of it was genuinely good work:

  • It converted the WordPress export into clean Markdown, keeping code blocks, tables and the language of each code sample.
  • It rebuilt the site in Astro and kept every old URL working, fifty-odd of them including categories and tags, so nothing already shared or indexed would break.
  • It couldn’t reach my old host to download the images, so it wrote a small GitHub Action that ran from GitHub instead, copied all 43 images and committed them.
  • It tested its own work: every old address, every image, the feed and the redirects, first on a preview address and then on the real domain.

That last point matters more than the speed. An agent that checks its output against the real requirement is worth far more than one that just produces a lot of it.

Where I stayed in charge

The more useful moments were the ones where the agent didn’t act.

Accounts and money. Signing up for hosting, choosing the free plan, looking at renewal prices: those stayed with me. Along the way the agent spotted that my domain’s auto-renewal was switched off, which is exactly the kind of quiet risk that takes a site down a year later.

DNS. The agent drove the browser right up to the nameserver change, then refused to make it. Its guardrails block DNS and domain changes. At first that felt like friction. By the end I saw it as the right boundary: a DNS mistake can take a domain offline, and it’s the one step that’s hard to undo. So it prepared everything, I made the change, and it verified the result.

The words about me. The first About page it wrote was generic. It also included a line about technologies I’d only planned to learn, not ones I actually use. It was plausible, and it was wrong, and an interviewer would ask about it. I took it out. The rule I settled on: the agent can draft anything, but every claim about me has to be something I can defend in a conversation.

My voice. My first reading-notes post came back well written and not quite me. It read like a confession with a to-do list attached. We rewrote it until it said what I actually think. Fluent isn’t the same as authentic, and only the author can tell the difference.

What this changes for a team

I lead engineers, so I keep thinking about how this translates beyond a personal blog. A few things feel true already:

  • Treat agent output like a pull request from a very fast new joiner. It’s often good and occasionally confidently wrong, and it always needs a reviewer who understands the goal.
  • Guardrails are a feature. The steps an agent can’t take on its own are usually the irreversible ones. Those are exactly where a human decision should sit.
  • Verification is the multiplier. The value came from the agent checking its work against real URLs and real pages, not from how much it generated.
  • Decisions don’t delegate. The agent could build three visual styles in minutes. Choosing one, and choosing what the site should say about me, was still my job.

The site you’re reading is the result. It costs nothing to host, there’s nothing left to patch, and publishing a post is a pull request I review before it goes live, which is also how this one was published.