Grading my CEO’s predictions about Git-based CMSs

In March 2022, CloudCannon CEO Mike Neumegen wrote that the future of content management is Git-based. He compared traditional CMSs to a Swiss army knife (too many choices), API-based CMSs to a build-your-own-knife kit (good luck doing it all yourself), and Git-based CMSs to a boning knife (specific, targeted). Then he made three predictions.

He wrote that from the position of someone who co-founded a company based on Git’s architecture. I’m coming at it from the other end. I write and publish exclusively on CloudCannon websites, which — aside from our incredibly prolific docs writer Ella Williams — might make me the heaviest internal user of our own product. If the editing experience were bad, I’d be the first person to know, and probably the least able to avoid saying so.

Two of Mike’s three predictions landed, in my view. But the grades turned out to be the least interesting part of the exercise, because the strongest argument for Git-based content management in 2026 is one Mike couldn’t have made in 2022, and it isn’t focused on content management.

Prediction one: Wikipedia-style collaborative editing on any website # Direct link to this section

Grade: C

Mike predicted we’d see open collaborative editing on ordinary websites, with a visual interface replacing wikicode. This didn’t happen.

CloudCannon has no wiki-style collaboration, and there’s no version of our CMS where a stranger proposes an edit to your homepage and a volunteer moderator waves it through. Nobody else has built that either. The half of the prediction that landed is the easy half: editors do get a visual interface instead of markup, and that’s true across the whole category now.

Four years on, I don’t think open collaboration was the right thing to want. Wikipedia’s hard problems are moderation, vandalism, and the cost of reviewing contributions from strangers, and it manages those with two decades of governance rather than good software. Hand a company a public edit button and you’ve handed them a moderation queue nobody has budget for.

What did arrive is collaboration between people who already work together. Several of them on the same site at once, each in whatever interface suits them, with Git history reconciling what they did. The developer platform we shipped in August added a CLI, a Visual Editor API, and a local dev server, so cloudcannon dev now runs the editing experience on a developer’s own machine, against their own files, updating as they save. A developer can be in their terminal reshaping what editors will see while an editor is in a browser changing a heading, with two-way sync keeping both straight.

He got the mechanism right, but he was focused on the wrong users — he’d been thinking about strangers when the people who needed it work at an adjacent desk.

Prediction two: review processes with kernel-maintainer confidence # Direct link to this section

Grade: A

Mike predicted content teams would get the same confidence publishing copy that the Linux Foundation has shipping a kernel. This one landed, and I use it constantly.

Concretely: this article was written on a branch. CloudCannon built a preview of the site with it in place, at its own URL, which I sent to two colleagues. One of them left changes directly on the branch. When it merged to our staging branch, everyone else on our team could read it; when they were happy with it, we merged that branch to production, and our live site rebuilt. If something’s wrong with it in a week, the fix is either making an edit or reverting a commit, and the full history of who changed what stays attached forever.

None of that required me to think about Git. I’d describe my actual awareness of the branch as ’I clicked a button that said create a branch’. But the review discipline underneath is the same that our engineers use, with the same confidence. That’s the part Mike got right.

Prediction three: tight developer and editor collaboration # Direct link to this section

Grade: A^-

Mike predicted Git-based workflows would put developers and editors on the same page. This landed too, and I think I’m the evidence.

The test I’d apply is how often I have to ask a developer for something. In my first web content role, some years ago, changing a heading on a landing page meant someone had to make a ticket. Adding a new page meant two tickets and a few days. Now the only things I need a developer for are genuinely developer problems: a new component, a schema change, a template that needs to do something it doesn’t currently do. Copy, structure, images, page order, new pages, metadata, none of those touch anyone else’s queue. (Unless I bring in Claude Code — more on that below!)

Why coding agents work better on a Git-based site # Direct link to this section

There’s no mention of AI anywhere in the 2022 article, which is entirely reasonable for early 2022. But it’s now the argument I’d lead with, and it’s probably the thing that changed my week-to-week work the most.

You’ll often see it claimed that language models are trained on Git repositories. What we can observe is what coding agents are built to do: move through files and directories, read source code, produce diffs, work a Git branch. That’s the interface they’re designed around. A Git-based website is a pile of files and directories that you change with diffs on a Git branch.

So the fit isn’t lucky. The thing the agent expects to find is the thing that’s there.

Last week I asked Claude Code to add author bios to our blog, so we can give our authors a little more credit for their work. It read through the relevant templates, partials, and schemas, worked out where to add frontmatter fields, applied the right style, and its fix was a single approval away from our production site.

I want to be careful not to claim too much here, because an agent with API access could have done that too. It could call the API, pull the content model, read the frontend repo separately, and assemble the picture. The key difference is assembly. With a Git-based site that context is already in one place, in the shape the agent expects. With an API it has to be reconstructed across two systems that were deliberately designed not to know about each other. More moving parts means more steps, more tokens spent, and more places to go wrong. The reliability of your agent reliability drops with every one of them.

Agents shouldn’t publish straight to production # Direct link to this section

I don’t really want an agent publishing directly to my live sites, and I’d be suspicious of anyone who does.

What I want is an agent that proposes something a person reviews first, with a permanent record of what changed, who or what changed it, and what it looked like before. That sounds an awful lot like a pull request. And it has since 2005.

Every content platform is now building some version of that review layer. CloudCannon didn’t have to, because our storage format came with one. I’d love to present that as strategy, but it was a side effect of a decision made for completely different reasons.

Where the CMS market actually moved # Direct link to this section

In 2022 the active argument was ‘Git-based versus API-first’. That argument narrowed over the following four years, but not because either side won it. Instead, the ground moved underneath everyone.

Let’s start with WordPress, which stopped growing. It peaked in mid-2025 at around 43.6% of all websites and has been sliding since, the first sustained decline W3Techs has recorded. It’s currently sitting at just over 40% (still a sizeable chunk, to be fair), but the 3% wasn’t lost to a rival CMS. It went to sites running no detectable CMS at all. Some of that is parked domains and measurement noise. A good chunk of it is generated HTML, built ahead of time and served as files.

Then the API-first category consolidated into platform companies. Payload’s team joined Figma in 2025, where the project is becoming the engine behind Figma CMS, and Salesforce signed an agreement to acquire Contentful in June 2026. Both acquirers have committed to keeping things as they are; I have no reason to doubt them.

But: “Where does my content live if this vendor’s strategy shifts?” used to be a largely theoretical objection. It feels much less theoretical now.

Finally, self-hosted open source CMSs took real ground in the mid-market. Strapi and Payload being free to run on your own infrastructure pulled a lot of teams off SaaS platforms, and the reason those teams give is ownership. They’re paying in operational effort to keep their hands on the data.

That’s three different stories, that all pointing the same way. More teams want the artefact of their site itself, in a format they control, rather than simply paying for an account on a platform that holds it for them.

Which brings me to Git.

Mike did pretty well, and Git won a different bet # Direct link to this section

Averaging it all out, I’d give Mike a B⁺. His prediction on open collaboration drags down two strong results, but I’d argue the grading curve should be generous, because the mechanism he bet on still mattered, even if he didn’t address the reasons why.

Content and code stopped being scarce. Agents now produce drafts, components, pages, and entire sites faster than any team can read them, and that firehose isn’t slowing down. When production gets cheap, the bottleneck moves to trust. Can I see exactly what changed? Who changed it? What did it look like before? Who approved it? Was it a person?

Git answers every one of those, and has for the last twenty years: branches, diffs, attribution, history, and reviews. CloudCannon adopted it as a foundation of our CMS so developers and editors would stop blocking each other. Now it’s the governance layer for a kind of collaborator that didn’t exist when we chose it.

So here’s the claim I’d defend, four years on: Git is the trust layer for humans and agents building websites together. (And if it isn't, it should be!)

My pick for the next few years # Direct link to this section

I’m not going to make too many predictions, partly because I’ve just spent a few hundred words marking someone else’s and I’d rather not hand that job to a colleague in 2030.

What I’ll watch is volume. If a meaningful share of web content becomes machine-drafted over the next few years, and for better or worse I think it will, the bottleneck stops being our ability to produce content and becomes our ability to account for it. Who wrote what, and when, who approved it, and what did it say before? Those are the questions I can already answer by running git log.

That’s the bet Mike made in 2022. And even if he made it for different reasons, on the evidence of four years using the thing, I’d say it’s holding up.