Es war ein denkwürdiger Auftritt am Nachmittag des 11. Juni 2024: Apples damaliger KI-Chef John Giannandrea und Software-Chef Craig Federighi demonstrierten auf der Bühne des Steve Jobs Theater im Apple-Hauptquartier in Cupertino den großen Schulterschluss. Die von Apple-Chef Tim Cook eingeleitete Fragestunde mit YouTuberin iJustine sollte die kurz zuvor vorgestellte Apple Intelligence inhaltlich vertiefen und vermutlich ein Signal der Einmütigkeit in der Apple-Chefetage ausstrahlen. Jetzt, nicht einmal zwei Jahre danach, wird Giannandrea das Unternehmen zur Monatsmitte verlassen.

Das Schicksal des früheren Google-Mitarbeiters ist eng verknüpft mit den KI-Bemühungen Apples. Damals angekündigte Grundfunktionen der Apple Intelligence wie das Zusammenfassen von Texten oder maßgeschneiderte Emojis erreichten zwar binnen weniger Monate einen großen Teil der Apple-Kundschaft. Der Blick der Fachwelt richtete sich allerdings mehr auf das, was nicht kam: Siri sei kein Sprachassistent mehr, sondern ein Geräteassistent mit tieferem Verständnis dafür, was auf dem Gerät passiert, tönte Giannandrea in der damaligen Fragestunde. Zwei Jahre später gibt es immer noch nur die Ankündigung, dass Siri besser werden soll. Zuletzt verdichteten sich jedoch Berichte, wonach Apple für iOS 27 eine eigene Siri-App sowie einen Chatbot-Modus plant.

KI-Weichen neu gestellt

Giannandrea kam im Jahr 2018 zu Apple. Bei Google war er zuvor acht Jahre lang tätig. Seine Expertise in Machine-Learning passte gut zu Apples Ambitionen, die mit der Neural Engine auch in Hardware gegossen wurden. Doch als mit ChatGPT von OpenAI Jahre später die generativen Sprachmodelle einen Hype auslösten, wirkte Apple wie auf dem falschen Fuß erwischt. Die Vorstellung der Apple Intelligence, 2024, sollte der Befreiungsschlag werden. Die „AI for the rest of us“ (KI für den Rest von uns) sollte mit dem Datenschutz-Vorrang punkten. Stattdessen machte Apple Schlagzeilen damit, dass die KI-Siri offenbar gar nicht funktionierte und das Projekt offenbar komplett zurückgesetzt werden musste. Intern gilt die Dauerbaustelle Siri bereits seit Längerem als Problemfall, da versprochene Funktionen immer wieder verschoben wurden.

Die diesjährige Entwicklerkonferenz WWDC am 8. Juni soll nun den Trubel der vergangenen Jahre vergessen machen. Apple ist eine Kooperation mit Google eingegangen, um deren KI-Modell Gemini zu verwenden. Vor allem aber wurden erhebliche Veränderungen in der Leitung vorgenommen. Dabei gilt Federighi intern als Verfechter eines eher pragmatischen KI-Kurses mit Fokus auf Budgets und Partnerschaften. Der ehemalige Vision-Pro-Chef brachte für den Umbau der Siri-Abteilung zahlreiche Experten aus seinem alten Team mit. Weitere erfahrene Kräfte, die es richten sollen, sind Eddy Cue und Sabih Khan. Erneut ist ein Ex-Googler mit in der Verantwortung: Neuzugang Amar Subramanya soll als Vice President of AI aber deutlich weniger Eigenständigkeit genießen als sein Vorgänger. Er berichte an Federighi.

Videos by heise

Eine letzte Aktienprämie

Giannandrea war in den vergangenen Monaten nur noch Berater für Apple. Sein Rückzug wurde im Dezember 2025 angekündigt, nachdem zuvor bereits laut geworden war, dass es zwischen den Ressortleitern bei Apple geknirscht hat. Bereits im März 2025 habe Cook Giannandrea deshalb die Leitung des Siri-Teams entzogen, hieß es in Medienberichten. Es war ein Rückzug in Raten. Sein Verbleib bis Mitte April erklärt Bloomberg-Reporter Mark Gurman mit den üblichen Gepflogenheiten in börsennotierten Unternehmen, um Giannandrea noch eine letzte Aktienprämie auszahlen zu können.

Nach Apple will der frühere KI-Chef laut Bericht in verschiedenen Unternehmensvorständen mitwirken und als Berater für Start-up-Unternehmen tätig werden. Wie stark Apples stotternder KI-Motor tatsächlich mit seiner Person verknüpft war, wird sich in den nächsten Monaten zeigen. Finanziell profitiert der Konzern trotz technischer Rückstände massiv: Erwartungen zufolge wird Apple bald eine Milliarde US-Dollar durch KI-Apps im App Store verdienen.

Lesen Sie auch

KI-Betrug: Deutsche überschätzen ihre Fähigkeit, Deepfakes zu entlarven

Confluence-Seiten per KI in Diagramme, Prototypen und Apps verwandeln

Netflix-Synchronisationen: Schauspielergewerkschaft gegen Sprecherverband

KI-Update kompakt: BSI warnt vor Mythos, Muse Spark, KI-Urteil, Apple-Klage

Interview: Puraite will Evidenzsynthese mit erklärbarer KI beschleunigen

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Einfache UX für domänenspezifische Sprachen mit VS Code gestalten

2026-04-11T07:41:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Steuererklärung, Prozesse oder Bauplanungen: Vieles lässt sich mit einer domänenspezifischen Sprache darstellen. Editoren mit LSP machen die Umsetzung leicht.

(Bild: lassedesignen / Shutterstock.com)

11.04.2026, 09:41 Uhr

Lesezeit: 13 Min.

Developer

Von

Georg Hinkel

Lohnt es sich, eine eigene Programmiersprache samt Syntax-Highlighting, Code Completion anderen Features im Editor nur für ein einzelnes Projekt zu erstellen? Was sich auf den ersten Blick nach viel Arbeit anhört, ist dank Language Server Protocol (LSP) deutlich einfacher geworden. Durch die reichhaltigen Möglichkeiten zur Interaktion mit Texteditoren wie Visual Studio Code eignen sich domänenspezifische Sprachen (Domain Specific Languages, DSL) als eine vollwertige und auch unterschätzte Möglichkeit der Gestaltung einer UX.

(Bild:

Georg Hinkel

)

Georg Hinkel forscht und lehrt an der Hochschule RheinMain zu den Themenschwerpunkten Softwaretechnik, modellgetriebene Softwareentwicklung und verteilte Systeme. Er ist außerdem Maintainer des Open-Source-Projekts NMF.

Anwenderinnen und Anwender jenseits der Informatik nehmen Spezifikationen oft mit Formularen vor. Je komplexer die Anforderungen sind, desto komplizierter wird die Umsetzung per Formular. Ein grotesk wirkendes Beispiel zeigt Abbildung 1: Anweisungen für einen Compiler, über ein Formular zu spezifizieren.

Programmieren per Formular wirkt grotesk (Abb. 1)

Gleich mehrere Gründe machen diese Idee so absurd:

Die Spezifikation ist völlig aufgebläht: Die noch unvollständige Implementierung des Heron-Verfahrens zum Wurzelziehen lässt sich auch mit nur drei Zeilen Code umsetzen.
Als direkte Folge davon ist das Formular deutlich schwerer verständlich.
Für erfahrene Nutzer ist eine Programmiersprache sehr viel effizienter, weil sie in der gleichen Zeit wesentlich mehr Spezifikationen verfassen können.
Es ist nur schwer vorstellbar, wie man eine formularbasierte Programmspezifikation versionieren kann. Textbasierte Algorithmen, wie Git sie verwendet, funktionieren hier vermutlich nicht.

Eine komplexe Spezifikation ist keine Besonderheit der Informatik, auch in anderen Fachbereichen gibt es schwierige Probleme, die immer mehr mithilfe von Computern gelöst werden sollen. Das kann die Automatisierung von Workflows sein, die Planung von Bauteilen oder Gebäuden, die Dokumentation von manuellen Prozessen oder vieles mehr. Ein Erfolgsfaktor von Programmiersprachen ist sicherlich, dass Programme sowieso abstrakt sind, während sich physische Bauteile oder Gebäudepläne schon immer auch grafisch haben repräsentieren lassen. Das Beispiel von Prozessautomatisierung zeigt aber, dass in vielen Bereichen ebenfalls abstrakte Konzepte auftreten.

Innerhalb der Informatik haben sich textuelle Sprachen auch jenseits des Programmierens bewährt. Admins legen Infrastrukturen in der Cloud schon lange nicht mehr per Formular an (diese Praxis wird eher als ClickOps geschmäht), sondern in Textform per Infrastructure-as-Code. Die Gründe sind dieselben: die Spezifikation ist schlanker, verständlicher, einfacher zu versionieren und man ist damit schneller.

Einfacher zu versionieren als Formulare, sind generische Formate wie JSON oder XML. Sie sind allerdings ursprünglich nicht dafür gedacht, für Menschen lesbar zu sein, sondern für Maschinen. Da viele Anwendungen ohnehin eine maschinenlesbare Sprache benötigen, ist es bequem, diese auch als alternative Schnittstelle anzubieten.

Aber auch solche Konfigurationsdateien erreichen nicht die Prägnanz, Lesbarkeit und Effizienz einer domänenspezifischen Sprache, zumal auch Validierungstechnologien wie XML Schema oder JSON Schema nur die Struktur der Dokumente validieren, aber wenig zur fachlichen Analyse beitragen können.

DSL als Alternative zu Formularen und Konfigurationsdateien

Komplexe Vorgänge, die Menschen gern sehr prägnant, lesbar und versionierbar ausdrücken wollen, kann man vorteilhaft mit einer domänenspezifischen Sprache spezifizieren, mit der gleichen Editorunterstützung wie bei Programmiersprachen. Beispiele wären Reisekostenabrechnungen, Nebenkostenabrechnungen, Steuererklärungen, Umsatzabfragen, Prozessautomatisierungen oder Bauplanungen.

Videos by heise

LLM-basierte Chatfunktionen sind dabei kein Ersatz für domänenspezifische Sprachen, umgekehrt aber können domänenspezifische Sprachen die Intention eines KI-Systems einfacher überprüfbar machen. Anstatt agentenbasierte Systeme kritische Dinge tun zu lassen (was zumindest in der EU per AI Act streng reglementiert ist), kann man KI-Systeme auch eine in natürlicher Sprache vorliegende Beschreibung in eine DSL umformulieren lassen.

Das Language Server Protocol als Enabler für eine DSL-UX

Die Entwicklung einer domänenspezifischen Sprache reduziert sich nicht nur auf einen Parser: Nutzerinnen und Nutzer sind den Komfort von Syntax-Highlighting, Code Completion, bequemes Springen zur Definition oder zu Referenzen gewohnt, die wesentlich für eine gute UX und gesteigerte Produktivität sind. In den letzten Jahren ist dies durch das von Microsoft entwickelte Language Server Protocol (LSP) deutlich einfacher geworden. Dieses Prinzip hat sich auf weitere Bereiche ausgeweitet, zum Beispiel auf grafische Sprachen mit dem Graphical Language Server Protocol (GLSP). LSP und GLSP erlauben es, weitgehend auf die Entwicklung von UI-Komponenten zu verzichten und sich stattdessen auf die Semantik einer Sprache zu konzentrieren.

Aus diesem Grund können Editoren wie Visual Studio Code mit beliebigen Programmiersprachen umgehen: Während sie als Frontend immer dasselbe UI verwenden (im Fall von Visual Studio Code den Monaco-Editor), liefert ein LSP-Server die sprachspezifische Editorunterstützung. Da LSP auf JSON-RPC basiert, das keine Transportschicht definiert, lässt sich LSP wahlweise über stdin/stdout oder über Websockets betreiben. Das ermöglicht viele Optionen für das Deployment: Der Client kann in einer Desktopanwendung (in Fall von Visual Studio Code via Electron) oder im Browser laufen, während der Server entweder in die IDE eingebettet oder auf einem entfernten Rechner arbeitet.

Mittlerweile gibt es für die Entwicklung von LSP-Servern mehrere Frameworks, je nachdem, mit welcher Programmiersprache man die DSL entwickeln will. Für die Beschreibung der Grammatik der DSL kommt ebenfalls eine DSL zum Einsatz. Daraus generiert das Framework Parser, Klassen für den abstrakten Syntaxbaum und die Editorunterstützung. Entwicklerinnen und Entwickler können das Ergebnis durch manuellen Code ergänzen oder überschreiben. Beispiele für entsprechende Tools sind Xtext für Java (siehe auch: [1]), Langium für TypeScript und AnyText für .NET (siehe auch [2]).

Eine neue DSL entwickeln

Der Startpunkt für die Entwicklung einer neuen DSL ist mit allen dreien der genannten Frameworks eine Grammatik, die auch die abstrakte Syntax der Sprache ausdrückt. Die abstrakte Syntax ist hierbei die Definition der Konzepte, die die Sprache ausmachen. Für die Grammatik werden bei Xtext und Langium kontextfreie LL(k)-Grammatiken verwendet, bei AnyText Parse-Expression-Grammatiken (PEGs). Beide Klassen von Grammatiken arbeiten mit Nichtterminalen (= Platzhaltern) und Produktionsregeln, die bestimmen, wie ein Nichtterminal ersetzt werden kann. Diese Produktionsregeln lassen sich bequem über die Metasprache Erweiterte Backus-Naur-Form (EBNF) spezifizieren, die zusätzlich noch um Zuweisungen ergänzt wird, um auch die abstrakte Syntax angeben zu können.

Praktischerweise bietet Langium mit dem Playground eine Möglichkeit an, mit der Entwicklung einer DSL ohne Installation einer Software direkt im Browser zu beginnen. Für Xtext oder AnyText bieten die Tutorials gute Einstiegspunkte.

Um beispielsweise die (hier vereinfachte) Deklaration einer Klasse in einer Programmiersprache zu spezifizieren, genügt das folgende Fragment:

Class: ‘class’ name=ID ‘{‘ members+=ClassMember* ‘}’;

Dieses Beispiel geht davon aus, dass es weitere Nichtterminale ID und ClassMember gibt, die regeln, wie ein Identifier genau aussieht und was zulässige Member einer Klasse sein können. Der Postfixoperator * erlaubt hierbei beliebig viele Member. Alternativ sind auch + oder ? möglich, um mindestens oder höchstens ein Vorkommen zu beschreiben. Der Operator | erlaubt auch Alternativen, was unterschiedliche Arten von Membern ermöglicht. Besteht eine Regel ausschließlich aus Alternativen, dann wird das in der abstrakten Syntax durch Inheritance abgebildet.

Die Zuweisung = bzw. += weist das System darüber hinaus an, das Ergebnis des Nichtterminals ID bzw. ClassMember dem abstrakten Element des Nichtterminals zuzuordnen. Das geht entweder als einwertige Eigenschaft (beispielsweise, dass das Ergebnis von ID den Namen bilden soll) oder als mehrwertige Eigenschaft, dass das Ergebnis von ClassMember zur Auflistung members hinzugefügt werden soll.

Aus diesen Zuweisungen lassen sich dann auch Klassen ableiten, um die abstrakten Elemente der Sprache im Speicher darstellen zu können. Sowohl Xtext und Langium als auch AnyText unterstützen den Operator [], mit dem sich Referenzen abbilden lassen, dass also an einer gegebenen Stelle nur eine Referenz auf ein anderes syntaktisches Element erscheinen soll.

Die Konstruktion des Parsers bleibt zwar weitestgehend vor den Entwicklern verborgen, allerdings haben manche Klassen von Grammatiken Einschränkungen, die Entwickler einer DSL berücksichtigen müssen. So sind die Produktionen bei kontextfreien Grammatiken ungeordnet, bei PEGs aber geordnet, weswegen es konstruktionsbedingt keine Mehrdeutigkeiten gibt. Gängige Parser für kontextfreie Grammatiken unterstützen keine Linksrekursionen, für PEGs aber schon.

Die Ordnung von Alternativen bedeutet, dass eine Alternative nur dann überhaupt in Betracht gezogen wird, wenn die vorherigen Alternativen fehlschlagen. Das hat zur Folge, dass es niemals Mehrdeutigkeiten geben kann und beispielsweise bei if-Statements in C-ähnlichen Sprachen ein else-Block immer dem inneren if zugeschlagen werden würde. Das kann in vielen Fällen erwünscht sein, weil die Sprache damit niemals mehrdeutig ist, kann aber auch gegen Intuition verstoßen. Beispielsweise matcht die Grammatik S: ‚a’S’a’ | ‚aa’ als kontextfreie Grammatik alle Wörter mit einer geraden Anzahl des Buchstabens a, als PEG aber nur Wörter, die nur aus a bestehen und deren Länge eine Zweierpotenz > 1 ist. Gerade wenn man kontextfreie Grammatiken gewohnt ist, ist dieses Verhalten kontraintuitiv. Aus meiner Sicht betrifft das aber nur eher pathologische Fälle.

Die Unterstützung von Linksrekursionen ist vor allem für Ausdrücke wichtig, da man damit sehr intuitiv Formeln umsetzen kann. Insbesondere sind binäre Ausdrücke selbst Ausdrücke, beginnen aber auch mit einem Ausdruck. Für PEGs haben Warth und andere [3] eine Erweiterung von Packrat-Parsern entwickelt, die Linksrekursionen parsen kann, wobei das lineare Laufzeitverhalten von Packrat-Parsern erhalten bleibt.

In AnyText lässt sich daher eine einfache Expression-Grammatik wie in Listing 1 unten dargestellt implementieren. Hierbei überschreibt das Schlüsselwort returns, welche Klasse der abstrakten Syntax das Nichtterminal zurückgibt. Im Beispiel dient es dazu, nicht für jedes einzelne Nichtterminal eine Klasse einführen zu müssen. Das Schlüsselwort enum kommt zum Einsatz, um eine fixe Menge von Werten abzubilden. Ferner beschreibt das Schlüsselwort parantheses ein Nichtterminal für Klammerungen und terminal ein Terminal, dargestellt durch einen regulären Ausdruck.

grammar Expressions (exp)
root Expression

Expression:
  AdditiveBinary | Multiplicative;
AdditiveBinary returns BinaryExpression:
  left=Expression operator=AdditiveOperator right=Expression;
enum AdditiveOperator returns BinaryOperator:
  Add => '+'
  Subtract => '-';
Multiplicative returns Expression:
  MultiplicativeBinary | LiteralExpression | VariableExpression | ParanthesisExpression;
MultiplicativeBinary returns BinaryExpression:
  left=Multiplicative operator=MultiplicativeOperator right=Multiplicative;
enum MultiplicativeOperator returns BinaryOperator:
  Multiply => '*'
  Divide => '/';
LiteralExpression:
  value=Number;
VariableExpression:
  variable=Identifier;
parantheses ParanthesisExpression:
  '(' Expression ')';
terminal Number returns nmeta.Integer:
  /\d+/;
terminal Identifier:
  /[a-zA-Z]\w*/;

UX-Interaktionen im Editor über LSP

LSP ist nicht nur auf das Parsen von Text begrenzt, sondern erlaubt auch praktische Interaktionen mit einem Text in der IDE. Programmiererinnen und Programmierern sind Features wie Code Lenses oder Code Fixes geläufig. Sie erlauben es, Analyseergebnisse wie die Anzahl der Referenzen oder Autor und Datum der letzten Änderung an einer Methode einfach in das Sichtfeld einzublenden. Interaktionen wie Refactorings lassen sich ebenfalls direkt aus dem Code heraus starten.

Zu Features dieser Art gehören:

Diagnostics: In den seltensten Fällen lassen sich Einschränkungen allein durch die Grammatik ausdrücken, auch domänenspezifische Analysen können auf Fehler hindeuten. Beispielsweise könnte man in einer DSL für Überweisungen eine Analyse des Empfängernamens einbauen und Fehler melden, sollte der Name nicht zur IBAN passen.
Code Lenses: Code Lenses können an einer beliebigen Stelle im Text eine beliebige Zeichenkette anzeigen. Damit lassen sich viele Arten von Analysen darstellen. Code Lenses können auch Aktionen anbieten, zum Beispiel öffnet sich beim Klicken auf die Anzeige der Referenzen üblicherweise ein Fenster mit Details. Einige Editoren bieten auch an, Unit Tests per Code Lens zu starten. Recht generisch könnte man Code Lenses verwenden, um in einer DSL den derzeitig beschriebenen Zustand auf ein modelliertes System anzuwenden.
Code Actions: Von Editoren wie der Visual-Studio-Familie mit einem Lampensymbol dargestellt, erlauben es Code Actions, zum Kontext passende Interaktionen auszuführen.
Inlays: Inlays blenden Texte im Editor ein, die eigentlich gar nicht dort stehen. Während dieses Feature in Programmiersprachen vor allem dazu dient, inferrierte Typsignaturen oder Parameternamen einzublenden, lässt es sich prinzipiell für beliebige Analysen verwenden.
Hover: Verweilt ein Nutzer mit der Maus auf einem Token, kann ein LSP-Server Kontextinformationen dazu liefern. Eine sehr clevere Nutzung ist beispielsweise, einen Hovertext für Schlüsselwörter mit Erklärungen dazu anzubieten. Gerade weil eine DSL nur für einen eingeschränkten Nutzerkreis gedacht ist, kann eine solche Unterstützung die Anwendung leichter zugänglich machen.

AnyText macht die Entwicklung dieser Features besonders einfach, indem es für jede Regel in der Grammatik eine Klasse generiert, in der Entwickler meist nur eine entsprechende Methode überschreiben müssen, um das jeweilige Feature zu aktivieren. Aber auch mit Langium oder Xtext lassen sich diese Features einfach nutzen.

Fazit: Alternative UX-Technologie

Domänenspezifische Sprachen haben neben Formularen oder KI-Agenten einen eigenen Platz als Möglichkeit verdient, mit der Endanwender spezifizieren, welche Probleme der Computer lösen soll. DSLs richten sich dabei vor allem an Expertinnen und Experten, die solche Spezifikationen häufiger verfassen müssen, für die also Produktivität, einfache Versionierbarkeit und Interoperabilität textueller Sprachen besonders vorteilhaft sind.

Dabei hat sich die Entwicklung neuer DSLs durch Innovationen wie das Language Server Protocol und Frameworks wie Langium, Xtext oder AnyText dramatisch vereinfacht. Wo Developer Parser früher per Hand schreiben mussten, können sie diese heute mit Editorunterstützung weitgehend aus der Spezifikation einer Grammatik ableiten, was den Aufwand stark reduziert. Daher sollten DSLs als alternative UX-Technologie durchaus in Betracht gezogen werden.

Literaturverzeichnis

[1] M. Eysholdt und H. Behrens, „Xtext: implement your language faster than the quick and dirty way,“ in Proceedings of the ACM International Conference Companion on Object Oriented Programming Systems Languages and Applications Companion, Reno/Tahoe, Nevada, USA, Association for Computing Machinery, 2010, pp. 307–309.

[2] G. Hinkel, A. Hert, N. Hettler und K. Weinert, „AnyText: Incremental, left-recursive Parsing and Pretty-Printing from a single Grammar Definition with first-class LSP support,“ Proceedings of the 18th ACM SIGPLAN International Conference on Software Language Engineering, SLE 2025, pp. 98–111, 12–13 Juni 2025.

[3] A. Warth, J. R. Douglass und T. Millstein, „Packrat parsers can support left recursion,“ in Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation, San Francisco, California, USA, Association for Computing Machinery, 2008, pp. 103–110.

(who)

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Developer-Häppchen fürs Wochenende – Kleinere News der Woche

2026-04-11T07:23:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kleine, aber interessante Meldungshäppchen vom News-Buffet zu React Native, Perl, JavaScript, ASP .NET Core, State of Web Dev AI, PHP, Python und OpenJDK.

(Bild: Natalia Klenova / Shutterstock.com)

11.04.2026, 09:23 Uhr

Lesezeit: 3 Min.

Developer

Von

In unserem leckeren Häppchen-Überblick servieren wir alles, was es zwar nicht in die News geschafft hat, wir aber dennoch für spannend halten:

React Native Windows 0.82 entfernt die alte Paper-Architektur vollständig und zwingt alle Apps auf die neue Fabric-Architektur als einheitliche Basis. Gleichzeitig ermöglicht das Update erstmals, native XAML-Controls direkt in React-Native-Komponenten einzubinden und verbessert damit Funktionsumfang, Accessibility und Stabilität deutlich.
PDL (Perl Data Language), eine Erweiterung für Perl, die effizientes numerisches Rechnen mit mehrdimensionalen Arrays ermöglicht, wurde vollständig in Rust neu implementiert. Die neue Version soll die Performance und die Architektur deutlich verbessern und sich nahtlos in eine moderne, JIT-fähige (Just in Time) Perl-Runtime ohne C/XS-Abhängigkeiten integrieren.
JSIR, eine neue High-Level-Zwischensprache für JavaScript im LLVM-Ökosystem, führt erstmals eine IR (Intermediate Representation, also eine Zwischenform von Code für Analyse und Optimierung) ein, die AST-Informationen vollständig erhält und offenbar verlustfrei zurück in Quellcode überführt werden kann. Neu sind außerdem integrierte Kontrollfluss- und Dataflow-Analysen auf Basis von MLIR.
Microsoft kündigt an, dass ASP.NET Core 2.3 am 7. April 2027 das Support-Ende erreicht und danach keine Sicherheitsupdates, Bugfixes oder Support mehr erhält. Entwickler sollen daher auf eine aktuelle .NET-Version migrieren, da die alte Version weiterhin läuft, aber zunehmend Sicherheitsrisiken birgt.

(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 nur noch bis 14. April im Online-Ticketshop verfügbar.

So steht es um KI in der Webentwicklung: Die Umfrage State of Web Dev AI ist eröffnet. Interessierte Webentwicklerinnen und -entwickler können bis zum 10. Mai daran teilnehmen – unabhängig von ihrem Erfahrungslevel und davon, ob sie KI nutzen.
Das Microsoft Agent Framework hat für .NET und Python die Version 1.0 erreicht. Das Open-Source-Projekt für agentische KI-Anwendungen erlaubt unter anderem Multi-Agenten-Orchestrierung und unterstützt das Model Context Protocol (MCP). Im neuen, produktionsreifen Release verspricht Microsoft stabile APIs und Long-Term Support.

Lesen Sie auch

Konsistenz ist eine fachliche Entscheidung

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Gas Town 1.0.0: Agenten brauchen jetzt eine Freigabe

2026-04-10T10:09:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Gas Town 1.0.0 orchestriert mehrstufige Entwicklungs-Workflows, härtet Agenten-Sicherheit und unterstützt erstmals Windows.

(Bild: heise medien)

10.04.2026, 12:09 Uhr

Lesezeit: 3 Min.

iX Magazin

Von

Moritz Förster

Gas Town hat Version 1.0.0 erreicht und gilt damit als produktionsreif. Nach 14 Vorabversionen (v0.5.0 bis v0.13.0) bringt das Release vor allem mehr Stabilität, bessere Sicherheit und neue Werkzeuge für die Orchestrierung komplexer Abläufe. Im Mittelpunkt stehen eine Workflow-basierte Ausführung, die direkte Anbindung an GitHub Merge Queues sowie zusätzliche Kontroll- und Schutzmechanismen für automatisierte Systeme.

Gas Town ist ein Open-Source-Projekt, das Entwicklungs- und Automatisierungsprozesse orchestriert – insbesondere mehrstufige, teils agentenbasierte Workflows. Konzepte wie „Formulas“, „Polecats“ oder „Refinery“ stehen für die Verbindung strukturierter Abläufe mit automatisierten Akteuren, die sich in bestehende Entwicklungsumgebungen wie GitHub einfügen. Entwickler arbeiten dazu nur mit einem einzigen, zentralen Agenten zusammen, dem Mayor, der die anderen Agenten selbsttätig ins Leben ruft und orchestriert.

Mehrstufige Workflows und GitHub-Merge-Queue-Anbindung

Die wichtigste funktionale Neuerung sind Workflow-Formeln. Der neue Typ „workflow“ in gt formula run erlaubt es, mehrstufige, interaktive Abläufe zu definieren und auszuführen. Statt einzelner Befehle lassen sich damit ganze Prozessketten abbilden – etwa Codegenerierung, Testlauf und Pull-Request-Erstellung in einem Durchgang. Für Entwicklungsteams entspricht das einer leichtgewichtigen Workflow-Engine, die besonders bei KI-gestützten Prozessen nützlich ist.

Dazu passend bindet die Komponente „Refinery“ jetzt nativ GitHub Merge Queues an. Mit merge_strategy=pr reiht Gas Town Pull Requests direkt in die Warteschlange ein. GitHub führt Änderungen dann seriell und erst nach erfolgreichem CI-Lauf zusammen. In automatisierten Setups entfällt damit ein guter Teil der eigenen Merge-Logik, gleichzeitig sinkt das Risiko von Konflikten durch parallele Änderungen.

Windows-Support

Version 1.0 bringt außerdem einen ersten Windows-Support. Gas Town implementiert dafür plattformspezifisches Signal-Handling, Prozessmanagement und die Nachverfolgung von tmux-Prozesshierarchien. Da sich diese Mechanismen unter Windows grundlegend von Unix unterscheiden, war eine eigene Umsetzung nötig. Teams mit gemischten Betriebssystemlandschaften können Gas Town damit erstmals durchgängig einsetzen.

Videos by heise

Sicherheit und Governance

Beim Thema Sicherheit bündelt das Release mehrere Maßnahmen. Die Entwickler haben eine SQL-Injection-Lücke in dolt_remotes geschlossen. Ein neuer „PreToolUse“-Guard blockiert kritische Systemeingriffe wie sudo-Aufrufe oder Paketinstallationen. Zusätzlich lehnt Gas Town unsignierte Binärdateien ab. Die Kombination aus Schwachstellenbehebung und Laufzeitkontrollen zielt vor allem auf agentenbasierte Szenarien, in denen automatisierte Akteure potenziell gefährliche Aktionen auslösen könnten.

Neu sind auch „Mayor Approval Gates“ als Governance-Mechanismus. Bevor ein Polecat – also ein ausführendes Modul oder ein Agent – seinen Wirkungsbereich erweitert, braucht er eine Freigabe. Das betrifft etwa den Zugriff auf zusätzliche Ressourcen oder Komponenten. Das Prinzip ähnelt Policy-Engines oder Human-in-the-Loop-Ansätzen und soll verhindern, dass automatisierte Systeme eigenmächtig ihre Berechtigungen ausweiten.

Ein neues Rate-Limit-Watchdog-Plugin rundet das Release ab. Es erkennt HTTP-429-Antworten und stoppt den betroffenen Prozess automatisch. Das verhindert, dass Workflows bei API-Überlastung in Endlosschleifen laufen oder ungewollt hohe Kosten verursachen.

Alle Details zur Version 1.0.0 finden sich in den Release Notes auf der GitHub-Projektseite von Gas Town.

Lesen Sie auch

Framework: Gas Town orchestriert Coding-Agenten nach Kubernetes-Vorbild

Gas Town: Mad-Max-inspiriertes Framework für Coding-Agenten

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Neu in .NET 10.0 [18]: Webserver als File-based App

2026-04-10T07:00:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

In einer File-based App kann man den Kestrel-Webserver auf Basis von ASP.NET Core starten.

(Bild: Pincasso / Shutterstock.com)

10.04.2026, 09:00 Uhr

Lesezeit: 1 Min.

Developer

Von

Dr. Holger Schwichtenberg

Das direkte Übersetzen und Starten von C#-Dateien nennt Microsoft File-based Apps. Es ist auch möglich, einen Kestrel-Webserver innerhalb einer solchen App zu starten. Unten stehendes Beispiel zeigt eine ASP.NET Core Minimal WebAPI als eigenständige C#-Datei. Das Hosting erfolgt in dem in ASP.NET Core mitgelieferten Webserver Kestrel.

Dr. Holger Schwichtenberg ist technischer Leiter des Expertennetzwerks www.IT-Visions.de, das mit 53 renommierten Experten zahlreiche mittlere und große Unternehmen durch Beratungen und Schulungen sowie bei der Softwareentwicklung unterstützt. Durch seine Auftritte auf zahlreichen nationalen und internationalen Fachkonferenzen sowie mehr als 90 Fachbücher und mehr als 1500 Fachartikel gehört Holger Schwichtenberg zu den bekanntesten Experten für .NET und Webtechniken in Deutschland.

In der File-based App wird Microsoft.NET.Sdk.Web als SDK angegeben. Als NuGet-Pakete werden Microsoft.AspNetCore.OpenApi und Humanizer verwendet. Die Ahead-of-Time-Kompilierung, die in File-based Apps Standard ist, ist hier deaktiviert, um Warnungen des JSON-Serialisierers zu vermeiden.

Videos by heise

Folgender Code zeigt den Webserver auf Basis von ASP.NET Core mit einem Minimal-WebAPI-Endpunkt und OpenAPI-Metadaten:

#:sdk Microsoft.NET.Sdk.Web
#:package Microsoft.AspNetCore.OpenApi@10.*-*
#:package Humanizer@2.14.1
#:property Version=1.1.4
#:property PublishAot=false

using Humanizer;
using Microsoft.OpenApi;

// Webserver einrichten
var builder = WebApplication.CreateBuilder();
builder.Services.AddOpenApi();
var app = builder.Build();
app.MapOpenApi(); // http://localhost:5000/openapi/v1.json

app.MapGet("/", () =>
 {
     // Daten für Operation
     var d = new Data
     {
         Version = "9.0",
         Release = "2024-11-12"
     };
     var dotNet9Released = DateTimeOffset.Parse(d.Release);
     var since = DateTimeOffset.Now - dotNet9Released;

     return $"It has been {since.Humanize()} since .NET {d.Version} was released.";
 });

app.MapGet("/data", () =>
 {
     var d = new Data
     {
         Version = "9.0",
         Release = "2024-11-12"
     };
     return Results.Json(d);
 });

app.Run();

class Data
{
    /// <summary>
    /// Version of the .NET release.
    /// </summary>
    public string? Version { get; set; }
    /// <summary>
    /// Release date of the .NET version.
    /// </summary>
    public string? Release { get; set; }
}

Start und Ausgabe des Webservers (Abb. 1)

(rme)

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Keycloak 26.6.0: Fünf Preview-Features werden produktionsreif

2026-04-09T11:55:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Das Open-Source-IAM-System Keycloak 26.6 befördert fünf Features in den produktiven Status – darunter Federated Client Authentication und Zero-Downtime-Updates.

(Bild: HAKINMHAN / Shutterstock.com)

09.04.2026, 13:55 Uhr

Lesezeit: 4 Min.

Developer

Von

Matthias Parbel

Das Keycloak-Projekt hat Version 26.6.0 des Open-Source-Identity-Providers veröffentlicht. Im Mittelpunkt stehen fünf Features, die den Preview-Status verlassen und nun als vollständig unterstützt gelten. Für Unternehmen, die Keycloak in Kubernetes-Umgebungen betreiben, dürften dabei vor allem die Zero-Downtime-Patch-Releases und die Federated Client Authentication relevant sein.

Die wohl praxisrelevanteste Neuerung laut Ankündigung: Patch-Releases lassen sich künftig als Rolling Updates innerhalb eines Minor-Release-Streams einspielen, ohne dass der Dienst unterbrochen wird. Zusammen mit dem ebenfalls verbesserten Graceful HTTP Shutdown, der Fehlermeldungen beim Abschalten einzelner Nodes verhindert, greift das Entwicklungsteam damit eine zentrale Anforderung containerisierter Deployments auf. Um von den Zero-Downtime-Patch-Releases profitieren zu können, genügt es laut Release Notes, die Update-Strategie für den Keycloak Operator auf „Auto“ zu setzen.

Die auf Developer Experience (DX) und Platform Engineering spezialisierte CLC-Konferenz findet vom 11. bis 12. November 2026 in Mannheim statt. Beim Call for Proposals werden bis zum 21. April Vorschläge für Workshops und Talks gesucht – vor allem Praxisberichte.

Weitere Informationen finden sich auf der CLC-Website.

Daneben hat das Projekt die Federated Client Authentication in den produktiven Status befördert. Das Feature erlaubt es Clients, vorhandene Credentials eines externen Issuers zu nutzen, sobald eine Vertrauensbeziehung besteht. Individuelle Client-Secrets in Keycloak entfallen damit. Unterstützt werden Client-Assertions externer OpenID-Connect-Identity-Provider sowie Kubernetes Service Accounts. Organisationen mit mehreren Identity-Providern reduzieren so den Verwaltungsaufwand für Secrets erheblich. Die OAuth-SPIFFE-Client-Authentication bleibt allerdings im Preview-Status, da die zugrunde liegende Spezifikation noch nicht finalisiert ist.

Videos by heise

Workflows und JWT Authorization Grant

Mit den nun unterstützten Workflows bringt Keycloak zentrale Funktionen aus dem Bereich Identity Governance and Administration (IGA) mit. Administratoren können Realm-Aufgaben wie das Lifecycle-Management von Benutzern und Clients in YAML-Dateien definieren und anhand von Ereignissen, Bedingungen oder Zeitplänen automatisiert ausführen lassen. Das Release enthält zudem neue Built-in-Steps, einen Troubleshooting-Guide sowie diverse Verbesserungen an der Workflow-Engine.

Auch der JWT Authorization Grant nach RFC 7523 gilt nun als produktionsreif. Er ermöglicht den Austausch externer JWT-Assertions gegen OAuth-2.0-Access-Token und hilft somit bei Anwendungsfällen, in denen externe Token in interne überführt werden müssen. Komplettiert wird das Quintett durch das neue Keycloak Test Framework, das den bisherigen Arquillian-basierten Ansatz ablöst.

Experimentelle MCP-Unterstützung und Java 25

Jenseits der fünf Haupt-Features liefert das Release weitere Neuerungen. Experimentell unterstützt Keycloak nun das OAuth Client ID Metadata Document (CIMD) – ein aufkommender Standard zur Beschreibung von OAuth-2.0-Client-Metadaten. Da das Model Context Protocol (MCP) ab Version 2025-11-25 CIMD voraussetzt, lässt sich Keycloak künftig als Authorization Server für MCP-Szenarien nutzen.

Als Preview erscheinen zudem die Identity Brokering APIs V2, die den Legacy Token Exchange V1 ablösen sollen, sowie Step-up Authentication für das SAML-Protokoll. Organisationen profitieren außerdem von isolierten Gruppenhierarchien pro Organisation, die Namenskonflikte innerhalb eines Realms vermeiden.

Auf der Infrastrukturseite unterstützt Keycloak inzwischen OpenJDK 25. Das Container-Image setzt allerdings weiterhin auf Java 21, um FIPS-Kompatibilität zu gewährleisten – für Unternehmen in regulierten Umgebungen bleibt damit alles beim Alten. Bestehende Deployments mit Java 21 sollen unverändert weiter funktionieren. Weitere Verbesserungen betreffen die automatische Truststore-Initialisierung auf Kubernetes und OpenShift, neue Client-Certificate-Lookup-Provider für Traefik und Envoy sowie überarbeitete HTTP-Access-Logs, die sensible Informationen wie Token und Cookies ausfiltern.

Lesen Sie auch

Keycloak: Der anpassbare Identity Provider im Überblick

Keycloak 26.2 überarbeitet feingranulare Admin-Berechtigungen

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Plane 1.3.0: Update der freien Jira-Alternative

2026-04-09T10:10:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit Version 1.3.0 erhält Plane viele wichtigste Updates: Gitea-Login, verbesserte Oberfläche und neue API-Endpunkte kommen für die Open-Source-Jira-Alternative.

(Bild: Plane)

09.04.2026, 12:10 Uhr

Lesezeit: 3 Min.

iX Magazin

Von

Moritz Förster

Plane schließt in Version 1.3.0 der freien Community-Version mehrere Sicherheitslücken, bringt neue Integrationen und überarbeitet die Benutzeroberfläche umfassend. Das Release führt unter anderem eine Gitea-Authentifizierung ein, öffnet die API für externe Projektzusammenfassungen und validiert Dateiuploads sowie Projektkennungen strenger. Parallel haben die Entwickler mehrere sicherheitsrelevante Schwachstellen behoben – darunter manipulierbare Rate-Limits für API-Tokens, eine SSRF-Lücke in Webhooks und CSV-Injection beim Datenexport.

Bei Plane handelt es sich um ein quelloffenes Projektmanagement- und Issue-Tracking-System für Entwickler. Es bietet Aufgabenverwaltung, Roadmaps und API-Anbindung und ist als selbst hostbare Alternative zu Jira oder Linear gedacht.

Integrationen: Gitea-Login und neue API-Endpunkte

Plane unterstützt ab Version 1.3.0 die Authentifizierung über Gitea. Teams mit selbst gehosteter Git-Infrastruktur können damit Benutzerkonten koppeln oder Single Sign-on einrichten. Neu ist außerdem eine externe Project-Summary-API, über die Drittsysteme Projektübersichten abrufen können – etwa für Dashboards oder Reporting. Webhook-Payloads lassen sich nun zudem lokalisieren.

Projektnamen und -kennungen akzeptieren keine potenziell ausführbaren Sonderzeichen mehr, was Injection-Angriffe erschwert. Im Administrationsmodus verhindert Plane außerdem, dass Admins versehentlich alle Authentifizierungsmethoden deaktivieren. Erweiterte Logs liefern detailliertere Fehlermeldungen bei Authentifizierungsproblemen und erleichtern die Fehlersuche und das Auditing.

Überarbeitete Oberfläche mit einheitlichem Designsystem

Einen großen Teil des Releases machen Änderungen an der Oberfläche aus. Plane setzt stärker auf Design-Tokens – also zentral definierte Werte für Farben, Abstände und andere UI-Parameter –, die für ein einheitlicheres Erscheinungsbild sorgen. Die Entwickler haben unter anderem die Detailansichten von Work Items, die Sidebar, Kommentare sowie die Workspace- und Mitgliederverwaltung überarbeitet. Dropdowns verhalten sich kontextsensitiver und zeigen ausgewählte Einträge oben an. Neue Ladezustände sorgen für flüssigere Übergänge, überarbeitete Themes und Editor-Farben für mehr visuelle Konsistenz.

Videos by heise

Attachments akzeptieren jetzt auch Markdown-Dateien. Eine Zeitzonen-Einstellung auf Workspace-Ebene sorgt dafür, dass neue Projekte automatisch die richtige Zeitzone übernehmen. Die Mention-Suche nutzt jetzt Debouncing und löst damit bei schneller Eingabe weniger API-Anfragen aus. Die Navigation zeigt eingehende Aufgaben (Intake) direkt als Zähler an.

Sicherheit: Mehrere Angriffsvektoren geschlossen

Im Bereich Sicherheit verhindert eine serverseitige Absicherung nun, dass Angreifer Rate-Limits von API-Tokens manipulieren. Webhook-URLs durchlaufen eine strengere Validierung, um Server-Side Request Forgery (SSRF) zu unterbinden – also Angriffe, bei denen ein Server dazu gebracht wird, interne Ressourcen anzusprechen.

Beim CSV-Export bereinigt Version 1.3.0 eingebettete Formeln, die Tabellenprogramme wie Excel sonst ungefragt ausführen könnten. Zusätzlich blockiert eine neue Upload-Validierung potenziell schädliche Dateien, und der HTTP-Header X-Frame-Options schützt vor Clickjacking.

Bei der Internationalisierung kommt Ukrainisch als neue Sprache hinzu, die russische Übersetzung wurde erweitert. Zahlreiche Bugfixes betreffen den Editor, die Navigation, API-Endpunkte und E-Mail-Templates.

Alle Informationen zum Update finden sich in den Release Notes auf der Projektseite von Plane auf GitHub.

Lesen Sie auch

Entwicklungsplattform: GitLab 18.10 führt Anmeldung per Passkey ein

GitLab 18.9: Eigene KI-Modelle und KI-gestützte Sicherheitsfeatures

Zu viel Copilot: Gentoo wechselt von GitHub zu Codeberg

Textprojekte gemeinsam stemmen mit Git: So gehen Dokumentationen und mehr

Merkle-Trees: Datenintegrität kryptografisch beweisen

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

software-architektur.tv: Was Developer von anarchistischen Denkern lernen können

2026-04-09T09:45:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Patterns of Anarchy: Andrew Harmel-Law und Eberhard Wolff sprechen über anarchistische Ideen, die auf Softwarearchitektur treffen.

(Bild: software-architektur.tv)

09.04.2026, 11:45 Uhr

Lesezeit: 2 Min.

Developer

Von

Matthias Parbel

Andrew Harmel-Law, Tech Principal beim Beratungsunternehmen Thoughtworks, hat eine ungewöhnliche Verbindung zwischen anarchistischer Theorie und moderner Softwarearchitektur aufgedeckt. Ausgangspunkt ist das 1966 erschienene Buch „Patterns of Anarchy“ von Leonard I. Krimerman und Lewis Perry – eine Anthologie anarchistischer Aufsätze, die auch Christopher Alexander als Inspiration für sein einflussreiches Werk „A Pattern Language“ diente.

Harmel-Law stieß auf die Sammlung, weil Alexander sie in seinem 1977 veröffentlichten Standardwerk zitierte. Alexanders Konzept der Pattern Language – 253 Entwurfsmuster für Architektur und Städtebau – hat auch die Softwarebranche nachhaltig geprägt. Die berühmten Design Patterns der sogenannten Gang of Four aus dem Jahr 1994 gehen direkt auf Alexanders Arbeit zurück.

Die Anthologie von Krimerman und Perry versammelt Texte zur anarchistischen Tradition und behandelt unter anderem alternative Gemeinschaftsmodelle und Organisationsprogramme. Besonders der Abschnitt „Constructive Anarchism: Alternative Communities and Programs“ widmet sich praktischen Aspekten dezentraler Organisationsformen – ein Thema, das in der Softwareentwicklung aktueller ist denn je. Darüber sprechen Andrew Harmel-Law und Eberhard Wolff in dieser englischsprachigen Folge des Videocasts software-architektur.tv.

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.

Der auf agile Methoden und Domain-Driven Design spezialisierte Berater Andrew Harmel-Law sieht deutliche Parallelen zwischen anarchistischen Organisationsideen und modernen Entwicklungspraktiken. Dezentrale, autonome Strukturen und föderale Entscheidungsprozesse, wie sie anarchistische Denker beschrieben, spiegeln sich in agilen Teams, Open-Source-Communities und selbstorganisierten Entwicklungsgruppen wider. Harmel-Law wird einige der interessantesten Erkenntnisse aus seiner Perspektive als Student des soziotechnischen Organisationsdesigns teilen. Manchmal wird er eigene Kommentare hinzufügen. Und natürlich stellt sich die Frage, inwiefern dies mit Softwareentwicklung zusammenhängt.

Livestream am 10. April

Die Folge wird am Freitag, 10. April 2026, live ab 13 Uhr gestreamt. 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 – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Eclipse hawkBit 1.0: Backend für IoT-Updates erreicht Produktionsreife

2026-04-09T08:29:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Eclipse hawkBit 1.0 ist da und gilt als produktionsreifes Backend für OTA-Updates von IoT-Geräten mit stabilen APIs für den operativen Einsatz.

(Bild: Peshkova / shutterstock.com)

09.04.2026, 10:29 Uhr

Lesezeit: 2 Min.

Developer

Von

Madeleine Domogalla

Mit Version 1.0 hat das Eclipse-Projekt hawkBit einen stabilen Meilenstein erreicht. Die Maintainer stufen das Backend-System für die Verteilung von Software-Updates an IoT-Geräte nun als produktionsreif ein und sichern stabile APIs zu.

Der Fokus des Tools liegt auf sogenannten Over-the-Air-Updates (OTA), also der zentralen Aktualisierung von Geräten im produktiven Einsatz – laut Eclipse Foundation reicht das Spektrum von stark eingeschränkten Edge-Geräten über alle Zwischenstufen bis hin zu leistungsfähigen Gateways.

Backend für IoT-Rollouts

Technisch positioniert sich hawkBit als domänenunabhängiges Framework für das Update-Management. Es übernimmt die Orchestrierung von Rollouts, die Verwaltung von Gerätegruppen und die Steuerung von Update-Prozessen. Typische Einsatzfelder sind offenbar Industrieanlagen, Automotive, Smart Buildings oder Telekommunikation.

Für die Integration stellt das Projekt mehrere Schnittstellen bereit:

REST-basierte Device-API (DDI) für direkt angebundene Geräte
AMQP-Schnittstelle (DMF) für Gateway-Szenarien
Management-API zur Steuerung und Automatisierung mit Fokus auf Betrieb und Sicherheit

Videos by heise

hawkBit adressiert vor allem Anforderungen aus dem operativen Betrieb größerer IoT-Installationen. Dazu gehören Multi-Tenancy, gestaffelte Rollouts mit definierten Abbruchregeln sowie Freigabe-Workflows. Auch eine rollenbasierte Zugriffskontrolle ist integriert.

Beim Thema Sicherheit setzt das Projekt unter anderem auf gerätespezifische Tokens, mTLS, OAuth 2.0/OIDC und fein granularen Zugriff auf Entitäten.

Flexible Architektur und Ökosystem

Der Server lässt sich sowohl monolithisch als auch als Microservice-Setup betreiben und horizontal skalieren. Entwicklerinnen und Entwickler können die Plattform selbst hosten und behalten damit die Kontrolle über ihre Update-Infrastruktur. Rund um hawkBit hat sich zudem laut Ankündigungsbeitrag ein Ökosystem aus Clients und Integrationen gebildet, beispielsweise für Embedded-Linux-Update-Tools, Zephyr RTOS oder LoRaWAN-Server. Auch kommerzielle Angebote bauen auf dem Projekt auf.

Lesen Sie auch

Eclipse Theia: Community-Release 2026-02 integriert GitHub Copilot

Eclipse IDE 2026-03: Mehr Refactoring und Templates für Syntax-Highlighting

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

VeraCrypt und WireGuard: Trubel bezüglich Treibersignierung, Lösung in Sicht

2026-04-09T07:39:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Microsoft-Konten für die Entwickler von VeraCrypt und WireGuard wurden gesperrt. Das verhinderte Updates – die Lösung ist in Sicht.

(Bild: Dirk Knop / heise medien)

09.04.2026, 09:39 Uhr

Lesezeit: 3 Min.

Security

Von

Dirk Knop

Die Entwickler des Laufwerksverschlüsselers VeraCrypt und der VPN-Software WireGuard waren in den letzten Tagen mit dem Umstand konfrontiert, dass Microsoft ihre Entwickler-Konten gesperrt hat. Dadurch war eine Signierung der Windows-Treiber nicht mehr möglich, was am Ende Softwareupdates unmöglich macht. Aktuelles Windows akzeptiert nur signierte Treiber.

Der VeraCrypt-Entwickler Mounir Idrassi hat das Ende März bereits im VeraCrypt-Forum thematisiert. Dort beschwerte er sich, dass er keine Benachrichtigung oder Erklärung dazu erhalten hat, dass sein Microsoft-Konto gesperrt wird, mit dem er Bootloader und Windows-Treiber signiere. Idrassi beklagt weiter, dass er versucht hat, Microsoft über diverse Kanäle zu erreichen. Aber stets stieß er auf Bots und automatische Antworten, Kontakt zu Menschen sei unmöglich.

Die aufkommenden Berichte haben den WireGuard-Entwickler dazu veranlasst, seine ähnliche Erfahrung auf X zu posten. WireGuard hat nach vier Jahren größere Updates für die Windows-Fassung geplant – Modernisierungen und Verbesserungen, Fehlerkorrekturen, neue Funktionen und mehr. Das Release ist jedoch durch die Kontosperrung seitens Microsoft blockiert, der WireGuardNT-Treiber lässt sich nicht signieren. „Anscheinend haben sie eine Richtlinie zur Identitätsprüfung eingeführt, mich aber nicht darüber informiert und dann wohl Konten gesperrt, deren Nutzer die Verifizierung nicht durchgeführt haben“, schreibt er dort.

Langwieriger Berufungsprozess

Der Programmierer führt aus, dass er die Verifikation mittels Personalausweis (ID Card) unmittelbar nachgeholt habe, dafür jedoch ein Berufungsverfahren (Appeal) nötig sei. Dafür muss ein Support-Ticket ausgefüllt werden – was nur mit einem nicht gesperrten Konto geht. Über einen Umweg in Azure und die Weiterleitung an die richtige Abteilung war das in diesem Fall aber lösbar. Das sei nun zwei Wochen her. Microsoft hat ihn informiert, dass der Berufungsprozess 60 Tage dauern kann.

Das könnte im Falle von kritischen Zero-Day-Codeschmuggel-Lücken zumindest problematisch sein, gibt er zu bedenken: „Sorry, du musst 60 Tage warten“. Er glaube jedoch, dass das lediglich ein Fall von überbordender Bürokratie sei, was mal passieren könne.

Videos by heise

Microsoft reagiert, Entwickler bald wieder einsatzfähig

Auf Anfrage von heise online dazu antwortete Microsoft mit einem Link auf eine Stellungnahme auf X. Das Unternehmen schreibt dort, dass es diese Berichte gesehen hat und die Probleme so schnell wie möglich lösen möchte. Der Präsident der Sparte Windows und Geräte von Microsoft, Pavan Davuluri, erklärt, dass sie den VeraCrypt-Entwickler kontaktiert und mit einem Entwickler namens Jason von WireGuard gesprochen hätten. Die sollten bald wieder einsatzbereit sein. Mounir Idrassi hat das im VeraCrypt-Forum in den frühen Morgenstunden des Donnerstags bestätigt.

Als Hintergrundinformation verweist Microsoft auf einen Blog-Beitrag aus dem Oktober 2025. Dort erklärt das Unternehmen, dass die Konto-Verifikation für das Windows-Hardware-Programm am 16. Oktober 2025 startet und insbesondere von den Partnern Maßnahmen erfordert, die keine Verifikation seit dem April 2024 vorgenommen hätten. Pavan Davuluri führt aus, dass Microsoft E-Mails dazu versendet habe, Banner geschaltet und Erinnerungen angezeigt hat. Microsoft wolle jedoch daran arbeiten, die Kommunikation zu verbessern.

Ein Problem könnte vielleicht sein, dass reine Software-Entwickler sich nicht unbedingt als Teil des Windows-Hardware-Programms fühlen und entsprechende E-Mails womöglich als fehlgeleitet angesehen haben.

(dmk)

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

React im Terminal: Ink 7.0 überarbeitet Input-Handling grundlegend

2026-04-09T06:53:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Ink 7.0 überarbeitet das Input-Handling und bringt neue Hooks für Animation, Paste und responsive Layouts. Voraussetzung sind jetzt Node.js 22 und React 19.2.

(Bild: Ink)

09.04.2026, 08:53 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

Mit Version 7.0.0 hebt die React-basierte CLI-Bibliothek Ink ihre Mindestanforderungen deutlich an und überarbeitet das Input-Handling grundlegend. Gleichzeitig kommen neue APIs für Interaktivität, Layout und Animation hinzu. Die Maintainer setzen künftig Node.js 22 und React ab Version 19.2 voraus. Die Änderungen erfordern Anpassungen in bestehenden Projekten, ermöglichen aber auch komplexere Terminal-UIs.

Mit Ink lassen sich interaktive Kommandozeilenanwendungen deklarativ mit React-Komponenten entwickeln. Statt direkt mit ANSI-Escape-Sequenzen und Low-Level-Terminal-APIs zu arbeiten, definieren Entwickler ihre CLI-Oberflächen ähnlich wie Web-UIs – mit State-Management, Komponentenstruktur und Hooks.

Breaking Changes im Input-Handling

Intern nutzt Ink nun Reacts useEffectEvent, um zu vermeiden, dass sich Input-Handler bei jedem Render neu registrieren. Das stabilisiert das Event-Handling und reduziert Performance-Overhead.

Auch bei der Verarbeitung von Tastatureingaben gibt es Korrekturen. So unterscheidet Ink nun sauber zwischen key.backspace und key.delete. Viele Terminals senden für beide Tasten identische Byte-Sequenzen, was bislang zu Fehlinterpretationen führte. Wer bisher auf key.delete reagiert hat, um Backspace abzufangen, muss seine Logik anpassen. Außerdem setzt Ink key.meta nicht mehr beim Drücken der Escape-Taste: key.meta steht jetzt ausschließlich für Alt-/Meta-Kombinationen, key.escape wird separat ausgewiesen.

Neue Hooks für Interaktivität und Animation

Der neue Hook usePaste behandelt eingefügten Text aus der Zwischenablage als eigenständiges Ereignis. Dafür aktiviert Ink den Bracketed-Paste-Modus des Terminals, sodass eingefügter Text als zusammenhängender String ankommt. Ohne diesen Modus würde ein Paste-Vorgang als Serie einzelner Keypress-Events erscheinen – das ist problematisch etwa bei Eingabefeldern oder REPL-artigen Interfaces.

Für responsive Layouts liefert der neue Hook useWindowSize die aktuelle Terminalgröße in Spalten und Zeilen und löst bei Änderungen automatisch ein Re-Render aus. So lassen sich etwa Tabellen oder Layouts dynamisch an unterschiedliche Terminalgrößen anpassen.

Mit useBoxMetrics ermitteln Entwickler zur Laufzeit die tatsächlichen Dimensionen von Layout-Containern – vergleichbar mit DOM-Messungen im Browser. Das führt zu präziserer Layout-Logik, wenn Inhalte abhängig von der gerenderten Größe positioniert oder gekürzt werden müssen.

Der Hook useAnimation bringt einen integrierten Animationsmechanismus mit. Er stellt einen Frame-Zähler bereit, der in konfigurierbaren Intervallen hochzählt und sich pausieren lässt. Beim Unmount räumt er automatisch auf. Typische Einsatzfälle sind Spinner, Fortschrittsanzeigen oder ASCII-Animationen.

Videos by heise

Rendering und Layout-Erweiterungen

Beim Rendering kommt ein Alternate-Screen-Modus hinzu. Aktiviert man ihn beim Aufruf von render(), nutzt die Anwendung den zweiten Bildschirmpuffer des Terminals – ein Verhalten, das von Programmen wie Vim oder less bekannt ist. Nach dem Beenden stellt das Terminal den ursprünglichen Inhalt wieder her. Ergänzend lässt sich mit der neuen Option interactive die automatische Erkennung interaktiver Umgebungen überschreiben, etwa für CI-Pipelines oder Pipe-Szenarien.

Das Layout-System erhält ebenfalls Erweiterungen. Die Komponente <Box> unterstützt jetzt aspectRatio, alignContent, position="static" sowie Positionsangaben wie top, right, bottom und left. Dazu kommen maxWidth und maxHeight. Mit borderBackgroundColor lässt sich erstmals die Hintergrundfarbe von Rahmen unabhängig vom Inhalt setzen. Für Text führt Ink die Option wrap="hard" ein: Sie füllt Zeilen strikt auf die verfügbare Breite auf und bricht dabei auch mitten im Wort um – nützlich für tabellarische oder streng ausgerichtete Monospace-Layouts.

Im Fokus-Management liefert der Hook useFocusManager nun zusätzlich die ID des aktuell fokussierten Elements. Das erleichtert die Steuerung komplexerer Interaktionen und die Fehlersuche.

Bugfixes

Neben den funktionalen Neuerungen behebt Version 7.0.0 mehrere Stabilitätsprobleme. Dazu zählen Darstellungsfehler bei CJK-Texten und Emojis, Abstürze bei unbekannten Keycodes im Input-Handling sowie Rendering-Fehler bei abschließenden Zeilenumbrüchen und überlappenden Schreibvorgängen.

Alle Informationen zur neuen Version 7.0.0 finden sich in den Release Notes auf der GitHub-Projektseite von Ink.

(fo)

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

DeerFlow: Super-Agenten-Framework von ByteDance

2026-04-08T09:11:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit DeerFlow stellt ByteDance ein Super-Agenten-Framework vor, das durch Sandboxes eine sichere und parallele Ausführung der Agenten erlaubt.

(Bild: Tada Images / Shutterstock.com)

08.04.2026, 11:11 Uhr

Lesezeit: 6 Min.

Developer

Von

Dr. Christian Winkler

OpenClaw hat es vorgemacht und gezeigt, zu welchen Leistungen LLMs schon in der Lage sind, wenn Agenten sie richtig nutzen. Allerdings sind die damit verbundenen Gefahren nicht nur groß, sondern sogar unüberschaubar: In manchen Fällen klaute OpenClaw Kreditkarten oder übernahm gleich den ganzen Computer. Dennoch steckt in der Technologie ein enormes Potenzial, was einige Nachahmer gefunden hat, die versuchen, die Schwächen zu korrigieren.

ByteDance legt vor

Einer der ersten Player, der sich aus der Deckung wagt, ist ByteDance, die Muttergesellschaft von TikTok, mit dem Tool DeerFlow (Deep Exploration and Efficient Research Flow). Nachdem das Projekt bereits über 56.000 Sterne auf GitHub erhalten hat, lohnt es sich, einen genaueren Blick darauf zu werfen.

ByteDance möchte, dass man für die Nutzung ein Coding-Abo abschließt, notwendig ist der aber nicht: DeerFlow lässt sich genauso mit lokalen Modellen verwenden. Etwas schwieriger wird es bei lokaler Nutzung allerdings, wenn das Framework selbstständig Websuchen durchführen soll. Das ist außerordentlich sinnvoll, denn der Knowledge Cutoff der meisten LLMs liegt beträchtlich in der Vergangenheit und sie sind über neue Entwicklungen nicht informiert. Hier kann man zum Beispiel die Search-Engine Tavily hinzufügen, für die es eine freie Variante gibt, mit der sich tausend Suchanfragen pro Monat durchführen lassen. Die gibt es auch bei InfoQuest, das ByteDance proprietär anbietet. Allerdings ist die Anzahl der Anfragen insgesamt auf tausend pro Account limitiert, Preise für weitere sind nicht direkt zu finden. Interessanterweise bietet ByteDance diesen Dienst in China selbst gar nicht an, möglicherweise auch aus Zensurgründen.

(Bild: TechSolution/Adobe Stock)

Der betterCode() GenAI Summit zeigt am 11. Juni, welche KI-Tools für welche Aufgaben geeignet sind und wie die KI-Integration effizient funktioniert. Außerdem thematisiert er die Auswirkungen der KI-gestützten Softwareentwicklung auf die Security und die Arbeit von Entwicklungsteams.

Alle lassen sich lokal installieren und konfigurieren. Die ausführliche Anleitung dazu findet sich auf GitHub. Zunächst muss man eine Konfigurationsdatei im YAML-Format anpassen. Anschließend lassen sich Docker-Container starten, in denen das System dann läuft. Die Container öffnen einen Port (2026, ob das Zufall ist?) auf dem Host-System. Das Ganze funktioniert ziemlich unproblematisch, wenn man alle Environment-Variablen in .env schreibt, die Variablen der Shell verwendet das System nämlich nicht. Das Ergebnis sieht dem Playground von DeerFlow sehr ähnlich, aber es lässt sich mit neuen Chats ergänzen.

Spielt man mit dem Playground, merkt man dem Tool auch seine Herkunft aus dem Deep Research an. Komplexe Themen kann der Agent selbst recherchieren und kommt zu guten Ergebnissen, die auch neue Entwicklungen beinhalten. Die Vorschläge für den heise-Verlag (siehe Abbildung 1) sind wie von anderen Agenten gewohnt sehr umfangreich und klingen auch sinnvoll. Allerdings ist das bei Weitem noch nicht alles.

Beispiel-Konversation mit DeerFlow mit der Frage, wie der heise-Verlag sein Geschäftsmodell ergänzen könnte (Abb. 1).

Von Deep Research zu Super-Agenten

Intern baut DeerFlow auf LangChain und LangGraph und ist damit hervorragend erweiterbar. Genau das betont auch ByteDance und bezeichnet das Framework als „Super Agent Harness“ – also ein Framework, das sich ausgezeichnet erweitern lässt. Angeblich haben die ByteDance-Developer DeerFlow neu konzipiert, als sie genau diese Erweiterungsfähigkeit von LangChain als einen entscheidenden Punkt erkannt haben.

Videos by heise

Derartige Erweiterungen können auf unterschiedlicher Ebene erfolgen. Zentral dafür sind Skills und Tools, in denen Anwender über Markdown-Files Workflows definieren. Auch der im Beispiel der Abbildung benutzte Research-Workflow basiert auf einem solchen Skill. Von Anwendern bereitgestellte Skills lädt DeerFlow bei Bedarf nach, wenn sie benötigt werden. Das spart Speicher und Rechenzeit und erlaubt eine dynamische Erweiterung des Systems zur Laufzeit. Tools sind etwas fortgeschrittener und erledigen komplexe Aufgaben wie beispielsweise die Websuche, können aber auch Bash-Skript oder Python-Programme in einer Sandbox sicher ausführen.

ByteDance hat erkannt, dass komplexe Aufgaben sich nur schlecht in einem einzigen Durchlauf erledigen lassen. Daher stammt das Konzept der Sub-Agenten, die ihren eigenen Kontext, eigene Tools und Abschlussbedingungen haben. Das erlaubt, sie parallel zueinander laufen zu lassen und damit Zeit zu sparen.

Die Sandbox funktioniert in DeerFlow wie ein eigener Computer. Jeder Prozess erhält eine eigene Umgebung mit einem separaten Filesystem, in dem sich wiederum Skills usw. befinden können. Durch diese Isolation können die Prozesse unabhängig voneinander agieren.

Großen Wert legt ByteDance auf die Isolation von Kontexten. Jeder Agent verfügt über einen eigenen Kontext und wird nicht von anderen Agenten gestört. Nebenbei erlaubt das die schon angesprochene Parallelisierung von Agenten. Um den Kontext möglichst klein zu halten (und damit Speicher bzw. Token im LLM zu sparen), findet ständig eine Zusammenfassung statt.

DeerFlow hat ein Langzeitgedächtnis und merkt sich Inhalte auch über eine Unterhaltung hinaus. Es fungiert somit als Wissensspeicher und passt sich den Wünschen der Benutzer immer besser an. Diese Daten speichert es alle lokal. Mit Empfehlungen und Apps, auf die man nicht mehr verzichten möchte, kennt sich ByteDance ja bestens aus. Im Gegensatz zu TikTok entsteht bei DeerFlow aber ein echter Mehrwert.

DeerFlow bringt neue Ideen

ByteDance veröffentlicht mit DeerFlow ein Agenten-Framework mit vielen neuen Ideen und zeigt damit, wie sich Agenten zukünftig entwickeln könnten. Besonders spannend sind dabei die einfach zu implementierenden Skills, die Isolation und Parallelisierung sowie die Sandboxen, die gefährliche Situationen wie bei OpenClaw vermeiden sollen.

Agentische KI beschäftigt Forscher gerade sehr intensiv. Noch weiß niemand ganz genau, wie sich das Feld entfalten wird. Alternative Tools wie n8n oder Dify sind hier noch deutlich statischer als DeerFlow, aber möglicherweise ergeben sich für sie nun auch neue Richtungen. Umso spannender wird es zu beobachten, wie sich das DeerFlow-Framework weiterentwickelt.

(who)

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Konsistenz ist eine fachliche Entscheidung

2026-04-08T08:13:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Konsistenz (und Eventual Consistency) wird oft als technisches Risiko behandelt. Dabei gab es sie schon vor Computern. Wer sie ignoriert, baut fragile Systeme.

(Bild: NicoElNino/Shutterstock.com)

08.04.2026, 10:13 Uhr

Lesezeit: 14 Min.

Developer

Von

Golo Roden

Im Deutschen hat sich eine Übersetzung eingebürgert, die das Denken über verteilte Systeme in eine falsche Richtung lenkt. „Eventual Consistency“ wird häufig als „eventuell konsistent“ wiedergegeben. Eventuell, also möglicherweise. Eine Datenbank, die möglicherweise konsistent ist, klingt nach einem System, dem man besser nicht vertraut. Kein Wunder, dass viele Entwicklerinnen und Entwickler reflexartig nach stärkeren Garantien greifen, sobald der Begriff fällt.

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.

Die englische Bedeutung von „eventual“ ist jedoch eine andere. Sie meint „letztendlich“ oder „am Ende“. Eventual Consistency bedeutet also nicht, dass Konsistenz vielleicht eintritt. Sie bedeutet, dass Konsistenz verlässlich eintritt, nur nicht sofort. Die Frage ist nicht, ob, sondern wann. Und diese Frage ist keine technische, sondern eine fachliche. Das war sie schon immer.

Ein besseres mentales Modell als „möglicherweise inkonsistent“ ist das der veralteten Daten. In jedem Moment kann irgendein Teil eines Systems auf Daten zugreifen, die den allerletzten Stand nicht widerspiegeln. Die Daten sind nicht falsch. Sie sind nur nicht aktuell. Sie waren vor einem Moment korrekt. Sie werden in einem Moment wieder korrekt sein. Gerade eben sind sie veraltet. Jedes System hat irgendwo veraltete Daten. Die Frage ist nicht, ob Daten veraltet sein können, sondern wie veraltet akzeptabel ist. Millisekunden? Sekunden? Minuten? Stunden? Die Antwort hängt vom Anwendungsfall ab, und sie lautet selten „niemals“.

Die bequeme Lüge der starken Konsistenz

Es gibt noch etwas, das sich in der Softwareentwicklung hartnäckig hält: Die Behauptung, eine relationale Datenbank sei immer konsistent. Transaktionen garantieren es. ACID garantiert es. Nach dem Commit sind die Daten da, und jeder sieht sie. Das stimmt allerdings nur innerhalb einer einzelnen Datenbankinstanz, für eine einzelne Abfrage, in einem einzelnen Moment. So funktionieren reale Systeme nicht.

Wer Read-Replicas einsetzt, akzeptiert bereits, dass Leseoperationen veraltete Daten liefern können. Wer einen Cache verwendet, akzeptiert, dass die gecachten Daten zum Zeitpunkt des Lesens nicht mehr aktuell sein müssen. Wer eine mobile App betreibt, akzeptiert, dass die Anzeige auf dem Gerät den Stand der letzten Synchronisation zeigt, nicht den aktuellen. Und wer HTML serverseitig rendert, akzeptiert, dass die Seite zum Zeitpunkt der Auslieferung bereits veraltet sein kann.

In dem Moment, in dem Daten die Datenbank verlassen, beginnen sie zu altern. Bis sie den Bildschirm einer Nutzerin oder eines Nutzers erreichen, sind sie bereits ein Schnappschuss der Vergangenheit. Die Kundin sieht „Bestellung bestätigt“, aber das Lagersystem hat den Auftrag noch nicht verarbeitet. Der Kunde sieht „3 Stück auf Lager“, aber jemand anders hat gerade zwei davon in den Warenkorb gelegt. Das ist kein Fehler. Das ist die Funktionsweise verteilter Systeme. Und jedes System mit einer Bedienoberfläche ist ein verteiltes System, denn das Endgerät ist ein eigener Knoten, das Netzwerk ist unzuverlässig, und zwischen Anfrage und Antwort vergeht Zeit.

Videos by heise

Ich begegne in meiner Beratungsarbeit regelmäßig Teams, die überzeugt sind, ihre Systeme seien stark konsistent. Bei genauerem Hinsehen zeigt sich fast immer, dass die Konsistenz an der Datenbankgrenze endet. Dahinter beginnt eine Welt aus Caches, Replikas, Message-Queues und gerenderten Oberflächen, in der Daten bereits veraltet sind, bevor sie ankommen. Das System ist längst eventually consistent. Es gibt nur niemanden, der das ausspricht.

Konsistenz vor dem Computer

Eventual Consistency ist kein Phänomen, das mit verteilten Softwaresystemen entstanden ist. Sie ist ein Grundproblem der physischen Welt, und Unternehmen haben seit Jahrhunderten Wege gefunden, damit umzugehen.

Man stelle sich eine Firma mit zwei Vertriebsbüros in verschiedenen Städten vor, zu einer Zeit, als das Telefon das schnellste Kommunikationsmittel war. Beide Büros verkaufen aus demselben Lagerbestand. Eine Kundin in München möchte die letzte Einheit eines Produkts kaufen. Ein Kunde in Hamburg möchte dieselbe Einheit kaufen. Keiner der beiden Vertriebsmitarbeiter weiß, was der andere gerade macht.

Wie haben Unternehmen dieses Problem gelöst? Nicht durch perfekte Echtzeitsynchronisation. Sie haben akzeptiert, dass Konflikte auftreten werden, und Prozesse entwickelt, um sie zu behandeln. Sie haben überbucht und sich entschuldigt. Sie haben Sicherheitsbestände geführt. Sie haben im Lager angerufen, bevor sie eine Lieferung zugesagt haben. Sie haben enttäuschte Kundinnen und Kunden kompensiert. Sie haben Risiken gemanagt, nicht Konsistenz.

Das gleiche Produkt, das gleiche Problem, nur mit Stift und Papier statt mit Datenbanken. Keine Technologie der Welt kann diese grundlegende Herausforderung eliminieren: zwei Personen, zwei Orte, eine Ressource, unvollständige Information. Die Naturgesetze garantieren, dass Information Zeit braucht, um sich auszubreiten. Perfekte Synchronisation ist nicht nur schwierig. Sie ist unmöglich.

Das Interessante daran ist, dass diese analogen Prozesse oft erstaunlich gut funktioniert haben. Nicht weil sie Inkonsistenzen verhindert hätten, sondern weil sie Strategien für den Umgang mit ihnen entwickelt hatten. Die Buchhaltung glich am Ende des Tages die Bestände ab. Der Vertrieb rief im Zweifelsfall im Lager an. Und wenn doch einmal zwei Kunden dasselbe Produkt zugesagt bekamen, gab es ein Gespräch, eine Entschuldigung und eine Lösung. Der Geschäftsprozess war auf Konflikte vorbereitet, weil niemand auf die Idee gekommen wäre, sie für unmöglich zu erklären.

Wenn ich mit Teams über Eventual Consistency spreche, hilft dieser historische Blick oft mehr als jedes Architekturdiagramm. Er verschiebt das Problem aus der technischen Ecke in die geschäftliche, wo es hingehört. Die Frage lautet nicht: Wie verhindern wir Inkonsistenz? Sie lautet: Wie gehen wir mit ihr um?

Die richtigen Fragen stellen

Wenn Entwicklerinnen und Entwickler über Eventual Consistency diskutieren, stellen sie häufig die falsche Frage. Sie fragen: Ist Eventual Consistency hier akzeptabel? Das rahmt Konsistenz als binäre Eigenschaft, als hätte man sie oder hätte sie nicht.

Die richtigen Fragen sind anders: Wie häufig tritt ein Konflikt tatsächlich auf? Wenn zwei Nutzerinnen oder Nutzer gleichzeitig den letzten Artikel kaufen wollen: Passiert das einmal am Tag? Einmal im Monat? Einmal im Jahr? Die Häufigkeit entscheidet darüber, ob ein Konflikt ein reales Problem ist oder eine theoretische Sorge. Was kostet ein Konflikt? Ist die Konsequenz eine enttäuschte Kundin? Eine Rückerstattung? Ein manueller Eingriff? Ein rechtliches Problem? Die Kosten bestimmen, wie viel Aufwand die Vermeidung rechtfertigt. Und was kostet die Vermeidung? Stärkere Konsistenzgarantien sind nicht kostenlos. Sie erfordern Koordination, also Latenz. Sie erfordern Sperren, also geringeren Durchsatz. Sie erfordern Infrastruktur, also Geld.

Das sind betriebswirtschaftliche Fragen, keine Ingenieursfragen. Das Entwicklungsteam kann erklären, was technisch möglich ist und was jede Option kostet. Aber die Entscheidung über das akzeptable Risiko gehört ins Business. Ein Bezahlsystem und ein Social-Media-Feed haben unterschiedliche Toleranzen. Eine Patientenakte und ein Warenkorb haben unterschiedliche Anforderungen. Der Kontext bestimmt die Antwort.

Genau deshalb gehören Diskussionen über Eventual Consistency nicht ausschließlich in Technik-Meetings. Das Team mag starke Meinungen über technische Korrektheit haben, weiß aber vielleicht nicht, dass die Fachabteilung eine Verzögerung von einer Sekunde bereitwillig akzeptieren würde, wenn dafür die Infrastrukturkosten sinken. Oder es weiß nicht, dass ein bestimmter Anwendungsfall regulatorische Anforderungen hat, die stärkere Garantien verlangen. Das Gespräch braucht beide Perspektiven.

Alltagsbeispiele zeigen, wie selbstverständlich Eventual Consistency bereits ist. Paketverfolgung zeigt einen Status, der vor Stunden erfasst wurde. Das Paket wurde gescannt, als es das Sortierzentrum verlassen hat. Seitdem ist es unterwegs, möglicherweise bereits zugestellt. Die angezeigte Information ist veraltet, und das stört niemanden, weil ein ungefährer Überblick über den Fortschritt ausreicht. Bestandsanzeigen in Online-Shops sind ein ähnlicher Fall. „Nur noch 3 auf Lager“ war korrekt, als die Seite gerendert wurde. Inzwischen hat vielleicht jemand eines gekauft. Vielleicht hat jemand eines in den Warenkorb gelegt, ohne zu bestellen. Die Zahl ist ein Hinweis, keine Garantie. Und das ist akzeptabel, weil der Checkout-Prozess den Grenzfall abfängt, in dem der Artikel tatsächlich vergriffen ist.

Besonders aufschlussreich ist das Beispiel der Fluggesellschaften. Airlines überbuchen bewusst, weil sie wissen, dass ein Teil der Passagiere nicht erscheinen wird. Das Buchungssystem akzeptiert mehr Reservierungen, als Sitzplätze vorhanden sind. Wenn doch alle erscheinen, wird das Problem am Gate gelöst: Kompensation, Umbuchung, Upgrade. Das System ist darauf ausgelegt, Konflikte zu akzeptieren und sie nachträglich zu lösen. Das ist kein Versagen der Konsistenz. Es ist eine Geschäftsstrategie, die jedes Jahr Millionen von Flügen mit freien Sitzen füllt, die sonst leer geblieben wären.

All diese Systeme funktionieren. Ihre Nutzerinnen und Nutzer beschweren sich nicht, weil das Konsistenzfenster kurz genug ist oder weil der Geschäftsprozess die Ausnahmen elegant abfängt. Das Ziel war nie perfekte Konsistenz. Das Ziel war ausreichende Konsistenz.

Der Geldautomat, der weiterarbeitete

Unter den vielen Beispielen, die ich in Gesprächen über Eventual Consistency verwende, ist eines besonders aufschlussreich, weil es die Perspektive komplett umdreht.

Geldautomaten sind normalerweise online und mit den Systemen der Bank in Echtzeit verbunden. Bei einer Abhebung prüft der Automat den Kontostand, verifiziert die Deckung und gibt das Geld aus. Einfach und konsistent. Doch was passiert, wenn die Netzwerkverbindung ausfällt und der Automat offline geht?

Die meisten Entwicklerinnen und Entwickler, denen ich diese Frage stelle, antworten: „Der Automat muss den Betrieb einstellen. Keine Verbindung bedeutet keine Kontostandsprüfung. Keine Prüfung bedeutet mögliche Überziehungen. Also abschalten, bis die Verbindung wiederhergestellt ist.“ Das ist die naheliegende, die sichere, die technisch korrekte Antwort. Es ist aber auch die falsche.

Man stelle sich einen prominenten Millionär vor, der an einem Geldautomaten steht und 50 Euro abheben möchte, nur um zu erfahren, dass der Automat außer Betrieb ist. Die Schlagzeile am nächsten Tag: „Bank lässt Topkunden wegen Netzwerkproblem im Regen stehen.“ Das ist keine Schlagzeile, die eine Bank gebrauchen kann. Der Reputationsschaden übersteigt jedes Überziehungsrisiko bei einer Kleinbetragabhebung um ein Vielfaches.

Was machen Banken also tatsächlich? Der Automat arbeitet weiter, auch offline. Aber mit intelligentem Risikomanagement. Die meisten Ausfälle sind kurz: Die Verbindung bricht für wenige Minuten ab und stellt sich dann von selbst wieder her. Bis jemand etwas bemerkt, hat sich das Problem bereits gelöst. Die meisten Menschen heben zudem nur Geld ab, wenn sie wissen, dass sie es haben. Niemand möchte die Peinlichkeit erleben, an einem Geldautomaten mit einer Schlange hinter sich abgelehnt zu werden. Diese Selbstselektion reduziert das Überziehungsrisiko erheblich. Und für den Fall, dass die Verbindung länger ausfällt, begrenzt die Bank den maximalen Abhebungsbetrag im Offline-Modus.

Doch der eigentlich interessante Punkt liegt woanders. Wenn jemand im Offline-Modus sein Konto tatsächlich überzieht, hat die Bank zwei Möglichkeiten, die Situation zu rahmen. Erste Variante: „Kunde nutzte Systemschwachstelle während Netzwerkausfall.“ Das klingt nach einem Sicherheitsvorfall. Zweite Variante: „Bank zeigte Flexibilität und half Kunden trotz technischer Schwierigkeiten.“ Das klingt nach exzellentem Kundenservice. Und nebenbei: Die Bank berechnet Überziehungszinsen. Der Kunde, der 50 Euro abgehoben hat, die er nicht hatte, zahlt sie zurück, mit Aufschlag. Die Bank hat eine technische Einschränkung in eine Einnahmequelle verwandelt.

Das ist es, was fachliches Denken über Konsistenz bedeutet. Die Entwicklerin sieht ein Konsistenzproblem und will es um jeden Preis verhindern. Die Geschäftsseite sieht eine Risiko-Ertrags-Rechnung und findet eine Lösung, die besser ist als sowohl „immer konsistent“ als auch „immer verfügbar“. Die beste Antwort lag nicht im Engineering-Meeting. Sie lag im Business-Meeting.

Das Verstecken ist das eigentliche Risiko

Die Gefahr liegt nicht in Eventual Consistency. Sie liegt darin, so zu tun, als gäbe es sie nicht.

Wer sein System für stark konsistent hält, entwirft keine Kompensationslogik. Wer keine Konflikte erwartet, baut keine Konfliktbehandlung. Wer keine veralteten Daten einplant, gestaltet keine Benutzererfahrung, die damit umgehen kann. Und wenn dann die Race Condition doch eintritt, wenn der Cache im falschen Moment veraltete Daten liefert, wenn die Replica-Verzögerung zu einer sichtbaren Inkonsistenz führt, gibt es keinen Plan. Das System versagt auf eine Weise, die niemand vorhergesehen hat, weil sich niemand die Mühe gemacht hat, sie vorherzusehen.

Wer Eventual Consistency dagegen anerkennt, entwirft dafür. Man denkt darüber nach, was passiert, wenn Daten veraltet sind. Man baut idempotente Operationen, die gefahrlos wiederholt werden können. Man schafft Kompensationsmechanismen für den Fall, dass etwas schiefgeht. Man kommuniziert Unsicherheit gegenüber Nutzerinnen und Nutzern, statt falsche Sicherheit zu vermitteln.

In der Praxis bedeutet das konkrete Entwurfsentscheidungen. Statt „Bestellung erfolgreich“ anzuzeigen, wenn die Bestellung lediglich angenommen wurde, zeigt man „Bestellung wird verarbeitet“ und aktualisiert den Status, sobald die Verarbeitung abgeschlossen ist. Statt eine Schaltfläche nach dem Klick zu deaktivieren und auf Konsistenz zu hoffen, gestaltet man die Operation idempotent, sodass ein doppelter Klick keinen Schaden anrichtet. Statt einen Fehler zu zeigen, wenn ein Artikel zwischen Warenkorb und Checkout vergriffen ist, bietet man eine Alternative an. Das sind keine technischen Notlösungen. Das sind durchdachte Benutzererlebnisse, die auf einer ehrlichen Einschätzung der Systemrealität basieren.

Die deutsche Fehlübersetzung ist dabei versehentlich tiefgründig. „Eventuell konsistent“ klingt bedrohlich, weil Unsicherheit bedrohlich klingt. Aber Unsicherheit ist die Realität verteilter Systeme. Die Wahl besteht nicht zwischen Sicherheit und Unsicherheit. Sie besteht zwischen eingestandener und versteckter Unsicherheit. Das eine führt zu robusten Systemen. Das andere führt zu Überraschungen.

Eventual Consistency ist keine Einschränkung, die es zu überwinden gilt. Sie ist eine Realität, für die es zu entwerfen gilt. Ihre Systeme sind bereits eventually consistent. Die Frage ist, ob Sie für diese Realität entwerfen oder so tun, als existiere sie nicht. Und diese Frage ist keine, die ein Engineering-Team allein beantworten sollte. Sie ist eine fachliche Entscheidung. Das war sie schon immer.

(rme)

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Programmiersprache C++: Was reinterpret_cast nicht tut

2026-04-08T07:41:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Der Blog beschäftigt sich mit einem der größten Fallstricke von C++: reinterpret_cast kann zweckentfremdet undefiniertes Verhalten auslösen.

(Bild: Fransizka Panter)

08.04.2026, 09:41 Uhr

Lesezeit: 6 Min.

Developer

Von

Andreas Fertig

Im heutigen Beitrag werde ich eine der größten Fallstricke von C++ erläutern: reinterpret_cast. Ein anderer Titel für diesen Beitrag könnte lauten: „Das ist nicht der Cast, den du suchst!“

Andreas Fertig ist erfahrener C++-Trainer und Berater, der weltweit Präsenz- sowie Remote-Kurse anbietet. Er engagiert sich im C++-Standardisierungskomitee und spricht regelmäßig auf internationalen Konferenzen. Mit C++ Insights (https://cppinsights.io) hat er ein international anerkanntes Tool entwickelt, das C++-Programmierenden hilft, C++ noch besser zu verstehen.

Meine Motivation für diesen Blogbeitrag stammt aus mehreren Schulungen und einigen Vorträgen, die ich gehalten habe. Seit C++23 gibt es in der Standardbibliothek eine neue Funktion: std::start_lifetime_as. Wenn ich Kurse mit Schwerpunkt auf eingebetteten Umgebungen unterrichte oder Vorträge mit diesem Schwerpunkt halte, habe ich begonnen, std::start_lifetime_as in das Material aufzunehmen. Mit einem interessanten Ergebnis.

Das Feedback, das ich bekomme, lautet in etwa:

Warum benötige ich std::start_lifetime_as, ich habe doch schon reinterpret_cast?
Warum kann ich reinterpret_cast nicht verwenden?

Wer noch nie von start_lifetime_as gehört hat, findet weitere Informationen in meinem englischen Artikel „The correct way to do type punning in C++ - The second act“. Ich verwende folgendes Beispiel daraus:

struct ConfigValues {
  uint32_t                  chksum;
  std::array<uint32_t, 128> values;
};

bool ProcessData(std::span<unsigned char> bytes)
{
  if(bytes.size() < sizeof(ConfigValues)) { return false; }

  // #A
  ConfigValues* cfgValues = reinterpret_cast<ConfigValues*>(bytes.data());

  return HandleConfigValues(cfgValues);
}

Die Idee hier ist, eine Reihe von rohen Bytes in eine bekannte Struktur umzuwandeln – hier mit dem Namen ConfigValues. Zusammen mit start_lifetime_as gerate ich immer öfter in Gespräche, in denen mir Leute sagen, dass der Name reinterpret impliziert, dass solcher Code wie erwartet funktionieren sollte. Die Erwartung ist, dass solcher Code frei von undefiniertem Verhalten ist und tatsächlich einen Zeiger auf ein ConfigValues-Objekt zurückgibt.

Videos by heise

Zwar kann ich einer solchen Erwartung aufgrund des Wortlauts des Standards und des C++-Objektmodells nicht widersprechen, doch eine solche Erwartung führt zu undefiniertem Verhalten. In einer typsicheren Sprache kann ein Objekt nicht in ein anderes, nicht verwandtes Objekt konvertiert werden.

Der wichtigste Wortlaut ist [expr.reinterpret.cast § 7], der besagt:

An object pointer can be explicitly converted to an object pointer of a different type. When a prvalue v of object pointer type is converted to the object pointer type “pointer to cv T”, the result is static_cast<cv T*>(static_cast<cv void*>(v)). [Note 5: Converting a pointer of type “pointer to T1” that points to an object of type T1 to the type “pointer to T2” (where T2 is an object type and the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value. — end note]

Zunächst einmal handelt dieser ganze Absatz von Zeigern auf Objekte und nicht von Objekten selbst. Es heißt, dass du ein ConfigValues in einen void* oder einen beliebigen anderen Datentyp konvertieren kannst, der ein Objekttyp ist. Ein Objekttyp ist alles außer einem Funktionstyp, einem Referenztyp und void.

Weiter unten in der Anmerkung bestätigt der Standard ausdrücklich, dass du einen Rundlauf durchführen kannst. Zum Beispiel:

ConfigValues  cfg{};
ConfigValues* val{&cfg};
void*         typeErased         = reinterpret_cast<void*>(val);
ConfigValues* roundTripBackToVal = reinterpret_cast<ConfigValues*>(typeErased);

Dies ermöglicht Konstrukte, die sogenannte Typlöschung (Type Erasure) nutzen, wie std::any. Du kannst einen Alias eines anderen Zeigertyps erhalten.

Konvertierung nur für den Zeiger

In diesem Absatz ist von einer Konvertierung des Objekts selbst keine Rede. Nur den Zeiger kann man konvertieren.

Im Sinne des C++-Objektmodells muss eine Anwendung ein gültiges Objekt erstellen (und später zerstören). Aber alles, was jemals erstellt wurde, ist ein ConfigValues-Objekt. reinterpret_cast ist ein Werkzeug, das es ermöglicht, einen Zeiger eines anderen Typs zu speichern. Sobald du ihn verwenden möchtest, musst du den Zeiger wieder in seinen ursprünglichen Typ zurückkonvertieren.

Nehmen wir einmal an, reinterpret_cast würde so funktionieren, wie manche Leute es erwarten:

struct Apple {
  int x;
};

struct Orange {
  int y;
};

Apple*  grannySmith{new Apple{4}};
Orange* bali{reinterpret_cast<Orange*>(grannySmith)};  // #A

int y = bali->y;
int x = grannySmith->x;

Nach den Regeln von C++ muss ein Objekt erstellt und zerstört werden. Wenn #A ein Objekt erstellen würde, müsste es das grannySmith-Objekt zerstören. Was überraschend wäre. Dann hättest du keine Möglichkeit, eine Typlöschung wie std::any zu implementieren, da das Speichern eines gelöschten Typs void* das ursprüngliche Objekt aus Sicht der abstrakten Maschinerie von C++ zerstören würde. Das würde dem Compiler ermöglichen, verschiedene andere Optimierungen vorzunehmen, die das Programm zum Absturz bringen würden.

Mit reinterpret_cast hast du eine Möglichkeit, ein Objekt A als einen anderen Typ B zu aliasieren, jedoch ohne das Recht, jemals über diesen Zeiger auf ein B-Objekt zuzugreifen. Andererseits erstellt start_lifetime_as implizit ein B-Objekt am Zielort des Zeigers A, während gleichzeitig die Lebensdauer von A beendet wird.

Ein Objekt ins Leben rufen

Meist will man in diesen Situationen ein Objekt eines anderen Typs zum Leben erwecken. Und genau dafür ist std::start_lifetime_as gedacht.

Wenn du std::start_lifetime_as auf einen Zeiger anwendest, versteht die abstrakte Maschine, dass du ein neues Objekt dieses Typs erstellst. Im Gegensatz zu einem Aufruf von new oder einem Stack-Objekt wird kein Konstruktor ausgeführt. Alles geschieht nur innerhalb des C++-Objektmodells.

Es gibt noch eine weitere Funktion von std::start_lifetime_as: Wenn es die Lebensdauer eines neuen Objekts startet, wird die Lebensdauer der Quelle automatisch beendet, wiederum ohne einen tatsächlichen Destruktor aufzurufen. Das ist hier entscheidend.

Wenn ich std::start_lifetime_as auf mein vorheriges Beispiel anwende, sieht die korrekte Implementierung wie folgt aus:

struct Apple {
  int x;
};

struct Orange {
  int y;
};

Apple*  grannySmith{new Apple{4}};
Orange* bali{std::start_lifetime_as<Orange>(grannySmith)};  // #A

int y = bali->y;

grannySmith = std::start_lifetime_as<Apple>(bali);  // #B
int x       = grannySmith->x;

Der Code in #B startet die Lebensdauer des Zeigers erneut als Apple-Objekt.

Wichtigste Erkenntnisse

Mit reinterpret_cast erhältst du nur eine Zeigerkonvertierung. Du darfst diesen neuen Zeiger nicht verwenden, um auf ein Objekt des Typs zuzugreifen.

Wenn du die Lebensdauer eines Objekts starten möchtest, um auf Daten als neuen Typ zuzugreifen, benötigst du std::start_lifetime_as.

(rme)

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Anthropics neues KI-Modell Mythos: Zu gefährlich für die Öffentlichkeit

2026-04-08T05:03:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Anthropics neues KI-Modell Mythos soll so effektiv im Finden und Ausnutzen von Sicherheitslücken sein, dass es nur IT-Infrastruktur absichern soll.

128

(Bild: tete_escape/Shutterstock.com)

08.04.2026, 07:03 Uhr

Lesezeit: 3 Min.

Von

Martin Holland

Anthropic hat mit Mythos ein neues KI-Modell vorgestellt, das so gefährlich sein soll, dass es nicht öffentlich gemacht werden soll. Stattdessen soll Claude Mythos Preview im Rahmen einer Initiative namens Project Glasswing zuerst ausschließlich einer Reihe von Firmen zur Verfügung gestellt werden, die an IT-Sicherheit arbeiten. Die sollen die KI-Technik nutzen, um die „kritischste Software der Welt“ abzusichern. Das KI-Modell habe bereits tausende hochriskante Zero-Day-Lücken identifiziert, begründet Anthropic den Schritt. Solche seien in allen großen Betriebssystemen und jedem Internetbrowser, aber auch in zahlreicher anderer Software entdeckt worden. Vor allem sei Mythos Preview deutlich häufiger in der Lage, einen funktionierenden Exploit zu entwickeln.

Jahrzehntealte Lücken identifiziert

Als Beispiel listet Anthropic etwa eine seit 27 Jahren übersehene Lücke in OpenBSD auf, über die Angreifer ein Gerät aus der Ferne zum Absturz bringen könnten, „indem sie sich nur damit verbinden“. Auch von einer 16 Jahre alten Lücke in FFmpeg ist da die Rede, die bei fünf Millionen automatischen Scans mit speziellen Suchwerkzeugen nicht identifiziert worden sei. Zudem sei das Modell in der Lage gewesen, eine Reihe von bislang unbekannten Lücken im Linux-Kernel zusammenzuführen und daraus eine Attacke zu entwickeln, die es einem Angreifer ermöglichen würde, als normaler User die komplette Kontrolle über einen Rechner zu erlangen. Diese und andere Lücken seien den jeweils Verantwortlichen gemeldet worden. Anthropic hat dazu einen Blogeintrag veröffentlicht.

Der jetzt vorgestellten Initiative „Project Glasswing“ gehören demnach unter anderem Amazon Web Services (AWS), Anthropic, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, die Linux Foundation, Microsoft, NVIDIA und Palo Alto Networks an. 40 weitere Organisationen, die Software für kritische Infrastruktur verantworten, seien ebenfalls beteiligt. Insgesamt stellt Anthropic demnach Nutzungsrechte im Wert von bis zu 100 Millionen US-Dollar für das neue KI-Modell zur Verfügung, 4 Millionen US-Dollar sollen direkt an Betreiber von Open-Source-Software gehen. Damit soll ihnen allen ermöglicht werden, Systeme nach Schwachstellen zu durchsuchen. Die sollen geschlossen werden, bevor andere KI-Modelle zu den Fähigkeiten von Mythos aufholen.

Videos by heise

Anthropic ist primär für seine KI Claude bekannt, die mit ChatGPT von OpenAI konkurriert. Zuletzt geriet die Firma aber durch einen Streit mit dem Pentagon in die Schlagzeilen: Anthropic lehnte den Einsatz seiner KI in autonomen Waffen oder zur Massenüberwachung in den USA ab und wurde im Gegenzug zum Sicherheitsrisiko erklärt. Dagegen geht das Unternehmen gerichtlich vor. Dem US-Magazin Platformer hat die KI-Firma erklärt, dass sie der US-Regierung bei der sicher nötigen Evaluierung von Mythos helfen könnte. Noch sei aber unklar, ob sie das Angebot annehmen würde. Unklar ist auch, ob der Plan, Sicherheitslücken mit immer mächtigeren KI-Werkzeugen jeweils rechtzeitig vor böswilligen Angreifern finden zu wollen, aufgehen kann.

Lesen Sie auch

Anthropic will über 3,5 Gigawatt Rechenkapazität mit Googles TPUs

Top 10: Der beste Fensterputzroboter im Test – Hutt vor Ecovacs und Dreame

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Self-Hosted Backend: Appwrite 1.9 bringt MongoDB

2026-04-07T13:41:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Appwrite 1.9 bringt MongoDB-Support, ressourcenbasierte API-Keys und Query-Filter für Realtime-Subscriptions. Hinzu kommen Performance- und Compute-Updates.

(Bild: Appwrite)

15:41 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

Appwrite 1.9.0 ist da und unterstützt nun MongoDB, feinere Sicherheitsmechanismen und gezieltere Realtime-Funktionen. Hinzu kommen ein ausgebauter Compute-Bereich und zahlreiche Performance-Verbesserungen.

Bei Appwrite handelt es sich um eine quelloffene Backend-as-a-Service-Plattform (BaaS), die Authentifizierung, Datenbank, Storage, Serverless Functions und Realtime-Kommunikation in einem Paket für den Eigenbetrieb bündelt. Damit richtet sie sich an Teams, die mehr Kontrolle über ihre Backend-Infrastruktur behalten wollen, als es klassische Cloud-BaaS-Dienste erlauben.

MongoDB und Datenbank-Feinschliff

Die zentrale Neuerung: Appwrite unterstützt jetzt MongoDB als Datenbank-Backend. Damit steht neben dem bisherigen TablesDB-Modell erstmals eine dokumentenorientierte Alternative bereit. Entwickler können so dynamische Datenstrukturen abbilden – etwa Event- oder Log-Daten mit variierenden Feldern –, ohne vorher ein Schema anzupassen.

Ferner ergänzt Version 1.9.0 neue String-Typen wie mediumtext und longtext, unterstützt 64-Bit-Integer und zeigt den Speicherverbrauch einzelner Collections an. Dokumentlisten lassen sich zudem mit konfigurierbarer TTL cachen, was bei häufig abgefragten Datenbeständen die Datenbanklast senkt.

Neue Admin-APIs

Administratoren erhalten mehrere neue Schnittstellen: Eine Webhooks-API verwaltet Ereignisbenachrichtigungen zentral. Eine Schedules-API gibt Einblick in geplante Aufgaben und stellt Steuerungsfunktionen bereit. Neu ist auch eine Nutzer-Impersonation (User Impersonation). Damit kann sich ein Admin als ein bestimmter Nutzer anmelden, um Fehler direkt aus dessen Perspektive nachzuvollziehen. Projektvariablen lassen sich jetzt gezielt als öffentlich markieren, etwa um Konfigurationswerte ans Frontend durchzureichen.

Die Realtime-Schnittstelle arbeitet nun gezielter. Clients definieren Subscriptions mit Query-Filtern und empfangen nur noch passende Ereignisse statt sämtlicher Änderungen in einer Collection. Ein Client könnte so ausschließlich Updates für eine bestimmte Nutzer-ID abonnieren. Appwrite liefert außerdem Metriken zu Verbindungen, Nachrichtenaufkommen und Bandbreite.

Feinere Zugriffskontrolle

API-Keys lassen sich ab Version 1.9.0 ressourcenbezogen einschränken. Ein Key kann etwa Lesezugriff auf den Storage erhalten, ohne gleichzeitig die Benutzerverwaltung freizuschalten. JWT-Laufzeiten sind individuell konfigurierbar. Verbesserungen bei CORS, OAuth und Multi-Domain-Support erleichtern Setups mit mehreren Frontends.

Im Serverless-Bereich trennt Appwrite jetzt Build- und Runtime-Ressourcen. Wer rechenintensive Builds mit einer schlanken Runtime kombinieren muss, kann beides unabhängig dimensionieren. Eigene Startkommandos, automatisches Aufräumen alter Deployments und verwaister Ausführungen sowie saubere Worker-Shutdowns sollen den Betrieb stabiler machen.

Videos by heise

Storage, Migration und SDKs

Dateien lassen sich jetzt einzeln mit Verschlüsselungs- und Komprimierungsparametern versehen. Listenabfragen geben den gesamten Speicherverbrauch zurück. Neue Migrationstools übertragen Sites und Messaging-Ressourcen zwischen Appwrite-Instanzen. Hinzu kommen ein offizielles Rust-SDK, ein Plugin für die KI-gestützte IDE Cursor sowie ein Agent Skills SDK, das die Integration von KI-Agenten erleichtern soll.

Unter der Haube haben die Entwickler die Architektur auf die modulare Utopia-Plattform umgestellt. Der bisherige Proxy-Container entfällt, Traefik wird direkt angesprochen. Sparse Updates senden nur noch geänderte Attribute, Shared-Memory-Caching via Swoole Tables ersetzt den bisherigen Pro-Worker-Cache und vorverarbeitete Queries beschleunigen häufig genutzte Pfade. Swoole ist eine PHP-Erweiterung für asynchrone Programmierung, die hier für effizientes Shared-Memory-Caching genutzt wird. Diverse Memory Leaks in der Webhook-, Statistik- und Event-Verarbeitung haben die Entwickler behoben.

Upgrade

Appwrite 1.9.0 setzt ein Upgrade von Version 1.8.1 voraus und erfordert eine Datenbankmigration. Diese lässt sich über den neuen Web-Installer, das CLI-Flag --migrate oder manuell per docker compose exec appwrite migrate anstoßen.

Alle Informationen zu Appwrite 1.9.0 finden sich in den Release Notes auf GitHub.

(fo)

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

JSON Alexander: Syntax-Highlighting und Baumdarstellung im Browser

2026-04-07T10:50:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Syntax-Highlighting und Baumdarstellung: Das Add-on verbessert die Ansicht von JSON-Daten, insbesondere für API-Entwickler.

(Bild: TierneyMJ / Shutterstock.com)

12:50 Uhr

Lesezeit: 1 Min.

Developer

Von

Wolf Hosbach

JSON Alexander, eine neue Extension für Firefox und Chrome, formatiert automatisch JSON-Daten, die beispielsweise von einer API gesendet wurden. Das Add-on erweitert die rudimentären Darstellungen der Browser insbesondere um Syntax-Highlighting und eine Baum-Ansicht.

JSON Alexander zeigt JSON-Daten übersichtlich formatiert.

(Bild: JSON Alexander)

Das Add-on bietet eine Reihe von Komfortfunktionen, die über die Standarddarstellung der Browser hinausgehen. Neben dem Syntax-Highlighting und den ausklappbaren Strukturbäumen sind das zum Beispiel Zusatzinfos beim Hover über ein Feld oder eine parallele Daten-Ansicht als windows.data in der Konsole.

JS-Autor und Podcaster Wes Bos hat JSON Alexander unter MIT-Lizenz veröffentlicht. Zuvor waren ihm Zweifel am Add-on „Heads Up“ gekommen, das ähnliche Funktionen bietet, weil es laut Bos Webtracking in Webseiten implementiert. Die Redaktion konnte das nicht überprüfen.

Videos by heise

Das Add-on ist noch nicht in den Stores der Browser vorhanden, sondern Anwenderinnen und Anwender müssen es von Hand installieren. Bei Firefox müssen sie zusätzlich den JSON-Standardmechanismus deaktivieren. Anleitungen finden sich im Repository. Der Name des Tools spielt auf den US-amerikanischen Schauspieler Jason Alexander an.

Lesen Sie auch

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

IntelliJ IDEA 2026.1: Kostenfreier Basis-Support für JavaScript und TypeScript

Next.js 16.2 bringt Updates für die Nutzung von KI-Agenten

Wasmer stellt Edge.js vor: Node.js in WebAssembly-Sandbox

enterJS Integrate AI: KI‑Workflows in der Webentwicklung souverän einsetzen

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Software Testing: Als Software-Tester von der Stiftung Warentest lernen

2026-04-07T08:33:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Was können Software-Tester davon lernen, wie Stiftung Warentest beim Testen vorgeht? Das bespricht Richard Seidl mit Johannes Stiller.

(Bild: Richard Seidl)

10:33 Uhr

Lesezeit: 2 Min.

Developer

Von

Richard Seidl
Johannes Stiller

In dieser Episode spricht Richard Seidl mit Johannes Stiller von Stiftung Warentest über die Testmethoden und Entscheidungsprozesse bei Produktprüfungen. Es geht darum, wie die Stiftung ihre Prüfprogramme entwickelt, welche Kriterien für verschiedene Produkte gelten und wie Teams aus Wissenschaftlern und Marktanalysten zusammenarbeiten. Besonders spannend: die Parallelen zum Softwaretesting, etwa Objektivität, Transparenz und die Perspektive des Nutzers. Wie funktioniert die Auswahl der getesteten Produkte und wie werden subjektive Eindrücke bei Zahnbürsten oder Laptops möglichst vergleichbar gemacht?

Empfohlener redaktioneller Inhalt

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

YouTube-Video immer laden

Johannes Stiller schloss 2016 seine Promotion im Bereich der nuklearen Kern- und Teilchenphysik in Heidelberg ab. Während dieser Zeit arbeitete er intensiv vor Ort am CERN am ALICE-Experiment. Aufgrund seiner Expertise in Tracking-Algorithmen wechselte er anschließend in die Softwareentwicklung der Automobilindustrie. Ein wesentlicher Meilenstein war seine maßgebliche Beteiligung an den Sicherheitsbremssystemen für das autonome Parkshuttle-System Parkshuttle Rivium. Nach seinem Umzug nach Berlin widmete er sich im VW-Konzern der Serienentwicklung von Fahrassistenzsystemen wie dem Emergency Assist und dem Travel Assist, inklusive der ASPICE-konformen Entwicklung, Prüfung und Freigabe. Seit August 2025 bekleidet Johannes Stiller eine leitende Funktion bei der Stiftung Warentest, wobei ihn besonders die Möglichkeit motiviert, vielseitige Themen auf wissenschaftlich fundierter Basis zu bearbeiten.

Lesen Sie auch

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

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

AGENTS.md: Hilfreiches Agentenbriefing oder Tokenfresser?

2026-04-06T05:16:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Eine AGENTS.md gilt meist als Pflicht für den Einsatz von Coding-Agenten. Doch aus einer gut gemeinten Hilfe kann schnell zusätzlicher Ballast werden.

(Bild: Vanessa Bahr / iX)

06.04.2026, 07:16 Uhr

Lesezeit: 8 Min.

iX Magazin

Von

Dr. Fabian Deitelhoff

Die Datei AGENTS.md ist ein Readme für KI-Agenten: Ein fester Ort im Repository, an dem Build‑Schritte, Testkommandos, Tooling, Architekturlinien und Coding-Guidelines speziell für autonome Coding-Agenten beschrieben sind. Die Idee ist, dass Agenten diese Datei früh lesen und dadurch schneller verstehen, wie sie Tests ausführen, den Code strukturieren und welche Konventionen sie beachten müssen.

Anbieter wie OpenAI, Anthropic, GitHub und Qwen bewerben dieses Muster offensiv. Zudem bringen viele Frameworks Kommandozeilenbefehle wie /init mit, die aus einem bestehenden Repository automatisch eine AGENTS.md oder eine ähnliche Datei wie CLAUDE.md generieren. Dadurch hat sich der Standard rasant verbreitet: Im Jahr 2025 waren bereits zehntausende öffentliche GitHub-Repositorys mit Kontextdateien ausgestattet, die Tendenz ist steigend. Das AGENTS.md-Repository auf GitHub listet die Vorteile auf und zeigt Beispiele für den Aufbau solch einer Datei.

Ein Team an der ETH Zürich hat den Aufbau und die Nützlichkeit von AGENTS.md unter die Lupe genommen. Die Studie „Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?“ untersucht erstmals systematisch, welchen Effekt solche Dateien auf reale Agentenworkflows haben. Die Forschenden kombinieren dafür zwei Benchmarks: das etablierte SWE‑bench Lite mit 300 Aufgaben aus elf populären Python-Repositorys und das Benchmarktool AgentBench mit 138 Aufgaben aus zwölf weniger bekannten Repos, die alle echte, von Entwicklern geschriebene Kontextdateien enthalten.

Getestet hat das Team der Studie die Coding-Agenten Claude Code mit Sonnet 4.5, OpenAI Codex mit GPT-5.2 und GPT-5.1 mini sowie Qwen Code mit Qwen3-30B-Coder, jeweils in drei Varianten: ohne Kontextdatei, mit automatisch generierter Kontextdatei nach Empfehlung des jeweiligen Agentenentwicklers und – auf AgentBench – mit der real vorhandenen, von Entwicklern gepflegten Kontextdatei. Alle Agenten haben die Datei in ihren Kontext geladen, entweder AGENTS.md (für Codex- und Qwen-Code) oder CLAUDE.md (Claude Code). Die Erfolgsquote hat das Team dabei streng über Testsuites gemessen: Ein Task gilt nur dann als gelöst, wenn alle zugehörigen Tests nach Anwenden des Agentenpatches grün laufen.

Die Erkenntnis: kaum Nutzen, spürbare Kosten

Das Ergebnis ist ernüchternd: LLM‑generierte Kontextdateien reduzieren die Erfolgsrate im Mittel leicht – um etwa 0,5 Prozentpunkte bei SWE‑bench Lite und rund 2 bis 3 Prozentpunkte bei AgentBench, je nach Modell. Gleichzeitig steigen die Inferenzkosten im Schnitt um 20 bis 23 Prozent, weil die Agenten mehr Schritte ausführen und längere Reasoning‑Passagen produzieren.

Auch menschlich gepflegte Kontextdateien schneiden nur moderat besser ab: Sie verbessern die Erfolgsrate auf AgentBench im Mittel um etwa 4 Prozentpunkte gegenüber dem Szenario ganz ohne Kontextdatei, erhöhen aber ebenfalls die Anzahl der Agentenschritte und damit die Kosten – in einzelnen Set-ups um knapp 20 Prozent. Überspitzt formuliert bedeutet das: Für ein paar Prozentpunkte Erfolgsgewinn bezahlt man mit deutlich mehr Tokenverbrauch, längeren Laufzeiten und komplexeren Agenten-Traces.

Die Studie zeigt, dass Agenten die Anweisungen in Kontextdateien ernst nehmen: Sind bestimmte Tools oder Workflows erwähnt, nutzen Agenten sie häufiger – etwa Projektskripte, pytest, uv oder repositoryspezifische Hilfstools. Kontextdateien führen auch zu mehr Tests, mehr Dateizugriffen und ausführlicherer Repositorynavigation. Das Problem ist also nicht, dass die Modelle Kontextinstruktionen ignorieren.

Die zusätzliche Aktivität macht die Aufgaben jedoch schwieriger: Mehr Anweisungen bedeuten mehr Dinge, die der Agent berücksichtigen und gegeneinander abwägen muss, was sich in mehr Reasoning-Token pro Task niederschlägt. Gleichzeitig funktionieren Kontextdateien schlecht als Repository-Overview: Die Agenten finden die für einen Bugfix relevanten Dateien im Schnitt nicht schneller als ohne AGENTS.md, obwohl viele Dateien explizit Verzeichnisstrukturen, Komponenten und Einstiegspunkte beschreiben.

Redundante Dokumentation statt gezielten Mehrwerts

Eine wichtige Beobachtung des ETH-Teams ist, dass LLM‑generierte Kontextdateien meist redundant zur bestehenden Dokumentation sind: Readme, Contributing, Docs‑Ordner und Beispiele enthalten bereits Build‑und Testhinweise, Architekturübersichten und Stilvorgaben, die die Agenten via Dateizugriff ebenfalls nutzen können. In einem Ablationsexperiment entfernten die Forschenden deshalb alle anderen Dokumentationsdateien aus dem Repository und ließen nur die generierte Kontextdatei stehen. Ein Ablationsexperiment (Ablation Study) ist eine Methode zur Evaluierung von KI-Modellen, bei der gezielt spezifische Komponenten wie ein Feature, ein Layer oder Module entfernt oder verändert wurden, um deren Einfluss auf die Gesamtleistung zu messen.

In solch einem dokumentationsarmen Setting kippt das Bild: Plötzlich verbessern die generierten Kontextdateien die Erfolgsrate der Agenten im Schnitt um rund 2,7 Prozentpunkte und schneiden teilweise sogar besser ab als die ursprünglichen Entwicklerdokumente. Die naheliegende Interpretation: Kontextdateien sind dann hilfreich, wenn sie echte Wissenslücken der Agenten füllen und nicht, wenn sie bereits vorhandene Informationen noch einmal in leicht anderer Form wiederholen.

Eine separate empirische Analyse von über 2.300 Agenten-Readmes aus knapp 2.000 Repositorys zeigt, wie Entwickler solche Dateien heute nutzen (siehe Studie „Agent READMEs: An Empirical Study of Context Files for Agentic Coding“). Am häufigsten enthalten sie funktionalen Kontext: Build‑ und Run‑Kommandos (in gut 60 Prozent der Fälle), Implementationsdetails (knapp 70 Prozent) und Architekturhinweise (rund 68 Prozent).

Deutlich unterrepräsentiert sind dagegen nicht funktionale Anforderungen wie Sicherheit und Performance, die nur jeweils in rund 15 Prozent der Dateien explizit adressiert sind. Zudem sind viele Dateien lang, schwer lesbar und entwickeln sich eher wie Konfigurationsartefakte mit vielen kleinen Ergänzungen als wie klar kuratierte Dokumente – ein weiterer Hinweis darauf, warum generalistische Kontextdateien für Agenten schnell zur kognitiven Last heranwachsen.

Videos by heise

Praktische Leitlinien für den Einsatz

Aus Sicht der Praxis ergeben sich daraus einige Empfehlungen für den produktiven Einsatz von AGENTS.md (siehe GitHub-Blogartikel „How to write a great agents.md“):

Nichts wiederholen, was schon im Readme und in Docs steht. Doppelte Projektbeschreibungen oder lange Architekturexkurse sind zu vermeiden, wenn sie bereits an anderer Stelle gepflegt sind.
Schwerpunkt auf fehlendem, schwer zu erschließendem Kontext. Dazu gehören projekt- oder teamspezifische Skripte, besondere Test‑Set-ups, nicht offensichtliche Fallstricke oder domänenspezifische Invarianten, die der Agent sonst nur durch intensives Trial and Error lernen würde.
Minimalistische testbare Regeln statt Wunschliste. Jede zusätzliche Regel erhöht die Suchfläche für den Agenten. Sinnvoll sind wenige, klar begründete Anforderungen, etwa „Tests immer über make test-ci laufen lassen“ statt eines halben Dutzends alternativer Workflows.
Agentenrolle klar zuschneiden. GitHub berichtet aus der Analyse von über 2.500 AGENTS.md-Dateien, dass spezialisierte Rollen – beispielsweise ein reiner Testagent oder Docs‑Agent – besser funktionieren als generische Anweisungen.
Iterativ verbessern statt im Vorfeld alles perfektionieren. Erfolgreiche Agenten-Readmes entstehen dadurch, dass Teams typische Fehlervarianten des Agenten beobachten und daraus gezielte, knappe Korrekturanweisungen ableiten.

Zudem kann es hilfreich sein, den Agenten selbst seine eigene AGENTS.md optimieren zu lassen. Das LLM kann eine AGENTS.md analysieren und verbessern, indem es unklare Formulierungen, Widersprüche, Redundanzen oder fehlende Entscheidungsregeln erkennt und präziser formuliert. Die überarbeiteten Anweisungen steuern später das Verhalten eines Agenten. Besonders sinnvoll ist das, wenn das Resultat nicht nur das Umschreiben der Datei ist, sondern diese anschließend auch mit Beispielaufgaben getestet wird, um zu sehen, ob der Agent die gewünschten Regeln tatsächlich besser befolgt. Am zuverlässigsten ist deshalb ein iterativer Prozess, der analysiert, überarbeitet und testet, statt sich nur auf eine sprachlich schönere Version zu verlassen.

Implikationen für Teams mit Coding-Agenten

Für Entwicklungsteams ist AGENTS.md kein kostenloser Produktivitätsturbo, sondern ein Steuerungsinstrument, bei dem sie Kompromisse eingehen müssen. Automatisch generierte, stark redundante Kontextdateien verschlechtern in der aktuellen Evidenzlage die Erfolgsraten, verteuern jeden Agentenlauf und erzeugen komplexere Traces, die schwerer zu debuggen sind.

Hilfreich sind Repositorykontextdateien vor allem dort, wo sie gezielt fehlende Informationen bereitstellen, etwa in schlecht dokumentierten oder speziellen Codebasen, für Nischen-Toolchains oder klar abgegrenzte Agentenrollen. Die Aussage „Readme für KI-Agenten“ der AGENTS.md-Website ist daher wörtlich zu nehmen: nicht als weitere vollständige Dokumentation, sondern als schlanke, präzise Betriebsanleitung, die Agenten genau so viel Kontext gibt, wie sie für robuste Ergebnisse brauchen – und kein Token mehr.

(nb)

Top 10: Der beste Fensterputzroboter im Test

Top 10: Der beste Full-HD-Beamer für Heimkino, TV & Konsole im Test

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

Totgesagte leben länger: Lokale Bilder-KI Amuse 3.2.0 erschienen

2026-04-04T08:21:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Entwicklung an der Bild- und Video-KI Amuse wurde eingestellt, die Quellen als Open Source veröffentlicht. Nun gibt es erste Updates.

(Bild: heise medien)

04.04.2026, 10:21 Uhr

Lesezeit: 2 Min.

Von

Dirk Knop

Die Entwicklung der lokal arbeitenden Bild- und Video-KI-Software Amuse hatte Hersteller TensorStack-AI eigentlich eingestellt und die Quellen veröffentlicht. Jetzt hat das Open-Source-Projekt in der Nacht zum Freitag dieser Woche ein erstes Update veröffentlicht. Die Entwicklung geht damit weiter.

In dem Amuse-GitHub-Projekt hat es seit Dezember einige Änderungen gegeben. Die Konzentration und starke Optimierung für AMD-Hardware ist Vergangenheit. Nun hebt das Projekt insbesondere HP-KI-Geräte werblich hervor. Konkrete Anpassungen an die Hardware des Herstellers lassen sich allerdings nicht erkennen.

Nicht alle Änderungen protokolliert

Das offizielle Changelog zur aktuellen Version Amuse 3.2.0 fällt zunächst übersichtlich aus. Die Migration auf .NET 10 aller Komponenten solle demnach einen Performance-Schub aufgrund besserer Speicherverwaltung und Optimierungen des JIT-Compilers bringen. Das Update auf die OnnxRuntime 1.23.0 führt demnach zu mehr Stabilität und liefert Unterstützung zum Einbinden neuerer KI-Modell-Architekturen. Die Ausführungs-Provider sollen ebenfalls verbessert sein und mehr Geschwindigkeit bringen. Die Dependencies wurden modernisiert und die internen NuGet-Bibliotheken auf die jüngsten stabilen Versionen aktualisiert. Das sorge für mehr Sicherheit, Stabilität und Kompatibilität.

Videos by heise

Beim kurzen Test mit einem eher schwachbrüstigen AMD-Ryzen-7640HS-System mit 64 GByte RAM, das lediglich eine 10-TOp/s-NPU enthält, sind die Ergebnisse jedoch durchwachsen. Das Changelog erwähnt die Änderungen an der Bedienoberfläche nicht, etwa die Anzeigen zu Prozessor-, GPU- und NPU- sowie jeweiliger Speicherauslastung wurden eingedampft. AMD-Optimierungen wie der KI-basierte und flinke „AMD XDNA Super Resolution“-Upscaler sind rausgeflogen.

Die AMD-AI-optimierten Modelle sind in der Software nicht mehr auffindbar. Die allgemeinen Modelle funktionieren jedoch in weitgehend ähnlichem Tempo wie zuvor. Allerdings stürzt die OnnxRuntime nun bei Modellen mit mehr Speicherhunger öfter mit der Fehlermeldung ab, dass die Grafikkarte keine Befehle mehr annehme. Die kleineren Modelle bis etwa 4 GByte funktionieren jedoch problemlos.

Es bleibt spannend, ob die Weiterentwicklung diese Probleme aufnimmt und löst. Lokale Künstliche Intelligenz liefert mehr Privatsphäre, und Amuse ist die bislang einfachste Möglichkeit zur lokalen Erstellung von Bildern und Videoschnipseln. Lösungen wie ComfyUI sind zwar eine Alternative, jedoch deutlich schwieriger zu bedienen.

heise developer News

Apples früherer KI-Chef John Giannandrea verlässt das Unternehmen

KI-Weichen neu gestellt

Eine letzte Aktienprämie

Einfache UX für domänenspezifische Sprachen mit VS Code gestalten

DSL als Alternative zu Formularen und Konfigurationsdateien

Das Language Server Protocol als Enabler für eine DSL-UX

Eine neue DSL entwickeln

UX-Interaktionen im Editor über LSP

Fazit: Alternative UX-Technologie

Literaturverzeichnis

Developer-Häppchen fürs Wochenende – Kleinere News der Woche

Gas Town 1.0.0: Agenten brauchen jetzt eine Freigabe

Mehrstufige Workflows und GitHub-Merge-Queue-Anbindung

Windows-Support

Sicherheit und Governance

Neu in .NET 10.0 [18]: Webserver als File-based App

Keycloak 26.6.0: Fünf Preview-Features werden produktionsreif

Workflows und JWT Authorization Grant

Experimentelle MCP-Unterstützung und Java 25

Plane 1.3.0: Update der freien Jira-Alternative

Integrationen: Gitea-Login und neue API-Endpunkte

Überarbeitete Oberfläche mit einheitlichem Designsystem

Sicherheit: Mehrere Angriffsvektoren geschlossen

software-architektur.tv: Was Developer von anarchistischen Denkern lernen können

Empfohlener redaktioneller Inhalt

Livestream am 10. April

Eclipse hawkBit 1.0: Backend für IoT-Updates erreicht Produktionsreife

Backend für IoT-Rollouts

Flexible Architektur und Ökosystem

VeraCrypt und WireGuard: Trubel bezüglich Treibersignierung, Lösung in Sicht

Langwieriger Berufungsprozess

Microsoft reagiert, Entwickler bald wieder einsatzfähig

React im Terminal: Ink 7.0 überarbeitet Input-Handling grundlegend

Breaking Changes im Input-Handling

Neue Hooks für Interaktivität und Animation

Rendering und Layout-Erweiterungen

Bugfixes

DeerFlow: Super-Agenten-Framework von ByteDance

ByteDance legt vor

Von Deep Research zu Super-Agenten

DeerFlow bringt neue Ideen

Konsistenz ist eine fachliche Entscheidung

Die bequeme Lüge der starken Konsistenz

Konsistenz vor dem Computer

Die richtigen Fragen stellen

Der Geldautomat, der weiterarbeitete

Das Verstecken ist das eigentliche Risiko

Programmiersprache C++: Was reinterpret_cast nicht tut

Konvertierung nur für den Zeiger

Ein Objekt ins Leben rufen

Wichtigste Erkenntnisse

Anthropics neues KI-Modell Mythos: Zu gefährlich für die Öffentlichkeit

Jahrzehntealte Lücken identifiziert