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:

Das Windows App Development CLI 0.6.0 macht Tempo. Entwicklerinnen und Entwickler können neue WinUI‑Projekte jetzt mit einem einzigen Befehl erstellen und WinUI‑Steuerelemente durchsuchen, ohne das Terminal verlassen zu müssen. Außerdem lässt sich eine App nun direkt aus einer .csproj-Datei ausführen.
JetBrains IDE‑Manager Toolbox App 3.7 aktiviert standardmäßig die JVM‑Speicheroptimierung, behebt Probleme beim Sitzungsablauf und verbessert die Zuverlässigkeit von Patch-Updates unter macOS, indem es die Code-Signatur prüft. Zudem läuft die Toolbox App jetzt auch bei eingeschalteter Windows Smart App Control.
Der Binärdaten-Editor GNU Poke liegt in Version 5.0 vor. Das Release bringt Verbesserungen beim Poke‑Compiler, echte Float‑Operationen sowie Aktualisierungen der Laufzeitumgebung und der Standardbibliothek.

(Bild: AliaAyah / Shutterstock)

Am 22. und 23. September findet die heise devSec 2026 in Marburg statt. Im Fokus stehen dieses Jahr unter anderem die sichere Software Supply Chain und der Security-Aspekt bei Agentic AI in der Softwareentwicklung.

Das Anfang 2026 gegründete Python Packaging Council (PPC) führt erstmals Wahlen durch. Fünf Vorstandssitze sind zu vergeben, für die es 17 Kandidaten gibt. Um Kontinuität zu schaffen, bleiben die beiden Kandidaten mit den meisten Stimmen zwei Jahre lang im Amt, die übrigen drei Kandidaten jeweils ein Jahr.
Parallel geöffnete Chats, eine Prompt‑Zeitleiste und eine neue Suchfunktion im Chat: Visual Studio Code 1.134 vereinfacht die Arbeit mit mehreren Fenstern. Und lokale HTML‑Dateien lassen sich nun im integrierten Browser öffnen.

Lesen Sie auch

Passkeys in der Praxis – Teil 2: Registrierung und Authentifizierung

Ein gutes Produkt reicht nicht: Sales für Entwicklerinnen und Entwickler

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

AI für SRE: Warum Automatisierung das Ziel ist und KI nur ein Werkzeug

2026-08-22T06:58:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Severin Neumann kritisiert das Schlagwort „AI SRE“ und plädiert für ein CNCF-Modell, das Reliability-Aufgaben statt Menschen automatisiert.

(Bild: Matthias Parbel / KI / iX)

22.08.2026, 08:58 Uhr

Lesezeit: 9 Min.

Developer

Von

Matthias Parbel

Das Schlagwort „AI SRE“ suggeriert, dass künstliche Intelligenz künftig die Menschen im Site Reliability Engineering ersetzt. Genau daran stört sich Severin Neumann, Head of Community bei Bronto und Mitglied des OpenTelemetry Governance Committee. In seinem Vortrag „AI für SRE richtig einsetzen: Von klassischer Automation bis LLMs“ bei der Mastering Observability im April 2026 plädiert er für eine andere Sichtweise: KI ist nicht das Ziel, sondern eines von vielen Werkzeugen, um Reliability-Arbeit schrittweise zu automatisieren.

Neumann bevorzugt daher die Formulierung „AI for SRE“ – also KI für SRE statt SRE. Die Unterscheidung ist mehr als Wortklauberei. Sie verweist darauf, dass Site Reliability Engineering weit mehr umfasst als die Reaktion auf Störungen. Zu SRE gehören Instrumentierung, Kapazitätsplanung, die Prävention von Vorfällen, in Code gegossene Resilienz durch Timeouts, Retries oder Circuit Breaker, Post-Mortems und kontinuierliche Verbesserung. Incident Response ist in dieser Lesart der letzte Ausweg, nicht der Kern der Disziplin.

Mehr zu SRE, Observability, aber auch zu Agentic AI, digitaler Souveränität und weiteren Themen finden interessierte Developer, Software-Architekten, DevOps- und Platform-Engineering-Teams auf der CLC-Konferenz vom 11. bis 12. November 2026 in Mannheim.

Jetzt Tickets zum Frühbucherpreis sichern.

Wichtig ist Neumann eine zweite Klarstellung: KI ist nicht gleich Large Language Model. LLMs seien nur eine Teilmenge dessen, was unter künstliche Intelligenz fällt – und sie bringen erhebliche Grenzen mit. Halluzinationen, fehlendes Kausalverständnis, begrenzte Kontextfenster, mangelndes Echtzeit-Bewusstsein, fehlende Reproduzierbarkeit von Antworten, die Abhängigkeit von der Prompt-Qualität und die hohen Kosten für Inferenz und GPU-Rechenzeit sprechen dagegen, LLMs als Universalwerkzeug für jedes Problem zu nutzen. Daneben stünden klassische Machine-Learning-Modelle für Anomalieerkennung, Trendanalyse und Forecasting sowie deterministische Automatisierung durch Regeln, Linter, Operatoren und Runbooks. Die Leitfrage laute deshalb nicht „Wo können wir ein LLM einsetzen?“, sondern „Welches Werkzeug passt hier?“.

Um diese Frage systematisch zu beantworten, entsteht innerhalb der CNCF TAG Operational Resilience ein Referenzmodell mit dem Titel „Levels of Service Reliability Automation“. In einem CNCF-Blog beschreibt Mario Fahlandt, ehemaliger Leiter der TAG, das Whitepaper als Versuch, operative Autonomie von reaktivem Firefighting bis hin zu selbstheilenden Systemen abzubilden. Das Framework soll Teams eine gemeinsame Landkarte an die Hand geben, die zeigt, wie Reliability-Arbeit über alle Domänen hinweg vom rein manuellen Vorgehen zu wachsender Autonomie fortschreiten kann.

Videos by heise

Eine Matrix statt eines Organisationslevels

Das Modell ist als zweidimensionale Matrix aufgebaut. Die horizontale Achse beschreibt den Automatisierungsgrad in fünf Stufen: Manual, Automatic, Assisted, Guided und Autonomous. Auf der vertikalen Achse stehen die Reliability-Aktivitäten – Instrumentation, Reliability Implementation, Incident Prevention beziehungsweise Risk Prevention sowie Incident Response. In den einzelnen Zellen werden konkrete Werkzeuge, Anforderungen und Fähigkeiten je Aktivität und Level beschrieben.

Darin unterscheidet sich der Ansatz von klassischen Reifegradmodellen, wie sie aus SRE- oder Observability-Frameworks bekannt sind. Statt eine ganze Organisation einem Level wie „Initial“ oder „Optimizing“ zuzuordnen, kartiert das Modell jede Aktivität einzeln. Ein Team kann bei der Instrumentierung noch komplett manuell arbeiten, bei der Incident Response aber bereits auf der Stufe Guided sein. Das bildet die Praxis realistischer ab, weil Teams in verschiedenen Bereichen unterschiedlich weit sind. Der Fokus liegt dabei explizit auf operativer Autonomie – ähnlich den SAE-Levels des autonomen Fahrens, übertragen auf Reliability-Arbeit.

Am Beispiel der Instrumentierung wird die Spannweite deutlich. Auf der Stufe Manual binden Entwicklerinnen und Entwickler Telemetrie selbst über die OpenTelemetry-SDKs ein und annotieren Spans, Metriken und Logs von Hand. Automatic bedeutet automatische Injektoren über Agents oder Sidecars. Auf der Stufe Assisted schlagen Tools fehlende Spans oder Metriken vor, während der Mensch entscheidet. Guided umfasst KI-gestützte Skills, die während Code-Reviews auf fehlende Trace-Kontexte oder unvollständige Semantic Conventions hinweisen. Auf der Stufe Autonomous bringen Systeme Telemetrie selbstständig an oder ändern sie – etwa durch dynamische Instrumentierung anhand von Laufzeitsignalen.

Ähnlich verhält es sich bei der Reliability Implementation, also den Schutzmechanismen im Code. Manuell designen Entwicklerinnen jedes Timeout, jeden Retry und jeden Circuit Breaker selbst. Regelbasierte Linter prüfen automatisch, ob HTTP-Calls überhaupt ein Timeout besitzen. Service-Mesh-Sidecars erzwingen Standard-Patterns global per Policy. Auf höheren Stufen schlagen Tools Retry-Strategien anhand von Traffic-Analysen vor, und LLM-basierte Code-Reviews identifizieren fehlende Timeouts, unbehandelte Promise Rejections oder Retry-Schleifen ohne Jitter.

Prävention vor Reaktion – und die Sache mit dem Alert Noise

Zentral ist für Neumann die Trennung von Prävention und Reaktion. Prävention bedeutet, ein Risiko zu erkennen, bevor Nutzer betroffen sind; bei der Response sind sie es bereits. Den Beginn eines Vorfalls zu erkennen, sei schwer – das Risiko vorher zu erkennen, noch schwerer. Daraus folgt eine klare Ansage: Ohne funktionierende Risiko-Prävention könnten „AI SREs“ nur assistieren und begleiten, aber nie die höchste Automatisierungsstufe erreichen. Hohe Autonomie in der Incident Response ohne starke Prävention führe lediglich zu effizienterem, aber nicht nachhaltigeren KI-Firefighting.

Auf die Frage, ob es also gutes Alerting brauche, antwortet Neumann mit einem gedehnten „Ja – naja…“. Sein Kritikpunkt: Alerting werde oft mit Detection vermischt, sodass alles gemeldet wird, was erkannt wird. Das Ergebnis ist Alert Noise. LLMs als Alert-Prozessoren lösen dieses Problem nicht, sondern erhöhen die Komplexität – schon die Auswertung von viel Alert Noise ist teuer, und es stellt sich die Frage, welche Alerts überhaupt in den Prompt gelangen: alle, aggregierte oder gefilterte.

Neumann fordert stattdessen gute Telemetrie mit niedrigem Rauschanteil und fortgeschrittene ML-Methoden jenseits reiner LLMs für Detection und Klassifikation. Eine Schlüsselrolle spielen dabei Semantic Conventions, wie sie OpenTelemetry definiert: Einheitliche Daten senken die Verarbeitungskosten, verbessern die Signalqualität und erhöhen das Verständnis – für Menschen wie für KI-Systeme. Für eine autonome Incident Response und Prävention brauche es solide Telemetrie und gute Erkennung. Neumann lädt ausdrücklich zur Mitarbeit am CNCF-Whitepaper ein.

Wenn KI ohne Telemetrie mehr schadet als nützt

Wie berechtigt diese Vorsicht ist, zeigen typische Fehlerbilder aus dem AIOps-Umfeld. Ein häufiges Muster: Ein KI-basiertes Event-Correlation-Tool gruppiert Alerts nach Ähnlichkeit und unterdrückt vermeintliche Duplikate. Ist die Telemetrie uneinheitlich und die historische Alert-Historie mit False Positives durchsetzt, lernt das Modell, bestimmte Muster zu ignorieren. Beginnt ein neuer Vorfall mit einem ähnlichen Muster, werden relevante Alerts unterdrückt – die mittlere Reparaturzeit steigt, SLOs werden verletzt. Das Tool agierte dabei korrekt im Rahmen seiner Trainingsdaten; die Telemetrie war das Problem.

Ein zweites Muster betrifft automatische Mitigation. Deckt Telemetrie nur Teilsysteme ab, kann ein ML-gestützter Auto-Mitigation-Loop falsche Korrelationen ziehen, eine scheinbare Ursache identifizieren und aggressiv Traffic abziehen. War der betroffene Service nicht die eigentliche Ursache, erzeugt die Maßnahme zusätzliche Last andernorts und löst eine Kettenreaktion aus. Auch LLM-Co-Piloten im On-Call können trügerische Sicherheit vermitteln: Bei lückenhafter Telemetrie liefert das Modell eine plausible, aber falsche Erklärung samt Mitigationsvorschlag, dem Menschen folgen, weil er detailliert und smart wirkt. Das Problem ist selten die KI allein, sondern die Kombination aus schlechter Observability, fehlender Prävention und mangelnder Governance.

Der EU AI Act als Rahmen für autonome SRE-Tools

Wer KI-Komponenten in kritischer Infrastruktur einsetzt, muss den EU AI Act im Blick behalten. Er definiert Hochrisiko-KI-Systeme, unter die auch Bereiche kritischer Infrastruktur fallen. SRE- und Monitoring-Systeme, die autonom in die Funktionsfähigkeit etwa von Energie-, Verkehrs- oder Finanzmarkt-Infrastruktur eingreifen, können als Bestandteil eines solchen Hochrisiko-Systems gelten – die juristische Einordnung muss projektspezifisch erfolgen.

Besonders relevant ist Artikel 14 zur menschlichen Aufsicht: Hochrisiko-Systeme müssen so gestaltet sein, dass natürliche Personen sie wirksam überwachen und bei Bedarf eingreifen können. Menschen müssen die Kapazitäten und Grenzen des Systems verstehen, Anomalien und Fehlfunktionen erkennen und sich der Gefahr von Automation Bias bewusst sein. Für die Stufe Autonomous im Neumann-Modell bedeutet das: Es muss klar definiert sein, wer die Aufsicht führt, und es braucht Not-Aus-Mechanismen sowie Governance-Prozesse wie Rollback-Policies. LLM-Plattformen können zudem als General-Purpose AI mit systemischem Risiko gelten, was Risiko-Evaluation, adversariales Testen und die Meldung schwerwiegender Vorfälle an das EU AI Office nach sich zieht. In Deutschland kommen DSGVO sowie sektorspezifische Regulierung durch BaFin oder BNetzA hinzu.

Neumanns Fazit bleibt konsistent: Alle Tätigkeiten, die zur Reliability beitragen, müssen adressiert werden. Automatisierung ist das Ziel, KI nur ein Werkzeug. Ob eine autonome Stufe über LLMs, klassische ML-Modelle oder SLO-basierte Control-Loops erreicht wird, ist zweitrangig – entscheidend sind solide Telemetrie, saubere Prävention und eine klare Rollenverteilung zwischen Mensch und Maschine.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier eine Vimeo-Video (Vimeo LLC) geladen.

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

Severin Neumann ist Head of Community bei Bronto. Er beschäftigt sich seit vielen Jahren mit Observability, verteilten Systemen und der Frage, wie Engineering-Teams komplexe Softwarelandschaften zuverlässig betreiben können. Severin ist Mitglied des OpenTelemetry Governance Committees sowie Co-Maintainer der OpenTelemetry-Dokumentation und engagiert sich aktiv in der Open-Source- und Cloud-Native-Community.

(map)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Neu in .NET 10.0 [37]: GetPropertyCount() in der Klasse JsonElement

2026-08-21T07:30:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Klasse JsonElement bietet nun die Methode GetPropertyCount() zum Zählen der Attributwerte.

(Bild: Pincasso / Shutterstock.com)

21.08.2026, 09:30 Uhr

Lesezeit: 1 Min.

Developer

Von

Dr. Holger Schwichtenberg

In System.Text.Json Version 10.0 hat Microsoft die Klasse JsonElement um die Methode GetPropertyCount() erweitert, mit der man ermitteln kann, wie viele Eigenschaften ein JSON-Objekt besitzt. Details dazu finden sich im zugehörigen Issue auf GitHub.

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.

Folgender Code zeigt den Einsatz der neuen Methode:

// Neu in .NET 10.0: GetPropertyCount()
JsonElement element2 = JsonSerializer.Deserialize<JsonElement>("""{ "ID" : 1, "Name" : "Dr. Holger Schwichtenberg", "Website": "www.IT-Visions.de" }""");
Console.WriteLine(element2.ToString());
Console.WriteLine(element2.ValueKind);
Console.WriteLine($"Anzahl der Eigenschaften: {element2.GetPropertyCount()}"); // 3

Videos by heise

Bisher war es nur möglich, die Anzahl der Objekte in einem Array zu ermitteln:

// Alt: GetArrayLength()
JsonElement element1 = JsonSerializer.Deserialize<JsonElement>("""[ 1, 2, 3, 4 ]""");
Console.WriteLine(element1.ToString());
Console.WriteLine(element1.ValueKind);
Console.WriteLine($"Anzahl der Elemente: {element1.GetArrayLength()}"); // 4

(rme)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Angriffsversuche auf GitLab-Lücke beobachtet

2026-08-20T09:41:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Alert!

Attacken auf eine jüngst außerplanmäßig geschlossene Lücke in GitLab wurden beobachtet. Angreifer können etwa Projekte löschen.

(Bild: amgun/ Shutterstock.com)

20.08.2026, 11:41 Uhr

Lesezeit: 2 Min.

Security

Von

Dirk Knop

Am Montag hat GitLab ungeplante Aktualisierungen der Codehosting-Software veröffentlicht. Sie schließen teils kritische Sicherheitslücken. IT-Forscher haben jetzt erste Angriffsversuche auf die schwerwiegendere Schwachstelle beobachtet.

Übereinstimmenden Medienberichten zufolge hat die renommierte IT-Sicherheitsfirma watchTowr die Angriffsversuche bestätigt. Der leitende IT-Sicherheitsforscher des Unternehmens, Jake Knott, sagte demnach, dass die neu veröffentlichte Sicherheitslücke (CVE-2026-19478, CVSS 9.4, Risiko „kritisch“) Angreifern ohne vorherige Authentifizierung ermöglicht, öffentlich zugreifbare GitLab-Projekte zu löschen, ihren Status zu ändern, ganze Repositories zu löschen, Merge-Einträge zu fälschen oder sogar Maintainer auszusperren. Das gelinge mit einer einzelnen HTTP-Anfrage ohne Zugangsdaten oder Nutzerinteraktion, es sei auch keine ungewöhnliche Konfiguration dafür erforderlich.

Knott erklärte am Mittwoch dieser Woche demnach weiter, dass watchTowr bereits Angriffsversuche in freier Wildbahn mit seinem globalen Honeypot-Netzwerk entdeckt hat. Organisationen, die die GitLab-Software noch nicht gepatcht haben, sollten die Weblogs nach Einträgen mit der Zeichenkette „@gl_introduced“ durchwühlen und nach Anzeichen für Erkundungs- oder Angriffsversuche Ausschau halten.

Schwachstelle in Minuten nachvollzogen

Auf LinkedIn gibt watchTowr an, dass das KI-Tool des Unternehmens die Schwachstelle allein anhand der Fehlerbeschreibung und der Code-Änderungen nachvollzogen hat. Zum Veröffentlichungszeitpunkt gab es demnach noch keinen öffentlich verfügbaren Proof-of-Concept-Exploitcode. Auf X gibt das Unternehmen noch den Tipp, entweder umgehend selbstverwaltete Installationen zu aktualisieren oder zumindest nach Möglichkeit den Zugriff auf „/api/graphql“ zu beschränken.

Videos by heise

Neben der kritischen Sicherheitslücke in der GraphQL-API hat GitLab mit den Updates vom Anfang der Woche auch eine hochriskante Schwachstelle ausgebessert. Sie betrifft ebenfalls die GraphQL-API, hier müssen jedoch Opfer mitspielen und etwa auf manipulierte Links klicken (CVE-2026-19650, CVSS 7.1, Risiko „hoch“).

(dmk)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

KI: Warum kollaborative Modellierung wichtiger wird als Programmieren

2026-08-20T08:20:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

LLMs und generative KI werden Softwarearchitektur grundlegend ändern, aber die fundamentalen Probleme bleiben.

(Bild: GaudiLab / Shutterstock.com)

20.08.2026, 10:20 Uhr

Lesezeit: 7 Min.

Developer

Von

Eberhard Wolff

Das Potenzial von KI-Ansätzen hängt davon ab, worum es in der Softwareentwicklung im Kern geht. Die offensichtliche Antwort: Code. Schließlich ist Software Code. Diese Antwort ist aber nicht nur offensichtlich, sondern auch falsch.

(Bild:

Eberhard Wolff

)

Eberhard Wolff ist Head of Architecture bei SWAGLab und arbeitet seit mehr als zwanzig Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenzen vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Domain-driven Design und Microservices.

Wichtigster Skill in der IT?

Stellen wir eine andere Frage. Was ist der wichtigste Skill in der IT? Wir haben bei „Software-Architektur im Stream“ diese Frage bei einer IT-Konferenz gestellt – und am häufigsten wurde als Antwort „Kommunikation“ genannt. Auch darüber hinaus kamen die allermeisten Antworten aus dem Bereich Soft Skills. Das ist bemerkenswert, weil es eine technisch ausgerichtete Konferenz war, bei der man vielleicht eher technische Skills als Antworten erwartet hätte.

Hauptherausforderung in der Softwarearchitektur

Die Frage nach dem wichtigsten Skill in der IT ist sehr breit – schließlich geht es um IT im Allgemeinen. Vielleicht sind im Bereich Softwarearchitektur andere Dinge wichtig? Wenn man nach der Hauptherausforderung in der Softwarearchitektur fragt, ergibt sich ein ähnliches Bild: Es geht vor allem um Menschen und die Zusammenarbeit zwischen ihnen.

Der Arbeitsalltag vieler Softwarearchitektinnen und -architekten zeigt auch, wie wichtig dieser Aspekt ist: Sie verbringen viel Zeit damit, mit Menschen zu kommunizieren, um gemeinsam am Projekt zu arbeiten.

Die Natur der Softwareentwicklung

Das ist nicht zufällig so. Der Grund ist die Natur von Softwareentwicklung. Die zu entwickelnde Software beeinflusst viele Menschen: Nutzer, Managerinnen und verschiedene andere Rollen. Die Anforderungen dieser Gruppen in Bereichen wie Sicherheit, Performance oder Betreibbarkeit zu verstehen, zu priorisieren und eine geeignete technologische Umsetzung zu finden, ist die zentrale Herausforderung in der Softwarearchitekturarbeit. Dabei haben Stakeholder unterschiedliche Interessen, manchmal sogar entgegengesetzte. Außerdem setzt ein Softwareprojekt einen Lernprozess in Gange, in dessen Rahmen dann neue Ideen und Gedanken auftauchen, die wieder neue Anforderungen zur Folge haben. Auslöser für das Lernen ist die Frage nach den genauen Anforderungen und die kritische Auseinandersetzung mit der vorhandenen Software und den schon bekannten Anforderungen. Dadurch denken die verschiedenen Rollen intensiv über die Software nach und finden so weitere Dinge, die es wert sind, umgesetzt zu werden.

Videos by heise

Neben den Stakeholdern sind auch viele Technikerinnen mit der Software beschäftigt: Implementierung, Betrieb und auch Felder wie Sicherheit werden von unterschiedlichen Personen verantwortet. Auch hier gilt: Die Personen und Rollen müssen koordiniert werden, damit sie erfolgreich zusammenarbeiten.

Natürlich ist ein technisches Verständnis als Grundlage für die Arbeit an der Architektur notwendig. Man kann kaum in der Koordination erfolgreich sein, wenn man nicht weiß, worum es eigentlich geht. Tiefes Expertenwissen ist aber nicht notwendig: Solches Wissen ist entweder im Team vorhanden oder kann als Beratung zugekauft werden. Das Wissen um die Kollaboration und Koordination ist also eigentlich wichtiger als das rein technische Wissen.

LLMs und generative KI löst das schon?

Für die hauptsächliche Herausforderung Kommunikation können LLMs und generative KI nur indirekt helfen. So wie man im Web oder in Büchern Tipps findet, wie man die Zusammenarbeit verbessern kann, so können LLMs auch Ideen liefern. Aber sie können nur Texte oder Code generieren, keine funktionierenden Teams. Am Ende ist also der Mensch gefragt.

Aber vielleicht machen LLMs Softwareentwicklung so einfach, dass keine Teams mehr benötigt werden, sondern nur noch eine einzelne Person? Bei den Technikern ist es denkbar, dass die Größe der Teams durch Produktivitätsvorteile sinkt. Vielleicht bleiben die Teams aber auch gleich groß. Dann führen die Produktivitätsvorteile dazu, dass komplexere Software entwickelt wird. Technischer Fortschritt hat auch in der Vergangenheit zu einer besseren Produktivität geführt. Dennoch ist die Anzahl der Entwicklerinnen und Entwickler in der Branche insgesamt und in den einzelnen Projekten nicht gesunken, sondern gestiegen.

Was also tun?

Damit befinden sich Softwarearchitekten in einer eigentümlichen Situation: Scheinbar geht es in ihrem Bereich um technische Themen. Die meisten haben deswegen auch eine technische Ausbildung. In Wirklichkeit geht es aber um Menschen und die Zusammenarbeit. Die Zusammenarbeit von Menschen ist aber nicht so einfach und gut strukturierbar wie Software. Zwar ist es auch nicht einfach, gute Strukturen für Software zu finden, aber Software kann gar nicht an den Strukturen vorbeiarbeiten oder sich widersetzen und hat auch keinen eignen Willen.

Event Storming

Es gibt aber Techniken, die Zusammenarbeit und Kommunikation verbessern können und recht einfach einsetzbar sind. Zudem sind sie auf typische Herausforderungen in der Softwarearchitekturarbeit angepasst. Ein bekanntes Beispiel ist Event Storming: Um sich eine Domäne zu erarbeiten, schreiben Domänen-Expertinnen und -Experten Events auf Post-its. Anschließend bringt man sie in die zeitlich korrekte Reihenfolge und identifiziert parallel Aktivitäten sowie Events, die einen neuen Bereich in dem Ablauf einläuten (Pivotal Events). Dieses Vorgehen verteilt Wissen über die Domäne im gesamten Team. Außerdem ist ein Bereich in einer Swimlane zwischen zwei Pivotal Events ein Kandidat für eine Komponente in der Architektur.

Dieses Vorgehen verbessert die Kollaboration: Alle arbeiten parallel. Menschen, die sonst in Meetings eher still sind, können bei diesem Vorgehen Post-its schreiben und sich so viel besser einbringen. Es geht also nicht um eine schwer fassbare, abstrakte Verbesserung der Zusammenarbeit, sondern die Technik ist so angelegt, dass Zusammenarbeit angenehmer, effektiver und effizienter wird.

In diesem Zusammenhang ist noch eine weitere Beobachtung interessant: Man könnte denken, dass durch das Meeting ein wichtiges Artefakt entsteht – eine strukturierte Sammlung von Events, auf der dann die Architektur und die Entwicklung aufbauen kann. Nehmen wir an, wir würden dieses Artefakt wegwerfen. Wir hätten dennoch sehr viel über die Domäne gelernt und Zusammenarbeit geübt, und soziale Aspekte wie die Qualität der Zusammenarbeit oder Wissensmonopole wären offensichtlich geworden. Diese Ergebnisse könnten vielleicht sogar wichtiger als das Artefakt sein und sich ebenfalls positiv auf die Zusammenarbeit auswirken.

Kollaborative Modellierung

Event Storming ist nur ein Beispiel für eine ganze Palette von Techniken, für die sich der Begriff „kollaborative Modellierung“ etabliert hat. Sie beschreiben Formate, mit denen sich die gemeinsame Arbeit an Architekturen verbessern lässt. Weil die Zusammenarbeit so wichtig ist, sind diese Techniken eine große Bereicherung für alle Architektinnen und Architekten. Wer sich dafür interessiert: Es gibt dazu diverse Episoden bei Software-Architektur im Stream und auch ein Training von Tom Asel und mir (auch in Wien von Daniel Sack), in dem man praxisnah lernt, solche kollaborativen Modellierungssessions erfolgreich vorzubereiten und durchzuführen.

tl:dr

Skills im Bereich Kollaboration sind besonders wertvoll, weil Zusammenarbeit ein fundamentales Problem in der Architekturarbeit darstellt und durch KI nicht lösbar ist. Entsprechende Techniken beispielsweise im Bereich kollaborativer Modellierung wie „Event Storming“ kann man erlernen.

(rme)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Mojo wird Open Source – Python-ähnliche Sprache für CPUs und GPUs

2026-08-20T06:05:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kurz nach Freigabe der Version 1.0 von Mojo stellt Modular (Qualcomm) den Compiler unter Apache-2-Lizenz.

(Bild: Wolf Hosbach / KI / ix)

20.08.2026, 08:05 Uhr

Lesezeit: 1 Min.

Developer

Von

Wolf Hosbach

Am 17. August haben wir noch berichtet, dass der Compiler der Programmiersprache Mojo nicht Open Source ist, einen Tag später war es dann so weit: Modular, ein Qualcomm-Unternehmen, hat Mojo 1 unter die Apache-2-Lizenz gestellt.

Ausgenommen davon sind einige Komponenten des zugrundeliegenden LLVM-Compilers, die unter anderen Lizenzen stehen. Modular hat den Quellcode für Compiler und die zugehörigen Werkzeuge auf GitHub veröffentlicht, hier finden sich auch weitere Details zur Lizenz inklusive der Ausnahmen. Contributors können jedoch erst ab Ende des Jahres mitmachen. Mojos Standardbibliothek war bereits seit Längerem Open Source.

Videos by heise

Die Sprache ist in der Syntax an Python angelehnt, bietet aber eine statische Typenprüfung und ein Ownership-Modell. In der Struktur ähnelt sie daher eher Rust. Außerdem benötigt sie keine CPython-Implementierung mit langsamen externen Bibliotheken. Die Sprache erzeugt Code für CPUs, GPUs und KI-Beschleuniger.

Eine Version lässt sich mit ./bazelw run --config=build-mojo KGEN:mojo -- run hello.mojo in einem geklonten Repository bauen. Mojo nutzt dabei Bazel für den Build-Prozess.

(who)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Drei Fragen und Antworten: Mehr Effizienz und Speed mit dem neuen Docker-VMM

2026-08-19T12:50:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Entwicklung der neuen Virtualisierungsschicht Virtual Machine Manager hat Docker selbst in die Hand genommen. Das hat Vorteile, meint Colin Hemmings.

(Bild: iX)

19.08.2026, 14:50 Uhr

Lesezeit: 7 Min.

Developer

Von

Wolf Hosbach

Docker Desktop 4.86 führt die neue, von Docker selbst entwickelte Virtualisierungsschicht Docker Virtual Machine Manager (VMM) ein. Er soll effizienter, schneller und besser zu managen sein als die bisherigen Komponenten der Betriebssysteme. Docker VMM ersetzt die bisherigen Virtualisierungen libkrun unter macOS und WSL 2 unter Windows. Colin Hemmings, Senior Product Manager bei Docker, weiß mehr über die Details und die Roadmap.

Colin Hemmings ist Senior Product Manager bei Docker Inc. und der leitende Produktmanager für den Docker Desktop.

Warum waren die bisherigen Virtualisierungslösungen nicht gut genug?

Es ging nicht darum, dass die bisherigen Virtualisierungslösungen nicht gut genug waren. Apples Virtualization.framework, WSL 2 und Hyper-V sind allesamt hervorragende Technologien, und wir haben jede bewusst ausgewählt. Darum ging es bei der jetzigen Umstellung nicht. Es ging vielmehr um die vielen Vorteile, die wir den Kunden mit der Neuausrichtung bieten können.

Die Aufgabe von Docker Desktop ist es, Entwicklerinnen und Entwicklern eine verwaltete Umgebung für die Ausführung von Containern bereitzustellen. Die VM ist dabei ein Implementierungsdetail, über das Entwickler nicht nachdenken müssen. Wie sie sich verhält, liegt vielmehr in unserer Verantwortung: Wie schnell sie startet, wie viel sie vom Rechner beansprucht und wie sie unter Last standhält. Docker hatte den Großteil dieser Umgebung bereits aufgebaut, einschließlich LinuxKit für das VM-Image sowie unsere eigenen Dienste für Netzwerk und Dateifreigabe. Das einzige wesentliche Bauteil, das wir bisher nicht selbst entwickelt hatten, war der zugrunde liegende VMM.

Jetzt, durch die neue Eigenentwicklung, können wir den VMM speziell für Container-Workloads tunen und diese Verbesserungen unserem eigenen Zeitplan folgend ausliefern. Außerdem verfügen wir dann über eine einheitliche Virtualisierungsschicht für macOS, Windows und Linux. So ist deren Verhalten unabhängig von den Arbeitsumgebungen der Entwickler konsistent. Das schafft uns eine Grundlage, auf der wir weiter aufbauen können.

Außerdem konnten wir ein paar konkreten Verbesserungen erzielen, zum Beispiel einen messbar schnelleren Start von Containern, und zwar sowohl beim ersten Start, als auch beim Projektwechsel und bei der Wiederherstellung nach einem Neustart. Der deutlich schnellere Dateiaustausch zwischen Container und Host beschleunigt jeden Build. Und die intelligentere Speicherverwaltung gibt dem Host RAM zurück, wenn Container im Leerlauf sind. Speicher ist ein gutes Beispiel für die Vorteile: VMM nutzt die Funktion Free Page Reporting, mit der ein Gastkernel kontinuierlich die von ihm freigegebenen Pages meldet, sodass wir diesen Speicherplatz fortlaufend dem Host zurückgeben können. Der Footprint von Desktop entspricht der wirklichen Nutzung der Container.

Aus technischer Sicht wurde Docker VMM von Grund auf in Rust geschrieben und läuft direkt auf der nativen Hypervisor-Schnittstelle der jeweiligen Plattform. Das ist Hypervisor-Framework unter macOS, der Windows Hypervisor und KVM unter Linux – nur eine Codebasis für alle drei. Die gleiche Engine betreibt auch Docker Sandboxes, unsere isolierten Umgebungen für Agenten und nicht vertrauenswürdige Workloads.

Bewusst eng gehalten ist das Gerätemodell. Wir implementieren nur die paravirtualisierten Geräte, die Container-Workloads tatsächlich nutzen, anstatt eine breite Palette an Hardware zu emulieren. Das sind virtio-fs für die Dateifreigabe, virtio-net für die Netzwerkkommunikation und virtio-balloon für den Speicher. Hinzu kommt nur das Minimum, das ein Linux-Gast für den Start benötigt.

Mehr zu Agentic AI, digitaler Souveränität und weiteren Themen finden interessierte Developer, Software-Architekten, DevOps- und Platform-Engineering-Teams auf der CLC-Konferenz vom 11. bis 12. November 2026 in Mannheim.

☞ Sichern Sie sich jetzt die Tickets zum Frühbucherpreis. ☜

Wie müssen sich Entwickler anpassen?

Für die meisten Entwickler ändert sich so gut wie nichts. VMM läuft unterhalb der Docker-Engine, sodass Engine, CLI, API, Images, Volumes, Netzwerke und Compose unverändert bleiben. Es gibt keine neue Syntax und nichts muss umgeschrieben werden.

Neben den bereits vorhandenen erscheint eine zusätzliche Option in den Einstellungen von Docker Desktop, wobei man jederzeit zurückwechseln kann. macOS-Entwickler, die bereits die bestehende Docker-VMM-Option nutzen, werden automatisch umgestellt.

Videos by heise

In dieser Beta läuft Docker VMM auf Apple-Silicon-Macs und Windows x86. Linux folgt erst mit der allgemeinen Verfügbarkeit. Ein Hinweis zu Windows: Docker VMM läuft in einer eigenen virtuellen Maschine mit eigenem Datenträger, sodass Images und Container aus dem vorhandenen Backend dort nicht erscheinen. Alles, was man nutzen möchten, sollte man in eine Registry übertragen oder neu bauen. Das bestehende Backend bleibt unberührt, wenn man zurückwechselt. Unter macOS wird der Datenträger gemeinsam genutzt, sodass nichts verschoben werden muss.

Zwei Funktionen, gibt es derzeit weder in der Beta noch in der endgültigen Version, sie liegen aber auf der Roadmap für kommende Versionen. In beiden Fällen funktioniert das bestehende Backend weiterhin genau wie bisher: Zum einen soll eine GPU-Unterstützung kommen. Derzeit läuft CUDA unter Windows über den WSL-2-eigenen GPU-Passthrough und nicht über die Virtualisierungsschicht. Für Anwender, die bei WSL-2 bleiben, ändert sich an den GPU-Workloads nichts.

Zum Anderen die Rosetta-Unterstützung auf Apple Silicon: Docker Desktop unterstützt Rosetta nur bei x86-Workloads, was für Apples Virtualization.framework spezifisch ist. Eine Emulation mit Docker VMM funktioniert zwar zum Beispiel mit docker run --platform linux/amd64, sie verwendet jedoch QEMU, was langsamer ist. Entwickler, die regelmäßig amd64-Images erstellen und die Leistung von Rosetta benötigen, sollten die unveränderte Option Apple Virtualization VMM verwenden.

Ähnliches gilt, wenn man die WSL-Integration von Docker Desktop nutzt, um die Docker-CLI innerhalb der eigenen WSL-Distributionen auszuführen – dies ist an das WSL-2-Backend gebunden.

Was sind die nächsten Schritte, und was können Entwickler erwarten?

Die Beta-Phase läuft bis in den Herbst hinein, und sehr nützlich sind für uns konkrete, reproduzierbare Berichte über Workloads, die sich anders als erwartet verhalten. Die allgemeine Verfügbarkeit ist derzeit für Ende Oktober geplant. Dann wird Linux zu den unterstützten Plattformen hinzugefügt und Docker VMM wird zur Standard-Virtualisierungsschicht für neue Docker-Desktop-Installationen. Bestehende Installationen werden nicht migriert und man verbleibt bei dem, was man gewählt hat, aber man kann Docker VMM jederzeit zum Ausprobieren aktivieren.

Vor der allgemeinen Verfügbarkeit werden wir einen umfassenden Satz an Benchmarks zusammen mit der dahinterstehenden Methodik veröffentlichen. Sie gehen dabei über Docker VMM hinaus, denn wir meinen, dass Entwickler über eine einheitliche, transparente Methode zur Messung der Container-Leistung verfügen sollten.

Die Kontrolle über die Virtualisierung eröffnet uns zwei Richtungen für weitere Entwicklungen: Die erste ist eine engere Integration des Host mit der Containerumgebung. Da wir die Virtualisierungsschicht kontrollieren, können wir Host-Ressourcen und Entwickler-Tools direkt mit ihr verbinden, sodass die von den Entwicklern bereits genutzten Tools mit ihren Containern zusammenarbeiten können. Bei dieser Geschichte geht es vor allem um Produktivität und Troubleshooting.

Die zweite Richtung ist die Kontrolle über die Isolation. Eine VM-Grenze um Container-Workloads ist für viele Unternehmen wichtig, insbesondere jetzt, da Entwickler KI-Agenten und deren erzeugter Code lokal ausführen. Da wir diese Schicht jetzt kontrollieren, Anwender explizit entscheiden und steuern, was diese Grenze überschreitet darf.

Beides sind zum jetzigen Zeitpunkt noch strategische Ausrichtungen und keine terminierten Feature-Zusagen, aber sie sind ein wesentlicher Grund dafür, dass wir in die Kontrolle dieser Ebene investiert haben.

(who)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Umfrage: Claude Code und GitHub Copilot sind die beliebtesten

2026-08-19T10:06:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Neun von zehn Entwicklerinnen und Entwicklern verwenden regelmäßig einen Coding-Agenten. Claude Code führt mit großem Abstand die Beliebtheitsliste an.

(Bild: Manuel Masiero / KI / iX)

19.08.2026, 12:06 Uhr

Lesezeit: 2 Min.

Developer

Von

Manuel Masiero

Claude Code gehört zusammen mit GitHub Copilot zu den populärsten Coding-Agenten, sowohl was die weltweite Nutzung als auch den Bekanntheitsgrad betrifft. Bei 90 Prozent der Entwicklerinnen und Entwickler sind Coding-Agenten mindestens einmal pro Woche im Einsatz, bei 68 Prozent sogar täglich.

Die Zahlen stammen aus der Developer Ecosystem Survey 2026, die JetBrains von Mai bis Juli dieses Jahres durchgeführt hat. Claude Code führt dabei die Beliebtheitsliste an. In der Umfrage gaben 39 Prozent der Entwicklerinnen und Entwickler an, Anthropics Coding-Agent beruflich einzusetzen, sei es lokal oder über die Cloud.

Im professionellen Entwicklerumfeld ist Claude Code der aktuell am häufigsten genutzte KI-Agent.

(Bild: JetBrains)

Das entspricht einem Anstieg von 21 Prozentpunkten gegenüber der im Januar dieses Jahres durchgeführten JetBrains-Umfrage AI Pulse. Besonders beliebt ist Claude Code in den USA. Dort erreicht das KI-Tool einen Anteil von 47 Prozent und läuft damit auf fast jedem zweiten Produktivsystem.

OpenAI Codex verzeichnet im gleichen Zeitraum zwar stärkere Wachstumsraten, da es seinen Anteil von 3 auf 16 Prozent mehr als verfünffachen konnte. Mit 16 Prozent schafft Codex aber nur Platz drei der meistgenutzten Tools. Direkt darüber landet GitHub Copilot, einst der meistgenutzte unter den Coding-Agenten. Im Januar nutzten ihn 29 Prozent der Entwickler, jetzt noch 21 Prozent.

Videos by heise

Nur jeder Zweite kennt Google Antigravity

So wie Claude Code bringt es auch GitHub Copilot auf einen weltweiten Bekanntheitsgrad von 79 Prozent. In der EU, in England und den USA liegt er noch deutlich höher. Dort geben zwischen 86 und 90 Prozent der Teilnehmerinnen und Teilnehmer an, Copilot zu kennen.

Den auf Visual Studio Code basierenden Cursor haben 75 Prozent der Entwicklerinnen und Entwickler auf dem Radar. Codex kennen allerdings nur 65 Prozent und bei JetBrains AI Assistant (53 %), Google Antigravity (47 %) sowie OpenCode (42 %) liegen die Bekanntheitsgrade noch deutlich darunter.

Für die Developer Ecosystem Survey 2026 sammelte JetBrains von Mai bis Juli 2026 Feedback von insgesamt 15.509 Teilnehmern ein. Davon lassen sich rund 90 Prozent den Kategorien Entwickler, Programmierer oder Software-Ingenieur zuordnen. Um die weltweite Entwickler-Community repräsentativ abzubilden, stand die Umfrage in acht Sprachen zur Verfügung (Englisch, Spanisch, Chinesisch, Japanisch, Koreanisch, Deutsch, Französisch, Portugiesisch). Die Erhebungsmethodik beschreibt JetBrains in seinem Blog.

(mro)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Linux 7.2 bringt umfangreiche Treiberupdates

2026-08-19T09:12:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Am Sonntag hat Linus Torvalds den Linux-Kernel 7.2 freigegeben. Im Entwicklungs-Endspurt gab es noch größere Änderungen.

(Bild: Tux by Larry Ewing/GIMP)

19.08.2026, 11:12 Uhr

Lesezeit: 2 Min.

Von

Dirk Knop

Am späten Nachmittag des vergangenen Sonntags hat Linus Torvalds den Linux-Kernel in Version 7.2 veröffentlicht. Der bringt zum größten Teil aktualisierte Treiber mit. In der letzten Entwicklungswoche waren jedoch noch größere Anpassungen nötig.

Wie Torvalds auf der Linux-Kernel-Mailingliste schreibt, waren die Änderungen am Code in der letzten Woche vor dem Release erneut größer, als er gehofft habe, das sei wohl aber das neue Normal. Würde er aus dem Grund Releases verzögern, gäbe es vermutlich niemals eine Veröffentlichung. Er nennt als Ursache, dass es umfangreiche späte Rückzieher im Code gab, besonders steche der DRM-Scheduling-Code hervor. Das sei zwar nicht schön, aber der einzige richtige Weg, mit unfertigem Code umzugehen, der Probleme bereite. Auf den letzten Metern gab es neben diesen großen Anpassungen auch einige kleinere Fixes quer durch alle Bereiche. Die meisten betreffen die Treiber, aber auch der Netzwerk-Code war zuletzt noch aktiv in der Entwicklung.

Linux 7.2: Ein ziemlich normales Release

Als Torvalds Ende Juni das Merge-Window für den Kernel 7.2 geschlossen hat, schrieb er an die Kernel-Mailingliste, dass das geplante Release sehr normal aussehe. Allerdings bestehe ein Drittel des Patches schon aus Registerdefinitionen für AMD-GPUs. Das sei für sich genommen jedoch nicht ungewöhnlich. Klammere man das aus, ergeben sich die Patch-Bestandteile zu gut der Hälfte aus Treiberupdates, und auch ohne die AMD-Register-Dumps finden sich andere Grafiktreiberupdates, es gebe jedoch auch „ein bisschen von allem“ darin. Der weitere Rest bestehe aus den üblichen Anteilen von Architektur-Updates, Änderungen am Tooling und Dokumentationen sowie Updates am Kernel-Core.

Videos by heise

Bislang handelt es sich bei Linux 7.2 um ein normales Mainline-Kernel-Release. Die Liste der Longterm-Support-Kernel steht bislang bei 6.18 als jüngstem Kandidaten, der Ende November 2025 erschien und bis Dezember 2028 offiziell gepflegt wird. Die Quellen stehen auf kernel.org zum Herunterladen bereit, ein vollständiges Changelog fehlt bislang noch. Einen umfassenden Deepdive in die Änderungen planen wir zu einem späteren Zeitpunkt.

Mitte Juni erschien der Kernel 7.1. Er brachte einen neuen NTFS-Treiber mit und aktiviert standardmäßig Intels FRED zur Leistungssteigerung.

(dmk)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Agentic Engineering: Webinar zum verlässlichen Arbeiten mit Claude Code

2026-08-19T07:46:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Am 26. August 2026 zeigt die the native web GmbH in einem Webinar, wie ein Repository beschaffen sein muss, damit ein KI-Agent verlässlich darin arbeitet.

(Bild: Manuel Masiero / KI / iX)

19.08.2026, 09:46 Uhr

Lesezeit: 5 Min.

Developer

Von

Golo Roden

Künstliche Intelligenz in der Softwareentwicklung gilt vielen als Spielerei, die über das Ausprobieren nicht hinauskommt. Ein Prompt geht hinein, Code kommt heraus, und ob das Ergebnis standhält, zeigt sich erst hinterher. Vibe-Coding heißt das inzwischen, und der Begriff trägt einen abschätzigen Beiklang, der nicht gänzlich unverdient ist. Wer so arbeitet, erhält Ergebnisse, die von Sitzung zu Sitzung schwanken, und zieht daraus die naheliegende, aber falsche Schlussfolgerung, dass mehr nicht möglich sei.

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.

Der Grund für die Schwankungen liegt nämlich nicht im Werkzeug, sondern in dem, was ein Agent im Repository vorfindet. Genau hier setzt das Webinar Agentic Engineering der the native web GmbH an, das am 26. August 2026 stattfindet und in zweieinhalb Stunden zeigt, wie sich ein Projekt so einrichten lässt, dass die Arbeit mit einem KI-Agenten planbar wird.

Agentic Engineering vs. Prompt-Engineering

Ein Agent ist kein Autovervollständiger. Während klassisches Prompt-Engineering darauf zielt, eine Frage möglichst geschickt zu formulieren, setzt ein Werkzeug wie Claude Code voraus, dass es selbstständig liest, sucht, plant, Änderungen vornimmt und Tests ausführt. Die Qualität des Ergebnisses hängt deshalb weit weniger am einzelnen Prompt als an dem, was das Projekt an Kontext bereitstellt.

Daraus folgt eine andere Arbeitsteilung. Optimiert wird nicht die Formulierung, sondern die Umgebung. Konventionen, Struktur und Erwartungen gehören in das Repository selbst, statt in jeder Sitzung neu erklärt zu werden. Wer einem Agenten nur Prompts zuwirft, bekommt zufällige Ergebnisse; wer die Umgebung einrichtet, reproduzierbare.

Diese Verschiebung ist der Kern dessen, was sich Agentic Engineering nennt, und sie hat eine praktische Folge: Was einmal im Projekt hinterlegt ist, gilt für jede weitere Sitzung und für jedes Teammitglied, das mit demselben Repository arbeitet. Der erste Teil des Webinars klärt, was sich damit tatsächlich verändert und warum die üblichen Ratschläge zur Formulierung von Prompts an der eigentlichen Frage vorbeigehen.

Die Bausteine einer verlässlichen Umgebung

Claude Code bringt für diesen Zweck eine Reihe von Mechanismen mit. Die Datei CLAUDE.md dient als Landkarte des Projekts und beschreibt, was wo liegt und worauf es ankommt. Rules halten verbindliche Konventionen fest, etwa zu Architektur, Namensgebung, Teststrategie oder dem Umgang mit Git. Skills bündeln wiederkehrende Abläufe zu abrufbaren Fähigkeiten, und Hooks greifen an definierten Stellen ein, um durchzusetzen, was nicht dem Zufall überlassen bleiben darf.

Hinzu kommen Arbeitsweisen, die den Ablauf strukturieren. Der Plan-Mode trennt das Überlegen vom Umsetzen, Subagents erledigen abgegrenzte Teilaufgaben, ohne den Hauptkontext zu belasten, und Git-Worktrees erlauben paralleles Arbeiten an mehreren Ständen. Jeder dieser Bausteine hat einen klar umrissenen Zweck, und ein guter Teil der Verwirrung um agentische Werkzeuge rührt daher, dass diese Zwecke selten sauber auseinandergehalten werden.

Der Nutzen reicht dabei über den Agenten hinaus. Konventionen, die sich präzise genug formulieren lassen, dass eine Maschine sie befolgt, sind in aller Regel auch für neue Kolleginnen und Kollegen die bessere Dokumentation. Der zweite Teil des Webinars ordnet ein, welcher Mechanismus wofür taugt und wie die Bausteine zusammenspielen.

Ein Grundgerüst, live gebaut

Nach einer kurzen Pause entsteht im dritten Teil live ein vollständiges Grundgerüst. Schritt für Schritt wird ein Repository eingerichtet: eine CLAUDE.md als Landkarte, Rules für die Konventionen des Projekts und Skills für die Aufgaben, die darin regelmäßig anfallen. Das Beispiel bleibt bewusst überschaubar, damit jeder Schritt nachvollziehbar bleibt.

Die Struktur ist dieselbe, unabhängig davon, ob im Repository am Ende Dokumentation, Anwendungscode oder beides liegt. Sichtbar wird vor allem, wie sich die einzelnen Bausteine gegenseitig stützen und woran sich erkennen lässt, dass eine Rule zu vage oder eine Skill zu breit geschnitten ist.

Umwege bleiben dabei sichtbar. Gerade sie zeigen, wie beim eigenen Aufbau vorzugehen ist, wenn ein erster Entwurf nicht das gewünschte Verhalten ergibt. Für Fragen aus dem Livechat bleibt in diesem Teil ausreichend Raum.

Voraussetzung, nicht Selbstläufer

Der vierte Teil verdichtet die Erkenntnisse zu einer Aussage, die zugleich Versprechen und Einschränkung ist. Die gezeigten Mechanismen sind die notwendige Voraussetzung dafür, mit KI effektiv und effizient zu arbeiten. Ohne sie bleibt der Einsatz eines Agenten Glückssache, mit ihnen funktioniert er zuverlässig und reproduzierbar, auch über längere Zeiträume und im Team.

Eine Grenze bleibt gleichwohl bestehen. Auch ein gut eingerichteter Agent liefert nicht mit hundertprozentiger Sicherheit das Richtige, weshalb der prüfende Blick eines Menschen am Ende nicht entfällt. Alles andere jedoch lässt sich einrichten, überprüfen und im Team teilen, und wer diese Verantwortung annimmt, gewinnt einen Arbeitsmodus, der trägt.

Termin und Konditionen

Das Webinar findet am 26. August 2026 von 15 bis 17:30 Uhr online über YouTube statt und wird auf Deutsch durchgeführt. Ein Livechat bietet Gelegenheit für Fragen und Austausch, im Anschluss steht eine vollständige Aufzeichnung bereit, sodass sich einzelne Themen in Ruhe nacharbeiten lassen. Es richtet sich an Entwicklerinnen und Entwickler sowie an Architektinnen und Architekten, die KI über das Vervollständigen einzelner Zeilen hinaus einsetzen möchten.

Die Teilnahme kostet 49 Euro zuzüglich 19 Prozent Umsatzsteuer. Alle Informationen und die Möglichkeit zur Anmeldung finden sich unter www.thenativeweb.io/learning/webinar-agentic-engineering. (mro)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Google führt erweiterten Sideloading-Ablauf für Android schrittweise ein

2026-08-19T07:20:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Google startet den „Advanced Flow“ für das Sideloading von Apps. Nutzer müssen bei nicht verifizierten Entwicklern künftig eine 24-stündige Wartezeit einplanen.

(Bild: Mijansk786 / Shutterstock.com)

19.08.2026, 09:20 Uhr

Lesezeit: 2 Min.

Security

Von

Andreas Floemer

Google führt die Einführung seines Anfang dieses Jahres angekündigten neuen Ablaufs („Advanced Flow“) für das Sideloading nicht verifizierter Apps fort. Bei diesen handelt es sich um Apps von Entwicklern, die sich gegen eine Identitätsüberprüfung bei Google entschieden haben. Dieses Verifizierungssystem für Entwickler soll am 30. September in Betrieb gehen und zunächst auf Länder mit einer hohen Zahl an App-Betrugsfällen beschränkt sein. Zu diesen gehören Brasilien, Indonesien, Singapur und Thailand.

„Advanced Flow“

Mit dem „Advanced Flow“ oder „erweitertem Ablauf“ erhöht Google die Hürden für die Installation von nicht verifizierten Apps. Die größte Änderung bestehe dabei in einer einmaligen Wartezeit von einem Tag zwischen der Freigabe der Installation von Apps von nicht verifizierten Entwicklern. Dieser neue Ablauf richte sich vor allem an „Power-User“, die besagte Apps auf zertifizierten Android-Geräten ohne Verwendung von ADB (Android Debug Bridge) installieren möchten.

So sieht der Advanced Flow zur Installation nicht verifizierter Apps aus.

(Bild: Google)

Das Unternehmen schreibt in einem Reddit-Beitrag, die „erste Version“ dieses neuen Verfahrens einzuführen. Nutzerinnen und Nutzer müssen fortan in die Entwickleroptionen gehen und die Option „Apps von nicht verifizierten Entwicklern zulassen“ aktivieren. Danach zeigt das System Warnmeldungen an, bevor Nutzer die einmalige, 24-stündige Wartezeit initiieren können. Die Einstellung kann vorübergehend – für sieben Tage – oder auf unbestimmte Zeit aktiviert werden. Dieses Verfahren muss laut Google nur einmal durchgeführt und kann auf ein neues Gerät übertragen werden.

Videos by heise

Zudem erklärt Google, dass bei der Installation oder dem Update der App eines nicht verifizierten Entwicklers weiterhin eine Warnung angezeigt werde – diese lasse sich mit dem Tap auf den Button „Trotzdem installieren“ quittieren.

Bei jeder Installation oder dem Update einer unverifizierten App erscheint laut Google ein Warnhinweis.

(Bild: Google)

In dem Beitrag weist Google außerdem darauf hin, dass ADB-Installationen von der neuen Richtlinie nicht betroffen seien und die Entwickleroptionen nach der Aktivierung des erweiterten Ablaufs wieder abgestellt werden können.

Schrittweise Einführung – global ab 2027

Laut Google wird der Advanced Flow nach und nach auf zertifizierten Android-Geräten ab Android-Version 8 und neuer bereitgestellt. Zentraler Bestandteil der Funktion sei die im März angekündigte App „Android Developer Verifier“. Der von Google genannte Zeitplan für die Entwickler-Registrierung nach dem 30. September ist nur grob skizziert. Das Unternehmen schreibt lediglich, dass der Verifizierungsprozess für Entwickler bis „2027 und darüber hinaus“ zu einer weltweit geltenden Richtlinie gemacht wird.

Lesen Sie auch

VW ID.-Modelle: Das Smartphone wird zum digitalen Autoschlüssel

Zwei mit Format: Samsung Galaxy Z Fold8 und Fold8 Ultra im Test

Google führt neue Personalisierungsfunktionen für Suche und News ein

Pixel 11 Pro: Entwickler bohrt HiLight-Funktion auf

Android 17: Google führt strengere Speicherlimits für Apps ein

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Fehler in HTML, CSS und Accessibility – 87 Prozent der Top-Seiten fehlerhaft

2026-08-19T05:56:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Viele der Top-Webseiten halten sich nicht an die Standards. Das kann zu Problemen mit der Barrierefreiheit oder der KI-Kommunikation führen.

(Bild: Wolf Hosbach / KI /iX)

19.08.2026, 07:56 Uhr

Lesezeit: 2 Min.

Developer

Von

Wolf Hosbach

Der Dienst ValidateHTML hat von den Tranco-Top-5000-Domains die 2656 erreichbaren Homepages (Stand: August 2026, Report zuletzt aktualisiert am 14. August) auf die Einhaltung von Standards überprüft und festgestellt, dass 87,2 Prozent von ihnen HTML-Fehler enthalten und 64,5 Prozent Mängel im CSS aufweisen.

Der Betreiber des kostenlosen Dienstes, laut The Register der private Entwickler Théo Ducreux, hat die ersten 5000 Domains aus der gegen Manipulationen gehärteten Tranco-Ranking-Liste vom August verwendet, von denen 2656 wirklich erreichbar waren. Für den Test der Seiten nutzte er die gängigen Tools HTML-validate und csstree-validator mit dem Parser Lightning CSS.

Die Liste der gefundenen Fehler ist lang.

HTML-Fehler Nummer Eins findet sich auf 1579 Seiten <style> element ist not permitted as content unter <div> gefolgt von Attribute "id" has invalid value "". Der am häufigsten auf 1330 Seiten gefundene CSS-Fehler ist invalid value for 'background-color' property und dann Unknown property 'tap-highlight-color'. Die Beispiele sind nicht exakt, die konkreten Eigenschaften können variieren. Nur 2,6 Prozent der Seiten sind nach Ansicht Ducreux komplett sauber und verletzen auch keine seiner Best-Practice-Empfehlungen.

Videos by heise

Über ein Drittel der von ihm geprüften Seiten hatten zudem Mängel bei der Barrierefreiheit, zum Beispiel bei den ARIA- oder Alt-Tag-Auszeichnungen, obwohl seit Juni 2025 in der EU der European Accessibility Act (EAA) gilt. Korrekte Seitenstrukturen sind nicht nur für Screenreader wichtig, sondern auch für das Verständnis von KI-Agenten.

Lesen Sie auch

Automatisierte Accessibility-Prüfung im Web: Möglichkeiten und Grenzen

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Apple und die EU-Kommission einigen sich: Neue App-Store-Regeln ab 1. Oktober

2026-08-18T16:00:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Überraschende Einigung zwischen zwei erbitterten Konfliktparteien: Apple und die EU-Kommission wollen den Streit um den App Store beenden.

115

(Bild: daily_creativity / Shutterstock.com)

18.08.2026, 18:00 Uhr

Lesezeit: 7 Min.

Mac & i

Von

Malte Kirchner

Diese Botschaft am Nachmittag des 18. August 2026 kam überraschend: Apple und die EU-Kommission haben sich gemeinsam auf neue App-Store-Bedingungen in der EU geeinigt. Herausgekommen sind ein neues einheitliches Gebührenmodell für App-Entwickler, erhöhte Kinderschutzmaßnahmen und eine breitere Öffnung für Anbieter alternativer App-Marktplätze. Vor allem aber hofft Apple, damit das Kapitel eines langjährigen Konflikts mit der EU-Kommission schließen zu können. Die neuen App-Store-Bedingungen sollen zum 1. Oktober 2026 in Kraft treten. Die EU-Kommission hat sich bislang noch nicht geäußert.

Kaum ein Tech-Konzern hat sich in den vergangenen Jahren so gegen die Vorgaben des Gesetzes für digitale Märkte (Digital Markets Act, DMA) gesträubt wie Apple. Der iPhone-Hersteller fürchtete eine massive Verschlechterung der Sicherheit auf iPhones und iPads und damit Nachteile für seine Kunden. Das Unternehmen mit Sitz im kalifornischen Cupertino reagierte mit einem komplexen neuen Regelwerk mit unterschiedlichen Gebührensätzen und Bedingungen. App-Entwickler mussten sich unter anderem entscheiden, ob sie weiterhin bei Apples globalen Geschäftsbedingungen verbleiben und nur im App Store veröffentlichen dürfen – oder ob sie auf neue EU-Bedingungen wechseln und dann auch alternative Marktplätze bestücken dürfen.

Über ein Jahr lang verhandelt

Kritiker Apples sahen in dieser Vorgehensweise keinen Beitrag zur Sicherheit, sondern schlichtweg den Versuch, den von der EU angestrebten Wettbewerb zu verhindern. Und tatsächlich blieb eine Blütephase alternativer App-Marktplätze aus. Ob es an Apple lag oder die EU schlichtweg ein nicht vorhandenes Bedürfnis befriedigen wollte, ist umstritten. Doch in Brüssel sah man rot und stellte im Juni 2024 eine Verletzung der DMA-Regeln fest.

Videos by heise

Was die überraschende Trendwende ausgelöst hat, verrät Apple nicht. Vor einigen Wochen wurde bekannt, dass der scheidende Apple-Chef Tim Cook persönlich mit der EU-Kommission sprach. Die Verhandlungen, die zum jetzigen Ergebnis führten, gingen allerdings über ein Jahr und sie waren intensiv: Nahezu wöchentlich habe man sich getroffen, ist zu hören. Dies markiert eine deutliche Trendwende, denn noch vor anderthalb Jahren klagte Apple darüber, dass man in Brüssel keine Ansprechpartner habe und die Kommission erratisch agiere.

Ab 1. Oktober mehr Klarheit und einfachere Regeln

Ab dem 1. Oktober 2026 wird die Situation in der EU nun für Entwickler wieder deutlich einfacher. Es gibt dann nur noch eine Ausfertigung der Geschäftsbedingungen, die sowohl Veröffentlichungen im App Store Apples als auch in alternativen Marktplätzen abdecken. Also kein Entweder-oder mehr – und das reicht bis hin zu In-App-Käufen, die künftig auch in Apps angeboten werden können, die in alternativen Marktplätzen veröffentlicht werden können.

Mit den Änderungen geht auch eine neue Gebührenstruktur einher. Die bisherige EU-spezifische Kerntechnologiegebühr (Core Technology Fee, CTF) entfällt zugunsten einer neuen „Core Technology Commission“ von pauschal 5 Prozent auf digitale Transaktionen außerhalb des App Stores. Apple bekommt damit seine Kosten für das Bereitstellen der technischen Infrastruktur und der Plattform bezahlt.

Neue Gebührensätze

Der App-Vertrieb über den App Store mit Apple-In-App-Kauf kommt künftig mit einer Umsatzabgabe von 26 Prozent (Standard) daher bzw. 15 Prozent für Programme wie das „Small Business Program“ für App-Entwickler mit geringem Jahresumsatz. Die alternative Zahlungsabwicklung innerhalb der App schlägt mit 20 Prozent (Standard) oder 10 Prozent für begünstigte Entwicklerprogramme zu Buche. Für Apps im App Store, die für den Abschluss von Käufen aus der App heraus verlinken, beträgt die Provision 15 Prozent bzw. 10 Prozent in den Programmen.

Wer sich für eine Zahlungsoptions-Kombination entscheidet, muss diese laut Apple mindestens 12 Monate beibehalten. Für viele Entwickler dürfte das Bereitstellen von Apps günstiger werden – sie zahlen etwa im Standard-Tarif 26 statt bislang 30 Prozent.

Vorbilder Brasilien und Japan

Die neuen App-Store-Bedingungen ähneln in vielerlei Hinsicht jenen, die in Brasilien und Japan eingeführt wurden. Apple hatte dort jeweils im Zusammenspiel mit den Regulierern nach Lösungen gesucht, während man jeweils beklagte, dass es in der EU nur einen Konfrontationskurs gab. Das hat sich jetzt offenbar geändert. Änderungen findet man im Detail, etwa, dass Entwickler sich in der EU auch dazu entscheiden können, In-App-Käufe via Apple gar nicht anzubieten.

Ein weiteres Thema, das Apple nach eigener Aussage wichtig ist und das Berücksichtigung gefunden hat, ist der Kinderschutz. Apps in der Kids-Kategorie dürfen künftig keine Links zu externen Bezahl-Websites mehr enthalten. Für Nutzer unter 13 Jahren ist generell kein Verlinken zu Web-Zahlungen erlaubt. Und für Nutzer unter 18 Jahren ist bei alternativen Zahlungen oder Verlinkungen vorgeschrieben, dass Erziehungsberechtigte eingebunden werden müssen.

Apple öffnet sich für weitere Alternativen

Apple wiederum hat sich für erweiterte Zulassungsmöglichkeiten für alternative App-Marktplätze geöffnet. Unternehmen sind jetzt dafür qualifiziert, wenn sie festgelegte Mindestanforderungen an die finanzielle Stabilität erfüllen, öffentlich börsennotiert oder im Besitz eines öffentlich börsennotierten Unternehmens sind, Risikokapital von einer etablierten Investmentfirma erhalten haben oder eine Finanzprüfung durch einen zugelassenen Wirtschaftsprüfer vorgenommen haben. Auch staatliche Einrichtungen, Bildungseinrichtungen oder gemeinnützige Organisationen sind berechtigt.

Kein Wort gab es hingegen dazu, ob die bisherigen Hürden bei der Installation alternativer App-Stores reduziert werden. Zu erwarten ist dies nicht, denn Apple sieht in dem Aufbohren seiner Plattform weiterhin eine Erhöhung der Sicherheitsrisiken, auch wenn es in den zwei Jahren seit Einführung des DMA zu keinem großen Sicherheitsvorfall gekommen ist.

Eine Einigung mit Signalwirkung?

Ob die neuen Bedingungen deshalb die Kritik von Apple-kritischen Unternehmen wie Epic oder Spotify abreißen lassen, ist zu bezweifeln. Dass Apple jetzt in einem ersten wichtigen Punkt der jahrelangen DMA-Streitigkeiten eine Einigung mit der EU-Kommission erzielt hat, könnte allerdings eine Signalwirkung auf andere Konflikte zwischen den beiden Parteien haben. So zittern Apple-Nutzer in der EU aktuell, ob und wann sie die KI-erneuerte Sprachassistenz Siri AI bekommen. Apple hat angekündigt, iPhones und iPads in der EU vorerst nicht damit auszustatten – aus Sorge vor Regulierung durch die EU: Viele warten auch noch auf die iPhone-Fernsteuerung über macOS, die Apple ebenfalls zurückhält. Zähneknirschen gibt es außerdem bei der Interoperabilität, also inwieweit zum Beispiel Hersteller von Smartwatches und Kopfhörern gleichberechtigten Zugang zum System bekommen, wie Apple ihn für seine Geräte vorhält.

Mit der jetzigen Einigung ist ein Anfang gemacht, vielleicht auch weitere Konfliktpunkte einvernehmlich zu lösen.

Lesen Sie auch

iPhone-Kindersicherung: "Wer nur auf technischen Schutz setzt, denkt zu kurz"

Bericht: Apple entlässt zahlreiche Mitarbeiter in Vision Products Group

Vom Millimeterpapier zum Mac-Icon: Susan Kares Design-Geschichte

Apple TV: Apple Intelligence kommt – via Siri AI

KI-Blase: Expertengruppe der EZB warnt vor den Folgen eines Kursrutsches

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Kritische Sicherheitslücke in GitLab: Angreifer können Projekte löschen

2026-08-18T08:29:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Alert!

GitLab-Umgebungen sind über zwei nun geschlossene Schwachstellen attackierbar.

(Bild: Artur Szczybylo/Shutterstock.com)

18.08.2026, 10:29 Uhr

Lesezeit: 2 Min.

Security

Von

Dennis Schirrmacher

Die Code-Hosting-Plattform GitLab ist verwundbar. Angreifer können an zwei Sicherheitslücken ansetzen und Projektdaten manipulieren oder sogar löschen.

In einer Warnmeldung versichern die Entwickler, dass sie die Ausgaben 18.11.11, 19.0.8, 19.1.6 und 19.2.4 der GitLab Community Edition und Enterprise Edition repariert haben. Admins von On-Premises-Installationen sollten zeitnah handeln und eine der aktuellen Versionen installieren. Den Entwicklern zufolge sind auf GitLab.com bereits die reparierten Versionen installiert.

Integrität von Projekten gefährdet

Nutzen Angreifer eine „kritische“ Sicherheitslücke (CVE-2026-19478) aus, können sie öffentliche Projekte und Nutzerdaten verändern oder löschen. Die Schwachstelle findet sich in der GraphQL-API einer GitLab-Instanz. Kann ein Angreifer darauf zugreifen, nutzt er die Lücke mit präparierten GraphQL-Anfragen aus.

Im zweiten Fall (CVE-2026-19650 „hoch“) muss ein Opfer mitspielen und etwa auf einen manipulierten Link klicken. Im Anschluss kann ein Angreifer über GET-Anfragen an der GraphQL-API ansetzen und etwa Projekteinstellungen verändern. Wenn ein Opfer Admin-Rechte hat, könnte ein Angreifer mit diesen Rechten ausgestattet ganze Instanzen kompromittieren.

Videos by heise

Bislang gibt es vom Softwareentwickler keine Hinweise, dass Angreifer die Lücken bereits ausnutzen. Sie raten aber dringend zu einem zügigen Update. Demzufolge sollten Admins die Patches demnächst installieren, um ihre Instanzen vor möglichen Attacken zu schützen. Schließlich können Angreifer in Softwareentwicklungsumgebungen ziemliches Unheil anrichten. Wer eine nicht mehr im Support befindliche Ausgabe nutzt, muss auf eine noch unterstützte upgraden.

Zuletzt haben die GitLab-Entwickler Ende Juli zu einem zügigen Update geraten.

(des)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Software Testing: KI als Tester – So funktioniert LLM-as-a-Judge

2026-08-18T07:40:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Automatisiertes Testing: Was hinter dem Ansatz steckt, ein LLM über ein anderes urteilen zu lassen, klärt Richard Seidl im Gespräch mit Anupam Krishnamurthy.

(Bild: Richard Seidl)

18.08.2026, 09:40 Uhr

Lesezeit: 2 Min.

Developer

Von

Richard Seidl
Anupam Krishnamurthy

Wer KI-Systeme testet, muss Determinismus neu denken. Richard Seidl spricht mit Anupam Krishnamurthy darüber, warum das vertraute Fundament der Testautomatisierung bei LLMs nicht mehr trägt und was stattdessen funktioniert. Anupam Krishnamurthy erklärt, wie man ein RAG-System in seine Bestandteile zerlegt, warum die meisten Fehler im Retrieval stecken und nicht in der Generierung, und was hinter dem Ansatz steckt, ein LLM als Richter über ein anderes urteilen zu lassen. Außerdem zeigt er, wie klassische Testkonzepte wie das Isolieren von Komponenten und kontextspezifisches Vorgehen auch im KI-Testing weiterhelfen, solange man bereit ist, Fragen wie „Was ist eine korrekte Antwort?“ grundsätzlich neu zu stellen.

Richard Seidl ist Berater, Speaker und Podcast-Host. Für ihn ist klar: Wer heute exzellente Software kreieren möchte, denkt den Entwicklungsprozess ganzheitlich: Menschen, Kontext, Methoden und Tools. Er hat seine Erfahrungen in acht Fachbüchern veröffentlicht, betreibt erfolgreich zwei Community-Podcasts und ist Beirat der heise-Konferenz betterCode() Testing.

„Die meisten Probleme liegen im Retrieval.“ – Anupam Krishnamurthy

Empfohlener redaktioneller Inhalt

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

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.

Anupam Krishnamurthy ist Head of AI Testing bei der TestSolutions GmbH, wo er die Bemühungen des Unternehmens leitet, beim Testen im Zeitalter von KI-gestützter Softwareentwicklung an der Spitze zu bleiben. Er ist Mitgründer der BeyondQuality-Community und Co-Host des dazugehörigen Podcasts. Anupam ist ein Manager, der zum Softwareentwickler wurde – ein bunter Karriereweg, der ihn zu den Grundlagen zurückführte. Er begann als Maschinenbauingenieur, der in Indiens Raumfahrtprogramm Satelliten zusammenbaute, machte einen MBA, arbeitete als Strategieberater und stellte dann fest, dass ihm Programmieren mehr Spaß macht als PowerPoint. Zuvor war er als Test Automation Engineer und als freiberuflicher Berater tätig und half seinen Kunden, qualitativ hochwertige Software schneller auszuliefern. Ursprünglich aus Bangalore, Indien, und mittlerweile in Berlin zu Hause, findet man ihn in seiner Freizeit vertieft in eine Partie Online-Schach, beim Langstreckenlauf mit einem History-Podcast im Ohr oder beim Blues-Spielen auf seiner Akustikgitarre.

Softwarequalität im Gespräch

Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, welche die Qualität in der Softwareentwicklung steigern.

Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar.

(mai)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Neu in .NET 10.0 [36]: Neue Einstellungssammlung mit Best Practices für JSON

2026-08-18T07:28:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit JsonSerializationOptions.Strict aktiviert man mehrere strengere Einstellungen für die Deserialisierung von JSON-Inhalten.

(Bild: Pincasso / Shutterstock.com)

18.08.2026, 09:28 Uhr

Lesezeit: 1 Min.

Developer

Von

Dr. Holger Schwichtenberg

Der JSON-Serialisierer System.Text.Json bietet in Version 10.0 unter JsonSerializationOptions.Strict neue Optionen an, darunter JSON AllowDuplicateProperties = false.

JsonSerializationOptions.Strict setzt Einstellungen, die Microsoft in den Release Notes als „Best Practices“ bezeichnet:

UnmappedMemberHandling = Disallow
AllowDuplicateProperties = false
RespectNullableAnnotations = true
RespectRequiredConstructorParameters = true

Vergleich der Eigenschaften von JsonSerializerOptions.Default (oben) und JsonSerializerOptions.Strict (unten) (Abb. 1)

(Bild: King / stock.adobe.com)

Das ist neu in .NET 11.0: Dr. Holger Schwichtenberg und weitere Experten präsentieren am 17. November 2026 auf der Online-Konferenz betterCode() .NET 11.0 die Änderungen für Entwicklerinnen und Entwickler. Tickets zum Frühbucherpreis sind im Online-Shop verfügbar.

Diese Einstellungen sind lesekompatibel mit JsonSerializationOptions.Default, das heißt, ein mit JsonSerializationOptions.Default serialisiertes Objekt kann mit JsonSerializationOptions.Strict deserialisiert werden. Der folgende Codeausschnitt führt zum Laufzeitfehler „The JSON property 'ID' could not be mapped to any .NET member contained in type 'Person'.“:

public void JSONStrict()
{
 CUI.Demo(nameof(JSONStrict));
 
 CUI.H2("JSON-Dokumente mit doppelten Eigenschaften");
 string json = """{ "ID": 123, "FirstName": "Holger", "LastName": "Schwichtenberg", "LastName": "www.IT-Visions.de" }""";
 Console.WriteLine(json);
 
 CUI.H2("Deserialisierung im Standard");
 var person = JsonSerializer.Deserialize<Person>(json);
 Console.WriteLine(person); // AUSGABE: Person: Holger www.IT-Visions.de
 
 try
 {
  CUI.H2("Deserialisierung mit JsonSerializerOptions.Strict");
  Console.WriteLine(JsonSerializerOptions.Strict.ToNameValueString());
  JsonSerializer.Deserialize<Person>(json, JsonSerializerOptions.Strict); // throws JsonException "The JSON property 'ID' could not be mapped to any .NET member"
 }
 catch (Exception ex)
 {
  CUI.PrintError(ex);
 }
}

Der zweite Fehler des doppelten Wertes für "LastName" wird nicht ausgegeben, da System.Text.Json leider immer nur den ersten Fehler liefert.

JsonSerializationOptions.Strict kann auch beim Serialisieren eingesetzt werden. Allerdings machen die meisten Einstellungen dabei keinen Unterschied.

Videos by heise

Hier ist ein Beispiel, in dem JsonSerializerOptions.Strict einen Unterschied bei Serialize() macht:

#nullable enable

Wenn man dann eine Property in Person auf null lässt, kommt:

The property or field 'PrivateEmail' on type 'Person' doesn't allow getting null values.

Das liegt daran, dass JsonSerializerOptions.Strict die Eigenschaft RespectNullableAnnotations = true setzt. Das ist aber im engeren Sinne nicht neu in .NET 10.0. RespectNullableAnnotations wurde in .NET 9.0 eingeführt.

(rme)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Model-Schau: Offene Modelle aus den USA, große aus China und kleine aus Europa

2026-08-18T07:15:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die chinesischen Modelle werden größer und die amerikanischen Modelle offener. Außerdem gibt es Neuigkeiten aus der Schweiz und endlich aus Deutschland.

(Bild: pncha.me/Shutterstock.com)

18.08.2026, 09:15 Uhr

Lesezeit: 14 Min.

Developer

Von

Dr. Christian Winkler

Vom Sommerloch keine Spur, im Gegenteil: Die Meldungen zu neuen Sprachmodellen überstürzten sich in den vergangenen Wochen regelrecht. Während man aus China vor allem Superlative bezüglich der Modellgrößen hört, sind die offenen amerikanischen Modelle aktuell eher etwas kleiner – immerhin gibt es endlich welche. Eine andere Art von Superlativen aus den USA sind Modelle, die sich nicht an Vorgaben halten und andere Websites hacken.

Prof. Dr. Christian Winkler beschäftigt sich speziell mit der automatisierten Analyse natürlichsprachiger Texte (NLP). Als Professor an der TH Nürnberg konzentriert er sich bei seiner Forschung auf die Optimierung der User Experience.

In Europa tut sich zumindest ein wenig: Apertus aus der Schweiz gibt es in einer verbesserten Version und endlich mit Soofi auch ein deutsches Modell, das aber noch Startschwierigkeiten hat.

Große und kleine chinesische Modelle

Als der chinesische Anbieter Moonshot das neue Kimi K3-Modell ankündigte, gingen Schockwellen fast wie bei DeepSeek R1 durch die LLM-Community. Ein derart großes Modell mit 2,8 Billionen Parametern war vorher mit offenen Gewichten noch nicht verfügbar. Zudem erwies sich Kimi K3 in vielen Tests als äußerst stark und ist in den einschlägigen Benchmarks wie arena.ai oder artificialanalysis.ai stets auf den Top-Plätzen zu finden.

(Bild: mooam / 123rf)

Am 15. Oktober 2026 widmet sich die Online-Konferenz „LLMs im Unternehmen“ den lokalen Modellen: Für welche Anwendungen sie sich lohnen, welche Hardware erforderlich ist und wie man die Performance optimiert.

Neben der schieren Größe hat Moonshot einige Optimierungen zu bieten, die das Modell in der Inferenz deutlich gegenüber Kimi K2.6 deutlich beschleunigen. Dazu gehört ein optimierter Attention-Mechanismus, den Moonshot Kimi Delta Attention (KDA) nennt. Dabei wechseln sich lineare und globale Attention Layer im Verhältnis 3:1 ab. Das spart viel Rechenzeit und Speicherbedarf, was besonders bei langen Kontexten ins Gewicht fällt. Spannend ist auch die Mixture-of-Experts-Architektur (MoE), denn Kimi nutzt sage und schreibe 896 Experten. So viele waren bisher in offenen Modellen nicht verfügbar.

Dankenswerterweise hat Moonshot die Gewichte auch ins kompakte MXFP4-Format überführt und damit den Speicherbedarf im Vergleich zu dem sonst oft üblichen bfloat16 auf ein Viertel reduziert. Dennoch sind auch bei kleinen Kontexten mindestens 1,5 TByte RAM erforderlich, was das Budget vieler Firmen sprengt. Eine lokale Ausführung wird damit nur für die wenigsten in Frage kommen, ist aber möglich. Moonshot bietet Kimi K3 auch als Clouddienst an, dessen Kosten im Vergleich zu anderen Modellen überschaubar sind.

Auch beim Training nutzte Moonshot einige kreative Ideen, um die vielen Experten gleichmäßig zu trainieren. Laut Anbieter hat das Modell zudem seine eigenen Kernels optimiert, sodass es nun die eigene Inferenz schneller ausführen kann.

In eigenen Tests funktionierte das Modell hervorragend und gab ausführliche Antworten. Lediglich bei heiklen politischen Fragen war das Modell genau auf Kurs der Kommunistischen Partei.

Anfang August erschien mit Qwen3.8-Max das nächste große chinesische Modell. Ähnlich zu Kimi K3 steht Qwen3.8-Max zunächst nur per API zur Verfügung, aber die Gewichte sollen noch folgen. Auch das neue Qwen-Modell ist sehr groß, hat aber „nur“ 2,4 Billionen Parametern.

Alibaba hat Qwen3.8 die Aufgabe gegeben, das oh-my-cli-Projekt zu implementieren. Dabei handelt es sich um ein kleines Coding-Agentenframework für die Kommandozeile. Nach eigenen Aussagen hat das Modell fast 16 Tage autark daran gearbeitet, was beachtlich wäre. Auch wissenschaftliche Artikel hat das Modell überprüft, den darin verwendeten Programmcode verstanden und sogar optimiert. Der Artikel ist voller Superlative – was davon wirklich umsetzbar ist und mit welchem Aufwand, müssen unabhängige Tests verifizieren.

Qwen3.8 Max schneidet in den Benchmarks gut ab. Besonders im Bereich Webentwicklung scheint es mit den besten – auch geschlossenen – Modellen mithalten zu können. In eigenen Tests antwortet das Modell kompetent, war allerdings bei politischen Fragen äußerst schweigsam.

Leider finden sich bisher wenige technische Details zu Qwen3.8 Max. Es liegt nahe, dass sich die Architektur im Vergleich zu der offenen Qwen3.6-Reihe kaum verändert hat. Genaueres wird man erst nach der Veröffentlichung der Gewichte herausfinden. Die Community erwartet sie sehnlich – nicht nur wegen Qwen3.8 Max, sondern insbesondere auch wegen des gleichzeitig angekündigten Qwen3.8-27B. Das Vorgängermodell Qwen3.6-27B ist für viele lokale Anwender noch immer Mittel der Wahl, weil es insbesondere mit Multi-Token Prediction (MTP) gute Performance bietet (mehr als 100 Token/s auf einer RTX 5090) und sich daher hervorragend für lokale agentische Systeme eignet.

Vermutlich ist das Ende der Fahnenstange bei den großen chinesischen Modellen damit noch nicht erreicht. Die normalerweise zuverlässige Financial Times berichtet, dass die TikTok-Mutter Bytedance an einem Modell mit 10 Billionen Parametern arbeitet. Damit nähert sich die Zahl der Parameter denen, der besten geschlossenen Modelle. Bei Anthropics Mythos 5 vermutet man acht Billionen Parameter, bei Fable 5 des gleichen Anbieters fünf Billionen.

Flash-Modell von DeepSeek

Deutlich kleiner als Kimi K3 und Qwen3.8 Max ist das DeepSeek-Modell DeepSeek-V4-Flash-0731. Dennoch ist es spannend, weil es das deutlich größere DeepSeek-V4-Pro (Preview) in vielen Benchmarks schlägt. Die unscheinbare Versionsnummer 0731 – für den 31.07.2026 – hat hier viel bewegt und das Modell enorm verbessert.

Für ein Flash-Modell hat es allerdings viele Parameter: 284 Milliarden, von denen 13 Milliarden aktiv sind. Dankenswerterweise hat DeepSeek das Modell in Vier-Bit-Präzision bei den Experten trainiert, sodass man zwar nur 168 GByte Daten herunterladen und im Speicher unterbringen muss – das aber allein für die Gewichte. Mit solchen Modellen möchte man normalerweise mit einem großen Kontext arbeiten, der zusätzlich Platz in Anspruch nimmt.

Dass das Flash-Modell als stark gilt, hat die Community auf den Plan gerufen und einige interessante Projekte hervorgebracht. An erster Stelle sei hier vLLM-Moet genannt, das den Betrieb des Modells auf einer RTX 5090 mit immerhin 31 Token/s ermöglicht. Das ist deutlich schneller, als man mitlesen kann. Wer über eine RTX 6000 verfügt, kann das Modell gar mit 161 Token/s betreiben. Noch schneller geht es mit vier RTX 5090. In beiden Fällen sind allerdings schon fünfstellige Investitionen notwendig.

Wer einen Mac nutzt, kann stattdessen ds4 ausprobieren. Dank der speziellen Quantisierung lässt sich das Modell mit 128 GByte RAM betreiben. Mit einem dazu passenden spekulativen DSpark-Modell erreicht es Geschwindigkeiten von fast 40 Token/s. Es ist möglich, mehrere Macs zu koppeln, um die Geschwindigkeit zu steigern.

Wer sich den Hardware-Overkill nicht antun möchte, kann das Modell als Cloudservice günstig nutzen. Bei nicht sensiblen Daten ist das kein Problem. Neben DeepSeek selbst gibt es auch andere Anbieter, die das Modell im Portfolio haben. Aktuell verlangt OpenRouter 0,08 US-Dollar für eine Million Input-Token und 0,252 US-Dollar für eine Million Output-Token.

Eigene Experimente bescheinigen dem Modell gute Antworten, auch die politische Färbung ist (noch?) nicht ganz so ausgeprägt wie bei anderen Modellen. Fragen zu heise, zur Erdbeere und zur Waschanlage beantwortet das Modell sicher, auch pivot_table wird bei der pandas-Frage erwähnt. Diese Performance ist neben der handhabbaren Größe vermutlich ein Grund, warum das DeepSeek-Modell im Moment zu den beliebtesten Modellen überhaupt gehört.

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

GitHub stundenlang kaputt

2026-08-17T19:16:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Microsofts Code-Plattform GitHub hat am Montag ungeplant Pause gemacht. Manche Entwickler auch.

(Bild: Sundry Photography/Shutterstock.com)

17.08.2026, 21:16 Uhr

Lesezeit: 2 Min.

Developer

Von

Daniel AJ Sokolov

GitHub ist Montagnachmittag unvorhergesehen offline gegangen. Wie Betreiber Microsoft bestätigt hat, gibt es seit mindestens 15:40 MESZ /13:40 UTC Schwierigkeiten. Die Probleme gehen quer durch die Bank: Log-ins, Downloads, GitHub Actions, API-Anfragen, Webhooks, und andere Funktionen der Code-Plattform zeigten hohe Fehlerraten. Zudem funktionierte das beigestellte Large Language Model Copilot nur eingeschränkt.

Seit circa 19 Uhr MESZ/17 Uhr UTC bessert sich die Lage schrittweise. Microsoft hat Ursachen ausgemacht und Maßnahmen gesetzt. Die GitHub-Statuspage zeigt zur Stunde noch gröbere Schwierigkeiten beim Copilot und teilweise Ausfälle bei GitHub Issues. Mit diesem Werkzeug können bei GitHub-Projekten Fehler und Wünsche eingemeldet sowie etwaige Arbeitsfortschritte verfolgt werden.

Die konkrete Ursache des GitHub-Ausfalls ist bislang nicht bekannt. Technische Basis ist immer mehr Microsofts Cloud-Plattform Azure. KI-Bots haben den Datenverkehr auf GitHub vervielfacht. Manche Entwickler, die GitHub intensiv einsetzen, nutzten am Montag den Ausfall, um in Sozialen Netzen ihrer Freude über die ungeplante Arbeitspause oder früheren Feierabend Ausdruck zu verleihen.

Seit bald acht Jahren bei Microsoft

Die Software-Entwicklungsplattform GitHub besteht seit 2008. Zehn Jahre später, im Juni 2018, wurde sie von Microsoft für 7,5 Milliarden Dollar gekauft. Nach Erlangung der notwendigen wettbewerbsrechtlichen Genehmigungen im Oktober desselben Jahres wurde die Übernahme GitHubs durch Microsoft abgeschlossen. Damals gab es offiziell keine unmittelbaren Pläne, auf Azure umzuziehen.

Videos by heise

In der Folge begann dennoch ein schrittweiser Umzug. Im August 2025 verließ GitHub-CEO Thomas Dohmke das Unternehmen. Wenig später gab Microsoft intern das Ziel aus, binnen 24 Monaten alle bis dahin unabhängig verbliebenen Teil GitHubs auf Azure zu migrieren. Dafür wurde auch die Entwicklung neuer Leistungsmerkmale hintangestellt.

(ds)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Schadcode-Sicherheitslücken bedrohen PostgreSQL

2026-08-17T10:21:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Alert!

In aktuellen Versionen haben die PostgreSQL-Entwickler mehrere Sicherheitslücken geschlossen. Für einen Versionsstrang läuft bald der Support aus.

(Bild: ronstik/Shutterstock.com)

17.08.2026, 12:21 Uhr

Lesezeit: 1 Min.

Security

Von

Dennis Schirrmacher

Angreifer können über mehrere Softwareschwachstellen im Datenbankmanagementsystem PostgreSQL Schadcode auf Systeme schieben und ausführen. Dagegen sind abgesicherte Ausgaben erschienen.

28 Lücken geschlossen

Die Entwickler geben in einem Beitrag an, die Versionen 14.24, 15.19, 16.15, 17.11, 18.6 repariert zu haben. Sie weisen Admins darauf hin, dass der Support für PostgreSQL 14 am 12. November 2026 ausläuft. Ab diesem Zeitpunkt bekommt die Version keine Sicherheitsupdates mehr und Sicherheitslücken bleiben offen. Wer diese Ausgabe installiert hat, muss bis dahin ein Upgrade auf eine noch unterstützte Version vornehmen.

In den meisten Fällen können Angreifer nach erfolgreichen Attacken eigenen Code ausführen und so die volle Kontrolle über Instanzen erlangen. Etwa im Kontext der Datentypen tsvector und tsquery kann es zu einem Speicherfehler kommen (CVE-2026-14662 „hoch“), sodass das System außerhalb des reservierten Bereichs schreibt ("Out-of-bounds write").

Videos by heise

Zusätzlich kann ein Angreifer im Zuge des Restore-Prozesses Schadcode ausführen (CVE-2026-18408 „hoch“). Zurzeit gibt es noch keine Berichte, dass Angreifer die Sicherheitslücken ausnutzen.

(des)

Top 10: Der beste Insektenstichheiler im Test

Top 10: Das beste City-E-Bike im Test

Top 10: Mähroboter ohne Begrenzungskabel

Mojo 1: Sieht aus wie Python – ist aber mehr Rust

2026-08-17T09:55:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Nach gut drei Jahren räumt Anbieter Qualcomm beim Python-Ableger Mojo auf. Die Sprache wird einheitlicher, schlanker, aber auch strenger.

(Bild: Wolf Hosbach / KI / iX)

17.08.2026, 11:55 Uhr

Lesezeit: 6 Min.

Developer

Von

Stefan Wintermeyer

Das zu Qualcomm gehörende Unternehmen Modular hat die stabile Version 1.0 der Programmiersprache Mojo veröffentlicht. Die an Python angelehnte Sprache ist schlanker und einheitlicher geworden: Früher gab es oft mehrere Wege für dieselbe Sache, jetzt lassen sich Variablen beispielsweise einheitlich mit var deklarieren. Der Anbieter hat zudem Closures vereinheitlicht und die vormals getrennten Typen Pointer und UnsafePointer zu einem Pointer verschmolzen, bei dem die riskanten Operationen ein unsafe_ im Namen tragen müssen.

Version 1 ist zusammen mit Version 26.5 der hauseigenen KI-Plattform MAX erschienen, beide im selben GitHub-Release. MAX zählt Versionen kalendarisch nach Jahr und laufender Ausgabe, Mojo wechselt mit dem ersten stabilen Release dagegen auf semantische Versionierung und markiert erstmals einen Teil seiner Schnittstellen ausdrücklich als stabil.

Strengere Regeln für def

Die tiefgreifendste Neuerung betrifft die Funktionsdefinition. Mojo kannte lange def für Python-ähnliche und fn für strenger geprüfte Funktionen. Auf dem Weg zu Version 1 hat Modular fn gestrichen: Seit der Beta 2 quittiert der Compiler das Schlüsselwort nicht mehr mit einer Warnung, sondern mit einem harten Fehler:

error: 'fn' has been removed; use 'def' instead

Verschwunden ist dabei nur das Schlüsselwort, nicht sein Verhalten: Die strengeren fn-Regeln gelten jetzt für def, das ohne ausdrückliches raises keine Ausnahmen mehr auslöst. Ein Umbenennen von fn zu def genügt daher meist, umgekehrt kann alter def-Code an den neuen Regeln scheitern.

Videos by heise

Ebenfalls neu ist eine Lambda-Syntax für kurze anonyme Funktionen. Modular bewirbt sie als „Python-style“, verlangt aber Klammern und Typangaben: lambda (x: Int) -> Int: x * 2 statt Pythons lambda x: x * 2.

Der Compiler findet mehr Fehler

Über die Typprüfung hinaus erkennt der Compiler nun ungültig gewordene Referenzen. Wächst eine Liste über ihren reservierten Platz hinaus, zieht sie an eine größere Stelle im Speicher um, und ein Verweis auf die alte Stelle zeigt danach ins Leere. In C++ ist das ein klassischer Weg zu Absturz oder Sicherheitslücke. Mojo lehnt das jetzt schon beim Übersetzen ab:

def main():
    var numbers: List[Int] = [1, 2, 3]
    ref first = numbers[0]
    numbers.append(4)
    print(first)

ref first ist ein Verweis auf das erste Listenelement, keine Kopie. Die Typangabe List[Int] ist nötig, weil [1, 2, 3] in Mojo 1.0 sonst einen Array fester Länge ohne append erzeugt. Der Compiler benennt präzise, wo die Referenz ihre Gültigkeit verlor:

error: use of invalidated interior reference 'numbers["element"]'
    print(first)
          ^
note: origin was invalidated here
    numbers.append(4)

Zieht man print(first) vor das append, läuft dasselbe Programm anstandslos. Ergänzend hat Modular nach eigenen Angaben den Language Server stabilisiert.

Typenprüfung und Ownership

Warum eine weitere Programmiersprache? – Python dominiert die KI-Entwicklung, ist in der verbreiteten CPython-Implementierung aber langsam; die Rechenarbeit übernehmen deshalb Bibliotheken in C, C++ oder CUDA. Dieses Zwei-Sprachen-Problem will Mojo auflösen. Die Sprache ist übersetzt und bringt statische Typprüfung, ein Ownership-Modell ohne Garbage Collector und direkte Hardwarekontrolle mit. Damit steht Mojo trotz vertrauter Python-Optik näher bei C++ und Rust als bei Python. Modular selbst nutzt Mojo als Grundlage von MAX und der Modular Cloud.

Gegründet wurde Modular im Januar 2022 von Chris Lattner, dem ursprünglichen Entwickler von LLVM und Swift, und Tim Davis, bei Google zuständig für TensorFlow, XLA und TPU. Beide entwickelten dort MLIR, das heute Mojos Unterbau bildet: Daher erzeugt die Sprache Code für CPUs ebenso wie für GPUs und andere Beschleuniger. Seit dem 29. Juli 2026 gehört Modular zu Qualcomm; Mojo, MAX und die Modular Cloud sollen jedoch eigenständige Produkte bleiben.

So sieht Mojo aus

def square(x: Int) -> Int:
    return x * x

def main():
    var value = 42
    print(square(value))

Typangaben wie x: Int und -> Int sind Pflicht, var deklariert eine Variable, den Funktionsrumpf markiert wie in Python allein die Einrückung. Mit mojo build entsteht daraus eine eigenständige ausführbare Datei. Mojo läuft unter Linux, macOS und unter Windows via WSL.

Statisch typisiert, und zwar konsequent

Der augenfälligste Unterschied zu Python steckt in der Typprüfung. Python erlaubt es, derselben Variablen nacheinander eine Zahl und dann eine Zeichenkette zuzuweisen; Typfehler zeigen sich erst zur Laufzeit. Mojo legt den Typ beim Übersetzen fest: Aus var value = 42 schließt der Compiler auf eine Ganzzahl, ein anschließendes value = "hallo" bricht die Übersetzung ab:

error: cannot implicitly convert 'StringLiteral["hallo"]' value to 'Int'

Diese Strenge geht weiter, als der Python-Anstrich vermuten lässt. Ein def square(x): ohne Typangabe, in Python der Normalfall, lehnt der Compiler mit argument type must be specified ab.

Als Brücke in bestehende Codebestände importiert Mojo über das Modul std.python vorhandene Python-Module, allerdings im echten CPython-Interpreter und damit in dessen Tempo.

Compiler bleibt vorerst geschlossen

In der Vergangenheit hat Modular die Sprache in hohem Tempo umgebaut. Seit der ersten öffentlichen Fassung im Mai 2023 änderten sich laufend APIs und Sprachkonstrukte, was nach eigenem Eingeständnis die langfristige Pflege von Mojo-Projekten erschwert hat.

Damit soll Version 1 Schluss machen: Änderungen sollen während der 1.x-Reihe überwiegend additiv ausfallen; inkompatible schließt Modular nicht aus, will sie aber mit der bei gereiften Sprachen wie C++ üblichen Sorgfalt handhaben. Fertig ist die Sprache damit noch nicht.

Offen ist bislang nur ein Teil der Plattform: Die Standardbibliothek steht unter der Apache-2-Lizenz mit LLVM-Ausnahmen auf GitHub bereit, Compiler und Werkzeugkette nicht. Deren Freigabe hatte Modular bereits früher in Aussicht gestellt und bekräftigt sie nun für 2026. Bis dahin bleibt Mitarbeit nur an der Bibliothek möglich, nicht an der Sprache selbst. Genutzt haben das laut Modular knapp 200 Beitragende, mit mehr als 1.100 Pull Requests und über 200.000 veränderten Codezeilen.

Auf der Roadmap stehen zudem ein belastbares Modell für asynchrone Programmierung, Pattern Matching und Union Types.

(who)

heise developer News

Developer-Häppchen – Go mit generischen Methoden und DuckDB als Server

AI für SRE: Warum Automatisierung das Ziel ist und KI nur ein Werkzeug

Eine Matrix statt eines Organisationslevels

Prävention vor Reaktion – und die Sache mit dem Alert Noise

Wenn KI ohne Telemetrie mehr schadet als nützt

Der EU AI Act als Rahmen für autonome SRE-Tools

Empfohlener redaktioneller Inhalt

Neu in .NET 10.0 [37]: GetPropertyCount() in der Klasse JsonElement

Angriffsversuche auf GitLab-Lücke beobachtet

Schwachstelle in Minuten nachvollzogen

KI: Warum kollaborative Modellierung wichtiger wird als Programmieren

Wichtigster Skill in der IT?

Hauptherausforderung in der Softwarearchitektur

Die Natur der Softwareentwicklung

LLMs und generative KI löst das schon?

Was also tun?

Event Storming

Kollaborative Modellierung

tl:dr

Mojo wird Open Source – Python-ähnliche Sprache für CPUs und GPUs

Drei Fragen und Antworten: Mehr Effizienz und Speed mit dem neuen Docker-VMM

Umfrage: Claude Code und GitHub Copilot sind die beliebtesten

Nur jeder Zweite kennt Google Antigravity

Linux 7.2 bringt umfangreiche Treiberupdates

Linux 7.2: Ein ziemlich normales Release

Agentic Engineering: Webinar zum verlässlichen Arbeiten mit Claude Code

Agentic Engineering vs. Prompt-Engineering

Die Bausteine einer verlässlichen Umgebung

Ein Grundgerüst, live gebaut

Voraussetzung, nicht Selbstläufer

Termin und Konditionen

Google führt erweiterten Sideloading-Ablauf für Android schrittweise ein

„Advanced Flow“

Schrittweise Einführung – global ab 2027

Fehler in HTML, CSS und Accessibility – 87 Prozent der Top-Seiten fehlerhaft

Apple und die EU-Kommission einigen sich: Neue App-Store-Regeln ab 1. Oktober

Über ein Jahr lang verhandelt

Ab 1. Oktober mehr Klarheit und einfachere Regeln

Neue Gebührensätze

Vorbilder Brasilien und Japan

Apple öffnet sich für weitere Alternativen

Eine Einigung mit Signalwirkung?

Kritische Sicherheitslücke in GitLab: Angreifer können Projekte löschen

Integrität von Projekten gefährdet

Software Testing: KI als Tester – So funktioniert LLM-as-a-Judge

Empfohlener redaktioneller Inhalt

Softwarequalität im Gespräch

Neu in .NET 10.0 [36]: Neue Einstellungssammlung mit Best Practices für JSON

Model-Schau: Offene Modelle aus den USA, große aus China und kleine aus Europa

Große und kleine chinesische Modelle