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)

In der populären JavaScript-Laufzeitumgebung Node.js wurden mehrere Sicherheitslücken entdeckt, die teils mit hohem Risiko eingestuft werden. Jetzt sind für bereits Mitte Dezember angekündigte aktualisierte Versionen erschienen, die die Schwachstellen ausbessern. Entwickler sollten sicherstellen, dass die fehlerbereinigten Fassungen zeitnah zum Einsatz kommen.

In der Ankündigung vom Dienstag dieser Woche schreiben die Node.js-Entwickler, dass die Updates drei Sicherheitslücken mit hohem Risiko, vier mit mittlerem und ein Leck mit niedriger Risikoeinstufung schließen. Angreifer können sie missbrauchen, um etwa eingeschleusten Schadcode auszuführen, ihre Rechte auszuweiten, Sicherheitsmaßnahmen zu umgehen und Daten zu manipulieren oder vertrauliche Informationen abzugreifen, wie das CERT-Bund zusammenfasst. Außerdem enthalten die Sicherheits-Releases aktualisierte Abhängigkeiten, um öffentlich bekannte Schwachstellen anzugehen, und zwar „c-ares“ in Version 1.34.6 und „undici“ in den Fassungen 6.23.0 und 7.18.0.

Hochriskante Sicherheitslücken

In der Programmlogik zum Allokieren von Puffern kann nicht initialisierter Speicher offengelegt werden, wenn das „vm“-Modul mit einem Timeout verwendet und die Allokierung des Speichers davon unterbrochen wird (CVE-2025-55131, CVSS 8.1, Risiko „hoch“). Die Restriktionen mit den Optionen --allow-fs-read und --allow-fs-write ließen sich außerdem durch das Zusammensetzen von relativen Symlink-Pfaden umgehen (CVE-2025-55130, CVSS 7.7, Risiko „hoch“). Ein präparierter „HTTP/2 HEADERS“-Frame mit übergroßen und ungültigen „HPACK“-Daten kann Node.js zum Abstürzen bringen, was in einem Denial-of-Service mündet (CVE-2025-59465, CVSS 7.5, Risiko „hoch“).

Details zu den mittelschweren sowie den als niedriges Risiko eingestuften Schwachstellen finden Interessierte in der Ankündigung der Node.js-Entwickler. Die Schwachstellen sind in den Versionen Node.js 25.3.0, 24.13.0, 22.22.0 und 20.20.0 sowie neueren nicht mehr vorhanden. Die Aktualisierungen sollten Nutzerinnen und Nutzer zeitnah vornehmen.

Im vergangenen September konnte ein Kryptowährungsdieb mit einer Spearphishing-Attacke Zugriff auf das npm-Konto eines Entwicklers erlangen – npm ist die Paketverwaltung für Node.js-Pakete. Damit gelang dem bösartigen Akteur, Schadcode in rund 20 Pakete des Entwicklers qix, die zusammen auf mehr als zwei Milliarden wöchentliche Downloads kommen.

(dmk)

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)