Linus Torvalds, der sich bislang eher kritisch zum Einsatz von KI geäußert hat, ist selbst unter die Vibe-Coder gegangen. Er ließ die künstliche Intelligenz, in diesem Fall Googles Antigravity AI, jedoch weder auf den Linux-Kernel noch auf Git los, sondern erstellte mit ihrer Hilfe ein Hobby-Programm namens AudioNoise.

Das auf GitHub gehostete Tool simuliert Gitarrenpedal-Effekte wie Echo oder Phaser, und Torvalds hat es in erster Linie entwickelt, um selbst die Grundlagen der digitalen Signalverarbeitung besser zu verstehen. Für etwa die Hälfte des Programmcodes nutze er C, für die Python-basierte Visualisierung der Audiosamples kam dann Antigravity zum Einsatz.

„Über analoge Filter weiß ich mehr – wenn auch nicht viel mehr – als über Python“, sagt Torvalds im Readme-File zu AudioNoise. Daher habe er anfangs noch nach dem Motto „googlen und nachmachen“ programmiert, sich dann aber immer mehr aus dem Python-Coding zurückgezogen und den Audio-Sample-Visualizer schließlich komplett von der Google-KI in deren Eigenregie entwickeln lassen.

Fazit: Bestenfalls für Spaßprojekte geeignet

Auch das Ergebnis lässt sich in der Readme-Datei nachlesen: „Das Python-Visualizer-Tool ist im Grunde durch Vibe Coding entstanden“, erklärt Torvalds darin. Und es macht, was es machen sollte. Er hatte am KI-generierten Code so wenig auszusetzen, dass er ihn ohne Änderungen übernommen hat.

Für die Kernel-Entwicklung oder andere seriöse Projekte sei Vibe Coding jedoch ungeeignet, sagte Torvalds auf dem Open Source Summit im November 2025. Dem Linux-Kernel-Chef wird auch das Zitat zugeschrieben, „Vibe“ sei eine Abkürzung von „Very inefficient but entertaining“.

Immer wieder stellen Studien fest, dass sich die Codequalität durch den zunehmenden Einsatz von KI-Assistenten verschlechtert. Auch das Problem der KI-Halluzinationen ist weiterhin ungelöst.

(who)

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)