Lately there's been a debate about whether, in the era of vibe-coding and agentic AI, anyone still needs a dedicated content management system — or whether you can just keep everything in text files and let Claude or Codex handle the rest.

Last fall, Lee Robinson from Cursor wrote about his team's move  away from Sanity (our favorite CMS) toward Markdown files, HTML templates, and their own AI agent. Sanity's Knut Melvaer responded  with the case that CMS features exist because the underlying problems are real, and that bespoke tooling will accrete complexity until you've reinvented one anyway. Chris Coyier weighed in too , arguing that Markdown files in a Next.js app already are a CMS — Lee didn't rip out a CMS so much as a cloud database.

This is a live wire for every kind of website work right now, especially for businesses like ours, where we want other businesses to pay us to do that work. We've had a couple of engagements where marketers hire us to implement a CMS, then their engineering counterparts come in and ask why everything can't just be in the codebase. Which is a fair question!

Here's my attempt to answer it. The short version: the CMS-vs-codebase question isn't really about tooling — it's about which parts of your website should move at which speeds, and AI doesn't change that math as much as you'd think.

Pace layers

When I worked on design system teams, we talked a lot about ‘pace layers’ and would frequently bust out this graphic from Stewart Brand’s book The Clock of the Long Now ( hat tip Caterina Fake ):

What this is saying: different parts of society move at different speeds while also coexisting. Fashion—the whirly, swirly, Jeremy Bearimy -esque line—is constantly moving, but it rests atop commerce which moves more slowly. Commerce sits atop infrastructure, which sits atop governance, and so on. Fast things can move fast because they're built on slower foundations.

Software has historically moved more slowly than content. If you're a non-coder marketer who needs to update a pricing page, you'd reach out to a dev, who has to carve out time, make the change, stage it, show it to you, take feedback, repeat as needed, then schedule a production rollout.

CMSes were created to solve this. If the pricing page is built not out of static text but rows in a database, and the marketer can update the database, then content can move at content speed without code having to keep up.

It's practically an axiom that no matter how slow and complex a company's content management process is, their software development process is slower. At one point I worked on a content management platform for a giant telecom; their marketing rollout schedule was measured in weeks, but software changes could take months. Another client, a digital-native e-commerce company, could ship code changes in a few days, but often needed to update content daily or even hourly.

Here's the thing AI doesn't change: those layers are still there. A coding agent can make the code layer faster, but it doesn't fold content and code into a single layer. The marketer's loop still goes through Git, preview builds, and PR review — it's just got a robot in the middle of it now instead of a developer. The pace mismatch is structural, not a function of how fast any one person (or agent) can type.

Giving marketers a safe sandbox

If nothing else, CMSes exist to draw a neat little line around the kinds of changes non-developers can make quickly and safely without destabilizing the rest of the software production process.

On modern CMSes these can include:

• Simple text updates, like changing the Terms of Service text whenever Legal says it needs changing
• Creating structured content items — blog posts, help docs, full landing pages — that the frontend can render without needing a designer or dev
• Uploading images, videos, or other rich content
• Setting up A/B tests or experiments atop CMS-managed content
• Adding or configuring event tracking codes that feed dashboards

Handling this stuff in a CMS or digital experience platform isn't just safer and more stable — it's a lot more user-friendly for marketers, which helps them ship more content, run more experiments, and generally do their jobs more efficiently. And it frees up developers to focus on stuff that's more uniquely valuable to the business.

The trouble with “vibe content management”

The argument against all this in the AI era is that coding agents have made the developer piece much faster and cheaper. If the reason for a CMS was not having to wait for a dev, maybe that problem's been solved on two fronts:

• For marketers: AI agents can generate code in response to prompts, learn your site's design system, and (in principle) just make the change.
• For developers: Content changes within a well-structured codebase can also get done in minutes — sometimes all that's needed is to paste a screenshot of a change request into Claude Code and let the robots cook.

On our recent launch for our friends at Copytree, I did a lot of the latter. I'd paste screenshots of change requests into Claude Code on my phone, have it open a GitHub pull request, review a preview build, then merge — all without opening my laptop.

But here's the thing: Copytree's site uses Sanity for most of its content.

If their content had been 100% Markdown — like Lee implemented for Cursor — Claude would have been able to access and edit it, but then all changes would have to route through either a developer (me) or an AI agent. And here's the part worth saying out loud: in a model where marketers work with an AI coder instead of a CMS, everyone is effectively a developer.

Granting Claude access to make the changes I made for Copytree isn't hard (says me, a developer), but it's not as simple as clicking buttons in a UI. Your code needs to be in a Git repo on GitHub. Claude Code needs access to it. And once that's wired up, the AI isn't simply going to edit your live website — it's going to create branches, open pull requests, and ask you for direction in the language of Git.

Using Sanity, Copytree's CEO Paige and her team can see content changes instantly in a familiar web interface and publish in seconds.

Doing the same through Claude Code would actually be slower: ask the chatbot for a change, wait for it to interpret and implement, wait for it to push a branch to staging, wait for the build server to build it (usually 2+ minutes), then review the preview URL. That's fine for a developer. It's not the best use of Paige's time, and a developer-like workflow for her content shouldn't be a thing she has to learn.

Beyond speed, there's a collaboration story too. The single-threaded change model — branch, PR, review, merge — is a holdover from how software engineers work, and it still makes a lot of sense for code. For content, we've long since entered a world where different team members and stakeholders jam on the same documents in real time. Relying solely on AI coder bots is actually a step backward on that front. You can have different people talking to different agents on different branches, but there's no good way yet for multiple team members to participate in a group chat with an AI working on a single update. (That'd be a cool feature, though!)

When you actually don’t need a CMS

Here's the version of Lee's case I find most persuasive, and which gets lost in the AI framing: if your team is small, your content is mostly developer-adjacent, and your editors are comfortable in a code workflow, the cognitive overhead of a CMS can exceed its benefits. Cursor's website fits this pretty well — it's a developer-tools company whose marketing team probably overlaps significantly with its engineering team, and whose content doesn't change at high frequency from non-technical hands.

The threshold flips when any of these flip:

• The people editing content aren't comfortable with Git, and shouldn't have to be.
• Content needs to change faster than your build-and-deploy cycle.
• More than one person needs to edit the same thing at the same time.
• You need scheduling, previews, rollback to "three weeks ago," approval workflows, or any of the other things Knut listed.
• Your codebase has sensitivity (auth, billing, customer data) that makes giving marketers commit access — even AI-mediated — a non-starter.

Most companies past a certain size hit two or more of these. Cursor doesn't. Copytree does. Your situation is probably somewhere on that continuum, and that's the question to ask before the tooling one.

Why not both?

For several clients I've used a hybrid approach: Claude Code or Codex talking to Sanity's excellent MCP server.

I usually build out the first prototypes of a website entirely in code, but with content objects set up as JSON files or TypeScript objects rather than hard-coded into HTML. Why? So that they're structured content from day one, and so an AI agent will have clear guidance about where and how the frontend and content should be coupled together or kept separate. Then we move content into Sanity once the shape is clear.

On this website, I use Sanity (for this blog) and Astro's Markdown content layer (for the portfolio), for the same reasons as my clients: I want to publish blog posts quickly without messing around in code, while portfolio pages are more considered and benefit from a slower dev cycle.

AI helps with both workflows. For blog content, in addition to using Sanity's Content Agent to refine text and structure before publishing, I had Claude write a tool that imports drafts from Google Docs — including images — and creates new Sanity posts from them.

The takeaway, if there is one, isn't "use the right tool for the job" — that's true of everything and useful guidance for nothing. It's something more specific: structure your content as data from day one, regardless of where it lives. Then put the things that need to move fast somewhere editors can reach without a Git workflow, and the things that don't in code. AI agents make both halves of that easier. They don't collapse the distinction.