AI Is Killing the CMS
The content management system was sold as a way for non-technical people to run their own websites. That promise was never kept. AI assistants finally deliver it, and they do it without the CMS.
Every content management system has been sold with the same promise: you will not need a developer.
Log in, click around, change your text, hit publish. No HTML, no JavaScript, no engineer standing between you and your own website.
Let’s be honest. That promise was never kept.
The loop that never closed
I have watched the same scene play out in dozens of small companies. A business owner needs to change a price, swap a photo, or add a page. They log in to the CMS, and within a few minutes they run into something the interface cannot explain: a template that doesn’t match, a plugin that needs configuring, a block that refuses to sit where they want it.
So they do what they always did. They call the person who knows.
The CMS did not remove the technical person from the process. It moved them one step further away and gave everyone a login screen to feel good about.
The CMS never made websites easy to edit. It only made them easy to log in to.
What actually changed
Tools like Claude, Cursor, Codex, and Google Antigravity changed the shape of the problem.
A person can now write, in plain language, “add a page about our new summer menu, use the same style as the others, and put it in the top navigation”, and get exactly that. Not a form to fill in. Not a block to drag. The actual change, made in the actual files, ready to publish.
The difference is subtle but decisive:
- A CMS gave people a restricted interface to a system they still did not understand. Anything the interface did not anticipate was out of reach.
- An AI assistant gives people plain language over the whole thing. Nothing is out of reach, because nothing has to be anticipated in advance.
For twenty years we tried to solve a language problem with a user interface. The answer turned out to be language.
This blog is the proof
There is no backend behind this site. No WordPress. No headless CMS, no admin panel, no API, no database. Just text files that get turned into plain, static HTML pages and served as-is.
When I want a new post, I describe it. When I want to change the layout, I describe that too. If I handed this repository tomorrow to someone who has never written a line of code, they could keep it running with any of the tools above, and the site would never notice the difference.
That is not a clever trick. It is what most small websites should have looked like all along.
Far fewer moving parts
The hidden cost of a CMS was never the license. It was everything the CMS dragged along with it.
A static site cannot be hacked through a plugin it does not have. It cannot go down because a database ran out of connections. It does not need an urgent security update on a Friday afternoon.
What this does to the bill
I have helped a few friends migrate old websites, the kind that needed a technical person permanently on call. None of them are technical people, and none of them have needed me since.
The clearest change was the invoice.
Hosting a small website used to be a recurring expense with a recurring dependency attached. Now the hosting is free, the domain costs about as much as a coffee, and the only real subscription is a tool that most people already pay for and use for a dozen other things.
To be fair, the CMS is not dead everywhere
A newsroom with two hundred authors needs editorial workflows, scheduled publishing, per-role permissions, and review queues. A large retailer needs a product catalog in nine languages with inventory behind it. In those places a CMS is genuine infrastructure, and it earns every dollar it costs.
But that was never the market that made the CMS universal.
The universal market was the restaurant, the law firm, the clinic, the consultancy, the small agency: sites of five to thirty pages that change a handful of times a year. For all of them, the CMS was always too much machine for too little content, and now there is something better suited to the job.
What this really means
The CMS is not dying because it is bad software. Much of it is excellent software, built by people who were solving a real problem with the best tools available at the time.
It is dying because the problem it was built to solve, letting non-technical people change a website, has finally been solved properly.
And the solution did not look like a CMS at all. It looked like a conversation.