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

Ich bin Entwickler und habe CMS gebaut.

Einen großen Teil der vergangenen zwanzig Jahre habe ich mit ihnen gearbeitet. CMS bedeutete oft WordPress, und WordPress bedeutete Websites. Diese Verbindung ist verständlich, erzählt aber nur einen Teil der Geschichte.

Ein Titel, ein Foto und die Schaltfläche „Veröffentlichen“ sind womöglich alles, was man sieht. Dahinter können Redaktionen, Übersetzungen, Berechtigungen, Integrationen und jahrelang gesammelte Inhalte stehen, die das nächste Update überstehen müssen. Bei der Arbeit an diesen Problemen habe ich am meisten gelernt.

Heute ermöglicht KI viel mehr Menschen, eine Anwendung, eine Unternehmenssoftware oder sogar ein eigenes CMS zu bauen. Das begeistert mich. Und ich erkenne in diesen Projekten viele Probleme wieder, an denen wir jahrelang gearbeitet haben.

Je einfacher sich Software erzeugen lässt, desto nützlicher wird das Wissen darüber, was sie dauerhaft leisten muss. Über diese Erfahrung möchte ich sprechen.

Software beginnt bei den Menschen, die sie nutzen

Wer ein CMS öffnet, möchte meist eine Arbeit erledigen: einen Artikel veröffentlichen, einen Katalog aktualisieren, eine Veranstaltung organisieren. Unser Datenmodell muss zu dieser Arbeit passen. Ein Pflichtfeld kann in der Datenbank völlig sinnvoll sein und sich dennoch unmöglich ausfüllen lassen, wenn jemand gerade erst einen Inhalt skizziert. Irgendwann wird dort „noch offen“ stehen, und die Vorgabe hat schlechtere Daten erzeugt.

Das ist eine Produktlektion, die unmittelbar zu Architektur wird: einen Entwurf von veröffentlichbaren Inhalten unterscheiden, Informationen zum richtigen Zeitpunkt abfragen, Fehler verständlich und eine Wiederherstellung möglich machen.

Bei Unternehmenssoftware sind Käufer und Nutzer häufig verschiedene Menschen. Beschäftigte müssen unter Umständen jahrelang mit einer umständlichen Oberfläche leben. Bei Verbraucherprodukten, die man leichter verlassen kann, kostet dieselbe Hürde möglicherweise einen Kunden. Viele CMS liegen dazwischen: Arbeitswerkzeuge für Menschen mit sehr unterschiedlichen Fähigkeiten, Gewohnheiten und Geduldsgrenzen. Eine gute Schule, um Struktur und Bedienbarkeit zusammenzubringen.

In heutigen Anwendungen erkennt man Vertrautes wieder. Ein CRM, eine Immobilienverwaltung, ein Administrationsbereich: Ich filtere Informationen, wähle eine Darstellung und tue etwas. Abfrage, Ansicht, Aktion. Tabelle, Kalender und Kanban können drei Arbeitsweisen mit denselben Daten sein.

Diese Grammatik hat ihre Wurzeln auch in Datenbanken und Unternehmenssoftware. CMS haben sie lange eingeübt und Menschen zugänglich gemacht, die täglich damit arbeiten mussten, ohne Fremdschlüssel zu kennen. Heute können wir mit KI eine Ansicht für eine einzige Aufgabe erzeugen, vielleicht nur für zehn Minuten. Darunter müssen die Bedeutung der Daten und die Regeln für ihre Änderung erkennbar bleiben.

Anatomie eines CMS

Nehmen wir Directus, weil ich damit arbeite und es aus der Nähe betrachten kann. „Eine Datenbank mit APIs und einer Oberfläche“ ist ungefähr so treffend, wie ein Tier als etwas mit Haut und Organen zu beschreiben. Um zu verstehen, was wir kaufen, wiederverwenden oder mit KI nachbauen wollen, müssen wir seine Verantwortlichkeiten auseinandernehmen.

Ich beginne außen. Die Haut ist das Data Studio: Formulare, Ansichten und Dashboards machen das System bedienbar. Ein im Formular verborgenes Feld ist dadurch allerdings nicht auf dem Server geschützt. Das Skelett ist das Datenmodell: SQL-Tabellen und Beziehungen samt Metadaten, mit denen Directus Felder, Oberflächen und Konfigurationen beschreibt. Was „Kunde“, „Projekt“ oder „genehmigt“ bedeutet, müssen wir festlegen. Dann öffnen wir das Kaninchen.

Entscheidend ist der Unterschied zwischen dem, was Directus leisten kann, und den Entscheidungen, die wir selbst treffen müssen. Es bietet Sammlungen, Beziehungen, Berechtigungen, Versionen und Automatisierungen. Wer eine Ausgabe genehmigen darf, wann ein Entwurf veröffentlichbar ist oder wie derselbe Kunde in zwei Systemen erkannt wird, erfordert ein Modell unserer Arbeit. Das Produkt liefert Werkzeuge, um es auszudrücken; für die Richtigkeit dieses Modells bleiben wir verantwortlich.

Verfolgen wir eine konkrete Änderung: Eine Redakteurin ändert einen Produktpreis. Das Data Studio erfasst den Wert; die API erhält die Anfrage; Dienste führen sie im Kontext des Nutzers und der eingerichteten Berechtigungen aus. Die Datenbank setzt ihre eigenen Bedingungen durch. Der Verlauf hält die Änderung fest, sofern konfiguriert. Ein Flow kann die Aktualisierung eines externen Katalogs anstoßen. Das sind verschiedene Aufgaben: Antwortet dieser letzte Dienst nicht, können gespeicherter und andernorts angezeigter Preis auseinanderlaufen. Wir brauchen eine Wiederherstellungsregel und eine Möglichkeit, das zu bemerken.

Auch beim Erweitern der Plattform zählen Grenzen. Die Dokumentation der Dienste verlangt Aufmerksamkeit beim Berechtigungskontext, accountability genannt: Wird er weggelassen, kann der Dienst Administratorrechte erhalten.³ Ein im Data Studio verborgenes Feld ersetzt zudem keine Datenrichtlinie.⁴ Der Wert der Plattform hängt auch davon ab, wie gut wir ihre Grenzen beachten.

Außerhalb des Tiers liegen Betrieb und Wartung: Datenbank und Speicher, Geheimnisse, geprüfte Backups, Überwachung, Updates und Client-Kompatibilität. Einen Teil können wir an einen verwalteten Dienst abgeben. Trotzdem müssen wir wissen, wer ihn übernimmt. Auch eine Schemamigration oder das Wiederherstellen einer Revision löst nur einen Teil des Problems und ersetzt keinen vollständigen Wiederherstellungsplan.

Lizenzentscheidungen lenken ebenfalls den Blick auf die Gesamtkosten. Directus verwendet derzeit die MSCL, eine Source-available-Lizenz: Der Quellcode ist einsehbar, die Nutzung hängt von den geltenden Bedingungen ab.⁵ Wer eine Alternative prüft, muss einrechnen, was die dauerhaft übernommenen Verantwortlichkeiten kosten werden.

Bedienbarkeit auch außerhalb des Browsers

Dieselbe Sorgfalt muss Menschen erreichen, die mit Code, Skripten und Automatisierungen arbeiten. Developer Experience, kurz DevEx, ist eine weitere Form der Bedienbarkeit: klare Dokumentation, explizite Typen, vorhersehbare Befehle, verständliche Fehler. Diese Eigenschaften ermöglichen Präzision und wiederholbare Operationen mit bekannten Erwartungen.

Bei Directus wird das konkret. Das JavaScript- und TypeScript-SDK bietet einen zusammensetzbaren Client für APIs, Authentifizierung und Echtzeitfunktionen mit Typunterstützung für das eigene Schema.⁶ Die CLI zur Umgebungssynchronisierung exportiert Schema und Konfiguration, zeigt Unterschiede und wendet sie auf kompatible Instanzen an, auch in einer Pipeline.⁷ Der MCP-Server stellt über das Model Context Protocol Daten und Operationen für KI-Assistenten bereit und beachtet dabei die Berechtigungen der Identität, mit der sie sich verbinden.⁸

Das schafft echte Wahlfreiheit: die Oberfläche nutzen, eine Integration schreiben, einen Befehl ausführen oder mit dem eigenen Agenten in der eigenen Umgebung arbeiten. Man wählt die Interaktion und trifft auf dasselbe Datenmodell, mit den für die jeweiligen Operationen erforderlichen Berechtigungen. KI kommt damit in ein System, das bereits Struktur und Regeln besitzt.

Zu „schön und bequem“ gehört für mich auch Software, die ein Mensch orchestrieren kann, auch über seinen eigenen Agenten. Ich kann einen Ablauf zusammenstellen, Schritte delegieren, Ergebnisse prüfen und eingreifen. Automatisierung wird so zu einer Möglichkeit, mehr Kontrolle über die Arbeit auszuüben. Sorgfältige DevEx macht das schon heute zugänglich.

„Es ist doch nur eine Bildergalerie“

Eine gewöhnliche Anfrage: Das Hauptbild eines Artikels soll zu einer sortierten Galerie werden. Im Formular ergänzen wir Vorschaubilder und machen sie verschiebbar. Klingt nach einem ruhigen Nachmittag.

Das Modell wechselt jedoch von einem einzelnen Verweis zu einer Beziehung mit mehreren Bildern und einer Reihenfolge. Bestehende Artikel müssen ihr Foto behalten. APIs und Templates müssen die neue Struktur verstehen. Berechtigungen müssen Redakteuren auch die Verwaltung der Beziehung erlauben, ohne unerwünschten Dateizugriff zu öffnen. Und währenddessen arbeiten die Redakteure weiter.

Wir können schrittweise vorgehen: Beziehung ergänzen, vorhandene Verweise in das erste Bild der jeweiligen Galerie umwandeln, Lesezugriffe anpassen und schließlich das alte Feld abschaffen. Während des Übergangs müssen wir auch neue Schreibzugriffe behandeln: Ändert jemand das alte Bild nach der ersten Migration, muss diese Änderung in der Galerie ankommen. Ein kompatibles Release berücksichtigt auch, was während seiner Auslieferung passiert.

Schema, Daten, Dateien und Code müssen in jeder Änderungsphase zusammenarbeiten können. Sie dürfen sich zu unterschiedlichen Zeitpunkten weiterentwickeln, solange ein kompatibler Übergang vorgesehen ist.

Deshalb sind die Übernahme eines Schemas aus Entwicklung in Produktion und die Übertragung von Inhalten verschiedene Operationen.⁹ Deshalb kann die Rückkehr zum gestrigen Code ein defektes System hinterlassen, wenn inzwischen Daten umgeformt wurden. Und deshalb genügt ein Datenbank-Backup allein möglicherweise nicht: Verweist es auf bereits gelöschte Bilder, haben wir Verweise auf etwas wiederhergestellt, das nicht mehr existiert.

Von einer Galerie sind wir bei Disaster Recovery angekommen. Wir müssen wissen, welche Dateien aufzubewahren sind, welche Codeversionen die Daten öffnen können und wie Integrationen ohne doppelte Aktionen wieder anlaufen. Eine versandte E-Mail oder eine Operation in einem externen Dienst wird nicht zusammen mit der Datenbank zurückgedreht.

Hier kommt die Werkstatt rund um das CMS ins Spiel: Infrastruktur, CI/CD-Pipelines, Beobachtbarkeit und Wiederherstellungsübungen. Sie ermöglicht Releases in festgelegter Reihenfolge, unterscheidet falsche Berechtigungen von ausgefallenen Diensten und prüft, wie viel Arbeit bei einem Vorfall verloren gehen könnte. Dazu kommen Menschen: Wer genehmigt die Änderung, wer greift ein, wer kennt den Grund für diese seltsame Regel?

Bei welance gehören unsere Cloud und die darum aufgebauten Prozesse zu dieser gemeinsamen Erfahrung. Wer komplexe CMS betreut hat, bringt oft eine ganze Arbeitsweise mit, die sich viel schwerer erkennen lässt als eine Bildschirmansicht.

KI kann auch Migrationen, Tests und Wiederherstellungsabläufe mitschreiben. Erfahrung hilft zu erkennen, welche wir brauchen und ob die Prüfungen tatsächlich das belegen, worauf es ankommt. Der Prototyp zeigt, dass etwas funktionieren kann; die folgende Arbeit klärt, unter welchen Bedingungen es weiter funktionieren wird.

Das C steht für Content

Bisher ging es um Artikel und Fotos. Inhalt kann aber auch eine Anforderung, eine Immobilie, eine Verfügbarkeit, eine Entscheidung oder die Beziehung zwischen Projekt und Person sein. Diese Offenheit hat mich an CMS immer interessiert.

Ein ausreichend flexibles System kann Grundlage einer Immobilienverwaltung, eines CRM oder von Teilen eines ERP werden. Es bietet bereits einen Ort, um Entitäten zu beschreiben, zu verbinden, Zugriffe zuzuweisen und Oberflächen zu bauen. Darauf kommt das Fachwissen: Eine Buchung muss Überschneidungen auch bei zwei gleichzeitigen Anfragen verhindern; eine Buchhaltungsentscheidung bringt andere Bedingungen mit als ein Artikel.

Mich interessiert das CMS gerade als Raum für diese Möglichkeiten. Vieles, was wir Unternehmenssoftware nennen, strukturiert Informationen und erlaubt den richtigen Menschen, damit zu handeln. Mit KI kommt ein weiterer Beteiligter hinzu, der lesen, vorschlagen und handeln kann. Die Qualität der Struktur wird damit noch wichtiger.

Wenn Gedächtnis handlungsfähig wird

Ein gemeinsames Gedächtnis wird handlungsfähig, wenn wir Daten zu ihrer Quelle, Entscheidungen zu ihren Gründen und Aktionen zu den Regeln zurückverfolgen können, die sie erlauben.

Wissen wird in dem Maß rational, in dem wir es rekonstruieren und überprüfen können. Eine erfasste Buchung, eine Schätzung und eine Schlussfolgerung des Modells müssen unterscheidbar bleiben. Rechenregeln und Verbindungen müssen einsehbar sein. So können verschiedene Menschen mit verschiedenen Agenten auf denselben Fakten arbeiten und ihre Auslegungen diskutieren.

Hier sehe ich eine Verbindung zur von Andrej Karpathy vorgeschlagenen LLM Wiki: Ein Modell liest Quellen und pflegt dauerhaftes Wissen aus Zusammenfassungen und Verknüpfungen, die sich weiterentwickeln.¹¹ In einem CMS können wir dieses Wissen Projekten, Verantwortlichkeiten und Zuständen zuordnen: Welche Anforderung ist genehmigt, wer darf sie ändern, welche Aufgabe hängt davon ab?

Quellen können Dokumente, Aufnahmen oder Fotos sein. Die Werkzeuge, die sie interpretieren, müssen ihre Herkunft bewahren, damit Menschen Zusammenfassungen prüfen und korrigieren können. Das Modell kann wechseln; Daten, Entscheidungen und Beziehungen müssen bleiben können. In diesem Sinne wird das System Teil der Intelligenz des Unternehmens.

Der Übergang zum Handeln erfordert genaue Berechtigungen. Eine Anforderung lesen zu dürfen erlaubt nicht automatisch, das Projekt zu ändern oder einem Kunden etwas zu senden. Jeder Konnektor muss die angefragte Aktion prüfen und geeignete Zugangsdaten für den externen Dienst verwenden. MCP bietet eine gemeinsame Verbindungsmöglichkeit; die Zuordnung der Berechtigungen zwischen Systemen muss entworfen werden. Auch Zusammenfassungen vertraulicher Dokumente müssen diese Grenzen achten.¹²

Diese Entwicklung meine ich mit einem AI Management System, kurz AI MS: einer Unternehmenssoftware, in der Menschen und Agenten mit demselben operativen Gedächtnis arbeiten. Jeder kann auf eigene Weise interagieren, während Regeln, Verantwortlichkeiten und Änderungshistorie überprüfbar bleiben. Es ist ein Arbeitsname für eine Richtung, die mir vielversprechend erscheint.

Vielleicht sollte gerade das CMS wegfallen

Der stärkste Einwand gegen meine These lautet: KI könnte Daten und Regeln wichtiger machen und das CMS, das sie zusammenführt, weniger notwendig. Die Verantwortlichkeiten der anatomischen Tafel lassen sich anders zusammensetzen. Die beschriebenen Fähigkeiten gehören zum Software Engineering. Dass ich sie an CMS gelernt habe, beweist nicht, dass ein CMS weiterhin die beste Wahl ist.

Wenn spezialisierte Werkzeuge günstiger zu bauen sind, verändert sich der Vorteil, sich einer allgemeinen Plattform anzupassen. Eine kleine Anwendung für die eigene Arbeit kann einem CMS voller Erweiterungen vorzuziehen sein. SDK, CLI und MCP stützen auch diese Alternative: Sie machen Produkte zugänglich und kombinierbar, ohne ihnen zwingend eine zentrale Rolle zu geben.

Auch ein gemeinsames Modell kostet. Ein Projekt für die Arbeitsplanung und ein Auftrag für die Rechnungsstellung können unterschiedliche Grenzen haben. Domain-driven Design behandelt genau diese Vielfalt, grenzt Modelle ab und macht ihre Beziehungen ausdrücklich.¹³ Sie in eine einzige Struktur zu pressen kann fragile Übersetzungen, veraltete Kopien und einen Punkt erzeugen, den jede Änderung passieren muss.

Eine sinnvolle Alternative belässt die maßgeblichen Systeme in ihren jeweiligen Bereichen und verbindet sie über explizite Verträge. Der Agent koordiniert Operationen; die Dienste setzen weiter ihre eigenen Regeln durch. Das CMS bleibt dort, wo Redakteure es brauchen, oder scheidet ganz aus diesem Ablauf aus. Diese Möglichkeit muss ich auch bedenken, damit ich in der Zukunft nicht vor allem mein vertrautestes Werkzeug wiedererkenne.

Für mich verdient ein CMS diesen Platz, wenn gemeinsame Beziehungen, Berechtigungen und redaktionelle Abläufe einen wesentlichen Teil der Arbeit ausmachen. Muss ich dafür andernorts zuverlässige Regeln duplizieren und laufend synchronisieren, kann der Vorteil verschwinden. Der praktische Test ist, es gedanklich zu entfernen: Welche Verantwortlichkeiten müsste ich neu aufbauen, welche Integrationen entfielen, und wie viel schwerer würden Fehleranalyse und Wiederherstellung? Die beste Wahl senkt den Gesamtaufwand und bewahrt die nötigen Garantien.

Die Werkzeuge, die ich morgen nutzen möchte

Diese Perspektive prägt mein Interesse an Werkzeugen. Bei Railway gefallen mir Dienste und Umgebungen als sichtbare Projektbestandteile. Lovable beginnt mit dem Bau der Anwendung und bietet außerdem ein verwaltetes Backend mit Datenbank, Authentifizierung und Speicher.¹⁴ Es sind unterschiedliche Wege, ein System zugänglich zu machen, unter dessen Oberfläche weiterhin Abhängigkeiten bestehen.

Ich bevorzuge Plattformen, die diese Abhängigkeiten verständlich machen und uns helfen, sie zu steuern. Ich sehe den dialoggestützten Bau als eine Fähigkeit einer umfassenderen Plattform, die Software auch nach dem ersten Release begleitet.

Ich möchte „mach aus diesem Bild eine Galerie“ sagen können und sehen, welche Daten sich ändern, wie bestehende behandelt werden, welche Dienste beteiligt sind und wo eine Freigabe nötig ist. Auch der Weg zurück bei Fehlern soll sichtbar sein. Komponenten auf einer Zeichenfläche anzuordnen ist ein guter Anfang; der Wert liegt darin, die sie durchlaufende Veränderung zu steuern.

Hieraus könnte das nächste CMS entstehen, oder aus der Weiterentwicklung vorhandener Werkzeuge. Mir ist wichtig, dass Menschen ihre Oberfläche und ihren Agenten wählen und auf gemeinsamer Grundlage weiterarbeiten können. Entscheidend wird sein, eine Änderung von der Absicht des Auftraggebers bis zu ihren Folgen im System zu begleiten.

Es lebe das CMS

Auch im CMS-Bereich wird vieles auf Autopilot erledigt: ein Theme installieren, Plugins anhäufen und ausliefern, ohne zu fragen, wie sich das System bewähren wird. Mit CMS gearbeitet zu haben, ist für sich genommen kein Zeichen von Sorgfalt oder Kompetenz. Ein leichter Einstieg kann Neugier ebenso fördern wie Bequemlichkeit.

Wenn ich sehe, was wir heute mit KI bauen, fällt mir vor allem etwas auf, das schon immer offensichtlich war: Gute Software ist gute Software. Man erkennt sie daran, wie gut sie den Menschen hilft, die sie nutzen, und wie sie sich über die Zeit und bei Veränderungen bewährt. Namen, Abkürzungen und die gerade angesagte Technologie sagen für sich genommen wenig aus.

Wer heute mit KI seine eigene Unternehmenssoftware baut, dem möchte ich vier Fragen mitgeben, die ich auch mir weiterhin stellen würde:

• Welche Regeln müssen während einer Systemänderung gültig bleiben?
• Wer darf handeln, mit welchen Daten und welchen Folgen?
• Was haben wir nach einem Fehler tatsächlich wiederherzustellen versucht?
• Was werden die Menschen wissen, die nach uns kommen?

An CMS habe ich gelernt, mir diese Fragen zu stellen. Das Gelernte nehme ich mit, auch wenn es mir hilft, eine andere Architektur zu wählen.

CMS is dead. Long live the CMS.