Is the CMS Dead?

Twisted Brackets used to run on Ghost. Good editor, sensible defaults, a clean publishing flow. I did not leave because Ghost failed. I left because the middle layer stopped earning its keep.

This site is now a plain Next.js app. Posts are MDX files in the repo. No admin panel. No database. No sync between draft and production. When I want to publish, I ask Claude Code or Cursor to write the post, drop it in the right folder, and update whatever else needs updating. The agent already has the repo open. It already knows the conventions. The content ships as static HTML.

That workflow changes the question. It is no longer "which CMS should I use?" It is "do I need a CMS at all?"

What a CMS actually is

Strip away the marketing and a traditional CMS is a stack of problems you have agreed to own:

• A database to store content separately from presentation
• An admin UI so non-developers can edit without touching code
• A plugin ecosystem to bolt on SEO, forms, analytics, and memberships
• Hosting that understands PHP or Node, cron jobs, and database backups
• Migration paths every time the schema or platform shifts

That made sense for a long time. Most people cannot edit HTML. Most teams need workflows, roles, and preview links. Most marketing sites need someone other than the engineer to change the homepage copy.

But if you are a developer in 2026 with Claude Code or Cursor on your machine, a lot of that stack solves problems you no longer have.

Two ways to publish a blog post

You do not need a textarea in a browser when the agent can edit the file on disk. You do not need a media library abstraction when images live in public/ and the agent can reference them. You do not need a "publish" button when merging to main triggers a deploy.

The CMS was the interface between humans and stored content. The coding agent is becoming that interface instead.

The workflow that replaced my admin panel

Here is what publishing looks like now.

I describe what I want: a new post, a title change, an updated excerpt, a diagram added to an existing article. The agent reads the repo, finds the MDX conventions, writes frontmatter, drafts the body, and edits in place. If the nav needs updating or a category changes, it handles that too. I review the diff like any other PR.

I tried the alternative: Claude with MCP connectors into external systems. It works. It is also slower. You are asking the agent to learn an API, authenticate, map fields, and work around whatever the CMS thinks a "post" is. Meanwhile the file is right there. Git already versions it. The preview is a local dev server or a Vercel branch.

For a solo technical writer, the best CMS might be a folder of clean documents and an agent that respects your conventions.

That is what surprised me most about leaving Ghost. The hard part was never writing. It was context switching: compose in one place, paste into admin, fight the theme, check preview, fix formatting the editor mangled. When the post is just a file in the project you are already working in, all of that goes away.

Why raw documents are enough

People hear "no CMS" and picture hand-coding every paragraph in a text editor. That is not what this is.

MDX and HTML are documents. Structured, readable, diffable, portable. My posts have frontmatter for title, date, category, and SEO metadata. The body is markdown with components where I need them. Mermaid diagrams, prop tables, links to other pages on the site. None of that requires a database row. It requires a file and a template.

Static generation does the rest. Next.js reads the files at build time and outputs plain HTML. No database query on every request. No plugin conflicts. No "the site is down because MySQL ran out of connections."

The simplicity is the point. A blog post is a document. A page is a document. Serve them.

So is the CMS dead?

Not entirely. But the default CMS, the one you reach for before you have thought about whether you need it, is dying for a growing slice of developers.

If you are one person, comfortable reviewing agent output, and your content lives in a codebase you already maintain, a full CMS is overhead. You are running a database, an admin layer, and a plugin stack to do what an agent plus flat files already handle.

The CMS still makes sense when the problem is not editing files. It makes sense when:

Non-technical people need to publish. Your marketing team will not clone a repo. Your client wants to change copy without opening a pull request. Keep the CMS, or add a git-backed layer like Tina or Decap.

You are buying distribution, not storage. Ghost and WordPress are platforms. Ghost 6 syndicates to the open social web via ActivityPub. WordPress.com Reader surfaces Jetpack-connected sites to millions of users. If your growth strategy depends on those networks, leaving means building reach yourself. I was not getting that reach anyway. My blog was small, infrequent, and invisible inside algorithms designed for volume. Paying for a network I never entered was a bad trade.

You need the bundle. Memberships, paywalls, native newsletters, comment moderation, editorial workflows, stakeholder preview links. A file-based blog does not ship with those. You build them or you skip them.

None of these are absolutes. They are workload shapes.

What the CMS was really selling

It helps to be honest about what you are leaving.

Ghost and WordPress are not fighting Markdown files. They are fighting Substack and each other for creators who want audience growth as a service. The editor is table stakes. The product is the network: readers, recommendations, newsletters, memberships, analytics dashboards that tell you what to publish next.

That is a real product. It is just not the product I was using.

I wanted to write technical articles, control how they looked, and ship without friction. AI removed the friction the CMS was supposed to solve. Claude Code does not need a WYSIWYG block editor. It needs context, conventions, and permission to edit the repo.

What I would do again

If I were starting a personal technical blog today, I would not install a CMS first and ask questions later.

I would start with a simple static stack. Next.js, Astro, plain HTML if you want to go minimal. Store content as files. Point your coding agent at the conventions. Spend your time on components that make writing clearer: diagrams, interactive examples, internal links that turn posts into a library.

Skip the database until you have a problem only a database solves.

The CMS is not dead. The assumption that every blog needs one probably is, at least for developers who already live in a repo with an agent beside them.

If you are building more than blog posts with that agent, the workflow layer matters more than the publishing platform. I wrote about that in A Development Harness for Building Software with AI Agents. Same idea: own your output, keep the stack thin, and only add complexity when something actually breaks without it.