I'm really getting tired of gen AI and this article is like a perfect microcosm. Partially or at least fully AI generated, discussing a vibe-coded CMS built by an AI startup. It's several layers of marketing and no serious engineering.
I have built several small websites in the past that were updated by non tech people.
I have tried, believe me, to make CMS work. I really did. But every time the customer came back with “can I do this or that” and inevitably, it fell in a blind corner of the CMS engine I was trying to use.
In the end, I developped something where the structure of the site matched a folder structure, setup a dropbox auto sync, and let the customers write anything they needed using markdown for content and yaml for metadata.
Sure, it didn’t do a hundredth of what the cms did, but it did what the customers needed. it took me less time to build this than to actually install/understand a cms system.
If I did have AI back then, it would have been even faster for me to build that stuff.
The point about CMSs having value in possibly being a more real-time collaborative UI layer to interact with that's less-scary for the average Joe is a valid driver; and is a critical factor for many use cases. But the the other stuff is clearly reasoning with a solution already in mind...
"All blog posts mentioning feature Y published after September...[more examples]...The three most recent case studies in the finance category...[etc]"
Fairly simple queries. If you're willing to build an MCP server (as they did for their solution), you could just as well build one that reads structured front matter.
"You can't. You'd need to parse frontmatter, understand your date format, resolve the category references, handle the sorting, limit the results. At which point you've built a query engine."
Well that's a scoped problem. Looks like it already exists (e.g., https://markdowndb.com/) and doesn't require moving away from Markdown files in GIT if you want.
The AI-generated points aren't as compelling as the prompter thinks. A new common problem.
Yes, you don't need flatfile-committed raw text for AI tools to work properly, in part because of things like MCP servers. Yes, semantically linked content with proper metadata enables additional use cases.
The next point to make would be "if you use our thing, you don't need to think about this", but instead goes into a highly debatable rant about markdown in git not being able to fulfil those additional use cases on a practical level.
This distracts from the what I imagine is the real intent: "git and markdown files don't come automagically with a snazzy collaborative UI. And yes you can still use AI, and use it well out of the box. If someone tells you you need markdown in git to do x,y,z with AI they are wrong."
Personally, I can get over the "AI writing style", but only if the content still nails the salient point...
This story reminds me of a similar issue people love to solve with the same idea. Software builds. The can’t we have a simple make file or worse just a shell script to build.
And just like described in the post it starts the same. Simple script wrapper. No tasks no tasks dependencies. Then over time you need to built now a library which contains the core part of the software to share between different other projects. You need to publish to different platforms. Shell scripts become harder to use on windows all of a sudden. You need to built for different architectures and have to integrate platform specific libraries.
You can built your simple make / shell file around all that. But it ain’t so simple anymore.
This is a great testament to why 75% of the web runs on WordPress.
Most of the problem mentioned have been solved by wordpress for ages, but there’s an entire industry set on reinventing the wheel in ways that really baffle me.
If your actual goal is to publish on the web in a sane and understandable way, wordpress solves the problem for the largest number of cases.
Scalability is solved. Usability by non tech editors is solved. Draft and approval flow is solved. Caching and speed is solved. You want headless? Oh, turns out wordpress is actually GREAT for that too.
It’s not sexy I guess? But if the goal is “work done” instead of “tech wank to impress investors with complexity”, that’s a solution that works very well.
I think there is a need for Agent-first tooling for things like CMS.
> Previously, we could @cursor and ask it to modify the code and content, but now we introduced a new CMS abstraction in between.
That is a very real benefit to having everything accessible by Agents. Whenever I need to setup connections in web UIs, it slows me down. IaC is a huge step in the right direction for Agent workflows, but so much is still locked away like CMS management, Confluence docs, Jira tickets, etc.
> Give it six months. ... The "simple" system will accrete complexity because content management is complex.
Ah I was looking for the boogeyman threat and there it is.
I am so glad to see people finally getting away from all CMS platforms. They never worked well and have always caused a lot more problems than they solved. Everyone used them either out of ignorance or red tape.
I think it's good practise to build something CMS like for fun - as long as you don't expect it to be useful or used, outside of maybe your personal page. It's useful to experiment and learn stuff that might be useful at scale in other projects.
I intentionally made a few interesting choices for my stuff, just to see how far you can push it, and to make sure no sane person would ever use that in production (like, from before Markdown was around, I was wondering how far you can get with doing a simple markup language parsed by using regexp only. Turns out, surprisingly far, but if something doesn't parse as expected later on you have a bit of a problem)
reading these comments - wow, absolutely nobody has an idea what a CMS is. if your going to "replace it with cursor" or "AI" you've completely lost the plot as a software engineer
you guys do realize that WordPress (as much as I hate its ubiquitous existence) is the CMS model?
and still something like 40% of all pages on the internet
I thought this was a classy response. It’s very hard to address the original points of criticism without coming across as too defensive, but he managed to do it well. On top of that the author is kind of speaking on behalf of the whole CMS industry, which when all taken together certainly has a lot of issues. He made a good case for his product without trashing his competitors.
2007, my employer is a magazine. I demand a blog. They decide to write one from scratch in .NET because we are a software magazine. 2010, said CMS is retired for Hubspot. Or maybe that happened later. Either way, to make me happy to have Hubspot is a feat. Also a great business angle for Hubspot: write your own shitty CMS? Welcome! And again, either way, 2017, bankruptcy. All money spent on CMS from inception to retirement could have been abated by a WordPress subscription. Definitely way above 6 figures lost. Coulda kept us alive for a few more years, anyway.
Lee is a marketer (not in title but in truth) for Cursor. He wrote a post to market their new CMS/WYSIWYG feature.
We spend ~$120/month on our CMS which hosts hundreds of people across different spaces.
Nobody manages it, it just works.
That’s why people build software so you don’t need someone like Lee to burn a weekend to build an extremely brittle proprietary system that may or may not actually work for the 3 people that use it.
Engineers love to build software, marketers working for gen ai companies love to point to a sector and say “just use us instead!”, just shuffling monthly spend bills around.
But after you hand roll your brittle thing that never gets updates but for some reason uses NextJS and it’s exploited by the nth bug and the marketer that built it is on to the next company suddenly the cheap managed service starts looking pretty good.
Anyway, it’s just marketing from both sides, embarrassing how easily people get one-shot by ads like this.
29 comments
[ 1.9 ms ] story [ 38.2 ms ] threadThat seems backwards and hellish when you want to grow your content and marketing team as they have no clue on how to use this arcane tool.
Now the engineers would need to be bothered by the marketing department time and time again to add blog posts, wasting engineering time.
This is the reason why CMS's like Sanity, Wordpress, Directus exist.
using Git as a CMS doesn't make sense at scale.
Where are the grownups in the room?
I have tried, believe me, to make CMS work. I really did. But every time the customer came back with “can I do this or that” and inevitably, it fell in a blind corner of the CMS engine I was trying to use.
In the end, I developped something where the structure of the site matched a folder structure, setup a dropbox auto sync, and let the customers write anything they needed using markdown for content and yaml for metadata.
Sure, it didn’t do a hundredth of what the cms did, but it did what the customers needed. it took me less time to build this than to actually install/understand a cms system.
If I did have AI back then, it would have been even faster for me to build that stuff.
At some point, it just helps you get shit done.
"All blog posts mentioning feature Y published after September...[more examples]...The three most recent case studies in the finance category...[etc]"
Fairly simple queries. If you're willing to build an MCP server (as they did for their solution), you could just as well build one that reads structured front matter.
"You can't. You'd need to parse frontmatter, understand your date format, resolve the category references, handle the sorting, limit the results. At which point you've built a query engine."
Well that's a scoped problem. Looks like it already exists (e.g., https://markdowndb.com/) and doesn't require moving away from Markdown files in GIT if you want.
Or use something like content collection in astro (https://docs.astro.build/en/guides/content-collections/). Hell, looks like that lets you have the MD files somewhere else instead of git if you please.
The AI-generated points aren't as compelling as the prompter thinks. A new common problem.
Yes, you don't need flatfile-committed raw text for AI tools to work properly, in part because of things like MCP servers. Yes, semantically linked content with proper metadata enables additional use cases.
The next point to make would be "if you use our thing, you don't need to think about this", but instead goes into a highly debatable rant about markdown in git not being able to fulfil those additional use cases on a practical level.
This distracts from the what I imagine is the real intent: "git and markdown files don't come automagically with a snazzy collaborative UI. And yes you can still use AI, and use it well out of the box. If someone tells you you need markdown in git to do x,y,z with AI they are wrong."
Personally, I can get over the "AI writing style", but only if the content still nails the salient point...
And just like described in the post it starts the same. Simple script wrapper. No tasks no tasks dependencies. Then over time you need to built now a library which contains the core part of the software to share between different other projects. You need to publish to different platforms. Shell scripts become harder to use on windows all of a sudden. You need to built for different architectures and have to integrate platform specific libraries. You can built your simple make / shell file around all that. But it ain’t so simple anymore.
It’s not sexy I guess? But if the goal is “work done” instead of “tech wank to impress investors with complexity”, that’s a solution that works very well.
> Previously, we could @cursor and ask it to modify the code and content, but now we introduced a new CMS abstraction in between.
That is a very real benefit to having everything accessible by Agents. Whenever I need to setup connections in web UIs, it slows me down. IaC is a huge step in the right direction for Agent workflows, but so much is still locked away like CMS management, Confluence docs, Jira tickets, etc.
Ah I was looking for the boogeyman threat and there it is.
I am so glad to see people finally getting away from all CMS platforms. They never worked well and have always caused a lot more problems than they solved. Everyone used them either out of ignorance or red tape.
I intentionally made a few interesting choices for my stuff, just to see how far you can push it, and to make sure no sane person would ever use that in production (like, from before Markdown was around, I was wondering how far you can get with doing a simple markup language parsed by using regexp only. Turns out, surprisingly far, but if something doesn't parse as expected later on you have a bit of a problem)
you guys do realize that WordPress (as much as I hate its ubiquitous existence) is the CMS model?
and still something like 40% of all pages on the internet
Code merges are extremely semantic. Changes over multiple files/places in project are the norm.
Feels like author went on defensive mode against Git. But he is quite right on other points.
Oh. The irony.
We spend ~$120/month on our CMS which hosts hundreds of people across different spaces.
Nobody manages it, it just works.
That’s why people build software so you don’t need someone like Lee to burn a weekend to build an extremely brittle proprietary system that may or may not actually work for the 3 people that use it.
Engineers love to build software, marketers working for gen ai companies love to point to a sector and say “just use us instead!”, just shuffling monthly spend bills around.
But after you hand roll your brittle thing that never gets updates but for some reason uses NextJS and it’s exploited by the nth bug and the marketer that built it is on to the next company suddenly the cheap managed service starts looking pretty good.
Anyway, it’s just marketing from both sides, embarrassing how easily people get one-shot by ads like this.