Mit über 90.000 Contributors und rund 4,4 Millionen Contributions ist Kubernetes nach Linux das zweitgrößte Open-Source-Projekt weltweit. Hierzulande stuft mittlerweile auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) Kubernetes als De-facto-Standard für Container-Orchestrierung ein. Doch wie funktioniert ein Projekt dieser Größenordnung eigentlich von innen? Im Rahmen des Cloud-Native-Festivals CloudLand 2025 hat Mario Fahlandt, der im Kubernetes-Projekt unter anderem in den Special Interest Groups (SIG) Contributor Experience und K8s Infra aktiv ist, einen detaillierten Einblick in die Strukturen, Einstiegsmöglichkeiten und Karrierepfade der Kubernetes-Community gegeben.

Fahlandt, der selbst als Host für die EMEA/APAC-Region bei der Kubernetes New Contributor Orientation (NCO) fungiert, machte in seinem Vortrag deutlich: Beiträge zum Projekt beschränken sich keineswegs auf Code. Meeting-Notizen anfertigen, Fragen im Slack-Channel beantworten, Dokumentationen korrigieren oder Blog-Posts verfassen – all das zählt als Contribution.

(Bild: cloudland.org)

Vom 19. bis 22. Mai 2026 finden Interessierte beim Cloud-Native-Festival CloudLand ein prall gefülltes Line-up mit mehr als 200 Highlights – darunter die beiden neuen Themenbereiche „Open Source“ und „Platform Engineering“ mit einer bunten Mischung überwiegend interaktiver Sessions, Hands-ons und Workshops.

Tickets für das Festival und Unterkünfte im Heide Park Soltau lassen sich über die Festival-Homepage buchen.

Drei Kategorien von Special Interest Groups

Die Community organisiert sich unter dem Dach der Cloud Native Computing Foundation (CNCF) in einer ausdifferenzierten Struktur. An der Spitze steht ein Steering Committee mit sieben gewählten Mitgliedern. Die eigentliche Arbeit findet in 24 Special Interest Groups (SIGs) statt, die sich in drei Kategorien gliedern: Project-SIGs wie Architecture, Docs oder Release unterstützen das Gesamtprojekt organisatorisch. Horizontal-SIGs – darunter API-Machinery, Auth oder Scalability – kümmern sich um querschnittliche Kernfunktionalität. Vertical-SIGs wie Network, Storage oder Node verantworten jeweils spezifische technische Komponenten. Ergänzt wird diese Struktur durch sieben Working Groups für temporäre Themen und drei Committees. Jeder Code- und Dokumentationsteil ist dabei einer konkreten SIG oder einem Subproject zugeordnet.

Wer sollte sich engagieren und wie gelingt der Einstieg?

Wer einsteigen möchte, findet über den Kubernetes-Slack (Kanal #kubernetes-new-contributors), die K-Dev-Mailingliste und den Community-Kalender Anschluss. Die monatliche NCO-Session findet jeweils am dritten Dienstag statt – für die EMEA/APAC-Region beispielsweise um 10:30 Uhr CET. Die Sessions laufen seit September 2024 und werden auch 2026 fortgesetzt.

Die Contributor Ladder als Karrierepfad

Fahlandt zufolge definiert die sogenannte Contributor Ladder einen transparenten Aufstiegspfad. Vom Non-member Contributor gelangt man über die Org-Membership – für die zwei bestehende Reviewer bürgen müssen – zum Reviewer, Approver und schließlich zum Subproject Owner oder SIG Chair. Fahlandt warnte allerdings vor einer typischen Einstiegsfalle: Wer sich isoliert ein „Good First Issue“ aus dem Repository schnappt und ohne Kontakt zur jeweiligen SIG daran arbeitet, scheitert häufig. Labels wie „good first issue“ oder „help wanted“ in Repositories wie kubernetes/kubernetes markieren zwar geeignete Aufgaben – etwa Dokumentationsverbesserungen, Link-Korrekturen oder Test-Ergänzungen. Doch der Schlüssel zum Erfolg liegt darin, zunächst einer SIG beizutreten, an deren Meetings teilzunehmen und sich dauerhaft einzubringen. Besonders niedrigschwellig sind sogenannte Evergreen-Aufgaben wie Meeting-Protokolle, SIG-Spotlight-Blogposts oder Reviews für die SIG Docs.

Lesen Sie auch

c’t-Workshop: Kubernetes im Blick: Observability mit Grafana LGTM meistern

Mastering GitOps: Praxiswissen von Argo-CD-Fallstricken bis OCI-Patterns

KubeCon EU 2026: Kubernetes wird erwachsen – BSD, eBPF und mTLS

KubeCon EU 2026: Kubernetes wird weiter als Infrastruktur für KI optimiert

Kubermatic SecureGuard: Automatisiertes Secrets-Management für Kubernetes

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

Claude Code geleakt: Milliarden für KI-Sicherheit, null für Softwarehygiene

2026-04-02T08:49:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kein Hack, kein Exploit – nur ein vergessener Schalter. Und genau dieses Prozessversagen macht den Claude-Code-Leak so gefährlich, meint Moritz Förster.

(Bild: Stockinq/Shutterstock.com)

10:49 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

Es klingt nach dem nächsten großen Skandal: Über 500.000 Zeilen Quellcode von Anthropics CLI-Tool Claude Code tauchen öffentlich auf. Die Security-Community horcht auf, Wettbewerber reiben sich die Hände, Kommentatoren wittern den nächsten Beweis, dass KI eh an allem schuld ist. Doch wer genauer hinschaut, findet keine ausgeklügelte Attacke, keinen Zero-Day-Exploit, nicht einmal Social Engineering. Sondern schlicht eine Source Map im npm-Paket, die da nicht hingehörte. Also bloß ein vergessener Schalter in der Build-Pipeline. System scheint hier nur die Schludrigkeit zu haben.

Moritz Förster schreibt seit 2012 für die iX und heise online. Er betreut neben dem iX-Channel den Bereich Arbeitsplatz.

Debug-Artefakte im Produktions-Build – ein Klassiker

Source Maps sind nützliche Helfer in der Entwicklung. Sie bilden kompilierten Code zurück auf den lesbaren Quelltext – unverzichtbar beim Debuggen, fatal in der Produktion. Dass sie im fertigen Paket landen, passiert nicht durch einen raffinierten Angriff oder eine ausgerastete KI. Es passiert, weil niemand den Build-Prozess sauber konfiguriert hat. Oder weil die Konfiguration irgendwann still und leise überschrieben wurde. Oder weil schlicht niemand nachgeschaut hat.

Entwickler kennen das Muster. Es ist die vergessene .env-Datei im Git-Repository. Das Docker-Image mit eingebetteten Credentials. Die Debug-API, die seit Monaten offensteht, weil sie ja „nur intern“ ist. Genau das ist Prozessversagen.

Lesen Sie auch

Anthropics Claude Code: Kompletter Quellcode im Netz

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

Visual Studio 2026 erlaubt das Erstellen benutzerdefinierter KI-Agenten

2026-04-02T07:32:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die neuesten Features umfassen das Erstellen spezialisierter Copilot-Agenten, das Festlegen von Agent Skills und das Beheben von NuGet-Vulnerabilities per KI.

(Bild: tadamichi / Shutterstock.com)

09:32 Uhr

Lesezeit: 2 Min.

Developer

Von

Maika Möbus

Microsoft hat seine Entwicklungsumgebung Visual Studio 2026 im März mit neuen Features versehen, die sich vor allem um Künstliche Intelligenz (KI) drehen. Alle neuen Funktionen sind in der Insiders-Version verfügbar.

Agent Skills und benutzerdefinierte Agenten

In Visual Studio können Entwicklerinnen und Entwickler nun benutzerdefinierte Copilot-Agenten erstellen. Diese können beispielsweise den Coding-Standards des Teams folgen oder interne Dokumentation durchsuchen. Die spezialisierten Copilot-Agenten können Zugriff auf Workspace-Awareness, Codeverständnis, Tools, das bevorzugte Modell und Verbindungen via Model Context Protocol (MCP) zu externen Wissensquellen erhalten.

Dazu spezifizieren Entwickler die gewünschten Anpassungen in einer .agent.md-Datei, fügen diese im Repository zu .github/agents/ hinzu und können dann den neuen Agenten im Agent Picker auswählen. Wurde kein Modell festgelegt, verwendet der KI-Agent das im Model Picker gewählte Modell.

Videos by heise

Mit Skills lassen sich die KI-Agenten ebenfalls versehen. Die Agenten beziehen Skills automatisch aus verschiedenen Stellen im Repo, etwa .github/skills/, oder aus dem User-Profil, etwa ~/.copilot/skills/. Jeder Skill besitzt ein eigenes Verzeichnis mit einer SKILL.md-Datei, die der Agent-Skill-Spezifikation entspricht. Agent Skills sind ein offenes Format, um KI-Agenten mit spezialisiertem Wissen auszustatten.

Copilot behebt NuGet-Vulnerabilities

Der KI-Copilot kann nun auch dabei helfen, Vulnerabilities zu beheben. Direkt aus dem Solution Explorer heraus können Entwicklerinnen und Entwickler die Benachrichtigung „Fix with GitHub Copilot“ anwählen, wenn eine Vulnerability erkannt wurde, die NuGet betrifft, das Paketverwaltungssystem für .NET. Beim Durchklicken analysiert Copilot die Schwachstelle und kann entsprechende Dependency-Updates empfehlen sowie implementieren.

Die neue Option „Fix with Copilot“ soll NuGet-Vulnerabilities beheben.

(Bild: Microsoft)

Weitere Updates betreffen unter anderem die Verwendung von MCP: Admins können festlegen, welche MCP-Server innerhalb ihrer Organisation erlaubt sind, und nur diese lassen sich dann in Visual Studio verwenden. Bei anderen Servern erscheint eine Fehlermeldung.

Die neuen Features lassen sich im Insiders-Build nutzen. Weitere Informationen zu den Updates liefert Microsofts Entwicklerblog.

Lesen Sie auch

Visual Studio 2026: KI-Agenten, besseres Debugging und C++-Migration

Microsoft: XAML Studio ist jetzt Open Source

Microsoft: Visual Studio erhält kürzere Releasezyklen

Uno Platform Studio 2.0 und Uno Platform 6.4: KI-Assistent und .NET-10.0-Support

Visual Studio 2022: Im Oktober-Update erinnert sich Copilot an frühere Wünsche

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

Event Sourcing trifft MCP: Die ganze Geschichte für LLMs

2026-04-02T07:15:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Event Sourcing liefert LLMs den reichhaltigsten Kontext. Das Model Context Protocol macht diesen Kontext über eine Standardschnittstelle zugänglich.

(Bild: Jirsak / Shutterstock.com)

09:15 Uhr

Lesezeit: 14 Min.

Developer

Von

Golo Roden

Im vergangenen August habe ich an dieser Stelle argumentiert, dass Event Sourcing die perfekte Grundlage für KI sei. Die Kernthese lautete: Ohne vollständige, kontextreiche Daten bleibt jedes noch so leistungsfähige Modell blind. Event Sourcing liefert genau diese Daten, weil es nicht nur den aktuellen Zustand speichert, sondern die gesamte fachliche Geschichte. An der These hat sich nichts geändert. Doch eine Frage blieb damals offen: Wie macht man diese Daten für ein Large Language Model zugänglich?

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Seit knapp anderthalb Jahren existiert mit dem Model Context Protocol (MCP) ein offener Standard, der LLMs mit beliebigen externen Datenquellen verbindet. Damit lässt sich die Lücke zwischen dem, was ein Event-Store an Daten bereithält, und dem, was ein Sprachmodell davon sehen kann, elegant schließen. Dieses Zusammenspiel verdient einen genaueren Blick.

Warum Kontext für LLMs alles entscheidet

Wer mit Large Language Models arbeitet, lernt schnell eine wichtige Lektion: Die Qualität der Antworten hängt weniger vom Modell ab als vom Kontext, den man ihm gibt. Ein durchschnittliches Modell mit hervorragendem Kontext liefert bessere Ergebnisse als ein Spitzenmodell, dem der Kontext fehlt. Das gilt für einfache Prompts ebenso wie für komplexe Analysen über Unternehmensdaten.

Kontext bedeutet hier nicht nur die Frage, die man stellt, sondern vor allem auch die Daten, auf die das Modell zugreifen kann. Und genau hier liegt das Problem: Die meisten Datenbanken speichern ausschließlich den aktuellen Zustand. Eine relationale Datenbank verrät Ihnen, dass eine Kundin den Status „Premium“ hat. Sie verrät aber nicht, seit wann, warum oder welche Interaktionen dazu geführt haben. Sie zeigt, dass ein Produkt 9,99 Euro kostet, nicht jedoch, ob dieser Preis gestern gesenkt wurde oder seit zehn Jahren unverändert ist. Sie zeigt, dass eine Bestellung den Status „offen“ hat, nicht jedoch, ob sie dreimal geändert, einmal storniert und dann erneut aufgegeben wurde.

Für ein LLM ist das, als würde man ihm ein Buch reichen, in dem nur das letzte Kapitel steht. Es kann den aktuellen Zustand beschreiben, aber keine Zusammenhänge erklären, keine Muster erkennen, keine Entwicklungen nachvollziehen. Es fehlt schlicht die Geschichte, die in den vorangegangenen Kapiteln erzählt wurde.

Event Sourcing löst dieses Problem grundlegend. Statt den Zustand zu speichern und bei jeder Änderung zu überschreiben, werden die einzelnen Zustandsänderungen als fachliche Ereignisse festgehalten. Jedes Ereignis beschreibt, was passiert ist, wann es passiert ist und in welchem fachlichen Kontext es steht. Die Summe aller Ereignisse ergibt nicht nur den aktuellen Zustand, sondern die vollständige, chronologische und unveränderliche Geschichte. Aus dem letzten Kapitel wird das gesamte Buch.

MCP als universelle Brücke

Die beste Datengrundlage nützt allerdings wenig, wenn ein LLM nicht darauf zugreifen kann. Bislang erforderte die Anbindung externer Datenquellen an ein Sprachmodell in der Regel individuelle Integrationen: eigene APIs, eigenen Glue-Code, eigene Wartung. Für jede Kombination aus Datenquelle und LLM musste eine eigene Lösung gebaut werden. Das skaliert schlecht und schafft Abhängigkeiten, die sich im Laufe der Zeit zu einer ernsthaften technischen Schuld entwickeln.

Das Model Context Protocol ändert das: MCP ist ein offener Standard, den Anthropic im November 2024 vorgestellt hat und der inzwischen breite Unterstützung durch zahlreiche Anbieter genießt. Auch OpenAI, Google und andere große Anbieter haben sich dem Standard angeschlossen. MCP definiert eine einheitliche Schnittstelle zwischen LLMs und externen Datenquellen. Ein MCP-Server stellt Werkzeuge und Daten bereit, die ein LLM über einen MCP-Client nutzen kann. Die Interaktion erfolgt in natürlicher Sprache: Das Modell formuliert Anfragen, der Server liefert die passenden Daten. Das Ganze geschieht über ein standardisiertes Protokoll auf Basis von JSON-RPC, sodass weder auf Client- noch auf Server-Seite proprietäre Technik erforderlich ist.

Das Entscheidende an MCP ist seine Datenquellenagnostik. Der Standard definiert, wie die Kommunikation abläuft, nicht jedoch, welche Art von Daten dahintersteckt. Ob ein MCP-Server eine relationale Datenbank, ein Dateisystem, eine API oder einen Event-Store anbindet, spielt auf Protokollebene keine Rolle. Inzwischen existieren MCP-Server für Dutzende von Systemen: von GitHub über Slack bis hin zu Datenbanken verschiedenster Art.

Die Frage, die MCP nicht beantwortet, ist deshalb umso wichtiger: Welche Qualität haben die Daten, die über diesen Kanal fließen? Wenn MCP die Brücke zwischen LLM und Datenquelle ist, dann entscheidet die Datenquelle darüber, wie tragfähig diese Brücke sein kann. Eine über MCP angebundene CRUD-Datenbank liefert weiterhin nur Snapshots. Ein Event-Store hingegen liefert die ganze Geschichte.

Was ein LLM in einer Bibliothek sehen kann

Um das greifbar zu machen, hilft ein konkretes, von mir regelmäßig genutztes Beispiel, das eine öffentliche Bibliothek als Domäne modelliert. Die zugehörigen Events sind überschaubar und dennoch fachlich reichhaltig: Ein BookAcquired-Event beschreibt die Anschaffung eines neuen Buches mit Titel, Autorin oder Autor und ISBN. BookBorrowed dokumentiert die Ausleihe, BookReturned die Rückgabe. Auf der Seite der Leserinnen und Leser gibt es ReaderApplied für die Anmeldung und ReaderAccepted für die Freischaltung des Bibliotheksausweises. Geht es an die konkrete Implementierung, greife ich auf den CloudEvents-Standard zurück, der ein fachlich benanntes Typenfeld und eine umgekehrte Domain-Schreibweise wie io.eventsourcingdb.library.book-borrowed vorsieht. Jedes Buch und jede Leserin beziehungsweise jeder Leser bildet dabei ein eigenes Subject, also einen eigenen Event-Stream, der die jeweilige Geschichte vollständig abbildet.

Stellen Sie sich nun vor, ein LLM hätte über einen MCP-Server Zugriff auf den Event-Store dieser Stadtbibliothek. Es könnte die vorhandenen Subjects durchsuchen, also die einzelnen Bücher sowie Leserinnen und Leser identifizieren. Es könnte die Event-Typen auflisten und so die Struktur der Domäne verstehen, ohne dass jemand sie erklären müsste. Und es könnte gezielt Fragen beantworten, die mit einer CRUD-Datenbank schwer oder gar nicht zu beantworten wären.

„Welche Bücher wurden in den letzten zwölf Monaten angeschafft, aber noch nie ausgeliehen?“

Diese Frage erfordert die Kenntnis, dass ein Buch existiert (BookAcquired), und die Abwesenheit eines bestimmten Folgeereignisses (BookBorrowed). In einer CRUD-Datenbank müsste dafür ein eigens gepflegtes Feld existieren, das bei jeder Änderung korrekt aktualisiert wird. Im Event-Store ergibt sich die Antwort direkt aus der Ereignisfolge.

„Zeige mir die vollständige Ausleihhistorie von Leserin 23.“

In einer CRUD-Datenbank sehen Sie bestenfalls, welches Buch die Leserin gerade ausgeliehen hat. Im Event-Store sehen Sie jede einzelne Ausleihe, jede Rückgabe, jede verspätete Rückgabe und jede erhobene Gebühr. Das LLM kann daraus Muster ableiten, etwa ob bestimmte Genres bevorzugt werden oder ob Rückgaben regelmäßig verspätet erfolgen.

„Welche Bücher werden häufig ausgeliehen, aber selten rechtzeitig zurückgebracht?“

Auch das ist eine Frage, die erst durch die Kombination mehrerer Ereignisse über die Zeit beantwortbar wird. Ein LLM, das diese Daten sieht, kann nicht nur die Antwort liefern, sondern auch Hypothesen formulieren: Liegt es an der Länge des Buches? An der Beliebtheit? An konkreten Leserinnen und Lesern, die generell verspätet zurückgeben?

Entscheidend ist: Keine dieser Fragen erfordert, dass jemand vorab ein spezielles Lesemodell gebaut oder eine Auswertung programmiert hat. Das LLM formuliert die Frage, der MCP-Server liefert die Daten, und das Modell interpretiert sie. Die Flexibilität entsteht dadurch, dass die Rohdaten fachlich und historisch vollständig sind. Was in diesem Beispiel mit einer Stadtbibliothek funktioniert, funktioniert in der Realität mit jeder Domäne: Versicherungsschäden, Logistikketten, Bestellprozesse im E-Commerce, Behandlungsverläufe im Gesundheitswesen, …: Die Liste ist endlos. Und je reichhaltiger die Events aus semantischer Sicht sind, desto mehr kann ein LLM damit anfangen.

Warum Events die natürliche Sprache für LLMs sind

Es gibt einen weiteren Grund, warum Event Sourcing und LLMs so gut zusammenpassen, und er liegt in der Form der Daten selbst. Events sind von Natur aus in fachlicher Sprache formuliert. Ein Event-Typ wie io.eventsourcingdb.library.book-borrowed sagt bereits, was passiert ist. Die Daten des Events enthalten die Details: welches Buch, welche Leserin oder welcher Leser, zu welchem Zeitpunkt. Ein LLM muss bei solchen Daten nicht raten, was gemeint ist. Es liest keine kryptischen Statuscodes, keine technischen Fremdschlüssel, keine Spalte type mit dem Wert 3. Es liest genau das, was passiert ist: Ein Buch wurde ausgeliehen, ein Buch wurde zurückgegeben, eine Gebühr wurde erhoben, eine Leserin wurde gesperrt. Die Semantik steckt in den Daten selbst.

Hinzu kommt die chronologische Ordnung. Events sind naturgemäß zeitlich sortiert. Ein LLM kann die Events daher lesen wie eine Erzählung: Erst wurde das Buch angeschafft, dann ausgeliehen, dann zurückgegeben, dann erneut ausgeliehen, dann verspätet zurückgegeben, dann eine Gebühr erhoben. Diese narrative Struktur entspricht genau dem, womit Sprachmodelle am besten umgehen können. Sie sind darauf trainiert, Zusammenhänge in sequenziellen Daten zu erkennen, Muster zu identifizieren und Schlussfolgerungen zu ziehen. Eine Folge von Events ist strukturell näher an einem Text als an einer relationalen Tabelle.

Videos by heise

Schließlich ist jedes Event in sich abgeschlossen und kontextreich. Es beschreibt nicht nur, was sich geändert hat, sondern trägt den fachlichen Zusammenhang bereits in sich. Ein BookBorrowed-Event enthält nicht nur eine Buch-ID und eine Leser-ID, sondern steht im Kontext eines Subject, das die gesamte Geschichte dieses Buches repräsentiert. Dieser eingebaute Kontext reduziert die Notwendigkeit, dem LLM zusätzliche Erklärungen mitzugeben. Die Events sprechen für sich.

Wer die aktuelle Entwicklung beim Context Engineering verfolgt, erkennt die Parallele: Es geht darum, einem Sprachmodell möglichst reichhaltigen, strukturierten und relevanten Kontext zur Verfügung zu stellen. Events erfüllen alle drei Kriterien, ohne dass eine zusätzliche Aufbereitung nötig wäre. Sie sind gewissermaßen bereits in der Sprache geschrieben, die LLMs am besten verstehen. Mit anderen Worten: Wenn Ihre Software bereits gute Daten liefert, wird die Auswertung per künstlicher Intelligenz bedeutend vereinfacht.

Von der Idee zur Praxis

Die Verbindung von Event Sourcing und MCP ist keine bloße Theorie. Mitte März 2026 wurde beispielsweise für die Datenbank EventSourcingDB ein MCP-Server als kostenfreie Erweiterung veröffentlicht. Er ermöglicht es, über ein beliebiges LLM in natürlicher Sprache mit dem Event-Store zu interagieren: Events lesen und schreiben, Subjects und Event-Types durchsuchen, Event-Schemas registrieren, EventQL-Queries ausführen und sogar die eingebaute EventQL-Dokumentation abfragen. Der MCP-Server läuft dabei als eigenständiger Prozess neben der Datenbank, unterstützt TLS-Verschlüsselung und Token-basierte Authentifizierung und ist als Docker-Image verfügbar.

Praktisch bedeutet das: Eine Entwicklerin kann ihrem LLM die Frage stellen, welche Subjects im Event-Store existieren, und erhält eine strukturierte Antwort. Sie kann fragen, welche Ereignisse für ein bestimmtes Buch vorliegen, und das LLM liest sie chronologisch aus dem Store. Sie kann eine analytische Frage formulieren, und das LLM übersetzt sie in eine EventQL-Query, führt sie aus und interpretiert das Ergebnis. All das geschieht über eine standardisierte Schnittstelle, ohne eine einzige Zeile Integrationscode. Was bisher erfahrene Entwicklerinnen und Entwickler mit Kenntnissen der Query-Sprache und der Datenstruktur erforderte, wird durch natürliche Sprache für ein breiteres Publikum zugänglich.

Es wäre jedoch falsch, diesen Gedanken auf ein einzelnes Produkt zu verengen. Das Prinzip gilt für jeden Event-Store, der einen MCP-Server anbietet oder künftig anbieten wird. Der Wert liegt nicht in der spezifischen Implementierung, sondern in der Kombination: ein Event-Store, der die vollständige fachliche Geschichte bereithält, und ein standardisiertes Protokoll, das diese Geschichte für Sprachmodelle zugänglich macht. EventSourcingDB ist lediglich ein konkretes Beispiel dafür, wie diese Kombination heute in der Praxis aussehen kann.

Nicht die Technik entscheidet, sondern die Daten dahinter

MCP löst also ein reales Problem: Es standardisiert den Zugang von LLMs zu externen Datenquellen und macht individuelle Integrationen überflüssig. Das ist ein bedeutender Schritt. Doch MCP allein reicht nicht. Ein standardisierter Zugang zu unzureichenden Daten liefert standardisiert unzureichende Ergebnisse.

Die eigentliche Frage bleibt bestehen: Welche Daten stecken hinter dem MCP-Server? Wer eine CRUD-Datenbank anbindet, gibt einem LLM Zugriff auf den aktuellen Zustand. Das ist besser als gar kein Zugriff, bleibt aber bei Snapshots ohne Geschichte. Das LLM sieht, was ist. Es sieht nicht, was war, was sich verändert hat oder warum.

Wer hingegen einen Event-Store anbindet, gibt einem LLM Zugriff auf die gesamte fachliche Historie. Es sieht nicht nur den Zustand, sondern den Weg dorthin. Es kann Muster erkennen, Zusammenhänge herstellen und Entwicklungen nachvollziehen. Es kann erklären, nicht nur beschreiben.

Die Kombination aus Event Sourcing und MCP ist deshalb so wirkungsvoll, weil sie zwei komplementäre Probleme gleichzeitig behebt. Event Sourcing löst das Datenproblem: Es liefert vollständige, kontextreiche und fachlich formulierte Daten. MCP löst das Zugangsproblem: Es macht diese Daten über eine standardisierte Schnittstelle für Sprachmodelle erreichbar. Keines der beiden löst für sich allein die gesamte Herausforderung. Zusammen jedoch schließen sie eine Lücke, die bislang dafür sorgte, dass LLMs entweder keinen Zugang zu den richtigen Daten hatten oder Zugang zu den falschen.

Dabei ist bemerkenswert, wie stabil diese Kombination gegenüber Veränderungen ist. Die Modelle werden sich weiterentwickeln, neue LLMs werden erscheinen, bestehende werden leistungsfähiger. Die Art, wie wir Prompts formulieren, wird sich ändern. Auch MCP wird sich als Protokoll weiterentwickeln. Was sich nicht ändern wird, sind die gespeicherten Ereignisse. Sie bleiben das unveränderliche Fundament, auf dem alles andere aufbaut. Wer heute damit beginnt, Events zu speichern, investiert nicht in eine kurzlebige Technologie, sondern in Daten, die mit jedem neuen Modell und jedem zukünftigen Zugangsweg an Wert gewinnen.

Wer im vergangenen August meinen eingangs erwähnten Artikel über Event Sourcing als Grundlage für KI gelesen hat, findet hier den nächsten logischen Schritt. Die Daten sind da. Jetzt sind sie auch zugänglich.

(rme)

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

Analyse: Darf KI Kernfeatures in kritische Software implementieren?

2026-04-02T07:15:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Community diskutiert darüber, KI-Beiträge bei der Open-Source-Entwicklung abzulehnen. Das ist weder realistisch noch zielführend, meint Sebastian Springer.

(Bild: sommart sombutwanitkul / Shutterstock.com)

09:15 Uhr

Lesezeit: 7 Min.

Developer

Von

Sebastian Springer

Die Open-Source-Community und die Mitglieder des Technical Steering Committee (TSC) von Node.js diskutieren derzeit, ob Pull Requests zu Node.js künftig abgelehnt werden sollen, wenn sie mithilfe von KI entstanden sind. Das ist jedoch aus mehreren Gründen unrealistisch: KI ist längst ein Teil des Entwicklungsprozesses, die Maintainer können die Herkunft von Code kaum verlässlich prüfen und es gibt keine objektiven Kriterien, um KI-Unterstützung eindeutig von menschlicher Arbeit zu unterscheiden. Zudem ist ein Verbot nicht sinnvoll, da es die ohnehin knappen Ressourcen der Community weiter belasten würde und es auch keine verantwortungsvolle Governance ersetzt.

Sebastian Springer weckt als Dozent für JavaScript, Sprecher auf zahlreichen Konferenzen und Autor die Begeisterung für professionelle Entwicklung mit JavaScript.

Debatte um Node.js

Kritik an KI-generierten Pull Requests ist zwar nicht neu, hat aber durch diesen aktuellen Fall eine neue Dimension erreicht und betrifft hier ein kritisches Element der Software-Infrastruktur: Die Plattform Node.js bildet in zahlreichen Anwendungen entweder die technische Basis oder dient als Grundlage für Build- und Entwicklungswerkzeuge.

Auslöser der aktuellen Diskussion ist ein umfangreicher Pull Request mit mittlerweile über 21.000 Zeilen Code. Der Autor Matteo Collina, ein erfahrener Node.js-Contributor, hat offengelegt, dass er das Feature teilweise mit Claude Code entwickelt, den generierten Code aber gründlich überprüft habe. In seinem Blogartikel führt er aus, dass er sich bei der Umsetzung des Features auf die Architektur, das API-Design und die Code Review konzentriert habe, während er die langweilige Schreibarbeit wie die Implementierung der Methodenvarianten, Tests und Dokumentation der KI überlassen habe.

Bei dem Feature handelt es sich nicht um eine kosmetische Änderung oder zusätzliche Tests, sondern um ein komplett neues Kernfeature: VFS, ein virtuelles Dateisystem, das es ermöglicht, Dateien und Module direkt aus dem Speicher statt vom realen Dateisystem zu laden. Dieses Feature greift tief in das Dateisystem-Modul und das Modulsystem von Node.js selbst ein. Überspitzt gesagt, stellt sich die Frage: Darf KI Kernfeatures eines kritischen Open-Source-Projekts implementieren?

(Bild: Stone Story / stock.adobe.com)

Webanwendungen mit KI anreichern, sodass sie wirklich besser werden? Der Online-Thementag enterJS Integrate AI am 28. April 2026 zeigt, wie das geht. Frühbuchertickets und Gruppenrabatte sind im Online-Ticketshop verfügbar.

Umgang mit KI-Flut und ihren Risiken

Eine einfache Antwort gibt es darauf nicht. Der Fall zeigt aber sehr deutlich eines der Grundprobleme, mit denen viele Open-Source-Projekte aktuell konfrontiert sind. Viele Projekte werden regelrecht mit KI-generierten Beiträgen überflutet. Diese reichen von kleinen Rechtschreibkorrekturen in der Dokumentation bis hin zu tiefgreifenden Architektur-Features. Die Maintainer stehen zunehmend vor der Entscheidung, ob sie KI-generierten Code grundsätzlich zulassen oder verbieten sollen. Neben den offensichtlichen Vorteilen wie Effizienzsteigerung und einer niedrigeren Einstiegshürde für neue Beitragende gibt es mehrere ernst zu nehmende Bedenken.

Diese betreffen zum einen das Copyright, denn KI-generierter Code ist in der Regel nicht urheberrechtlich geschützt. Anders sieht es bei KI-unterstütztem Code aus. Hier hängt es vom Einzelfall ab. Zudem besteht das Risiko, dass Modelle versehentlich proprietären Code reproduzieren und so zu Urheberrechtsproblemen führen. Diese Unsicherheit führt dazu, dass manche Maintainer KI-Beiträge grundsätzlich ablehnen möchten.

Zweitens wird die Qualität des Codes kritisch gesehen. KI-Agenten neigen dazu, sehr viel Code zu produzieren. Sowohl Autorinnen und Autoren als auch Maintainer müssen sicherstellen, dass der Code den Qualitäts- und Architekturstandards des Projekts genügt. Statische Analyse kann nur einen Teil davon abdecken. Aspekte, die die Architektur betreffen, müssen meist manuell überprüft werden. Gerade bei umfangreichen Beiträgen steigt das Risiko, dass suboptimale oder schwer wartbare Lösungen in den Code gelangen.

Und drittens nimmt der Aufwand für die Maintainer zu. Durch die Menge an generiertem Code verschiebt sich der Schwerpunkt vieler Maintainer vom Schreiben von Code hin zur Code Review. Dieser Aspekt nimmt teilweise so überhand, dass manche sich nur noch mit Code Reviews beschäftigen. Bei vielen Open-Source-Projekten entsteht das Problem, dass die Beiträge automatisiert übermittelt werden, sodass kaum noch menschliche Interaktion erforderlich ist. In der Flut aus KI-generierten Beiträgen können wertvolle Bugfixes oder Feature-Implementierungen leicht untergehen.

Videos by heise

Trotz dieser Risiken ist ein generelles Verbot von KI-generiertem Code in der Praxis kaum durchsetzbar. Viele Entwicklerinnen und Entwickler nutzen Copilot, Cursor und andere Werkzeuge für die Entwicklung, und hier auch in unterschiedlichem Ausmaß, von einfachen Inline-Vervollständigungen bis hin zu agentenbasiertem Coding. Hier stellt sich die Frage: Was ist noch ein smartes Feature der Entwicklungsumgebung und was ist KI-gestütztes Coding, oder auch: Wo ist die Grenze zwischen „menschlich“ und „KI-gestützt“? Und wie soll man sie erkennen? Gerade bei kleineren Beiträgen ist es faktisch unmöglich festzustellen, ob der Code von einer KI stammt oder nicht.

Die Linux Foundation verfolgt hier einen pragmatischen Ansatz. Gemäß ihrer Richtlinie ist KI-generierter Code grundsätzlich erlaubt. Die Nutzungsbedingungen des KI-Tools dürfen jedoch keine Restriktionen enthalten, die der Lizenz des Projekts widersprechen. Der KI-generierte Code darf zudem keine Urheberrechtsverletzungen verursachen; die Nutzung des generierten Codes muss erlaubt sein. Dabei gilt, dass die KI assistieren darf, der Mensch aber der verantwortliche Autor bleibt.

Transparenz gehört zu den grundlegenden Prinzipien im verantwortungsvollen Umgang mit generativer KI. Das gilt nicht nur für die Entwicklung solcher Systeme, sondern ebenso für ihre Nutzung: Entwickler sollten offenlegen, wenn sie Code mithilfe von KI-Werkzeugen entwickelt haben. Einige Open-Source-Projekte haben entsprechende Offenlegungspflichten in ihre Contribution-Richtlinien aufgenommen, zum Beispiel der Terminal-Emulator Ghostty. Das Webframework Django hat eine AI Assistance Disclosure in das offizielle Pull-Request-Template integriert.

Verlässliche Richtlinien statt KI-Verbot

Die Diskussion um den Umgang mit KI ist für jedes Projekt, auch im Open-Source-Bereich, sehr wichtig, und sie wird auch nicht beendet sein. Stattdessen müssen wir uns kontinuierlich mit dem Thema beschäftigen, denn die Werkzeuge und Modelle entwickeln sich kontinuierlich weiter. Die Qualität wird immer besser und auch die Erfahrungen mit den Werkzeugen und ihrem Umgang nehmen zu.

Es braucht verlässliche Richtlinien, um Projekte und ihre Maintainer zu schützen. Ein generelles Verbot von KI ist wenig realistisch und auch nicht zielführend. Es wirkt eher wie ein reflexartiges Abwehren neuer Technologien. Sinnvoller ist es, Verantwortung klar zu definieren, Transparenz einzufordern und die Qualitätssicherung zu stärken. Das ist jedoch nicht nur die Aufgabe der Maintainer, die aktuell schon unter der Situation leiden, sondern einer jeden Entwicklerin und eines jeden Entwicklers, die zu Open-Source-Projekten beitragen möchten.

(mai)

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

software-architektur.tv: Analyse großer Softwaresysteme mit LLMs

2026-04-01T16:01:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

In der Episode diskutieren Eberhard Wolff und Michael Stal, wie auch die Analyse großer Softwarearchitekturen und Codebasen durch LLMs gelingt.

(Bild: software-architektur.tv)

01.04.2026, 18:01 Uhr

Lesezeit: 2 Min.

Developer

Von

Matthias Parbel

Bei der Verwendung von LLMs für Software-Architektur geht es meistens um das Erstellen von Architektur. In dieser Episode von software-architektur.tv spricht Eberhard Wolff mit Prof. Dr. Michael Stal, Principal Key Expert Engineer bei der Siemens AG, über dessen Erfahrungen bei der Benutzung von LLMs für die Code-Analyse.

Den vollmundigen Versprechen mancher Anbieter und Influencer für generative KI steht die praktische Realität gegenüber, dass die Beschränkungen von LLMs zu vielen Problemen führen, ganz besonders beim Softwareengineering. Die Analyse großer Softwarearchitekturen und Codebasen durch LLMs scheitert unter anderem an dem beschränkten Kontextfenster der Foundation-Modelle. Das gilt im Umkehrschluss auch für deren Generierung. Wie sich diese Problematik zumindest teilweise umgehen lässt, möchte iX-Blogger Michael Stal anhand geeigneter Techniken zeigen.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Livestream am 2. April

Die Ausstrahlung findet am Donnerstag, 2. April 2026, live ab 14:30 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, iX-Blogger 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 berichtet heise Developer über die Episoden.

(map)

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

Bund veröffentlicht lizenzfreie KI-Werkzeuge

2026-04-01T13:42:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit dem Projekt Spark setzt das BMDS auf digitale Souveränität: Die quelloffenen KI-Werkzeuge zur Planungsbeschleunigung stehen ab sofort auf OpenCode bereit.

(Bild: DC Studio / Shutterstock.com)

01.04.2026, 15:42 Uhr

Lesezeit: 3 Min.

Von

Stefan Krempl

Die deutsche Verwaltung gilt als Sinnbild für lahme Prozesse und dicke Aktenstapel. Doch beim Thema KI will der Bund zeigen, dass es auch anders geht. Das Bundesministerium für Digitales und Staatsmodernisierung (BMDS) hat mit dem Projekt Spark eine Reihe von KI-Modulen veröffentlicht, die die Arbeitsweise in Behörden grundlegend verändern könnten.

Eine Besonderheit ist der Ansatz der Veröffentlichung: Unter dem Leitsatz Public Money, Public Code stehen die Anwendungen für jeden auf der Plattform OpenCode zur Verfügung. Damit folgt das BMDS dem Ruf nach digitaler Souveränität und ermöglicht es Kommunen, Firmen und der Zivilgesellschaft, die Werkzeuge ohne Lizenzgebühren zu nutzen und weiterzuentwickeln.

Mit Spark sollen komplexe Planungs- und Genehmigungsverfahren, die bisher Monate oder gar Jahre dauerten, durch eine intelligente operative Assistenz beschleunigt werden. Die Finanzierung erfolgt über den Klima- und Transformationsfonds. Das Projekt soll Beschäftigte in den Genehmigungsbehörden von Routineaufgaben befreien, ohne Menschen zu ersetzen. Vielmehr bereite die KI die Flut an Informationen aus Antragsunterlagen so auf, dass Sachbearbeiter schneller zu einer fundierten Entscheidung kommen könnten. Das letzte Wort habe der Mensch.

Startpunkt Dokumentenprüfung

Technisch setzt Spark an, wo es bisher am meisten hakt: beim Sichten und Prüfen von Dokumenten. Die veröffentlichten Module decken typische Aufgaben wie die Zusammenstellung relevanter Daten aus Anträgen oder den formalen Check auf Vollständigkeit und Plausibilität ab. Das System soll dabei erkennen, wenn Dokumente fehlen oder Angaben widersprüchlich sind.

Das Herzstück bildet eine mit KI-Agenten unterstützte Rechtsdogmatik. Sie ist direkt an Gesetzesdatenbanken angeschlossen und kann Normen automatisiert dekonstruieren und juristisch bewerten. Im weiteren Verlauf sollen zusätzliche Module folgen, die sich auch der materiellen Prüfung und der Beschlusserstellung widmen.

Digitalminister Karsten Wildberger (CDU) sieht die Republik durch diesen Vorstoß weltweit in einer führenden Rolle bei KI-basierten Verwaltungsanwendungen. Erst im Februar sahnte das Projekt auf dem World Government Summit in Dubai den Preis für die beste KI-Nutzung in staatlichen Dienstleistungen ab. Die offene Bereitstellung des Quellcodes soll nun sicherstellen, dass kreative Köpfe die Module adaptieren und für verschiedene föderale Anforderungen optimieren können. Um diesen Prozess anzukurbeln, plant das BMDS für Juni einen zweitägigen Hackathon.

Videos by heise

Sicherheit und technische Hürden

Trotz der Euphorie mahnt das BMDS zur Sorgfalt bei der Implementierung. In den Begleitunterlagen findet sich ein Sicherheitshinweis: Der veröffentlichte Code sei als Referenz und Integrationsgrundlage zu verstehen, beinhalte aber keine fertige Sicherheitskonfiguration für den direkten Produktionseinsatz. Betreiber müssen die Anwendungen in ihren jeweiligen IT-Umgebungen härten, Zugriffsrechte definieren und sensible Daten sicher verwalten. Ein dediziertes Security-Review ist zwingend erforderlich, bevor die KI tatsächlich in produktive Genehmigungsverfahren eingebunden wird.

Für Entwickler soll der Einstieg aber hürdenarm sein. Die Module basieren auf einer Docker-Umgebung und lassen sich rasch aufsetzen. Die Konfiguration erfolgt über Skripte. Schnittstellen zu OpenAI-kompatiblen Endpunkten und lokalen Lösungen wie LiteLLM sind vorgesehen.

(mma)

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

Malware auf npm: HTTP-Client axios lädt Backdoor für Windows, macOS und Linux

2026-04-01T08:26:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Alert!

Der Maintainer-Account für das Paket axios auf npm wurde geknackt, um einen Remote-Access-Trojaner für Windows, macOS und Linux einzuschleusen.

(Bild: Gorodenkoff/Shutterstock.com)

01.04.2026, 10:26 Uhr

Lesezeit: 3 Min.

Developer

Von

Rainald Menge-Sonnentag

Auf dem JavaScript-Paketmanager npm hat es erneut einen Supply-Chain-Angriff gegeben: Der HTTP-Client axios hatte eine Backdoor an Bord. Angreifer hatten zuvor den Account des axios-Maintainers übernommen. Hinter der Attacke steht vermutlich die nordkoreanische Gruppe UNC1069.

Betroffen ist die Version 1.14.1, die die Angreifer am 30. März veröffentlicht haben. Inzwischen ist auf npm wieder die Version 1.14.0 ohne Malware verfügbar, und der ursprüngliche Maintainer hat die Kontrolle über das Paket zurückerlangt. Wer axios nutzt, sollte prüfen, ob zwischenzeitlich die mit Malware versehene Version auf das System gelangt ist. Neben der Version 1.14.1 haben die Angreifer auch eine Version 0.30.4 mit der Malware auf npm veröffentlicht, die ebenfalls nicht mehr existiert.

Plattformübergreifender Angriff

Die Angreifer haben sich zunächst Zugriff auf den Account des npm-Maintainers über Social Engineering verschafft und anschließend die Version 1.14.1 von axios mit der zusätzlichen Dependency „plain-crypto-js@4.2.1“ versehen, die im “postinstall“-Hook den JavaScript-Dropper setup.js ausführt.

(Bild: AliaAyah / Shutterstock)

Am 22. und 23. September findet die heise devSec 2026 statt. Die zehnte Auflage der Konferenz zu sicherer Softwareentwicklung wandert dieses Jahr nach Marburg. Weiterhin lautet das Motto „Sichere Software beginnt vor der ersten Zeile Code“.

Der Dropper verhält sich je nach Betriebssystem unterschiedlich. Auf Windows lädt er ein PowerShell-Skript nach, unter macOS ein Mach-O-Binary und unter Linux eine Python-Backdoor. Mehrere Methoden sollen den Angriff vertuschen: Das Skript ist mit Base64 und XOR verschleiert, und setup.js versucht, sich nach dem erfolgreichen Nachladen des Payloads selbst zu löschen und die package.json-Datei zurückzusetzen.

Command & Control

Die plattformspezifische Malware lädt anschließend die Backdoor nach, die Google Threat Intelligence in einer Analyse als WAVESHAPER.V2 identifiziert, da sie große Ähnlichkeiten mit der WAVESHAPER-Backdoor mitbringt, die im Februar 2026 aufgetaucht war. Da die ursprüngliche Backdoor der UNC1069-Gruppe zugeordnet wird, vermutet Google Threat Intelligence, dass die nordkoreanische Gruppe auch hinter dem Angriff auf axios steckt.

Videos by heise

WAVESHAPER.V2 arbeitet schließlich als Remote-Access-Trojaner: Die Software nimmt Kontakt zu einem C2-Server (Command & Control) auf und erwartet im Minutentakt die Befehle runscript, peinject oder rundir vom Server, um weitere Skripte oder Executables auszuführen oder Informationen zu Verzeichnissen und Dateien abzurufen. Der Befehl kill beendet die Ausführung. Google Threat Intelligence sieht in WAVESHAPER.V2 eine direkte Weiterentwicklung des Original-WAVESHAPER.

Zurück zu Version 1.14.0

Wer das axios-Paket verwendet, sollte überprüfen, ob die Versionen 1.14.1 oder 0.30.4 mit dem Schadcode ins System gelangt sind. Automatische Systeme sollten auf die feste Versionsnummer gepinnt werden, statt die aktuellste Version herunterzuladen.

Im Beitrag von Google Threat Intelligence findet sich eine Übersicht der Indikatoren, die auf einen Angriff hinweisen, darunter Netzwerkverkehr zu den IP-Adressen 142.11.206.73 oder 23.254.167.216.

Lesen Sie auch

Infostealer für Windows, macOS und Linux in zehn Pakten auf npm gefunden

Lieferketten-Wurm mit eigenem MCP-Server verbreitet sich über GitHub

npm als Sicherheitsrisiko: Warum Angriffe zunehmen und wie man vorbeugen kann

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

Drei Fragen und Antworten: Warum ABAP-Entwickler jetzt umdenken müssen

2026-04-01T07:25:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Der Wechsel von Dynpro zu SAP Fiori Elements fordert ABAP-Entwickler heraus. Marian Zeis erklärt, worauf es beim Umstieg ankommt.

(Bild: iX)

01.04.2026, 09:25 Uhr

Lesezeit: 4 Min.

Developer

Von

Matthias Parbel

Der Übergang von klassischen Dynpro- und Web-Dynpro-Oberflächen zu SAP Fiori Elements stellt viele ABAP-Entwickler vor grundlegende Herausforderungen. Statt imperativer Programmierung in der SE80 bestimmen nun CDS-Annotationen und das ABAP RESTful Application Programming Model (RAP) das Erscheinungsbild der Oberflächen. Marian Zeis, unabhängiger SAP-Entwickler und aktiv in der AG UI-Technologien der DSAG engagiert, ordnet ein, was der Wandel für die Praxis bedeutet.

Marian Zeis ist unabhängiger SAP-Entwickler/Consultant mit Fokus auf ABAP, RAP/OData und SAPUI5/SAP Fiori. Er baut Open-Source-Tools, schreibt Blog-Posts und engagiert sich in der DSAG in der AG UI-Technologien.

(Bild: Andriy Bezuglov / Adobe Stock)

Die Online-Konferenz betterCode() ABAP am 29. April 2026 eröffnet Entwicklerinnen und Entwicklern die Möglichkeit, ihre ABAP-Kenntnisse zu erweitern. ABAP Cloud, das ABAP RESTful Application Programming Model und der Einsatz von SAP Joule for Developers stehen im Fokus.

heise developer: Was ist die größte Herausforderung bei der UI-Entwicklung mit SAP Fiori Elements, wenn man bisher mit Web Dynpro ABAP oder Dynpro gearbeitet hat?

Zeis: Wenn man bisher primär mit Dynpro, Web Dynpro ABAP oder klassischen ALVs gearbeitet hat, ist die größte Herausforderung aus meiner Sicht, dass man plötzlich nicht mehr nur in der klassischen ABAP-Welt unterwegs ist.

Der erste Bruch ist schon beim Werkzeug: Man arbeitet nicht mehr hauptsächlich in der SE80, sondern in Eclipse mit den ABAP Development Tools. Dazu kommt mit RAP und Fiori Elements ein deutlich stärkerer service- und annotationsgetriebener Ansatz.

Die eigentliche Herausforderung ist für mich aber, dass Frontend-Themen näher an den ABAP-Entwickler heranrücken. Im Standard kann Fiori Elements zwar viel über Annotationen und Metadaten abbilden, aber sobald man erweitern will oder spezielleres Verhalten benötigt, kommt man schnell auch mit UI5 und teilweise JavaScript in Berührung. Genau dieser Wechsel im Denken ist für viele die größte Umstellung.

heise developer: Inwieweit muss oder sollte man die Benutzeroberflächen schon bei der Backend-Entwicklung mitdenken? Muss man mit ABAP CDS eine ganz neue Sprache lernen, um Annotationen verwenden zu können?

Zeis: Die Bedienoberfläche sollte man aus meiner Sicht sehr früh mitdenken, möglichst schon beim Datenmodell und bei den Services. Das war früher im Kern auch schon so, aber im RAP-Umfeld ist es noch wichtiger, weil sich die spätere Oberfläche stark aus dem Backend-Modell ableitet.

Gerade bei Fiori Elements steckt viel UI-Logik schon in den CDS-Views und Annotationen. Wenn das Modell fachlich unsauber ist oder die Daten nicht sinnvoll geschnitten sind, sieht man das später direkt in der Anwendung. Gute Oberflächen entstehen deshalb hier zu einem großen Teil schon im Backend.

Videos by heise

Zu ABAP CDS würde ich sagen: Ja, man muss etwas Neues lernen, aber nicht komplett bei null anfangen. Es ist eine andere Denkweise, weil es stärker um Modellierung, Semantik und Annotationen geht. Und genau daran führt künftig kaum ein Weg vorbei. Gerade wenn SAP in Richtung generativer UI denkt, werden saubere Fachobjekte und ein gutes Backend-Modell eher noch wichtiger.

heise developer: Werden ABAP- und UI-Entwicklung überhaupt noch benötigt, wenn Anwenderinnen und Anwender bald nur noch über Joule mit dem SAP-System interagieren?

Zeis: ABAP wird uns aus meiner Sicht auf jeden Fall noch lange begleiten. Dass SAP ABAP weiter als modern positioniert und insbesondere auch im Cloud-Umfeld ausbaut, zeigt deutlich, dass das kein Auslaufmodell ist.

Bei der UI-Entwicklung ist die Frage spannender. Mit Joule und generativer UI kommt natürlich eine neue Art der Interaktion dazu, also stärker kontextbezogene und dynamische Oberflächen. Das wird sicher verändern, wie man SAP-Anwendungen künftig denkt.

Trotzdem glaube ich nicht, dass ABAP- und UI-Entwicklung dadurch überflüssig werden. Es wird weiterhin viele Prozesse geben, bei denen strukturierte Oberflächen, Listen, Formulare oder geführte Abläufe sinnvoller sind als eine reine Chat-Interaktion. Ich glaube deshalb eher an eine Koexistenz: Joule wird wichtiger, aber klassische Anwendungen verschwinden nicht einfach.

heise developer: Herr Zeis, vielen Dank für das Interview!

In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(map)

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

Android-Sideloading: Entwickler können sich nun bei Google registrieren

2026-04-01T07:07:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Google will App-Installationen auf Android-Geräten an die Verifizierung von Entwicklern knüpfen. Nun können sich Developer bei Google registrieren.

Google Android-Bugdroid vor Schloss-Symbol.

(Bild: Primakov/Shutterstock.com)

01.04.2026, 09:07 Uhr

Lesezeit: 2 Min.

Von

Daniel Herbig

Google fährt mit seinen Plänen zu strengeren App-Regeln auf Android-Geräten fort: Entwickler für die Android-Plattformen können sich jetzt in der Play Console oder der Android Developer Console bei Google verifizieren. Diese Registrierung ist Voraussetzung dafür, dass sie weiterhin einfach zu installierende Apps für Android veröffentlichen dürfen.

Google hatte vergangenen August zunächst bekannt gemacht, dass künftig auf zertifizierten Android-Geräten nur noch Anwendungen installiert werden können, deren Herausgeber sich zuvor bei Google registriert und dann die jeweilige Anwendung signiert hat. Das betrifft im Gegensatz zum bisherigen Verfahren grundsätzlich nicht nur Apps im Play Store, sondern auch per Sideloading angebotene Anwendungen.

Mittlerweile hat Google klargestellt, dass es auch beim neuen System die Möglichkeit geben wird, unregistrierte Apps per Sideload aufs Handy zu bekommen. Das wird allerdings komplizierter als bisher: Nutzer von Android-Handys müssen zuerst in den Entwicklermodus wechseln und dann die neue Option „Advanced Flow“ aktivieren. Diese zusätzlichen Schritte sollen Nutzer laut Google daran hindern, auf Betrugsmaschen hereinzufallen und Malware auf ihren Handys zu installieren.

Lesen Sie auch

Android: Neue Sideloading-Regeln sollen bei Gerätewechsel weiter erfüllt bleiben

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

RxDB 17: Sync ohne Server, Zugang für KI-Agenten

2026-04-01T05:03:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Open-Source-Datenbank RxDB 17 synchronisiert Daten jetzt direkt über Google Drive oder OneDrive – ein eigenes Backend brauchen Entwickler nicht mehr.

(Bild: Noom_Studio/Shutterstock.com)

01.04.2026, 07:03 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

Die JavaScript-Datenbank RxDB kann ab Version 17.0.0 Daten ohne eigenes Backend synchronisieren. Außerdem führt das Projekt eine Schnittstelle für KI-Agenten ein und bringt ein schnelleres Storage-Backend für React-Native-Apps.

RxDB ist eine Open-Source-Datenbank für JavaScript und TypeScript. Sie setzt auf Storage-Backends wie IndexedDB oder SQLite auf und ist für Offline-First-Anwendungen gedacht: Apps, die lokal arbeiten und Daten bei Bedarf synchronisieren. Typische Einsatzgebiete sind Progressive Web Apps, React-Native-Apps und Electron-Anwendungen.

Synchronisation ohne Server

Das zentrale neue Feature in RxDB 17 sind zwei neue Replikations-Plugins für Google Drive und Microsoft OneDrive. Sie synchronisieren Daten direkt in den Cloud-Speicher des Nutzers, statt sie auf einem zentralen Server abzulegen. Entwickler können ihre App als statische Website auf GitHub Pages, Vercel oder Cloudflare hosten und brauchen kein eigenes Backend mehr. Die Synchronisation läuft nahezu in Echtzeit und geräteübergreifend. Mehrere Apps können auf denselben Cloud-Ordner zugreifen und so Daten teilen.

Videos by heise

Allerdings bringt dieser Ansatz Einschränkungen mit sich. Cloud-Speicher bieten keine ACID-Garantien, und die Synchronisation unterliegt den Ratenlimits der jeweiligen Cloud-API. Nutzer müssen zudem per OAuth den Zugriff auf ihr Konto erlauben.

KI-Agenten greifen direkt auf die Datenbank zu

Mit dem neuen WebMCP-Plugin können KI-Agenten über das Web Model Context Protocol direkt auf RxDB-Collections zugreifen. Bisher mussten Agenten im Browser entweder die gerenderte Seite analysieren oder die HTML-Struktur erraten – beides ist aufwendig und fehleranfällig. WebMCP stellt stattdessen eine maschinenlesbare API-Beschreibung bereit. Agenten erfahren darüber, welche Operationen verfügbar sind, und können beliebige Abfragen oder Änderungen ausführen, ohne dass Entwickler für jede Aktion ein eigenes Tool definieren müssen.

Für React-Native- und Expo-Apps bringt RxDB 17 das Expo Filesystem RxStorage mit. Es basiert auf expo-opfs und nutzt die aktuelle Expo-Filesystem-API. Laut den Entwicklern arbeitet es bei vielen Zugriffsmustern deutlich schneller als SQLite. Das Backend ist speziell für das Expo-Ökosystem optimiert und greift direkt auf das Dateisystem zu, um die Performance zu steigern.

Besser für LLMs

Ferner wurde RxDB 17 gezielt für KI-gestützte Programmierung optimiert. Eine neue Datei llms.txt fasst die API in einer für Sprachmodelle geeigneten Form zusammen. ERROR-MESSAGES.md listet alle Fehlercodes mit Ursache, Lösung und Link zur Dokumentation auf. Fehlerobjekte enthalten nun die Eigenschaften cause, fix und docs, sodass ein Sprachmodell beim Debugging nicht in Sackgassen gerät. Dateien wie .aiexclude und .claudeignore reduzieren den Kontext, den KI-Tools verarbeiten müssen. TypeScript-Kommentare enthalten jetzt @example-Tags, damit Agenten die API auch ohne Dokumentation nutzen können.

Auf der Framework-Seite gibt es ein neues React-Plugin mit Hooks und Signals sowie ein Paket reactivity-angular für Angular Signals. Die bisherigen Premium-Pakete für Vue und Preact Signals wandern in den frei verfügbaren Kern. Signals tragen jetzt den konkreten Datentyp des Dokuments – also etwa Signal<number> statt Signal<any>.

Performance und Stabilität

Die Entwickler haben den Bulk-Insert-Pfad, das Query-Routing und interne Datenstrukturen überarbeitet. IndexedDB speichert Anhänge jetzt binär statt als JSON, was Speicherplatz spart. Mehrere Speicherlecks in OPFS und im Migrationscode wurden ebenfalls behoben.

Neun Plugins verlassen die Beta-Phase und gelten ab sofort als produktionsreif. Dazu gehören die Replikations-Plugins für Appwrite, Supabase und MongoDB, die Storage-Backends für MongoDB, das Node.js-Dateisystem und DenoKV sowie die Attachment-Replikation, das CRDT-Plugin und RxPipeline.

Breaking Changes und Migration

Die meisten Anwendungen lassen sich ohne größere Anpassungen aktualisieren. Wer allerdings OPFS RxStorage, Filesystem RxStorage unter Node.js oder IndexedDB mit Anhängen nutzt, muss seine Daten mit dem Storage Migrator migrieren. Pull-Only-Replikationen speichern keine Server-Metadaten mehr auf dem Client. Primärschlüssel und Indizes sind auf maximal 2048 Zeichen begrenzt, da zu lange Schlüssel die Performance beeinträchtigen. Einige Integrationen wie Firebase, MongoDB und NATS sind jetzt optionale Peer Dependencies und müssen manuell installiert werden. Vorgebaute dist-Dateien liefert das GitHub-Repository nicht mehr mit – Entwickler installieren RxDB über npm oder bauen lokal selbst.

Die vollständigen Release Notes stehen auf der Projektseite bereit.

(fo)

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

OLG Bamberg: TikTok schummelt bei DSA-Pflichten

2026-03-31T20:56:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

TikTok versucht, sich um Pflichten aus dem Gesetz über digitale Dienste (DSA) herumzuwinden. Technisch wie juristisch.

Da soll sich einer auskennen...

(Bild: Daniel AJ Sokolov)

31.03.2026, 22:56 Uhr

Lesezeit: 4 Min.

Von

Daniel AJ Sokolov

Tiktok muss seine Webseite für Nutzer in Deutschland umprogrammieren, urteilt das Oberlandesgericht Bamberg (OLG). Die aktuelle Gestaltung verstößt mehrfach gegen die als DSA (Digital Services Act, auch Gesetz über digitale Dienste) bekannte EU-Verordnung. Tiktok muss es Nutzern leicht machen, die Nutzung personenbezogener Daten für die Auswahl der vorgesetzten Videos auszuschalten.

Außerdem muss die Meldung rechtswidriger Inhalte benutzerfreundlich gestaltet werden. Beides ist laut dem von der Verbraucherzentrale Bayern erstrittenen Urteil ( 3 UKl 5/25 e) nicht gegeben, obwohl der DSA das in Artikel 38 respektive 16 vorschreibt.

Da der Fall grundsätzliche Bedeutung hat, es zu den relevanten Rechtsfragen aber noch keine Rechtsprechung gibt, hat das OLG in seinem erstinstanzlichen Endurteil vom 18. März die Revision zum Bundesgerichtshof zugelassen. Tiktok wird das wohl in Anspruch nehmen und hat seine Webseite bisher nicht verbessert. TikToks Anregung, bestimmte Rechtsfragen zuerst dem Europäischen Gerichtshof (EuGH) vorzulegen, hat das Gericht nicht aufgegriffen.

TikTok will sich dem Verfahren nicht stellen

Im Prozess hat TikTok zunächst versucht, der Verbraucherzentrale die Berechtigung zur Klageführung abzustreiten. Der DSA diene der Wettbewerbsregulierung und nicht dem Verbraucherschutz; zudem sei ausschließlich die Europäische Kommission zur Durchsetzung befugt, und diese habe an der Webseite nichts ausgesetzt. Und überhaupt würden auch Nicht-Verbraucher die Webseite aufrufen.

Diese Argumente griffen beim OLG Bamberg nicht. Einerseits seien die für die Klage relevanten Passagen des DSA eindeutig verbraucherschützend, andererseits gebe das deutsche Gesetz über Unterlassungsklagen bei Verbraucherrechts- und anderen Verstößen (UKlaG) der Verbraucherzentrale ausdrücklich das Recht, wegen Verstößen gegen solche DSA-Passagen vor Gericht zu ziehen. Die Regelung des DSA, wonach die EU-Kommission für die Durchsetzung zuständig sei, diene der Abgrenzung gegenüber anderen Verwaltungsbehörden, schließe aber Gerichtsverfahren nach dem UKlaG nicht aus.

Interface-Tricks

Nutzer haben gemäß Artikel 38 DSA das Recht, TikTok zu verbieten, seinem Algorithmus ein Profil aus personenbezogenen Daten zu füttern. Diese Option hat TikTok allerdings ausnehmend gut versteckt. Nutzer müssen mit der rechten Maustaste auf ein Video oder ein beworbenes Produktbild klicken, und dann im Kontextmenü „Feed verwalten" auswählen.

Nur durch Klicken mit der rechten Maustaste auf ein Video oder ein angezeigtes Produkt kommt man zu diesem Menü – wenn der Browser mitspielt. Unter „Feeds verwalten“ kann man sich dann verbitten, dass der Algorithmus ein personenbezogenes Profil heranzieht.

(Bild: Tiktok (Screenshot))

Dieser Weg ist alles andere als naheliegend. Beim Versuch der Redaktion ist das Kontextmenü auch nur in einem von drei Webbrowsern aufgetaucht; die anderen beiden Browser zeigten ihr eigenes Kontextmenü. Und über jene TikTok-Menüs, die über die bekannten drei Punkte aufgerufen werden können, ist die Datenschutz-Option nicht zu finden. Damit sei die De-Personalisierungsfunktion auf Tiktoks Webseite zwar unmittelbar, aber nicht leicht zugänglich, was die Vorgaben des DSA verletzt.

Videos by heise

Die Meldung rechtswidriger Inhalte gemäß DSA ist sehr wohl über das Drei-Punkte-Menü im rechten oberen Eck des jeweiligen Videos erreichbar – allerdings gut versteckt. Zunächst muss „Melden“ ausgewählt werden, was eine Reihe von Auswahlmöglichkeiten beschert. Darunter „Hass und Belästigung“, „Betrug und Schwindel“ oder „Fälschungen und geistiges Eigentum“, was ja durchaus rechtswidrige Tatbestände sind.

Nur so wird korrekt gemeldet

Doch wer meint, damit eine Meldung gemäß Artikel 16 DSA erstattet zu haben, irrt. TikTok betrachtet dies lediglich als Hinweis auf einen Verstoß gegen die eigenen Richtlinien und setzt nicht die im DSA vorgesehenen Maßnahmen. Nutzer können keine Begründung hinzufügen und auch keine Kontaktdaten beifügen. Damit entfallen nicht nur die Empfangsbestätigung und Information über die Entscheidung über die Meldung, sondern TikTok wähnt sich auch haftungsfrei. Nur bei Meldungen nach Artikel 16 DSA gilt TikTok formalrechtlich als in Kenntnis gesetzt und muss gegebenenfalls Maßnahmen ergreifen.

Wer hier klickt, klickt vielleicht falsch. Die rechtsverbindliche Meldung nach dem Digital Services Act geht nur über die hier nicht sichtbare Option „Widerrechtlichen Inhalt melden“. Sie wird erst durch Scrollen nach unten sichtbar. Das ist unannehmlich, sagt das Gericht.

(Bild: TikTok/Daniel AJ Sokolov (bearbeiteter Screenshot))

Nur wer in dem Menü unter den Seitenumbruch hinunterscrollt und "Widerrechtlichen Inhalt melden" auswählt, kann nähere Informationen und seine Kontaktdaten hinzufügen. Das erschließt sich aber erst, nachdem man das ausgewählt hat. „Faktisch hängt es daher häufig vom Zufall ab, welche Schaltfläche der Nutzer betätigt und demnach auch, ob er ein den Anforderungen des Art 16 DSA genügendes Meldeverfahren in die Wege leitet“, begründet der OLG sein Unterlassungsurteil. „Die Auffindung dieses Meldeverfahrens wird dem Nutzer daher durch die Ausgestaltung in einer Weise erschwert, dass sie entgegen der Vorgabe der Benutzerfreundlichkeit mit Unannehmlichkeiten verbunden ist.“

Lesen Sie auch

Doom-Scrolling und Suchtgefahr: EU-Kommission fordert Änderungen bei TikTok

EU-Kommission: TikTok bricht DSA-Vorgaben bei Anzeigen

Lebensgefährliche Videos: EU droht Tiktok mit Verbot

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

Anthropics Claude Code: Kompletter Quellcode im Netz

2026-03-31T13:14:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Der Quellcode von Anthropics CLI-Tool Claude Code wurde versehentlich über eine Source-Map im npm-Registry öffentlich zugänglich.

142

Anthropic steht auf einem Smartphone, im HIntergrund Claude.

(Bild: Stockinq/Shutterstock.com)

31.03.2026, 15:14 Uhr

Lesezeit: 2 Min.

iX Magazin

Von

Moritz Förster

Der Quellcode von Anthropics CLI-Tool Claude Code ist am 31. März 2026 anscheinend unbeabsichtigt öffentlich zugänglich geworden. Auslöser war nach übereinstimmenden Berichten eine mitveröffentlichte Source-Map-Datei im npm-Registry. Der Sicherheitsexperte Chaofan Shou machte über X auf den Fund aufmerksam, kurz darauf tauchte ein vollständiger Snapshot des Codes in einem öffentlichen GitHub-Repository auf.

Der gespiegelte Code umfasst laut Repository rund 1900 Dateien mit über 512.000 Zeilen. Claude Code ist ein Kommandozeilenwerkzeug, mit dem Entwickler über natürliche Sprache auf Anthropics KI-Modelle zugreifen und typische Aufgaben wie das Bearbeiten von Dateien oder das Ausführen von Befehlen erledigen können.

Source Map als Einfallstor

Source Maps dienen eigentlich dazu, komprimierten oder gebündelten Code auf die ursprünglichen Quelldateien zurückzuführen. Gelangen sie jedoch in veröffentlichte Pakete, können sie den Zugriff auf den Originalcode ermöglichen. In diesem Fall verwies die Datei offenbar auf unminifizierte TypeScript-Quellen, die sich herunterladen ließen.

Als wahrscheinliche Ursache gilt eine fehlerhafte Paketkonfiguration bei der Veröffentlichung über npm. Anthropic reagierte schnell: Die betroffene Paketversion wurde bereits aus dem npm-Registry entfernt und durch eine bereinigte Version ohne Source-Maps ersetzt. Eine offizielle Stellungnahme des Unternehmens lag zum Zeitpunkt der Veröffentlichung dieser Meldung nicht vor.

Videos by heise

Modulare Architektur mit Bun und React

Ein erster Blick in das Material zeigt eine modular aufgebaute Codebasis. Das Tool nutzt demnach die JavaScript-Laufzeitumgebung Bun und setzt für die Terminaloberfläche auf React in Kombination mit der Ink-Bibliothek. Zudem enthält der Code unter anderem ein Befehlssystem, eine Schnittstelle zu Entwicklungsumgebungen sowie Mechanismen zur Steuerung von Berechtigungen.

Die Verbreitung erfolgte zunächst über soziale Netzwerke und Entwicklerforen auf Reddit. Parallel entstand auf GitHub ein Repository, das den Code zu Analysezwecken spiegelt und ausdrücklich als Forschungs- und Lehrmaterial einordnet.

Update 01.04.2026, 11:00 Uhr

Mittlerweile enthält das Repository einen angeblichen Rewrite des Codes in Python, der jedoch nicht vom ursprünglichen Contributor stammt. Wir haben als Vorsichtsmaßnahme den Link auf das Repository entfernt.

Laut CNBC hat Anthropic eine unbeabsichtigte Codeoffenlegung bestätigt. „Es waren keine sensiblen Kundendaten oder Zugangsdaten betroffen oder wurden offengelegt“, erklärte ein Sprecher von Anthropic. „Es handelte sich um ein Problem bei der Veröffentlichung der Software, das durch menschliches Versagen verursacht wurde, nicht um eine Sicherheitslücke. Wir ergreifen Maßnahmen, um zu verhindern, dass sich so etwas wiederholt.“

(fo)

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer im Test

Top 10: Das beste günstige Smartphone bis 300 Euro

Neovim 0.12 mit nativem Plugin-Manager

2026-03-31T10:54:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Neovim 0.12 bringt einen nativen Plugin-Manager und macht Schluss mit „Press ENTER“. Ziel ist ein Out-of-the-box-Editor.

(Bild: heise medien)

12:54 Uhr

Lesezeit: 3 Min.

iX Magazin

Von

Moritz Förster

Neovim ist in Version 0.12 erschienen. Unter dem Motto „The year of Nvim OOTB“ (Out of the box) baut das Release den Funktionsumfang des Open-Source-Editors aus. Die wichtigsten Neuerungen: ein nativer Plugin-Manager und das Ende störender UI-Blockaden.

Neovim ist ein Fork des Texteditors Vim. Das Projekt hat zum Ziel, die historische Codebasis zu modernisieren, und setzt auf eine asynchrone Architektur sowie eine API-getriebene Erweiterbarkeit. Als Konfigurations- und Skriptsprache dient Lua.

Nativer Plugin-Manager

Die zentrale Neuerung ist der in den Core integrierte, minimalistische Plugin-Manager vim.pack. Bislang mussten Nutzer für fast jedes Setup externe Paketmanager wie packer oder lazy.nvim per Skript herunterladen und initialisieren – das sogenannte Bootstrapping. Mit vim.pack genügt eine deklarative Lua-Konfiguration, um Erweiterungen direkt von GitHub zu laden und zu verwalten. Externe Manager bleiben nur noch für komplexe Setups nötig, etwa mit umfangreichem Lazy-Loading.

Außerdem ersetzt Neovim 0.12 die berüchtigte „Press ENTER“-Meldung durch eine experimentelle Nachrichten-UI. Die neue Oberfläche (vim._extui) ersetzt rund 3000 Zeilen alten C-Code und muss manuell aktiviert werden:

require('vim._extui').enable({})

Ohne Aktivierung bleibt das alte Verhalten erhalten – Nutzer können es aber über :set cmdheight=0 deaktivieren. In der neuen UI werden lange Nachrichten standardmäßig in der Kommandozeile mit einem Überlauf-Indikator (...) angezeigt. Bei cmdheight=0 oder expliziter Konfiguration (msg.pos = 'box') erscheinen sie stattdessen in einem Floating Window unten rechts.

Wer die vollständige Nachrichten-Historie oder lange Listen – etwa geöffnete Puffer via :ls – einsehen möchte, öffnet über das Tastenkürzel g< künftig ein reguläres, interaktives Editor-Fenster. Es ersetzt den bisherigen starren Pager. Die neue UI nutzt den Tree-sitter-Parser für Vimscript, um die Kommandozeile farblich hervorzuheben – etwa für Befehle und Argumente. Dieses Feature ist jedoch nur aktiv, wenn vim._extui eingeschaltet ist.

Hinzu kommen zwei neue Befehle: :restart startet den Editor-Prozess mitsamt Konfiguration neu, ohne dass die Terminal-Session geschlossen werden muss. :connect vereinfacht das Anbinden externer GUIs oder Headless-Instanzen über RPC.

Videos by heise

Einfacheres Remote-Plugin-System

Unter der Haube überarbeitet Neovim aktuell das System für Remote-Plugins. Diese Erweiterungen laufen in externen Sprachen wie Python oder Node.js und kommunizieren über MessagePack-RPC mit dem Editor. Bisher erforderte ihre Installation einen manuellen Registrierungsschritt: Der Befehl :UpdateRemotePlugins aktualisierte eine Manifest-Datei – ein fehleranfälliger Zwischenschritt. Für Version 0.13 plant das Projekt, Lua als nativen Plugin-Host einzusetzen – :UpdateRemotePlugins soll dann entfallen.

Alle Informationen zu Neovim 0.12 und zu den geplanten Updates finden sich auf der Webseite des Projekts und in den Release Notes auf GitHub.

Lesen Sie auch

Editor Neovim mit Plug-ins zur Python-IDE aufrüsten

Für Programmierer: Die Entwicklungsumgebung Neovim anpassen & erweitern

Top 10: Die beste Sportuhr im Test

Top 10: Die beste Dashcam fürs Auto im Test

Top 10: Die beste Soundbar mit Subwoofer im Test

Google veröffentlicht ADK 1.0 für Java

2026-03-31T09:48:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Google veröffentlicht ADK 1.0 für Java und erweitert sein Framework für KI-Agenten um Tools, Plugin-System und Zusammenarbeit zwischen Agenten.

(Bild: Besjunior / Shutterstock.com)

11:48 Uhr

Lesezeit: 2 Min.

Developer

Von

Madeleine Domogalla

Google hat das Agent Development Kit (ADK) für Java in Version 1.0.0 veröffentlicht und macht sein Framework für KI-Agenten damit erstmals auch für die weit verbreitete Java-Plattform verfügbar. Das Open-Source-Projekt, das ursprünglich in Python startete, wächst damit zu einem mehrsprachigen Ökosystem heran – neben Java unterstützt es auch Go und TypeScript.

Das ADK richtet sich an Entwicklerinnen und Entwickler, die KI-Agenten bauen wollen, die nicht nur Texte generieren, sondern aktiv mit ihrer Umgebung interagieren. Solche Agenten kombinieren Large Language Models (LLMs) mit Tools, Zustandsverwaltung und externen Datenquellen.

Mehr Tools und externe Datenquellen

Zu den wichtigsten Neuerungen zählen zusätzliche Tools für den Zugriff auf externe Informationen. So bindet etwa das GoogleMapsTool Ortsdaten direkt ein, während das UrlContextTool Webseiteninhalte automatisch abruft und zusammenfasst. Mit Code-Executoren können Agenten zudem eigenen Code lokal (Docker) oder in der Cloud ausführen.

Neu ist auch eine zentrale App-Struktur mit Plug-in-System. Damit lassen sich Funktionen wie Logging, Kontextfilterung oder globale Verhaltensregeln einmal definieren und auf alle Agenten anwenden.

Das Diagramm zeigt, an welchen Stellen Plug-ins und Callbacks in den Ablauf eines KI-Agenten eingreifen können.

(Bild: Google for Developers Blog)

Kontext, Kontrolle und Zusammenarbeit

Für längere Interaktionen führt ADK ein Context-Management ein, das ältere Gesprächsteile zusammenfasst, um Token-Limits und Kosten zu kontrollieren. Gleichzeitig unterstützt das Framework Human-in-the-Loop-Szenarien: Agenten können Aktionen pausieren und eine Freigabe einholen.

Hinzu kommen Bausteine für Sitzungs- und Langzeitspeicher sowie Unterstützung für das Agent2Agent-Protokoll, über das Agenten framework-übergreifend miteinander kommunizieren.

Videos by heise

Nähere Informationen bietet der Beitrag auf dem Blog Google for Developers sowie die Dokumentation zum Tool.

Lesen Sie auch

Java modernisiert: Einfacherer Einstieg und Programmstart

Moderne Java-Entwicklung: Online-Konferenz mit Deep-Dive-Vorträgen zu Spring

Java-Unkonferenz JSail: Mit vollem Segel zu aktuellen Java-Themen

Java 26 führt HTTP/3 ein und verzichtet endgültig auf die Applet-API

Zwei Tage Livestream von der JavaLand-Konferenz im Europa-Park Rust

Top 10: Die beste Sportuhr im Test

Top 10: Die beste Dashcam fürs Auto im Test

Top 10: Die beste Soundbar mit Subwoofer im Test

GitHub blendet Werbung in Pull Requests ein – Entwickler laufen Sturm

2026-03-31T08:48:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

WTF

GitHub Copilot hat bei Pull Requests ungefragt mit Hinweisen auf kommerzielle Produkte "geholfen". Inzwischen hat GitHub das Verhalten deaktiviert.

(Bild: Everett Collection / Shutterstock)

10:48 Uhr

Lesezeit: 2 Min.

Developer

Von

Rainald Menge-Sonnentag

GitHub Copilot hat in Pull Requests ungefragt Produkthinweise eingebaut, die deutlich nach Werbung aussehen. Die vermeintlich freundlichen Tipps finden sich nicht nur in den Pull Requests, die Copilot erstellt hat, sondern auch in solchen, die der KI-Helfer nur bearbeitet hat. Nach Verwunderung und Protesten hat GitHub das Verhalten nun deaktiviert.

Fehlerkorrektur mit Werbebonus

Der Entwickler Zach Manson hat am 30. März einen Screenshot eines Pull Request veröffentlicht, bei dem Copilot Tippfehler korrigieren sollte und der nach der Korrektur einen zusätzlichen Hinweis enthielt: „Quickly spin up Copilot coding agent tasks from anywhere on your macOS or Windows machine with Raycast“. Das Wort Raycast hat Copilot freundlicherweise direkt mit einem Link zum Produktivitätstool versehen.

Der Entwickler Zach Manson hat einen Screenshot des erweiterten Pull Requests gepostet.

(Bild: Zach Manson)

Der Pull Request von Zach Manson war kein Einzelfall: Eine Suche auf GitHub zeigt denselben Hinweis in gut 11.000 Pull Requests.

Videos by heise

Über 1,5 Millionen Pull Requests und auch GitLab betroffen

Offenbar hat Raycast die Werbung nicht einmal selbst beauftragt. Ein Artikel auf Neowin zeigt, dass sich im Markdown zum Pull Request der versteckte HTML-Kommentar „START COPILOT CODING AGENT TIPS“ findet.

Neowin hat ähnliche „Hinweise“ auf weitere Produkte in insgesamt 1,5 Millionen Pull Requests gefunden und den Raycast-Tipp nicht nur auf GitHub, sondern auch in mit Copilot bearbeiteten Merge Requests auf GitLab entdeckt. „Nützliche Hinweise“ gab es auch zu Integrationen für Slack und Microsoft Teams sowie zum Starten von Copilot-Aufgaben direkt aus Editoren wie VS Code, Visual Studio, JetBrains-IDEs und Eclipse.

Keine ungefragten Hinweise mehr

Inzwischen ist GitHub zurückgerudert. Auf Hacker News hat Tim Rogers aus dem Copilot-Coding-Agent-Team geschrieben, dass die Pull Requests nun keine Hinweise mehr enthalten. „Wir haben in den vom Copilot-Coding-Agent erstellten PRs Produkttipps eingefügt. Das Ziel war es, Entwicklern dabei zu helfen, neue Möglichkeiten für den Einsatz des Agenten in ihrem Arbeitsablauf zu entdecken. Doch angesichts des Feedbacks hier und nach reiflicher Überlegung war die Entscheidung falsch. Wir werden so etwas nicht wieder tun.“

Auf X hat Martin Woodward von GitHubs Developer-Relations-Team geschrieben, dass die Tipps ursprünglich für vollständig von Copilot erstellte Pull-Requests gedacht und da noch ganz in Ordnung waren, aber es wurde eklig, als Copilot sich in jeden PR einmischte, bei dem er mitmischte.

(rme)

Top 10: Die beste Sportuhr im Test

Top 10: Die beste Dashcam fürs Auto im Test

Top 10: Die beste Soundbar mit Subwoofer im Test

Software Testing: TACON – Eine Praxis-Konferenz rund um Testautomatisierung

2026-03-31T06:25:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Richard Seidl spricht mit André Köhler über die TACON, eine Konferenz mit klarem Fokus auf Testautomatisierung.

(Bild: Richard Seidl)

08:25 Uhr

Lesezeit: 1 Min.

Developer

Von

Richard Seidl
André Köhler

In dieser Episode sprechen Richard Seidl und André Köhler über die TACON, eine Konferenz mit klarem Fokus auf Testautomatisierung. Die beiden beleuchten, warum sie entstanden ist, was sie unterscheidet und wohin sie sich entwickelt. Praxisberichte aus Unternehmen, offene Einblicke in Stolpersteine und ein lernfreundliches Format prägen das Programm. Die familiäre Größe mit rund 130 Teilnehmenden und der feste Standort Leipzig schaffen Nähe, kurze Wege und abends tiefe Gespräche. Neue Elemente wie eine Gaming Area bringen Leichtigkeit.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden

André Köhler ist Gründer und Geschäftsführer von summit. Das Team von summit richtet zahlreiche Fachkonferenzen, Kongresse und Community Days rund um IT-Managementthemen aus. Dazu gehört auch die TACON (Test Automation Conference), die einmal jährlich stattfindet und interessierte Personen aus dieser Domäne zusammenbringt. Köhler ist darüber hinaus Professor für IT-Management an der IU Internationale Hochschule, wo er zu IT-Servicemanagement und IT-Projektmanagement lehrt und forscht.

Lesen Sie auch

betterCode() Testing 2026: Programm und Online-Workshops stehen fest

Top 10: Die beste Sportuhr im Test

Top 10: Die beste Dashcam fürs Auto im Test

Top 10: Die beste Soundbar mit Subwoofer im Test

GitHub Store 1.7.0: Updates ohne Klick, Sicherheit ohne Root

2026-03-30T12:50:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Automatische Updates, Silent Install, App-Repo-Verknüpfung und Signaturprüfung: GitHub Store wird mit Version 1.7.0 zum Power-User-Werkzeug.

(Bild: Sundry Photography / Shutterstock.com)

30.03.2026, 14:50 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

GitHub Store baut in Version 1.7.0 seine Open-Source-Software deutlich in Richtung Automatisierung und Power-User-Funktionen aus. Im Mittelpunkt stehen automatische Hintergrund-Updates mit optionaler Silent-Installation unter Android, eine neue Funktion zum Verknüpfen installierter Apps mit ihren GitHub-Repositories (genannt „Link Apps“) sowie eine überarbeitete Einstellungsoberfläche. Hinzu kommen Sicherheitsfunktionen wie eine APK-Signaturprüfung und Unterstützung für GitHub Artifact Attestations.

Der GitHub Store nutzt GitHub-Repositories als Quelle für Anwendungen. Nutzer installieren Apps direkt aus den Release-Artefakten, verfolgen Updates und beziehen Open-Source-Software ohne klassischen App-Store. Das Projekt versteht sich als Alternative zu Plattformen wie F-Droid, allerdings mit GitHub als zentralem Distributionskanal. Das Projekt ist trotz des Namens kein offizielles Microsoft-Produkt.

Updates im Hintergrund – ohne Antippen

Zu den wichtigsten Neuerungen gehört die Kombination aus automatischen Update-Prüfungen und Silent-Installation. Nutzer legen fest, in welchem Intervall – zwischen drei und 24 Stunden – der Client nach neuen Versionen sucht. In Verbindung mit Shizuku installiert er Updates unter Android ohne weitere Interaktion. Shizuku ermöglicht den Zugriff auf privilegierte System-APIs, ohne dass Root-Rechte nötig sind. So bleiben auch häufig aktualisierte Tools oder Nightly-Builds automatisch auf dem neuesten Stand, ohne dass APK-Dateien manuell installiert werden müssen.

Die neue Funktion „Link Apps“ verknüpft lokal installierte Anwendungen mit ihren GitHub-Repositories. Nutzer wählen eine installierte App aus, hinterlegen die Repository-URL und ordnen das passende Release-Asset zu. Der Client prüft Paketname und Signaturschlüssel, um die korrekte Zuordnung sicherzustellen. Das löst ein häufiges Problem bei GitHub-basierten Installationen: Releases lassen sich nicht immer eindeutig einer installierten App zuordnen. Nach der Verknüpfung übernimmt der Store das Update-Tracking automatisch. Verknüpfungen lassen sich außerdem exportieren und wieder importieren – praktisch beim Gerätewechsel.

Videos by heise

Zum Verbessern der Sicherheit prüft Version 1.7.0 vor jeder Installation die APK-Signatur. Der Client gleicht Fingerprints ab, um Manipulationen oder inkonsistente Releases zu erkennen. Zusätzlich unterstützt er GitHub Artifact Attestations. Hierbei handelt es sich um signierte Metadaten, mit denen sich Herkunft und Integrität eines Build-Artefakts nachvollziehen lassen, etwa im Sinne von SLSA. Stimmen Signaturschlüssel nicht überein, zeigt der Client eine Warnung an.

Einstellungen zentral gebündelt

Die Einstellungen hat das Projekt in einem neuen „Tweaks Screen“ zusammengefasst. Kategorien wie Netzwerk, Updates, Installation oder Darstellung sind dort zentral konfigurierbar. Der Profilbereich beschränkt sich nun auf Account- und Sammlungsfunktionen.

Außerdem bringt das Release eine Reihe von Komfort- und Discovery-Verbesserungen. Der Client speichert Suchverläufe lokal und löst Suchanfragen nur noch bei expliziter Bestätigung aus – das spart unnötige API-Aufrufe. Eine Zuletzt-Angesehen-Übersicht (Recently Viewed) zeigt zuletzt geöffnete Repositories an. Außerdem unterstützt der Home-Bildschirm nun themenbasiertes Filtern von Projekten anhand von GitHub Topics – Caching sorgt dabei für schnelle Ergebnisse. Bereits betrachtete Repositories lassen sich als „gesehen“ markieren und aus dem Feed ausblenden.

Neben den neuen Funktionen behebt Version 1.7.0 zahlreiche Fehler, unter anderem bei Netzwerk- und Proxy-Verbindungen auf dem Desktop sowie beim Umgang mit Downloads und Paketinstallationen. Für Linux-Desktop-Nutzer führt das Release außerdem Flatpak-Unterstützung ein. Die Vorgängerversion 1.6.0 hatte den Linux-Support deutlich ausgebaut. Auch die Build-Infrastruktur wurde überarbeitet: Das Projekt integriert ktlint und führt Gradle-Builds nun parallel aus. Alle Änderungen im Detail listen die Release Notes auf GitHub auf.

(fo)

Top 10: Die beste Sportuhr im Test

Top 10: Die beste Dashcam fürs Auto im Test

Top 10: Die beste Soundbar mit Subwoofer im Test

XPipe 22.0: Passwortmanager werden zum SSH-Schlüsselbund

2026-03-30T09:33:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

XPipe 22.0 bietet flexiblere Authentifizierung, eine erweiterte Integration von Passwordmanagern und Verbesserungen bei Containern.

(Bild: XPipe)

30.03.2026, 11:33 Uhr

Lesezeit: 3 Min.

iX Magazin

Von

Moritz Förster

XPipe liegt in Version 22.0 vor. Das Update bringt vor allem eine flexiblere Authentifizierung, eine ausgebaute Integration von Passwordmanagern und Verbesserungen bei Containern. Im Zentrum stehen Multi-Identitäten und die direkte Nutzung von SSH-Agenten aus gängigen Passwort-Tools.

Das Open-Core-Projekt richtet sich an Administratoren, DevOps-Teams und alle Nutzer, die viele Remote-Verbindungen und Shells einsetzen. Es dient als zentrale Oberfläche zum Starten und Verwalten von SSH-, Container-, VM- und weiteren Infrastruktur-Verbindungen.

Nutzer können jetzt mehrere Identitäten pro Zielsystem hinterlegen und zwischen ihnen wechseln. In Team-Vaults wählt XPipe automatisch eine verfügbare lokale Identität, wenn referenzierte Identitäten für den aktuellen Anwender nicht verfügbar sind. Statt mehrere Verbindungen für denselben Host anzulegen, können unterschiedliche Nutzer oder Rollen innerhalb einer Verbindung koexistieren.

Passwordmanager mit SSH-Agent-Support

XPipe unterstützt nun die SSH-Agenten von 1Password, Bitwarden, KeePassXC, Keeper und Proton Pass direkt. Laufende Agenten erkennt das Tool automatisch – eine manuelle Socket-Konfiguration entfällt. Zugangsdaten und SSH-Keys bezieht es gemeinsam aus dem Passwordmanager, was lokale Key-Dateien überflüssig machen kann. Schlüssel lassen sich im Agent-Feld auch über ihren Namen referenzieren, sofern der eingesetzte Passwortmanager das unterstützt. Darüber hinaus unterstützt XPipe jetzt mehrere 1Password-Konten gleichzeitig, zusätzliche Paketierungsformen von Bitwarden, KeePassXC und Keeper sowie nun auch Proton Pass; außerdem kann XPipe Secrets aus HashiCorp Vault abrufen.

Für Incus und LXD erkennt XPipe nun Container über alle Projekte, also getrennte Verwaltungsbereiche ähnlich Namensräumen, hinweg. Wenn ein Container eine IP-Adresse meldet, kann XPipe diese zum direkten Öffnen von Diensten nutzen, etwa für RDP- oder VNC-Verbindungen.

Für Podman verbessert Version 22.0 den Umgang mit Quadlets, also systemd-basierten Containerdefinitionen. XPipe erkennt zugehörige Unit-Files und erlaubt deren Bearbeitung. Ein Neustart greift korrekt auf den systemd-Service durch, statt nur den Container isoliert neu zu starten.

Videos by heise

Erweiterte Suche und Schnellzugriff

Die Suchleiste nimmt jetzt direkte Befehle entgegen. Wer etwa ssh user@host eingibt, startet sofort die passende Verbindung oder landet in einem Quick-Connect-Dialog. Die Filterung soll zudem spürbar schneller bei großen Verbindungslisten reagieren.

Kategorien lassen sich jetzt mit eigenen Icons versehen. Theme-Wechsel laufen flüssiger, und der neue Shortcut Strg+T öffnet das Terminal-Dock, das in der Vorgängerversion eingeführt wurde. Hinzu kommen zahlreiche Bugfixes, unter anderem bei SSH-Aliasen, gemischten Shell-Umgebungen und auf Windows-Systemen. Alle Informationen zu XPipe 22.0 finden sich in den Release Notes.

Siehe auch:

XPipe bei heise download

(fo)

heise developer News

Open-Source-CMS von Cloudflare: EmDash fordert WordPress heraus

Plug-ins in eigener Sandbox

Integrierte KI-Features

Wie funktioniert eigentlich ein Open-Source-Projekt – ein Blick in Kubernetes

Drei Kategorien von Special Interest Groups

Wer sollte sich engagieren und wie gelingt der Einstieg?

Die Contributor Ladder als Karrierepfad

Claude Code geleakt: Milliarden für KI-Sicherheit, null für Softwarehygiene

Debug-Artefakte im Produktions-Build – ein Klassiker

Visual Studio 2026 erlaubt das Erstellen benutzerdefinierter KI-Agenten

Agent Skills und benutzerdefinierte Agenten

Copilot behebt NuGet-Vulnerabilities

Event Sourcing trifft MCP: Die ganze Geschichte für LLMs

Warum Kontext für LLMs alles entscheidet

MCP als universelle Brücke

Was ein LLM in einer Bibliothek sehen kann

Warum Events die natürliche Sprache für LLMs sind

Von der Idee zur Praxis

Nicht die Technik entscheidet, sondern die Daten dahinter

Analyse: Darf KI Kernfeatures in kritische Software implementieren?

Debatte um Node.js

Umgang mit KI-Flut und ihren Risiken

Verlässliche Richtlinien statt KI-Verbot

software-architektur.tv: Analyse großer Softwaresysteme mit LLMs

Empfohlener redaktioneller Inhalt

Livestream am 2. April

Bund veröffentlicht lizenzfreie KI-Werkzeuge

Startpunkt Dokumentenprüfung

Sicherheit und technische Hürden

Malware auf npm: HTTP-Client axios lädt Backdoor für Windows, macOS und Linux

Plattformübergreifender Angriff

Command & Control

Zurück zu Version 1.14.0

Drei Fragen und Antworten: Warum ABAP-Entwickler jetzt umdenken müssen

Android-Sideloading: Entwickler können sich nun bei Google registrieren

RxDB 17: Sync ohne Server, Zugang für KI-Agenten

Synchronisation ohne Server

KI-Agenten greifen direkt auf die Datenbank zu

Besser für LLMs

Performance und Stabilität

Breaking Changes und Migration

OLG Bamberg: TikTok schummelt bei DSA-Pflichten

TikTok will sich dem Verfahren nicht stellen

Interface-Tricks

Nur so wird korrekt gemeldet

Anthropics Claude Code: Kompletter Quellcode im Netz

Source Map als Einfallstor

Modulare Architektur mit Bun und React

Neovim 0.12 mit nativem Plugin-Manager

Nativer Plugin-Manager

Einfacheres Remote-Plugin-System