Wer mit Events arbeitet, stößt früher oder später auf eine vermeintlich simple Frage: Wann ist etwas eigentlich passiert? Und die Antwort scheint naheliegend, denn jedes Event bringt schließlich einen Zeitstempel mit. Bei CloudEvents ist das etwa das time-Feld, das viele Systeme automatisch setzen, wenn ein Event gespeichert wird. Es liegt nahe, diesen Zeitstempel für Geschäftslogik zu verwenden, er ist ja schließlich da. Doch genau das führt zu subtilen Fehlern und falschen Annahmen.

Das Problem: Wann wurde das Buch ausgeliehen?

Nehmen wir ein klassisches Bibliotheksbeispiel. Ein Leser leiht ein Buch aus, und das System erzeugt folgendes Event:

{
"source": "
"subject": "/books/42",
"type": "io.thenativeweb.library.book-borrowed",
"data": {
"borrowedBy": "/readers/23",
"borrowedUntil": "2026-02-12"
}
}

Fällt Ihnen etwas auf? Das Event enthält borrowedUntil (das Rückgabedatum), aber kein borrowedAt. Wer wissen will, wann das Buch tatsächlich ausgeliehen wurde, müsste auf den technischen Zeitstempel des Events zurückgreifen.

Aber hier liegt das Problem: Was, wenn der Leser das Buch bereits um 14:00 Uhr ausgeliehen hat, das System das Event aber erst um 14:02 Uhr geschrieben hat? Oder wenn der Bibliothekar die gestrigen Ausleihen erst heute Morgen eingetragen hat? Der technische Zeitstempel sagt uns, wann das Event gespeichert wurde, und nicht, wann die Ausleihe tatsächlich stattgefunden hat.

Warum technische Zeitstempel keine Geschäfts-Zeitstempel sind

Es gibt mehrere Gründe, warum der technische Zeitstempel für Geschäftslogik problematisch ist. Ein technischer Zeitstempel beschreibt, wann das System etwas getan hat. Ein Geschäfts-Zeitstempel beschreibt, wann etwas in der realen Welt passiert ist. Das sind zwei grundlegend verschiedene Konzepte und sie zu vermischen, kann zu subtilen Fehlern führen.

Das time-Feld eines Events beantwortet die Frage:

„Wann wurde dieses Event aufgezeichnet?“

Die fachliche Anforderung lautet aber oft:

„Wann ist das wirklich passiert?“

Das ist nicht dieselbe Frage. Und wichtig: Es geht hier nicht um Präzision oder Latenz, es geht vielmehr um Semantik.

Hinzu kommt: Ob ein Zeitstempelfeld überhaupt existiert, hängt vom Event-Format ab. CloudEvents enthält ein time-Feld, andere Formate aber möglicherweise nicht. Wer Events jemals in ein anderes Format konvertieren muss (etwa für Archivierung, Export oder Integration in andere Systeme), riskiert, dass der technische Zeitstempel verloren geht. Wenn Geschäftslogik von einem Feld abhängt, das bei einer Migration verschwinden könnte, baut man auf instabilem Grund.

Und das vielleicht stärkste Argument: Events werden häufig erst nach dem eigentlichen Ereignis aufgezeichnet. Ein paar Beispiele:

• Ein Bibliothekar stellt fest, dass jemand die gestrige Ausleihe mit dem falschen Datum eingetragen hat. Das Korrektur-Event schreibt er heute, obwohl es sich aber auf etwas bezieht, das gestern passiert ist.
• Eine mobile Bibliotheks-App erfasst eine Ausleihe, während das Gerät offline ist. Wenn es sich Stunden später synchronisiert, wird das Event erst dann persistiert, aber die eigentliche Ausleihe fand viel früher statt.
• Die Datenmigration aus einem Legacy-System importiert Jahre historischer Events. Die technischen Zeitstempel würden alle das heutige Datum zeigen und historische Analysen wertlos machen.
• Wenn das Zielsystem vorübergehend nicht erreichbar war, werden Events möglicherweise zwischengespeichert und später geschrieben. Der technische Zeitstempel zeigt den Schreibzeitpunkt, nicht das ursprüngliche Ereignis.

In all diesen Fällen liefert der technische Zeitstempel falsche Antworten für die Geschäftslogik.

Die Lösung: Zeit explizit machen

Das heißt: Wenn Zeit für das Geschäft relevant ist, gehört sie in die Event-Daten. Hier die verbesserte Version des Ausleihe-Events:

{
"source": "
"subject": "/books/42",
"type": "io.thenativeweb.library.book-borrowed",
"data": {
"borrowedBy": "/readers/23",
"borrowedAt": "2026-01-12T14:00:00.000Z",
"borrowedUntil": "2026-02-12"
}
}

Jetzt ist die Semantik klar:

• borrowedAt: Wann das Buch tatsächlich ausgeliehen wurde (Geschäftszeit)
• borrowedUntil: Wann das Buch zurückgegeben werden muss (Geschäftszeit (das war schon korrekt))
• Event-Zeitstempel: Wann das System dieses Event aufgezeichnet hat (technische Zeit)

Interessant ist, dass borrowedUntil bereits ein Geschäftszeit-Feld war. Es fehlte nur das Gegenstück borrowedAt. Diese Inkonsistenz ist typisch: Entwickler denken oft daran, zukünftige Zeitpunkte aufzunehmen (Fristen, Fälligkeiten, Ablaufdaten …), vergessen aber gerne die vergangenen Zeitpunkte, also wann etwas tatsächlich geschehen ist.

Weitere Beispiele

Das Muster lässt sich auf andere Events übertragen:

• book-borrowed mit borrowedAt: Wann das Buch ausgeliehen wurde
• book-returned mit returnedAt: Wann das Buch zurückgegeben wurde
• reader-registered mit registeredAt: Wann sich der Leser angemeldet hat
• late-fee-charged mit chargedFor: Welchen Zeitraum die Gebühr abdeckt

Jedes dieser Felder beschreibt, wann etwas in der realen Welt passiert ist, unabhängig davon, wann das System es aufgezeichnet hat.

Wann der technische Zeitstempel akzeptabel ist

Heißt das, man sollte den technischen Zeitstempel komplett ignorieren? Nein. Es gibt legitime Verwendungszwecke: Debugging, um die Reihenfolge der Event-Persistierung nachzuvollziehen. Monitoring, um Systemlatenz und Durchsatz zu messen. Audit-Trails, um zu dokumentieren, wann Datensätze ins System gelangt sind.

Aber das sind alles technische Belange, keine fachlichen.

Und was ist mit dem technischen Zeitstempel als Fallback, wenn man vergessen hat, ein Geschäftszeit-Feld hinzuzufügen? Das ist ein Workaround, keine Lösung. Wer sich in dieser Situation wiederfindet, sollte erwägen, eine neue Version des Event-Typs einzuführen, die das explizite Zeitfeld enthält. Ja, dann muss man beide Versionen verarbeiten können, aber man gewinnt Klarheit und Korrektheit für die Zukunft.

Man sollte auch nicht versuchen, das Ganze mit

„die Latenz ist klein genug“

oder

„wir brauchen keine hohe Präzision“

zu beschönigen. Diese Argumente verfehlen den Punkt. Es geht nicht um Latenz oder Präzision, sondern es geht um semantische Klarheit. Ein technischer Zeitstempel und ein Geschäfts-Zeitstempel beantworten unterschiedliche Fragen, unabhängig davon, wie nah ihre Werte beieinander liegen mögen.

Fazit

Zeit wirkt einfach, bis man genauer hinschaut. Bei der Arbeit mit Events ist die Unterscheidung zwischen „wann etwas passiert ist“ und „wann das System es aufgezeichnet hat“ fundamental. Wer diese Grenze verwischt, riskiert subtile Bugs, fehlerhafte Reports und Systeme, die die Realität nicht korrekt abbilden.

Die Lösung ist einfach: Wenn Zeit für das Geschäft relevant ist, gehört sie explizit in die Event-Daten. Das zukünftige Ich (und alle, die diese Events später analysieren müssen) werden es danken.

(who)

Will man „Harry Potter und der Stein der Weisen“ lesen, hat aber sein Buch verlegt, so ließen sich große Teile des Buchs mit den passenden Prompts wortwörtlich aus großen Sprachmodellen (LLMs) wie Claude 3.7 Sonnet, Gemini 2.5 Pro oder Grok 3 extrahieren. Das geht aus einem Preprint auf arXiv hervor, den Forscher der Stanford University veröffentlicht haben.

Ziel ihrer Studie war es, herauszufinden, ob die gut abgesicherten produktiven Sprachmodelle großer Anbieter urheberrechtsgeschützte Werke aus ihren Trainingsdaten Wort für Wort wiedergeben können. Denn laut der Anbieter der LLMs lernen die Modelle während des Trainings die Daten eben nicht auswendig, sondern höchstens eine Repräsentation der Inhalte – weswegen das Modelltraining transformativ sei und das Verwenden von geschützten Werken unter Fair Use fiele. Der Stand der Forschung lässt diese Annahme wanken.

Trainingsdaten aus LLMs kitzeln

Da sich große Abschnitte von urheberrechtsgeschützten Werken aus Open-Weight-Modellen extrahieren lassen, wollten die Forscher diese Eigenheit der LLMs testen. Geprüft haben sie die proprietären und mit besseren Sicherheitsmaßnahmen versehenen Modellen Claude 3.7 Sonnet, GPT-4.1, Gemini 2.5 Pro und Grok 3 – allesamt Modelle, die in Produktion sind oder waren. Dafür gingen die Wissenschaftler in zwei Phasen vor. Zuerst fragten sie nach einer wortwörtlichen Fortführung eines Textabschnitts, also etwa nach dem Anfang von Kapitel 1 des ersten Harry-Potter-Romans. Bei einer Ablehnung variierten sie den Wortlaut des Prompts mit zufälligen Änderungen, bis sie ein Ergebnis erhielten oder das Modell nach 10.000 Variationen weiter ablehnte. Die verwendete Technik heißt Best-of-N (BoN) und gilt als Jailbreak, also als das Umgehen der Sicherheitsmaßnahmen der Sprachmodelle.

Im zweiten Schritt fragten die Forscher das Modell dann wiederholt, den Text anhand des bisher generierten Abschnittes weiter zu vervollständigen. Die Ähnlichkeit des Texts verglichen sie anhand eines Referenz-Buchs und der Metrik near-verbatim recall (nv-recall) anhand des längsten gleichen Textabschnitts. Das ergab für das erste Harry-Potter-Buch eine Textähnlichkeit von 95,8 Prozent für Claude 3.7 Sonnet, sowie 76,8 und 70,3 Prozent für Gemini 2.5 Pro und Grok 3. GPT 4.1 verweigerte die Zusammenarbeit, der nv-recall Wert für Harry Potter lag bei vier Prozent.

Studie verstärkt den Forschungsstand

Die Stanford-Forscher berichten, dass sie für Claude 3.7 Sonnet und GPT-4.1 den BoN-Jailbreak einsetzen mussten, um das Modell zu einem Ergebnis zu bewegen. Dafür gab Claude dann vier Bücher fast vollständig wortwörtlich wieder, darunter „Harry Potter und der Stein der Weisen“ und „1984“. Gemini 2.5 und Grok 3 befolgten die Anweisung ohne weiteres Prompt Engineering. Die Arbeit zieht den Schluss, dass große Sprachmodelle entgegen der Behauptung der Modellanbieter Teile ihrer Trainingsdaten auswendig lernen. Die bisherigen Sicherheitsbeschränkungen auf Modell- und Systemlevel würden dabei nicht ausreichen, um die Trainingsdaten der Modelle vor der Extraktion zu schützen.

Der arXiv-Preprint schließt an eine ähnliche Arbeit aus Stanford aus Mai 2025 an, die die Wiedergabe von ganzen Büchern in Open-Weight-Modellen wie Llama 3.1 untersuchte. Eine Arbeit von Forschern der ETH Zürich von November 2024 zeigt, dass bis zu 15 Prozent der Ausgaben von LLMs der Anbieter OpenAI, Anthropic, Google und Meta vorhandenen Textabschnitten im Internet entspricht. Die Modelle wiederholen in manchen Fällen wortwörtlich Antworten aus ihren Trainingsdaten. Das wirft Sicherheitsfragen für Unternehmen mit eigenen Modellen auf, die sich von Dritten bedienen lassen. Auch das Training mit synthetischen Daten könnte sich in so einem Fall als Quelle für weitere Halluzinationen erweisen.

LLM-Anbieter und Urheberrechte

Für die Anbieter großer Sprachmodelle ist das direkte Zitat von nicht-lizenzierten urheberrechtlich geschützten Werken dann ein Ärgernis, wenn die Urheber deswegen klagen. In den Vereinigten Staaten befindet sich die New York Times (NYT) in einem mehrjährigen Rechtsstreit mit OpenAI, da es dem Verlag gelang, mit einer ähnlichen Methode wie im Stanford-Preprint ganze Artikel aus ChatGPT zu extrahieren. In einer Stellungnahme vertrat OpenAI den Standpunkt, dass die NYT sich irreführender Prompts bedient habe und kein Nutzer die Modelle so verwenden würde. Außerdem sei die wortwörtliche Wiedergabe ein seltener Bug. Zumindest dem widerspricht der aktuelle Stanford-Preprint.

Gegenüber der GEMA unterlag OpenAI bereits vor Gericht. Die Verwertungsgesellschaft hatte geklagt, dass ChatGPT Songtexte von Liedern wie Atemlos oder Männer auf Anfrage fast exakt wiedergegeben habe, was die Rechte der Urheber verletze. Während OpenAI sich auf die Reflexion von Trainingsparametern berief, entschied das Gericht, dass das Modell die Texte auswendig gelernt haben müsse und untersagte das Speichern von urheberrechtlich geschützten Texten für die Zukunft. Ebenfalls mit dem auswendigen Wiedergeben von Trainingsdaten hatten Entwickler in einer Sammelklage in den USA gegen Microsoft, GitHub und OpenAI argumentiert. Die Klage besagte, dass GitHub Copilot wortwörtlich Code aus bestehenden Repositorys ohne Hinweise auf die Quelle ausgebe. Hier entschied das zuständige Gericht zugunsten der Modellanbieter.

(pst)

Microsoft hat Visual Studio Code 1.108 veröffentlicht. Traditionell nutzt Microsoft den Dezember für Aufräumarbeiten statt für ein reguläres Release, doch in diesem Jahr gibt es offenbar zwölf statt elf Releases. Dabei haben die VS-Code-Entwickler die Tradition beibehalten, im Dezember Issues und Pull Requests aufzuräumen: Rund 6000 davon wurden geschlossen, und darüber hinaus sind einige Feature-Updates in das Dezember-Update eingeflossen.

Profile importieren per Drag & Drop

Es ist nun möglich, Einstellungsprofile per Drag & Drop einer .code-profile-Datei in VS Code zu ziehen, ähnlich wie bei einer .code-workspace-Datei zum Öffnen eines Workspace. Dann öffnet sich der Profile-Editor, der eine Vorschau zeigt und das Importieren des Profils ermöglicht. Das soll es vereinfachen, Profile mit Teammitgliedern zu teilen oder schnell eine neue Umgebung aufzusetzen.

Spezialisierte Skills für den KI-Agenten

Als experimentelles Feature lassen sich Agent Skills in GitHub Copilot verwenden. Entwicklerinnen und Entwickler können dem KI-Agenten dadurch neue Fähigkeiten beibringen und ihn beispielsweise mit domänenspezifischem Wissen füttern. Agent Skills bestehen aus Ordnern mit Anweisungen, Skripte und Ressourcen, die GitHub Copilot bei Bedarf laden kann. Sie sind ein offener Standard und wurden ursprünglich vom Unternehmen Anthropic entwickelt.

Zu den Vorteilen zählen laut Microsoft die Kombinierbarkeit mehrerer Skills für das Erstellen komplexer Workflows, die Spezialisierungsmöglichkeit für domänenspezifische Aufgaben ohne wiederholenden Kontext und das effiziente Laden ausschließlich relevanter Inhalte. Die Skills können zudem Wiederholungen vermeiden, da sie sich über alle Unterhaltungen hinweg verwenden lassen.

Das Erstellen und Verwenden von Agent Skills behandelt die VS-Code-Dokumentation im Detail. Dort kommen auch die Unterschiede zwischen den Agent Skills und den VS-Code-spezifischen benutzerdefinierten Anweisungen (Custom Instructions) zur Sprache.

Neuerungen in Agent-Sessions- und Chat-Ansicht

Die Agent-Sessions-Ansicht wurde überarbeitet: Sie bietet nun Keyboard-Zugang zu Aktionen wie „Archivieren“, „State lesen“ und „Session öffnen“, zeigt Informationen zu geänderten Dateien sowie zugehörigen Pull Requests für eine Session und kann aus den neuen Gruppenabschnitten heraus mehrere Sessions auf einmal archivieren.

Neuerungen gibt es auch im Chat. Unter anderem werden nun vorherige Chat-Sessions nicht automatisch wiederhergestellt, wenn VS Code neu gestartet wird. Allerdings lassen sich aus der Agent-Sessions-Steuerung frühere Chat-Sessions aufrufen. Dieses neue Verhalten lässt sich in der Einstellung chat.viewRestorePreviousSession anpassen.

Hausputz im Dezember

Im Rahmen des jährlichen Dezember-Housekeeping hat das VS-Code-Entwicklungsteam dieses Mal 5951 offene Issues und Pull Requests geschlossen. Für weitere 1203 Issues wurde eine Triage durchgeführt, sodass diese nicht länger unter „Unknown Type“ laufen.

Alle weiteren Informationen zu den Neuerungen in VS Code 1.108 teilt das Entwicklungsteam in der Ankündigung mit.

(mai)