When AI can write your code, do you still need a CMS? | Bits&Letters
Bits&Letters Services<br>Work<br>Ideas<br>About B&L
Work with us
Book a call
= 1200px) 1600px, 100vw" width="1200" height="630" fetchpriority="high" loading="eager" decoding="async"><br>David Demaree<br>May 20, 2026
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.<br>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.<br>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!<br>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.<br>Pace layers<br>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 ):<br>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.<br>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.<br>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.<br>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.<br>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.<br>Giving marketers a safe sandbox<br>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.<br>On modern CMSes these can include:<br>Simple text updates, like changing the Terms of Service text whenever Legal says it needs changing<br>Creating structured content items — blog posts, help docs, full landing pages — that the frontend can render without needing a designer or dev<br>Uploading images, videos, or other rich content<br>Setting up A/B tests or experiments atop CMS-managed content<br>Adding or configuring event tracking codes that feed dashboards<br>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.<br>The trouble with “vibe content management”<br>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:<br>For marketers: AI agents can generate code in response to prompts, learn your site's design system, and (in principle) just...