How AI May Impact CMS Architecture AI is poised to reshape CMS architecture by shifting from traditional database-driven platforms to plain-file, Git-based systems that align with how large language models natively read and write content. The author argues that bolting AI onto existing CMS platforms as plugins is suboptimal, and proposes a 'Content Client' or 'Content IDE' architecture that stores content in Markdown and structured data under version control, enabling AI to operate directly on text, diffs, and branches. How AI May Impact CMS Architecture Static sites came first: files sitting on a server. But as soon as non-technical people needed to publish, editing raw files stopped scaling. The CMS put content in a database, wrapping the database in an editor, and rendering pages on request. This has been the predominant architecture for the last 20 years. Server-side rendering, caching, headless APIs — all refinements of one decision: content lives inside a platform, and humans reach it through the platform. 1 ref-1 A CMS is one runtime server doing five jobs at once: it stores content, governs who can change it, renders it into pages, runs dynamic behavior around the content, and gives authors an interface to create it. For the rest of this article I’ll just refer to these as “CMS”. I’ll also refer to hosting solutions like Netlify, Cloudflare, or Vercel simply as Cloud Hosts. Now as far as the jobs of a CMS, there is the source of truth — where the canonical content lives — and then the editing interface. They were fused for one reason: a database isn’t human-editable, so every platform had to bolt an interface onto its storage. Which means the whole system rests on a single assumption: the editor is a person. Well, the new editor is looking more likely to be a large language model, and as much as I question the massive investments, the usefulness of AI reading and writing plain files natively can’t be ignored. And the best implementation of AI when it comes to content management systems may not be a module or plugin on a complex and already bloated platform. This article makes an argument for a modern architecture for removing the obstacles from AI in the context of a website content management system. I call it a Content Client or Content IDE . The primary responsibilities of a CMS Here are the core responsibilities, and approaches of a CMS. I’ve associated them to a few of the most popular systems out there. | Responsibility | AEM | Drupal | WordPress | |---|---|---|---| | Content storage | Proprietary content repository | Relational database | Relational database | | Content modeling | Content types + fields | Content types + fields | Post types + custom fields | | Versioning & history | Built-in revisions | Built-in revisions | Built-in revisions | | Authoring / editing | Web-based editor | Web-based editor | Web-based editor | | Workflow & approvals | Built-in workflow engine | Moderation states | Draft/pending states plugins for more | | Access control | Roles + permissions | Roles + permissions | Roles + permissions | | Media management | Built-in asset library | Built-in media library | Built-in media library | | Search | Built-in query/index layer | Built-in search framework | Database queries | | URL routing & redirects | Managed URLs + redirects | Path aliases + redirects | Permalinks + redirects | | Templating & rendering | Server-side templates | Server-side templates | Server-side templates | | Localization | Built-in translation copies | Built-in multilingual | Via plugins | | Extensibility | Proprietary module system | Modules | Plugins | None of these responsibilities are going away, and whether AI joins them is no longer the question — every vendor is already bolting an assistant onto their system. But it may be time to reconsider these large, opinionated, mostly proprietary solutions for a more flexible, raw approach. In these common implementations, AI operates the way a human does — through the vendor’s API, one bespoke integration per row, per content type, per interface. But on plain files under version control, it operates in its native language: the text it was trained on, with diffs, branches, and direct read access to all content. 2 ref-2 The shortest path to advanced AI isn’t a smarter plugin, combination of tools, or a massive platform. It’s putting the content where the agent is strongest: Markdown and structured data in a Git repository. Git covers several rows of the table natively — storage, versioning, file history, review-gated approval, write control. Files in Git, with a build step that renders them into pages, is the static site generator SSG , and the ecosystem around it is over a decade mature. Dozens of generators Jekyll https://jekyllrb.com/ , Hugo https://gohugo.io/ , Eleventy https://www.11ty.dev/ , Astro https://astro.build/ , git-based editors 3 ref-3 , branch previews, CDN hosting: the whole arrangement was packaged and marketed as the Jamstack https://jamstack.org/ . The machinery for running a website out of a repository. The adoption never followed: fifteen years in, WordPress alone still runs 41.5% of the web, while the flagship site generators register a few tenths of a percent between them. 4 ref-4 5 ref-5 Its biggest challenge, and what the movement has always lacked was an author who didn’t need to be a developer. But I believe that given the current circumstances, these systems and slight alterations of them deserve a second look. Look at who runs the large static sites that already exist. MDN Web Docs https://github.com/mdn/content is fourteen thousand pages of Markdown in a public Git repository, with some forty-five thousand contributors across its history; the Kubernetes documentation https://github.com/kubernetes/website works the same way. 6 ref-6 These sites are large, multi-team, and governed — and every one of them serves a technical audience and is edited by technical people. Scale was never the limit. The authoring barrier is 7 ref-7 , and the gap of technical knowledge an editor possesses is diminishing. With AI built-in to help editors, and safeguards in place, it makes much more sense now to reduce the complexity of content management systems as opposed to bolting AI onto monolithic server-based solutions. Where AI belongs Authoring shouldn’t be typing into fields, it should be describing changes. “We renamed the Standard plan to Core — update every page that mentions it” is one instruction; the agent finds the mentions — including the ones in comparison tables and old announcements you forgot — and produces a single reviewable change across all of them. This doesn’t exist currently because none of this works by pouring the site into the model’s context. An agent works the way a developer joins a codebase: nobody reads the whole thing. They search it, follow its structure, and read the three files that matter. So the content needs what a codebase has — a way to be navigated rather than swallowed. It needs an index: a map of what exists, how it links together, and where to look — one the agent consults before every change and rebuilds after, since it is the one making changes. Notice what this adds up to. Full-corpus search. Structure it can traverse — links, an index, a map. Assemble those requirements and you have described a wiki. Or more precisely, Karpathy’s LLM wiki design https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f optimized for use as an agentic website management system. 8 ref-8 The canonical store is the content graph, markdown and structured data in a Git repository. The public website is not the system; it is one rendered view of the graph, produced by a build step. An internal knowledge base is another view, tracking historical decisions ADR , RACI matrices, source material, or general wiki content. There are a dozen startups trying to monetize just that offering right now, it might benefit to not keep it outside of the content. Another view would be a machine-readable endpoint llms.txt https://llmstxt.org/ for the agents reading your site. 9 ref-9 The actual generator hugo et al. producing the public view becomes a swappable adapter rather than the primary tool, because everything that matters — the content, the links, the history, the index — lives a layer below it. Where this leads I believe this will lead to more advanced setups that are built to support agentic content management specific to websites. Perhaps custom desktop applications with various integrations. There are already so many benefits to SSG 10 ref-10 11 ref-11 that if you can mitigate the shortcomings and/or replace features with modern alternatives simplicity could provide a massive overall benefit to the typical enterprise setup. For the rest of this article, I will call it a content client, and I’ll outline its structure now. You open it and see your site as a graph of pages, internal and public. I imagine the Content Client as a combination of Obsidian https://obsidian.md/ , GitHub Desktop https://desktop.github.com/ , and Dagger https://dagger.io/ or similar CI pipeline management plus integrated AI agents/tools. So let’s start by validating how this system could replace the core features of a CMS, they fall into a few categories. - Base content & storage - Authoring, roles, and permissions - The pipeline - Additions no CMS has Base content & storage The known SSG limitations apply here unchanged, so briefly: content you’d query at runtime like a large product catalog still requires a database 12 ref-12 ; frontmatter is a document format, not a schema engine 13 ref-13 . Authoring is Markdown, deliberately — there is no layout builder, and visual page composition stays developer territory in templates as in my opinion it should. Any blocks, inline editors, or draggable sections are overcomplicated, and sometimes heavyweight JavaScript overkill. In the Content Client everything renders at build time, so the rows below cover producing pages, not varying them per request. | Responsibility | Server Based CMS | Content client | |---|---|---| | Content storage | Relational database | Markdown + frontmatter in a Git repo | | Content modeling | Content types + Field API | Frontmatter schemas validated in CI; structure emerges from links, not fields link-first | | Versioning & history | Database / Node revisions | Git history, native — per-change authorship, full rollback; surfaced in-app as “page history” | Authoring, roles, and permissions Git has no permission model of its own — write access to a branch is write access to every file on it. But enforcement can happen at the Git host GitHub, GitLab, etc. , at push and merge time, through four mechanisms: Push rulesets : GitHub GA 2024 15 ref-15 ; GitLab push rules; pre-receive hooks generally — server rejects any push modifying designated paths. True path-level write permission.: changes touching designated paths require approval from the people who own them. Path-level approval permission. CODEOWNERS https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners + required reviews Branch protection — no direct pushes to protected branches, required reviews, force-push blocked. Required status checks : the check runner must pass before merge. The softest mechanism, but portable to any host. All four are server-side. The Content Client UI can be configured for roles, but it is not the security boundary. A “role” here is just a combination of settings on the Git host: read yes/no , write scoped by path patterns , approve scoped by path via CODEOWNERS , merge scoped by branch pattern , and administer. Every dimension except read is arbitrarily divisible, so you can create as many role instances as you want: - Scoped editors — a ruleset limiting a team to content/careers/ , or content/fr/ for a translation vendor. - Scoped approvers — CODEOWNERS entries per path: legal owns content/legal/ , brand owns content/press/ . - Branch-scoped roles — rulesets and protections target branch patterns, so “can merge into campaign/ but not main” is expressible. - Multi-approval tiers — require two approvals on main, or approvals from distinct owning teams, which gets you “senior approver”. A pre-defined branching structure might look similar to this: - main as always, remains the published site. - draft/