I mean… it’s not really, of course. I just thought such a thing would start to trickle out to people’s minds as agentic workflows start to take hold.
AI agents are already up in your codebase fingerbanging whole batches of files on command. What’s the difference between a CMS taking some content and smashing it into some templates and an AI doing that same job instead? Isn’t less tooling good?
I had missed that this particular topic already had quite a moment in the sun this past December. Lee Robinson wrote Coding Agents & Complexity Budgets. Without calling it out by name, Lee basically had a vibe-coding weekend where he ripped out Sanity from cursor.com. I don’t think Lee is wrong for this choice. Spend some money to save some money. Remove some complexity. Get the code base more AI-ready. Yadda yadda.
Even though Lee didn’t call out Sanity, they noticed and responded. They also make some good and measured points, I think. Which makes this a pretty great blog back-and-forth, by the way, which you love to see. Some of their argument as to why it can be the right choice to have Sanity is that some abstraction and complexity can be good, actually, because building websites from content can be complicated, especially as time and scale march on. And if you rip out a tool that does some of it, only to re-build many of those features in-house, what have you really gained?
TIME FOR MY TWO CENTS.
The language feels a little wrong to me.
I think if you’re working with Markdown-files as content in a Next.js app… that’s already a CMS. You didn’t rip out a CMS, you ripped out a cloud database. Yes, that cloud database does binary assets also, and handles user management, and has screens for CRUDing the content, but to me it’s more of a cloud data store than a CMS. The advantage Lee got was getting the data and assets out of the cloud data store. I don’t think they were using stuff like the fancy GROQ language to get at their content in fine-grained ways. It’s just that cursor.com happened to not really need a database, and in fact was using it for things they probably shouldn’t have been (like video hosting).
Me, I don’t think there is one right answer. If keeping content in Markdown files and building sites by smashing those into templates is wrong, then every static site generator ever built is wrong (🙄). But keeping content in databases isn’t wrong either. I tend to lean that way by default, since the power you get from being able to query is so obviously and regularly useful.
Maybe they are both right in that having LLM tools that have the power to wiggleworm their way into the content no matter where it is, is helpful. In the codebase? Fine. In a DB that an MCP can access? Fine.
We’ve been having a similar debate internally with the engineers suggesting that we use AI to rebuild our fairly simple web site…except that they tend to see a web site as primarily code. To them, why wouldn’t Markdown and AI generated templates be easier, but these aren’t assets I can hand easily to a marketing team and say, “Go ahead and create new pages, or edit existing ones.” Nevermind that they don’t generally like working in Markdown or have the coding skills to validate/fix the output where needed (because if they are just prompting new pages and templates, you know it will be needed), but they also don’t tend to work in a git-based workflow. So, I definitely don’t think we’re at the AI can replace your CMS point just yet.
Ah ha, this is what I was expecting to see some of.
Nathan Herald, I Don’t Have a CMS Anymore:
And then there’s the case where the content, a large chunk of it, lives in json files as “database.” That’s exactly the case for the 11tybundle.dev site. I had built a bunch of command line tools to allow me to create and edit items in those json files. With AI, I’ve since built a local-only Flask-based CMS that works in the browser and gives me a much richer interface than dealing with command line stuff. I’ve made it more feature rich over time and even added some capabilities to post to social media when new content becomes available.