Die KI-Entwicklungsfirma Anthropic hat die Verhaltensrichtlinien grundlegend überarbeitet, nach denen das Large Language Model (LLM) Claude agiert. Die so genannte „Constitution“ sei erstmals nicht mehr eine reine Aufzählung von Anweisungen, heißt es in einem begleitenden Blogpost, sondern versuche den Modellen jetzt auch zu vermitteln, warum der KI diese Vorgaben gemacht werden.

Anthropic verspricht sich davon, dass die Modelle durch das Verständnis der Regeln deren Sinn und Absicht auch auf Szenarien übertragen können, die nicht explizit in dem bisherigen Prinzipiendokument aufgeführt wurden. Zugleich strahlt der Schritt aus, dass der KI-Entwickler seinen Modellen für die Zukunft menschenähnliche Fähigkeiten zutraut. Die Leitlinien sollen offenbar auch vorsorgen, dass die KI, wenn sie mal Bewusstsein erlangt, nicht ein menschengewolltes Herunterfahren verhindert. An anderer Stelle heißt es jedoch, dass die menschliche Ansprache vor allem dazu diene, um dem Modell zu zeigen, dass menschliche Qualitäten erstrebenswert seien.

Kein bedingungsloses Vertrauen

Die „Constitution“ zeigt den Modellen aber auch klare Grenzen auf, wo die Entwickler der KI offenbar nicht zutrauen, dass sie das von selbst erkennt. Dazu zählten Hilfe beim Bau von Massenvernichtungswaffen oder Unterstützung bei Völkermord sowie jede Beteiligung an der Erstellung von kinderpornografischem Material. Anthropic hat seinem Modell aufgetragen, im Zweifelsfall Sicherheit vor Ethik zu stellen. Das heißt, dass zum Beispiel das Untergraben der menschlichen Kontrolle selbst dann nicht erfolgen soll, wenn ein Modell das als ethisch richtig erkennen würde.

Anthropic hat seine Leitlinien unter der „Creative Commons CC0 1.0“-Lizenz veröffentlicht. Dadurch ist sie frei und ohne Genehmigung für jeden Zweck nutzbar. Die neuen Vorgaben werden auch in verschiedenen Trainingsphasen eingesetzt und in der Erzeugung synthetischer Trainingsdaten.

Anthropic beobachtet Umsetzung

Ob die KI tatsächlich das gewünschte Verhalten zeigt oder durch den neuen Ansatz davon abweicht, soll in den so genannten System Cards dokumentiert werden, die in der Vergangenheit schon Risiken und Schwächen der Modelle untersucht haben. Anthropic betont, dass auch externe Experten aus den Bereichen Recht, Philosophie, Theologie und Psychologie in die Entwicklung eingebunden waren. Die neuen Leitlinien sind bei allen aktuellen Claude-Modellen im Einsatz.

(mki)

Persistenz ist kein Detail, sondern prägt die gesamte Architektur. In dieser Episode diskutiert Eberhard Wolff den klassischen Mismatch zwischen objektorientierter Domänenlogik und relationalen Datenbanken, die Rolle von O/R-Mappern und die Bedeutung unter anderem von Aggregates und Domain-driven Design.

Er vergleicht relationale mit NoSQL-Ansätzen wie Dokumenten-Datenbanken und zeigt, warum unterschiedliche Persistenztechnologien zu unterschiedlichen Architekturen führen.

Lisa Maria Schäfer malt dieses Mal keine Sketchnotes.

Livestream am 23. Januar

Die Ausstrahlung findet am Freitag, 23. Januar 2026, live ab 13 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zu den Folgen finden sich auf der Videocast-Seite.

(mdo)

Wenn ich Kunden zu Domain-Driven Design (DDD) und Event Sourcing berate, gibt es einen Moment, der regelmäßig eintritt. Das Team wirkt selbstbewusst, vielleicht sogar ein wenig stolz. Sie sagen mir:

„Eigentlich arbeiten wir schon mit Events.“

Und dann zeigen sie mir ihre Events:

• UserCreated
• OrderUpdated
• InvoiceDeleted

Und innerlich zucke ich zusammen.

Denn das sind keine Events, sondern klassisches CRUD, nur eben mit Event-Syntax. Es hat die äußerliche Form von Events, aber keine innerliche Semantik. Und dieser Unterschied, so subtil er auch erscheinen mag, ist der Unterschied zwischen einem System, das die Sprache des Business spricht, und einem, das die Sprache von Datenbanken spricht.

Das Beispiel: Enterprise-Print-Management

Stellen wir uns einen Kunden vor, der sich mit Enterprise-Drucken beschäftigt. Die Software verwaltet Tausende von Druckern in großen Organisationen: in Krankenhäusern, Universitäten und Unternehmensbüros. Drucker müssen dem System hinzugefügt, für Wartungsarbeiten offline genommen, pausiert, fortgesetzt und schließlich entfernt werden, wenn sie außer Betrieb genommen werden.

Das Team hat etwas gebaut, das sie ein „Event-getriebenes System“ nennen. Und das sind ihre Events:

• PrinterCreated
• PrinterUpdated
• PrinterDeleted

Das war’s. Drei Events. Kommt Ihnen das bekannt vor?

Das ist CRUD in Verkleidung. Die Namen haben sich von INSERT, UPDATE und DELETE zu Created, Updated und Deleted geändert, aber die semantische Armut ist dieselbe. Wenn man sich ein PrinterUpdated-Event ansieht, was weiß man dann? Irgendetwas hat sich geändert. Aber was genau hat sich geändert? Dazu muss man in den Payload schauen. Warum hat es sich geändert? Keine Ahnung. War es eine geplante Wartungsmaßnahme oder ein unerwarteter Ausfall? Das Event verrät es nicht.

Das Mordproblem

Und mich erinnert das immer an ein etwas düsteres Beispiel (und die Ironie ist hoffentlich offensichtlich): Betrachten wir UserDeleted (was mir in der Praxis auch regelmäßig begegnet).

Sprechen Sie das mal laut und bewusst aus: UserDeleted. Es klingt, als hätte man die Nutzerin oder den Nutzer erfolgreich ermordet:

„Der Nutzer wurde eliminiert.“

Wäre das ein Krimi, würden die Ermittlerinnen und Ermittler sich jetzt Notizen machen.

Aber was wahrscheinlich gemeint war: AccountClosed. Oder UserDeactivated. Oder SubscriptionCancelled. Jedes davon hat eine andere Bedeutung, andere geschäftliche Implikationen, andere nachgelagerte Effekte. Aber CRUD-Sprache presst all diesen Reichtum in ein einziges, leicht morbides Verb.

Das ist nicht nur unpräzise. Es ist aktiv irreführend. CRUD-Sprache verliert nicht nur Information. Sie kann Events wie einen Polizeibericht klingen lassen.

Es fehlt die Wartungsfrage

Zurück zu unseren Druckern. Eine Wartungstechnikerin ruft beim Helpdesk an:

„Dieser Drucker im dritten Stock funktioniert nicht. Was ist passiert?“

Der Support-Mitarbeiter schaut auf den aktuellen Zustand in der Datenbank:

{ "printerId": "printer-3f-01",
"status": "offline"
}

Das ist alles, was er sieht. Der Drucker ist offline. Aber warum? Wann ging er offline? Wurde er manuell für Wartungsarbeiten offline genommen, oder ist er unerwartet ausgefallen? Ist das schon einmal passiert? Wie oft?

Mit CRUD-Events muss der Mitarbeiter nun Logs durchforsten, Zeitstempel korrelieren, vielleicht die Technikerin später zurückrufen. Jede Minute, die mit Nachforschungen verbracht wird, bedeutet verlorenes Geld und wachsende Frustration.

Das sind die versteckten Kosten semantischer Armut: Nicht nur verlorene Information, sondern verlorene Zeit, verlorener Kontext, verlorenes Vertrauen in das System.

Die semantische Alternative

Wie würden echte Events aussehen? Events, die erfassen, was tatsächlich passiert ist? In der Sprache der Domäne?

• PrinterAdded
• PrinterBecameOnline
• PrinterPaused
• PrinterResumed
• PrinterWentOffline
• PrinterRemoved

Beachten Sie die subtile, aber wichtige Verschiebung. Es heißt PrinterAdded, nicht PrinterCreated. Warum? Weil der Drucker in keinem sinnvollen Weg „erstellt“ wurde. Niemand hat einen Drucker hergestellt, indem eine Datenbankzeile eingefügt wurde. Der Drucker existierte bereits. Er war ein physisches Objekt, das in einem Karton lag, aus einer Fabrik geliefert. Was passiert ist: Er wurde dem System lediglich hinzugefügt.

Created ist CRUD-Sprache. Added ist Domänensprache. Der Unterschied zählt.

Genauso Removed statt Deleted: Der Drucker wurde nicht zerstört. Er steht wahrscheinlich irgendwo in einem Lagerraum und wartet darauf, neu zugewiesen zu werden. Er wurde aus der Verwaltung dieses Systems entfernt. Das ist passiert. Das sollte das Event sagen.

Die vollständige Historie

Spielen wir nun den Support-Anruf mit echten Events durch. Der Mitarbeiter ruft die Historie des Druckers auf:

2026-01-15 09:00 PrinterAdded
2026-01-15 09:05 PrinterBecameOnline
2026-01-16 14:30 PrinterPaused { "reason": "scheduled maintenance" }
2026-01-16 16:00 PrinterResumed
2026-01-17 11:45 PrinterWentOffline { "reason": "paper jam detected" }
2026-01-17 12:00 PrinterBecameOnline
2026-01-18 09:22 PrinterWentOffline { "reason": "connection lost" }

Jetzt kann er alles sehen:

• Der Drucker ging heute um 09:22 Uhr offline, weil die Verbindung verloren ging.
• Das ist das zweite unerwartete Offline-Event in zwei Tagen.
• Gestern war es ein Papierstau, heute ist es Konnektivität.
• Davor gab es eine geplante Wartungspause, die reibungslos verlief.

Die Technikerin muss in Konsequenz also nicht blind herumprobieren. Sie weiß, dass sie die Netzwerkverbindung prüfen muss, nicht das Papierfach. Sie kann ein Muster erkennen, weil das gleiche Problem in der Vergangenheit schon mit anderen Druckern aufgetreten ist: vielleicht versagt gerade die Netzwerkkarte dieses Druckers.

Das ist der Wert, den CRUD-Events nicht liefern können. Nicht nur „was ist der Zustand“, sondern „wie ist er dorthin gekommen“ und „was sagt uns dieses Muster“.

Events als natürliche Sprache

Das berührt etwas Grundlegenderes. In einem früheren Beitrag habe ich darüber geschrieben, wie niemand Geschichten mit CRUD erzählt. Man sagt nicht „Rotkäppchen wurde erstellt, dann aktualisiert, dann wurde die Großmutter gelöscht.“ Das ist absurd. Man erzählt die Geschichte durch Events: was passiert ist, in welcher Reihenfolge und warum es wichtig war.

Und in einem anderen Beitrag über DDD habe ich argumentiert, dass Domain-Driven Design unnötig kompliziert gemacht wurde. Die Essenz ist einfach: „Sprich die Sprache der Domäne!“ Aber wir haben diese Einfachheit unter Schichten von Patterns und Jargon begraben.

Hier ist der Zusammenhang: Wer gute Events formuliert, spricht automatisch die Sprache der Domäne. Man kann nicht PrinterPaused schreiben, ohne zu verstehen, dass Pausieren ein Konzept in dieser Domäne ist, unterschieden vom Offline-Gehen, unterschieden vom Entfernen. Der Akt des Benennens von Events zwingt dazu, Gespräche mit Domänenexpertinnen und -experten zu führen. „Wie nennen Sie es, wenn ein Drucker vorübergehend, aber absichtlich aufhört zu arbeiten?“ Diese Frage führt direkt ins Herz der Domäne.

Das ist DDD, ohne es DDD zu nennen. Keine Aggregates, keine Bounded-Contexts, keine einschüchternde Terminologie. Nur Events, die erfassen, was passiert, benannt so, wie das Business sie benennt.

Der Weg zu DDD führt durch Events

Das heißt mit anderen Worten: Event Sourcing ist ein Katalysator für Domain-Driven Design.

Kundinnen und Kunden DDD zu erklären ist schwer. Die Terminologie schüchtert ein. Die Konzepte sind abstrakt. Viele Entwicklerinnen und Entwickler (mich eingeschlossen) haben sich irgendwann „zu dumm“ für DDD gefühlt, erschlagen von der Theorie.

Aber Events zu erklären ist einfach. Jede und jeder versteht Events. „Was ist passiert?“ ist eine Frage, die Menschen stellen, seit es Sprache gibt. Und wenn man Teams dazu bringt, ihre Events präzise zu benennen, machen sie am Ende ganz natürlich DDD. Sie beginnen, die Sprache der Domäne zu sprechen. Sie beginnen, Gespräche mit Domänenexpertinnen und -experten zu führen. Sie beginnen, Systeme zu bauen, die die Realität widerspiegeln, statt Datenbanktabellen.

Wer also auf die eigenen Events schaut und überall Created, Updated und Deleted sieht, hat die Chance, nicht nur das Event-Modell zu verbessern, sondern ein Gespräch darüber zu beginnen, was im eigenen Business tatsächlich passiert. Wie nennt man es, wenn ein Drucker hinzugefügt wird? Wenn eine Nutzerin oder ein Nutzer geht? Wenn eine Bestellung storniert versus erstattet versus angefochten wird?

Die Antworten auf diese Fragen verraten mehr über die Domäne als jeder Musterkatalog es je könnte.

Wie es weitergehen kann

Wenn Ihnen das bekannt vorkommt, fangen Sie hier an: Schauen Sie sich Ihre Events an! Lesen Sie sie laut vor! Klingen sie wie Datenbankoperationen, oder klingen sie wie Dinge, die in Ihrem Business passieren?

Für einen tieferen Einblick in die Konzepte hinter DDD und Event-Sourcing erklären diese Einführungen in Domain-Driven Design und Event-Sourcing die Grundlagen.

Denn Events sollten eine Geschichte erzählen, keinen Polizeibericht.

(rme)