Issue 27

What to make of Cursor dumping its CMS for a vibe-coded site

My corner of the internet lit up in the last week talking about how artificial intelligence (AI) company Cursor dumped its content management system (CMS), thanks to its AI-powered coding tools.

Lee Robinson, a developer and educator with Cursor, wrote an article about what he had done and why.

Robinson goes on to talk more about what he did and show screenshots of some of what he built using AI to code, a process known as vibe coding. It’s an interesting read, and there’s a lot to think about here.

Why this move makes sense for Cursor

I’ve seen consternation that Cursor has made such a brash move, but let’s think about it. The move makes a lot of sense—for them.

• Cursor is a startup. The content needs for startups are very different from the content needs for enterprise companies. As a Series D startup, Cursor doesn’t have a ton of content, and its business doesn’t have a portfolio of dozens of offerings.
• A CMS may be overkill for a startup. This is something I’ve recognized and addressed with my experimental Choose Your CMS tool.
• Cursor needs a vibe-coded website. This may be true in a technical and operational sense, but I think it’s more true as brand play.
• It’s inevitable. If Cursor didn’t do it, someone else would—and probably already has.

In this narrow setting, one can see why dropping their CMS vendor is logical. I think some content professionals are uneasy with the move, so let’s unpack what may have them worried.

Content is not just code.

The article has a heading that says “content is just code,” which reflects a lack of understanding of content and meaning.

I touched on this in Issue 6, and I think it would be useful to talk more about it here.

Code is instructions to tell a computer what to do. Content might instruct a computer, but it might also serve humans and provide a reference, give an overview, sell a product, warn, and so on.

There’s a related line that I hear from developers that is “content is data.” Not exactly.

Here’s the explanation I give. If I have a piece of data such as “23,” then I can know absolutely that we are not talking about a value that is not 22 or 24.

However, content is not so absolute. Let’s look at a small element of content—a word.

If I have simply the word “right,” I can’t determine if we’re talking about a direction, an affirmative answer, a moral judgment, veracity of a fact, an adverb, a verb, an entitlement, or a sarcastic response. Words are more than data values. They are meaningful. They are semantic.

For a deep, philosophical take on content versus data, see Revisiting the difference between content and data by Michael Andrews on his blog, Story Needle.

Content systems should not be viewed solely as output factories. They should be viewed as meaning enhancers.

Where the tradeoffs start to show

​One exercise that we used in a CMS implementation at Atlassian was “tradeoff sliders.” We specifically looked at tradeoffs between different requirements that various stakeholders brought to us.

Teams don’t always acknowledge these concessions explicitly, but it’s helpful for aligning, for understanding scope, and thinking about the impact of our decisions. Obviously, I don’t know all of what Robinson’s vibe-coded site does, but it might be helpful to try to look at tradeoffs that would be involved.

Tradeoff 1: Manage content in a CMS v. manage content elsewhere.

Content still needs to be managed. It still needs to have a strategy and a structure. Content can be managed in a CMS (which is a layer of purpose-built functionality on top of a database), a database, a file structure, or raw isolated text strings. Robinson chose a file structure.

His assertion that content is code and his use of Markdown brings to mind the docs as code methodology used heavily in documentation for APIs, where the documentation is compiled from within the API code itself. This approach works pretty well for API developers, but it runs into some problems at scale.

Tradeoff 2: Easy for a developer v. easy for a non-technical user

For Robinson, one easy solution is working not in cloud-based Software-as-a-Service (SaaS) products. For example, Robinson moves away from a CMS using standard user management practices to having everyone use GitHub instead. Certainly, some content folks are comfortable with source control and pull requests, but the marketers I know want what-you-see-is-what-you-get (WYSIWYG) page builders and would have nothing to do with GitHub.

Of course, the premise of the vibe-coded site seems to be that you just tell agents what you want. That seems like it should be easy enough, but it sounds like the solution caters to developers and not copywriters or marketers.

Tradeoff 3: Solve gnarly concerns v. defer/outsource them

Authors deserve a way to see what their content will look like on a website prior to hitting publish and making it available to the world. Robinson’s solution for this is to create a pull request in GitHub and “get a link with your changes.” I’m not sure if that’s a link to the pull request or a link to the published page. Either way, there is no preview in this solution. There’s either a link to a developer-centric change log or there’s a published page.

Similarly, setting up website code to work in different languages and cultures is also complex. But to Robinson, this is a problem easily solved with AI. This choice downplays the actual art of localization and linguistic expertise needed to properly internationalize and localize. It offloads complexity.

Tradeoff 4: Build v. buy

The decision to build a solution or to pay a vendor for a solution is a frequent tradeoff discussion, especially in tech companies. It’s at the root of Cursor’s decision, and their choice is to build.

Instead of relying on common tools and libraries to generate clean, reliable static webpages, Cursor has chosen to have AI handle rendering. I don’t know what that AI does under the hood.

By building a user interface for the vibe-coded asset manager, Cursor took a big step down the road toward building its own CMS. While this might be right for Cursor now, it commits the company to maintaining the asset manager tool and building it beyond its initial minimum viable feature set.

Abstraction is not the villain (it’s cyclical)

As alluded to already, one of the goals for the de-CMS-ification of Cursor seems to be to get rid of complexity in favor of simplicity.

Cutting complexity seems commendable. But what kind of complexity? What is simplicity?

I know that there’s usually a lot of complexity required to make simple user experiences.

Abstraction provides a way to make complexity simpler. For example, to drive to the store, you don’t need to understand combustion or transmission gearing or electrical systems. That complexity was abstracted away so that if you can manage a steering wheel, an accelerator, and a brake, you can drive to the store.

Most people don’t need to know about user management, website rendering, redirect logic, content modeling, bulk publishing, or content review workflows. They need to author, update, and publish content. The CMS has abstracted the complexity away.

But now the industry has “headless” CMS tools to make omnichannel publishing easier.

“Headless” is when content (the body) is separated from how the content is presented (the head). APIs—kind of like pipes that connect your house to the water system—deliver the content to experiences.

A headless CMS re-introduces some complexity back, and as Robinson points out, the CMS can lead to over-abstraction. (As I look around with a guilty look on my face, thinking of some of the content models I’ve experimented with.) But to be fair, I think Robinson is thinking mostly of code-level abstraction in the website code.

However, it’s worth pointing out that taking content out of a purpose-built system and putting it in text files managed through a chatbot is also an abstraction. I’d argue that it’s far more abstract than using a CMS.

Anyone who has been around a software product long enough has probably seen a cycle of abstraction → simplification → abstraction, and so on …

For Cursor, the pendulum has swung to simplification. Remember, Cursor is a startup, so that probably makes sense for them. If you’re a large enterprise, you should consider how your needs differ.

What is actually true

Headless CMS isn’t for everyone

Absolutely.

A few years ago, the industry was talking a lot about MACH Alliance, which is all about choosing best-in-class tools for microservices, API-first, cloud-native, and headless architectures. There’s a lot of benefits to a MACH approach, but it does lead to complexity that isn’t right for everyone.

Since that peak a few years ago, there’s been a “MACH-lash” of companies moving away from the MACH approach and CMS vendors building out more digital experience platform offerings.

If you’ve never built a large website on a headless CMS, you may not understand that you build the publishing pipeline (or use a framework), you build the site user interface, you write the code to make URLs, you build the logic to implement redirects when pages get unpublished, you build what schema and metadata go in the HTML outputs of which pages, and so on.

Many teams can’t take on that kind of technical scope.

Viewing draft content in a website context is a pain

You can make a strong case that preview functionality isn’t the responsibility of the headless CMS, but it’s true and reasonable that lots of content authors want preview capabilities.

Usually preview means pixel-perfect webpages, but before the public can see it. However, there’s a lot of nuance to what authors even expect from preview: are they previewing the page? The full URL? Where does the page sit in the site navigation or page tree? And so on.

The need for personalization and omnichannel outputs means the idea of preview becomes even more complex.

As Robinson points out, many solutions require logging into some internal system to see the pixel-perfect pre-published webpage.

SaaS CMS tools have risks to mitigate

First, SaaS CMS tools are expensive. This is very true, and it’s something I’ve called out in the past. Many vendors aim at enterprise clients, and their pricing reflects that. I’d love to see a CMS with the same functionality designed for and sold to small- and medium-sized companies. (If that exists, let me know!)

Second, vibe coding presents a risk to CMS vendors. Whether it’s from existing customers following Cursor’s lead or from newly-empowered vibe coders who have never been CMS customers, I think we’ll see an erosion of the CMS market. Vendors need to provide thought leadership about the value they bring to vibe-coded projects and actionable tips about how to vibe code experiences powered by a CMS.

Things, not strings

Google is famous for introducing the idea of “things, not strings” when it revolutionized the search engine world.

Prior to Google, many search tools were simply looking for strings of text that matched what was entered in the search bar. If someone entered “taco shops,” the pre-Google search engines would give you results that had “taco shops” on the page. You’d never see “Mexican restaurants” or “taquerias” in your results.

When Google came along with “things, not strings,” the idea was a simple way to introduce knowledge graphs. Instead of text matching, Google was searching for objects that matched the search text. As such, your search for “taco shops” would be more likely to return “taco shops,” “Mexican restaurants,” and “taquerias.”

A modern CMS paves the way for teams to define meaningful objects and start connecting them to each other. Throw in semantics tools for taxonomy and ontology, and you’ve defined “things” that humans and machines can understand.

Storing content in flat Markdown text files moves back toward “strings.” Sure, you can define some link mechanism and store simple tags in the files. Often Markdown-powered web experiences use a folder-based structure for storage that also drives some of the user-facing site structure. Folder-based structures are inflexible and fail to support the complexity inherent to a lot of content and information.

Ironically, semantically rich structured content with graph-like connections is super helpful for AI tools to ingest and “understand.”

Conclusion

We’re all seeing lots of hype about AI, as well as a lot of fear. I think it’s safe to say that both perspectives are valid.

Tooling and architecture decisions ought to be contextual, time-bound and focused on a specific organization. What works for one company might not work for its competitor. What works at Series D probably won’t work for a Fortune 500 company.

Tools change fast, but meaning, governance, and people change slowly. Systems that ignore those realities tend to recreate the problems they try to delete.

John Collins

Thanks for reading! Did someone forward you this email? Subscribe here​ If you’re already a subscriber and you found value in something here, tell your friends and colleagues to subscribe!

Welcome to the 5 new subscribers who joined us since the last issue of Model Thinking.