Using AI as a CMS

I have been building websites and working with content management systems for a long time.

Back in the noughties I was dabbling with PHP content management systems like Mambo and Joomla. Since then I have worked on WordPress sites, used platforms like Squarespace and Framer, and more recently, headless CMSs like Sanity and Contentful.

Each one offered a different way to manage a website. Different interfaces, different constraints, different amounts of setup before you could publish a single sentence.

Today my workflow is to open a conversation, describe the change I want, and have it made and put live.

Increasingly, AI is my CMS.

From Editing Fields to Describing Changes

A content management system gives you somewhere to put things. A title goes here. Body copy goes there. Images, categories, publication dates.

You learn how the system has decided to represent your website, then you work inside that shape. If the shape is wrong, you either live with it or you go and build a new content type.

With AI, I can start from the outcome instead.

An instruction can be as small as “fix the second paragraph on the about page” or as broad as “add this project and link to it from the homepage”.

Here is a real one: this post.

It started as an outline pasted into a conversation. Headings, and under each one a note to myself about what that section should cover.

The section further down this page, the one listing where I work and how a change goes live, began as five bullet points and one instruction: include the actual tools and where the content lives.

That instruction is the whole thing. I never supplied the actual tools. That posts are markdown with a short block of frontmatter, that the Impromptu line-up is a typed file, that review happens on a dev server at localhost, that Netlify is watching for a push: none of it was in the outline. It came back filled in, because whatever is writing the section can go and read the site it is describing.

A CMS gives you an empty box and waits for you to fill it. It has never read your repository.

What My Workflow Looks Like Now

The whole thing is unglamorous, which I think is the point.

• Where I work. A conversation open beside the project folder, in Claude Code. No admin URL, no login.
• Where the content lives. In a GitHub repository, as files. Posts are markdown with a short block of frontmatter at the top. The Impromptu line-up is a typed file the homepage and the events page both read from. Images sit in a public folder.
• How I hand over content. I talk, or I paste in a rough draft, or I drop an image into the folder and point at it.
• What gets edited. The actual files. Frontmatter, body copy, and occasionally a component, when the content needs something the page cannot do yet.
• How I review it. A dev server running at localhost, on screen next to the conversation. I read the change as a page rather than as a form.
• How it goes live. A commit and a push to GitHub. Netlify picks it up, builds the site and deploys it.

What Still Needs Managing

Quite a lot, as it turns out.

The content still has to live somewhere. Mine lives in the repository, and it has a schema: posts are validated at build time, so a missing description or a mistyped date breaks the build rather than the page.

Version history is git. Every change is a commit with a message explaining it, and undoing one is a revert.

There is also a plain-text summary of the site for machines to read, which is now one more file that has to stay current. It gets updated in the same pass as everything else.

Review is still entirely mine, and it is the part that matters. AI will happily write something that sounds like me and is not quite true. So I keep a short set of written rules in the project covering how I write, and I read every line on the page before it goes anywhere.

The obvious objection is that this only works because it is my own site. I do not think that is it.

Impromptu is not mine. I co-host it, the repository is shared, and the site is still managed this way. In the fortnight before a session the line-up moves constantly. Speakers get added, descriptions arrive late, times change. The quickest way through all of that has been to say what changed rather than to open an editor and go hunting for the right entry.

What decides it is not how many people are involved. It is whether the people who need to make changes are comfortable working in a repository at all.

Little Thunder’s blog is still in Contentful, and I am not planning to move it. Gabe needs a door into the content that is not a terminal, and you cannot hand a client a GitHub repository and a push command. Teams want roles, drafts, scheduling and a way to disagree with each other before something goes out.

That is most of what a CMS actually is, and none of it has gone away.

What has changed is that having more than one person involved is no longer, on its own, a reason to set one up.

Where This Leaves the CMS

Mambo, Joomla, WordPress, Squarespace, Framer, Sanity, Contentful. Every one of them asked me to learn its idea of my website before I was allowed to change my website.

After all those years, the interface I actually want turns out to be a conversation.

I describe a change in the same language I would use to explain it to another person, and a few minutes later it is on the live site.

I am not going to pretend this scales to a newsroom.

But across these sites I have stopped setting up a CMS, and I have not once wished I had one.