I was “just” a CMS developer.
Then came AI

I’m a developer, and I’ve built CMSs.

I’ve spent much of the past twenty years working with them. CMS often meant WordPress, and WordPress meant websites. It’s an understandable association, but it only tells part of the story.

A title, a photograph and a “Publish” button may be all you see. Behind them there may be editorial teams, translations, permissions, integrations and years of content that need to survive the next upgrade. Working on these problems is where I learned the most.

Today, AI lets many more people build an application, a business tool, even their own CMS. I find that exciting. And I recognise, in those projects, many of the problems we’ve spent years working on.

The easier software becomes to generate, the more useful it is to understand what that software must keep doing over time. That’s the experience I want to talk about.

Software starts with the people who use it

Someone opening a CMS usually has a job to finish: publish an article, update a catalogue, organise an event. Our data model needs to meet that work. A required field, for instance, can make perfect sense in the database and be impossible to fill in when someone is only sketching out a piece of content. Sooner or later, someone will type “TBD”, and the constraint will have produced worse data.

It’s a product lesson that immediately becomes architecture: distinguish a draft from publishable content, ask for information at the right time, make errors understandable and recovery possible.

In business software, the buyer and the user are often different people. An employee may have to live with an awkward interface for years. In consumer products, which are easier to leave, that same friction can cost a customer. Many CMSs sit somewhere in between: they are work tools, but they end up in the hands of people with very different skills, habits and patience. They were a good place to learn how to combine structure and usability.

You can recognise that familiarity in today’s applications. A CRM, a property management system, an admin panel: I filter some information, choose how to display it, do something. Query, view, action. A table, a calendar and a kanban board can be three ways of working with the same data.

This grammar also has roots in databases and business systems. CMSs have practised it for a long time, putting it in front of people who needed it every day without knowing what a foreign key was. Now AI lets us generate a view for a single task, perhaps one that will last ten minutes. Underneath, the meaning of the data and the rules for changing it must remain recognisable.

Anatomy of a CMS

Let’s take Directus, because I work with it and can examine it closely. Calling it “a database with APIs and an admin panel” is about as accurate as describing an animal as something with skin and organs. To understand what we’re buying, reusing or considering rebuilding with AI, we need to separate its responsibilities.

I’ll start on the outside. The skin is the Data Studio: forms, views and dashboards make the system usable. Hiding a field in a form, though, doesn’t protect it on the server. The skeleton is the data model: SQL tables and relationships, alongside the metadata Directus uses to describe fields, interfaces and configuration. We still have to decide what “customer”, “project” or “approved” means. Then we open up the rabbit.

The crucial distinction is between what Directus can do and the decisions we have to make ourselves. It provides collections, relationships, permissions, versions and automations. Deciding who can approve an expense, when a draft is ready to publish or how to recognise the same customer across two systems requires a model of our work. The product gives us tools to express it; the correctness of that model remains our responsibility.

Follow a concrete change: an editor changes a product’s price. The Data Studio collects the new value; the API receives the request; services execute it in the context of the user and configured permissions. The database enforces its own constraints. History, if configured, records the change. A Flow may trigger an update to an external catalogue. These are different responsibilities: if that last service doesn’t respond, the saved price and the price still visible elsewhere may diverge. We need a recovery rule and a way to notice.

Boundaries matter when extending the platform, too. The services documentation calls for care with the authorisation context, called accountability: omitting it can give the service administrative permissions.³ And marking a field as hidden in the Data Studio does not replace a data policy.⁴ The platform’s value also depends on how well we respect its boundaries.

Outside the animal lie running and maintaining the system: database and storage, secrets, verified backups, monitoring, updates and client compatibility. We can delegate some of this to a managed service. We still need to know who covers it. Migrating a schema or restoring a revision solves part of the problem; neither amounts to a complete recovery plan.

Licensing choices also bring the cost of this whole arrangement into focus. Directus currently uses the MSCL, a source-available licence: the source can be inspected, while use depends on the applicable terms.⁵ For anyone considering an alternative, the calculation includes the ongoing cost of maintaining the responsibilities they choose to take on.

Usability beyond the browser

The same care needs to reach people working through code, scripts and automation. Developer experience, or DevEx, is another form of usability: clear documentation, explicit types, predictable commands, understandable errors. These qualities let people be precise and repeat an operation knowing what to expect.

In Directus, that attention takes concrete forms. The JavaScript and TypeScript SDK provides a composable client for APIs, authentication and realtime, with support for your schema’s types.⁶ The environment synchronisation CLI lets you export schema and configuration, inspect differences and apply them to compatible instances, including in a pipeline.⁷ Through the Model Context Protocol, the MCP server exposes data and operations to AI assistants while respecting the permissions of the identity they connect with.⁸

This gives people a practical freedom: use the admin panel, write an integration, run a command or work with their own agent in their own environment. They can choose how to interact and find the same data model, with the authorisations required for each operation. AI enters a system that already has structure and rules.

For me, “beautiful and convenient” includes this: software a person can orchestrate, including through their own agent. I can compose a workflow, delegate some steps, check the outcome and intervene. Automation becomes a way to exercise more control over work. Thoughtful DevEx makes that possible today.

“It’s just an image gallery”

Take an ordinary request: an article’s main image needs to become an ordered gallery. We add a few thumbnails to the form and make them draggable. Sounds like a quiet afternoon.

The model, however, moves from a single reference to a relationship with several images and an order. Existing articles must retain their photographs. APIs and templates must understand the new structure. Permissions must let editors manage the relationship too, without granting unwanted file access. Meanwhile, the editors keep working.

We can proceed in stages: add the relationship, turn existing references into the first image of each gallery, update reads and finally retire the old field. During the transition, we also need to decide how to handle new writes: if someone changes the old image after the initial migration, that change needs to reach the gallery. A compatible release must account for what happens while it is being deployed.

Schema, data, files and code must work together at every stage of a change. They can evolve at different times, provided there is a path that keeps them compatible.

That’s why promoting a schema from development to production and transferring content are separate operations.⁹ It’s why returning to yesterday’s code can leave a system broken if we’ve transformed the data in the meantime. And it’s why a database backup alone may not be enough: if it references images already deleted from storage, we’ve recovered pointers to something that no longer exists.

An image gallery has brought us to disaster recovery. We need to know which files to retain, which code versions can reopen the data, and how to restart integrations without repeating actions already performed. A sent email or an operation on an external service doesn’t roll back along with the database.

This is where the workshop built around the CMS comes in: infrastructure, CI/CD pipelines, observability, restore drills. It lets us release in a precise order, distinguish a wrong permission from a service outage, and check how much work we might lose in an incident. Then there are the people: who approves the change, who intervenes, who knows why that strange rule exists.

At welance, our cloud and the processes we’ve built around it are part of this collective experience. People who have worked on complex CMSs often carry a whole way of working with them, much harder to see than a screen.

AI can also help us write migrations, tests and recovery procedures. Experience helps us recognise which ones to ask for and understand whether the tests actually demonstrate what matters. A prototype shows that something can work; the work that follows establishes the conditions under which it will keep working.

The C stands for content

So far, I’ve talked about articles and photographs. But content can also be a requirement, a property, an availability slot, a decision or the relationship between a project and a person. That openness has always interested me about CMSs.

A flexible enough system can become the foundation of a property management tool, a CRM or parts of an ERP. It already provides a place to describe entities, connect them, assign access and build interfaces. Domain knowledge is added on top: a booking must prevent overlaps even when two requests arrive simultaneously; an accounting decision carries constraints an article does not.

The CMS interests me precisely as a home for these possibilities. Much of what we call “business software” involves giving information structure and allowing the right people to act on it. With AI, a new participant joins those people and that information, able to read, propose and operate. The quality of the structure becomes even more important.

When memory becomes operational

Shared memory becomes operational when we can trace a piece of data to its source, a decision to its reasons and an action to the rules that authorise it.

Knowledge becomes rational to the extent that we can reconstruct and verify it. A recorded transaction, an estimate and a model’s conclusion must remain distinguishable. Calculation rules and connections must be inspectable. This foundation lets different people, with different agents, work from the same facts and discuss their interpretations.

I see a connection here with Andrej Karpathy’s proposed LLM Wiki: a model reads sources and maintains persistent knowledge through summaries and links that evolve over time.¹¹ In a CMS, we can connect that knowledge to projects, responsibilities and states: which requirement is approved, who can change it, which task depends on it.

Sources may be a document, a recording or a photograph. Tools interpreting them must preserve provenance so a person can check and correct the summary. The model may change; data, decisions and relationships must be able to remain. In this sense, the system becomes part of the company’s intelligence.

Moving to action requires precise authorisation. Reading a requirement does not automatically grant the right to modify a project or send something to a client. Each connector must check the requested action and use appropriate credentials on the external service. MCP provides a common way to connect tools; mapping permissions across systems still needs to be designed. Even a summary drawn from confidential documents must respect those boundaries.¹²

This is the evolution I imagine when I think of an AI Management System, or AI MS: a business system where people and agents work with the same operational memory. Each can interact in their own way, while rules, responsibilities and change history remain verifiable. It’s a working name for a direction I find promising.

The CMS might be the piece to remove

The strongest objection to my argument is that AI could make data and rules more important, while making the CMS that brings them together less necessary. The responsibilities in the anatomical plate can be assembled differently. The skills I’ve described belong to software engineering. Learning them through CMSs does not prove that a CMS is still the best choice.

As building specialised tools becomes cheaper, the advantage of adapting to a general-purpose platform changes. A small application built around your work may be preferable to a CMS full of extensions. SDKs, CLIs and MCP support this alternative too: they make each product accessible and composable without necessarily assigning it a central role.

A shared model also has a cost. A project for someone planning work and a job for someone invoicing it may have different boundaries. Domain-driven design addresses precisely this plurality of models, defining their boundaries and making their relationships explicit.¹³ Forcing them into one structure can create fragile translations, stale copies and a point every change must pass through.

A sensible alternative keeps authoritative systems in their own domains and connects them through explicit contracts. The agent coordinates operations; services continue to enforce their own rules. The CMS can remain where editors need it, or leave that workflow entirely. I have to consider this possibility, partly to avoid seeing the future mainly through the tool I know best.

For me, a CMS earns that place when shared relationships, permissions and editorial workflows are a substantial part of the work. If using it requires duplicating rules already reliable elsewhere and maintaining continuous synchronisation, the advantage may disappear. The practical test is to imagine removing it: which responsibilities would I have to rebuild, which integrations would I eliminate, and how much harder would understanding or recovering from an error become? The best choice reduces the overall work while preserving the necessary guarantees.

The tools I’d like to use tomorrow

This perspective shapes the tools I look towards. Railway’s approach interests me: services and environments are visible parts of the project. Lovable starts with building the application and also provides a managed backend, including database, authentication and storage.¹⁴ They are different ways of making a system accessible while it continues to have dependencies underneath.

I favour platforms that make those dependencies understandable and help us manage them. I imagine conversational building as one capability within a broader platform that supports software beyond its first release.

I’d like to ask “turn this image into a gallery” and see which data will change, how existing data will be handled, which services will be involved and where approval will be needed. I’d also like to know how to recover if something goes wrong. Drawing components on a canvas is a useful starting point; the value lies in managing the change that passes through them.

The next CMS could emerge from this, or from the evolution of tools we already use. What matters to me is that a person can choose their interface and agent while continuing to work on a shared foundation. The difference will come from guiding a change from the intention of the person requesting it through to its consequences for the system.

Long live the CMS

There is also plenty of CMS work done on autopilot: install a theme, pile on plugins and deliver without asking how the system will hold up. Having worked with CMSs is not, in itself, a sign of care or competence. An easy starting point can encourage curiosity as readily as laziness.

Looking at what we’re building with AI today, I mostly find myself noticing something that has always been obvious: good software is good software. You recognise it by how well it serves the people who use it and how it holds up over time and through change. Names, acronyms and the technology of the moment tell you little on their own.

For anyone building their own business software with AI today, I’d leave four questions, the same ones I would keep asking myself:

• Which rules must remain true as the system changes?
• Who can act, on which data, and with what consequences?
• What have we actually tried recovering after a failure?
• What will the people who come after us know?

CMSs were where I learned to ask these questions. I carry what I learned with me, including when it helps me choose a different architecture.

CMS is dead. Long live the CMS.