Who needs a Headless CMS when you got vibes?

TLDR

• Vibe coding is pretty dope. A solo dev can spin up a fully functional site or an app in an hour. I'm not here pretending that's not true.

• A CMS and vibe coding solve different problems. One accelerates how you build and one manages how your content lives after you've shipped.

• If you're the only person touching the content, and you're a developer, you might not need a CMS. If anyone else does, or if your content needs to outlive your current stack, then you probably do.

• AI slop generated content is a volume play, not a content strategy. Filling your site with just slop generated content faster doesn't solve the content problem.

Every few months a new discussion starts up for a hot "do you even need X/Y/Z anymore" take. We've seen "do you need a backend," "do you need this framework," and now with the rise of Cursor, Bolt, Lovable, and whatever tool dropped last Tuesday, we're firmly in "do you even need a CMS" territory.

Fair question, tbh.

If you can describe a website in plain English and have a working app scaffolded in 20 minutes, the case for adding yet another tool to the stack gets harder to make. I mean, I've vibe coded a bunch of stuff, and not just side projects to land up in the dreaded side project graveyard a couple of weeks later, so I'd rather approach this honestly than gaslight you with "101 reasons why you absolutely need a Headless CMS in the AI era we're seeing in 2026, 2027, and beyond", which is just another low effort SEO title that won't rank because that'd be ridiculous.

Anyways. CMS vs just vibes.

What a CMS actually does

Let's start here because the word "CMS" has been stretched into near meaninglessness by years of vendor positioning between website builder, CMS, app builder, CaaS, hosted backend, DXP, and heavens know what else. Let's not get into the whole "empower your editorial team" or "future-proof your content operations" or "superduper charge your customer's digital experience" fluff, let's just say what it does.

A Headless CMS separates your content from your code. That's all. That's what it's always done. That's the foundational thing. It means the person updating the homepage banner doesn't need to open a pull request. It means a typo in a product description doesn't require a deploy. It gives non-developers a place to work with content without touching the codebase.

Beyond that, a CMS enforces a schema that makes your content predictable and structured. If you've defined that a blog post has a title, a slug, a cover image, a body, and an author, every blog post has those things. You're not hunting through a JSON that's gotten messier over two years because three different people added fields differently.

It doesn't HAVE to, but more often than not, a CMS also handles media stuff: uploads, CDN delivery, image optimizations, alt text... It also manages who can publish what and when and how and where. It gives you audit trails. It handles localizations to translation states, locale fallbacks, schedules, versions, metadata, y'know, the stuff that's incredibly boring to build yourself and also incredibly necessary the moment you hear the dreaded "OK, but will this scale?"

I'm not going to pretend that any of this is glamorous. A CMS is infrastructure. The whole value prop is that it's just boring, stable, and invisible. When it's working right.

Now. What vibe coding gives you

Real talk. Quite a lot.

In fact, I'm going to let Claude handle this just to see how he/she/it summarizes my thoughts after reading what I've written till this point on.

<AI-slop>

The modern AI-assisted dev workflow is remarkable for solo developers and small teams. Cursor can scaffold a data model and wire up a basic CRUD UI faster than you could write the boilerplate by hand. Bolt can take a screenshot of a design and get you 80% of the way to a working component. For prototypes, internal tools, hackathon projects, and MVPs — this stuff is legitimately game-changing.

The issue is that vibe coding is great at building the shape of a thing. It's less great at thinking about how that thing lives, grows, and gets maintained over time.

When you vibe code a site, your content is typically living in one of a few places: hardcoded in components, in flat files (Markdown, MDX, JSON), or in a database your app owns. None of these are inherently bad. But none of them come with a schema enforcer, an editorial interface, a media pipeline, or a way for your marketing manager to update a page without pinging you on Slack at 4pm on a Friday.

Cursor doesn't know your editorial calendar. It doesn't know that Lena in marketing needs to push a campaign banner live tomorrow and doesn't have VS Code installed. The AI generates the structure just fine. The problem is everything that happens to that content after the code ships.

</AI-slop>

Honestly, not terrible. I mean its' not how I type (I'm pretty sure I'm allergic to the word gamechanger to begin with), but it gets the point across pretty well. You just know that content was AI generated even if I wouldn't have mentioned it.

It—smells—like—AI.

Which brings us to...

The AI Slop problem

Because a non-trivial number of devs vibe coding things are also asking if they can just vibe the content out too. Yeah, you can.

You can generate 500 articles in an afternoon. You can publish a fully automated website that spits out like 4 posts a day till the end of time. You can fill your site with copy about every topic even remotely related to your product/service/offering and have every page, FAQ, landing page, whatever, written by an LLM in time for an early and long lunch. But we'd all know it.

The content is cheap to produce and cheap to read, all you need is some good prompts and a little CLAUDE.md or some instructions somewhere for the LLM to know your tone/industry/vibe/etc. BUT. It often lacks a specific point of view that comes from expertise and experience, it doesn't reflect your actual experience with a problem, and its just really easily recognizable by both readers and search engines now. "Comprehensive guide to X" posts that are really just a topic outline with confident filler aren't new, but yet, here we are, surrounded by it.

Also, just generating more content doesn't fix a content strategy that wasn't working nor is it a content strategy by itself. If your blog wasn't driving traffic before, publishing 50,000 posts won't change that.

I'm not saying don't use AI at all (I do, that'd be super hypocritical of me). I use Claud-ia 💁‍♀️ for early drafting, some translations, and generating variants for testing, or just generating easy TLDRs, but its' more of a workflow thing. A CMS on the other hand manages the dreaded logistics and the output of real editorial work. If the content isn't worth managing in the first place, no tooling decision is going to save that.

SO. We need humans? Right?

Depends on how many people you got, what your site/app/product is, and how content-dependent it is on growth.

If the answer is zero where you're a solo dev, you're the only one writing and publishing, or if you're building small side projects that're going to top-out at a few pages/posts, keep cracking on with your .mds on a flat-file setup. I'm not going to tell you otherwise.

There's also the middle ground - where your website is a blend of static pages and posts, like our own. It doesn't need to be a "CMS or AI" question, both can coexist (I mean there's a reason so many CMS are betting on AI features and MCPs and trying out agentic workflows).

Like on our own website - you can do a mix of hardcoded or not, if there are places where editors are not involved and it's just easier to handle by code (see the navigation/footer or complex sections of the site). All our posts, guides, articles, docs, and text-heavy content gets handled in the CMS, but for most static-ey pages, I myself vibe code changes allll the time (just don't tell bossman).

But things change when you got a team. Not even a large team. Just others (especially non-technical ones) who need to make changes to pages and posts. The moment they need to work independently from you, and you don't need/want to give them access to the repo, or have varied flavors of roles and permissions, you have a content management problem.

And what solves content management problems? Content management systems.

When you need a CMS

Is this where I start shameless 🔌 territory? Absolutely.

Multi-locale websites and storefronts and products. The moment you and/or your team is managing content in more than one language, you have to think about things like translation states, fallbacks, and locale-specific publishing and un-publishing. Building this yourself issss doable. Maintaining it across contributors is a whole other story. Got external translators coming in or need idiomatic nuances between de-DE and de-AT? Yeah, that's a CMS thing, and most Headless CMS are built to handle modern websites and eCommerce sites.

Marketing sites with any kind of editorial cadence. If someone is publishing blog posts, campaign pages, or product announcements more than occasionally, they need an interface. Not a code editor. And you really don't want them to ping you every time somethings' needed for you to go and edit JSON files and open PRs to just make simple pushes.

Editorial/News sites. Ok this should be an obvious one, because, well, journalists and editorial teams collect tons of information to write content - and I've seen tons of "tiny" news sites spewing unverified news to have a sitemap of 1000s of pages which you can tell are slop. So can you run a news/editorial site on vibes hooked up to some News API? Yeah. But wow are they (mostly) terrible. The moment content operations is core to your business strategy, getting a Headless CMS for editors to do their thing becomes really important.

Anything intranet-ey or knowledge base-y. Support portals, docs, forums, and things like this need to be constantly updated, changed, created, and usually have several people contributing to them. Vibing that for anything beyond a simple website with 5-10 "knowledge" pages is a nightmare waiting to happen. Getting a Headless CMS that's optimized for knowledge management makes a ton of sense.

Anything multi-channel. Same content delivered to a web app, a mobile app, and maybe an email or a digital display? A Headless CMS is the cleanest answer to "how do we avoid managing five separate copies of this."

Content workflows. Not every team can have anyone push content to production. There's regulated industries, enterprises, multi-brand setups... these need staging, reviews, proof-checks, and role-based access to ensure permissions are honored. Again, that's CMS territory.

Content that needs to outlive the stack. This one's reallllly underrated because I've rewritten my own site with content SO many times from WP to Ghost to Gatsby to Next to Astro, going from WP posts to Ghost posts to markdown. Every time I've moved it I've had to painfully redo so much (and pour one out for when I decided I neeeeed TypeScript for my 5 posts with less than 2 monthly visitors). Finally I gave up and moved all my stuff to a CMS so I just need to modify the template/query stuff, not the actual content. If you hardcode content into a Next.js app and then rebuild in Astro two years later, migrating that content is a choooooore. If your content lives in a structured CMS with a clean API, the frontend is just a view layer to requery things.

Just anything with more than a few people, really. The moment you have more people contributing to the growth of a website or app, you'll need a CMS. There's only so much you can accomplish with vibes before wanting to rip your hair out AND babysit everyone's demands.

When you can skip the CMS and go all-in on vibes

I won't try to convince you that you neeeed a CMS for things like these.

Personal projects and portfolios. If it's your own site, you write all the content, and you're a developer, just use MDX, or hardcode it, or whatever you're comfortable with. A CMS is overhead you really don't need.

Purely functional apps with UGC. If your "content" is user-generated data stored in your own database like reviews, form submissions, app data, events, things like that, then that's not really necessarily a CMS use case. That's a database use case.

Internal dashboards. Dashboards, admin panels, utilities. Nobody's publishing high-volume content there. If your product/project is mostly visual without the need for classical content, skip the CMS. Need it localized? You can handle localized strings in the repo for labels and screens that barely change.

Sites that genuinely rarely change. There's a specific kind of digital brochure webpage (corporate sites, small business sites, F&B outlet sites, solopreneurs in some fields) that gets built once and then sits untouched for a super long time. The problem isn't tooling, it's that nobody's updating it. No one needs a CMS there if they've got some technical skills if I'm being honest.

Prototypes and throwaway projects. Stop adding infrastructure to things that might not exist in six months until its validated. We all know the meme.

So there. The framing that AI building and a CMS are competing choices is very off. Vibe coding accelerates the build and the CMS manages the content after the build.

If anything, vibe coding makes CMS integration faster and smoother and better. Your IDE can sort out a DatoCMS boilerplate and integrate everything within minutes to let your editors go do their thing.

What AI can't do is give Susan in marketing a usable interface to update the homepage without writing up a Jira ticket to distract you from whatever you were meant to be doing.

AND I KNOW WHAT YOU'RE THINKING NOW. "Why don't I just build a CMS, its just CRUD?". Just. No. But more on that soon.