heise developer News

Meta dekodiert getippte Sätze aus Hirnströmen – ohne Operation

2026-07-02T16:46:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Metas KI-Modell Brain2Qwerty rekonstruiert getippte Sätze aus EEG- und MEG-Hirnströmen – ohne Implantate. Die KI erreicht im Schnitt 61 Prozent Wortgenauigkeit.

Fast wie Gedanken lesen

(Bild: Gorodenkoff / Shutterstock.com)

18:46 Uhr

Lesezeit: 2 Min.

Von

Carolin Riethmüller

Meta AI’s KI-Modell Brain2Qwerty v2, das getippte Sätze aus nicht-invasiv aufgezeichneten Hirnströmen rekonstruieren kann, hat nun eine Wortgenauigkeit von 61 Prozent erreicht. Damit kommt es der Genauigkeit von Gehirn-Implantaten immer näher.

Wie die begleitende Studie im Fachjournal Nature zeigt, dekodiert das System aus Magnetoenzephalografie-Daten (MEG) mit einer durchschnittlichen Wortgenauigkeit von 61 Prozent; bei den besten Teilnehmenden sind es 78 Prozent. Mehr als die Hälfte aller Sätze enthält dabei höchstens einen Wortfehler. Das ist sicherlich noch kein alltagstaugliches Ergebnis, aber ein guter Schritt auf dem Weg dahin.

Kein Gedankenlesen – aber ein Schritt näher

Denn auf solchen Verfahren beruhen große Hoffnungen. Nach aktuellem Stand der Technik müssen für solche Anwendungen Implantate ins Gehirn gesetzt werden. Diese Geräte haben eine hohe Präzision. Ein prominentes Beispiel ist ein ALS-Patient, der ein implantiertes BCI fast zwei Jahre lang nahezu täglich zu Hause nutzte – mit 256 Kontakten im Sprachmotorkortex, einer Kommunikationsgeschwindigkeit von 56 Wörtern pro Minute und über 99 Prozent Wortgenauigkeit bei einem Vokabular von 125.000 Wörtern. Solche Systeme erfordern allerdings neurochirurgische Eingriffe mit entsprechenden Risiken wie Hirnblutungen oder Infektionen. Beim Meta-System wäre das anders.

Ein praktisches Hindernis für den breiten Einsatz bleibt jedoch aktuell noch die MEG-Technologie selbst: Die Geräte benötigen magnetisch geschirmte Räume und sind stationär – für Consumer-Anwendungen oder den häuslichen Einsatz taugen sie vorerst nicht. Erst wenn günstigere Sensorik vergleichbare Signalqualität liefert, dürfte nicht-invasive Sprachdekodierung aus dem Labor in den Alltag gelangen.

Videos by heise

Dreistufige KI-Architektur

Brain2Qwerty arbeitet als dreistufiges Deep-Learning-System. In der ersten Stufe extrahiert ein Modul Merkmale aus den EEG- oder MEG-Rohsignalen, anhand derer das Modell getippte Zeichen erkennen kann. Darauf aufbauend rekonstruiert ein Transformer-Modell die Zeichen- oder Wortfolge. In der dritten Stufe korrigiert ein vortrainiertes Sprachmodell die Roh-Ausgabe – analog zu Sprachmodellen, die bei automatischer Spracherkennung die Fehlerquote senken.

Für die Studie tippten 35 gesunde Probanden zuvor kurz memorierte Sätze auf einer QWERTY-Tastatur, während ihre Hirnaktivität per Elektroenzephalografie (EEG) oder MEG aufgezeichnet wurde. Visuelles Feedback beim Tippen gab es nicht – die Teilnehmer konnten also nicht sehen, welche Buchstaben sie eingaben.

Die Resultate auf der Grundlage von MEG-Messungen waren dabei deutlich besser als die auf EEG-Grundlage. Meta hat Code und Modelle von Brain2Qwerty als Open Source veröffentlicht.

(rie)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

software-architektur.tv: Johannes Link und der Anti-GenAI-Aktivismus

2026-07-02T10:03:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

In dieser Episode spricht Eberhard Wolff mit Johannes Link über dessen ethische Beweggründe, KI-Coding-Bots von einem Open-Source-Projekt auszusperren.

(Bild: software-architektur.tv)

12:03 Uhr

Lesezeit: 2 Min.

Developer

Von

Matthias Parbel

Johannes Link, Maintainer der Java-Test-Bibliothek jqwik, hat sich intensiv mit der ethischen Seite von GenAI auseinandergesetzt. Daher hat er im Projekt jqwik, das auf Property-basiertes Testing ausgelegt ist, Vorkehrungen gegen die Nutzung mit GenAI getroffen.

Eine einzelne Zeile Code hat daraufhin eine Debatte über die Grenzen zwischen Protest, Prompt Injection und Lieferketten-Vertrauen im Open-Source-Umfeld ausgelöst. Johannes Link hat in einem ausführlichen Blogeintrag dargelegt, warum er eine bewusst provokante Botschaft an KI-Coding-Agenten in sein Projekt einbaute – und warum er die Aktion als ethisch motivierte Selbstverteidigung versteht und nicht als PR-Gag.

In dieser Episode spricht Eberhard Wolff mit Johannes Link über den Aufschrei in Teilen der Community, der ihm öffentlichen Gegenwind, aber auch Unterstützung eingebracht hat. Link legt seine ethische Motivation dar und was er aus dem ganzen Vorfall gelernt hat.

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.

Livestream am 3. Juli

Die Ausstrahlung findet am Freitag, 3. Juli 2026, live ab 13:00 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal solo mit Wolff, Schäfer oder Müller. Seit mittlerweile mehr als zwei Jahren berichtet iX (heise Developer) über die Episoden.

(map)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Soziotechnische Architektur-Reviews: Teams verstehen, nicht nur Artefakte

2026-07-01T10:07:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Architektur-Reviews betrachten oft nur die Struktur der Software. Viel effizienter und effektiver ist es aber, den Fokus beim Review auf das Team zu legen.

(Bild: fizkes/ Shutterstock.com)

01.07.2026, 12:07 Uhr

Lesezeit: 8 Min.

Developer

Von

Eberhard Wolff

Klassische Architektur-Reviews beschäftigen sich mit dem Code: Architektur gibt dem Code schließlich Struktur. Diese Struktur ist zentral für die Änderbarkeit.

(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.

Metriken machen die Qualität dieser Struktur messbar und ermöglichen die schnelle Analyse auch großer Projekte. Ein System sollte in überschaubar große Bestandteile mit möglichst wenigen Abhängigkeiten aufgeteilt werden. Zu solchen Bestandteilen zählen Klassen, Packages (Sammlungen von Klassen in Java) oder Microservices. Die Größe der Bestandteile und die Anzahl der Abhängigkeiten kann man als Metrik messen und so die Qualität beurteilen.

Besonders schlimm sind zyklische Abhängigkeiten: Wenn beispielsweise zwei Packages wechselseitig voneinander abhängen, kann eine Änderung in einem der Packages das andere beeinflussen. Eigentlich sollten die beiden Packages also getrennt sein – in Wirklichkeit sind sie aber eins. So ein Zyklus ist eine Art „Todsünde“ in der Architektur.

Es gibt aber noch andere Metriken. Man kann auch die zyklomatische Komplexität von Methoden messen. Das ist die Anzahl der möglichen Ausführungspfade durch eine Methode. Jede Fallunterscheidung (if-Statement) ergibt einen weiteren möglichen Ausführungspfad. Mehr Ausführungspfade bedeutet, dass der Code komplexer und schwerer zu verstehen ist.

Aber treffen solche Metriken den Kern der Probleme?

Metriken haben wenig Aussagekraft

Metriken bergen fast immer Probleme. Nicht selten muss man von einem „Big Ball of Mud“ sprechen. Das ist ein System mit so schlechten Metriken, dass es eigentlich keine echte Strukturierung hat. Wenn niemand mit entsprechenden Werkzeugen die Metriken managt, ergibt sich fast immer ein unstrukturiertes System. Es ist dann trivial herauszufinden, dass ein System schlecht strukturiert ist. Wenn das so einfach ist – welchen Wert hat dieser Einblick?

Videos by heise

Es stellen sich dann eher andere Fragen:

Das Verschieben einer einzigen Klasse kann einen Zyklus auflösen. Wir haben dann eine „Todsünde“ beseitigt. Aber ist das System wirklich signifikant einfacher änderbar?
Vielleicht kommt das Team mit dem System ausreichend gut zurecht, weil es sich an die schlechte Strukturierung gewöhnt hat. Wie kann man das erfassen?
Ein System bildet eine Fachlichkeit ab. Wie hoch ist die minimale Komplexität, die für eine bestimmte Fachlichkeit benötigt wird? Wie viel überflüssige Komplexität hat das System dann?

Eigentlich interessiert uns die Änderbarkeit des Systems. Die Metriken können Hinweise auf eine gute oder schlechte Änderbarkeit geben, aber nicht mehr. Es ist durchaus denkbar, dass ein System mit schlechten Metriken dennoch ausreichend änderbar ist, weil das Team das System schon lange weiterentwickelt und sich an die Strukturierung gewöhnt hat.

Gute Metriken bedeuten auch nicht unbedingt eine gute Änderbarkeit: Wenn ein Team ein perfekt strukturiertes System ohne Übergabe und Wissenstransfer übernimmt, wird es das System dennoch nur schwer ändern können. Es gibt sogar Hinweise, dass selbst eine ausführliche und klare Dokumentation nicht ausreichend ist, um ein System sinnvoll weiterzuentwickeln, sondern das ursprüngliche Team zur Verfügung stehen muss.

Software ist ein soziotechnisches System

An diesem Punkt hilft eine andere Perspektive:

Softwaresysteme sind nicht rein technische Systeme. Sie sind soziotechnische Systeme.

Die Idee der soziotechnischen Systeme geht unter anderem auf die Untersuchung im britischen Steinkohlebergbau zurück. In diesem Bereich kann man nicht einfach nur die Maschinen und Technologien betrachten, sondern man muss die Menschen mit betrachten – und zwar als spezifische Individuen, nicht als austauschbare Ressourcen. Der Verdacht liegt nahe, dass die Betrachtung der individuellen Menschen im Bereich Softwareentwicklung noch wichtiger ist.

Orientiert man sich an dieser Idee, muss man bei Reviews anders vorgehen. Die zentrale Frage lautet dann nicht: Wie sieht die Architektur aus? Und wie gut ist sie? Wichtig sind stattdessen Fragen wie: Wie geht dieses Team mit dieser Architektur um? Welche Probleme hat es dabei?

Teams haben die Expertise für ihre Systeme

Das führt zu einem weiteren wichtigen Perspektivwechsel: Die Menschen, die täglich an einem System arbeiten, sind offensichtlich die Expertinnen und Experten für das System. Es lohnt sich, diese Expertise zu nutzen.

Interviews mit diesen Menschen werden daher zu einem zentralen Bestandteil des Review. Als Einstieg bieten sich offene Fragen an:

Was sind die Hauptstärken des Systems?
Was sind die Hauptherausforderungen?

So kann man eine Unterhaltung starten, in deren Verlauf die Expertinnen und Experten einen nahezu automatisch zu den Hauptherausforderungen des Systems führen. Wenn das Review bestimmte Herausforderungen oder Fragestellungen untersuchen soll, muss man natürlich diese Punkte in das Gespräch einfließen lassen.

Wichtig ist außerdem eine Mischung unterschiedlicher Personen als Interviewpartner. Neben denjenigen, die das System umsetzen, sind auch Benutzerinnen und Benutzer sowie andere Stakeholder relevant. Schließlich sind sie die Quelle der Anforderungen, die dem Projekt und damit der Architektur zugrunde liegen. Wenn sich die Perspektiven der verschiedenen Gruppen sehr unterscheiden, ist das ein interessantes Ergebnis. Schließlich kann das Projekt wohl kaum erfolgreich sein, wenn verschiedene Gruppen das Ziel des Projekts unterschiedlich sehen.

Architekturprobleme sind oft soziale Probleme

So führen diese Reviews zu anderen Erkenntnissen.

Ein Beispiel: In einem Review beschwerten sich viele Interviewpartner über dieselbe Architekturentscheidung. Sie wurde als katastrophal empfunden. Interessanterweise konnte aber niemand eine Alternative oder eine Idee zu einer Alternative nennen, die unter den damaligen Randbedingungen funktioniert hätte.

Die eigentliche Erkenntnis war also nicht: „Die Entscheidung war richtig oder falsch.“ Sondern: „Das Team hat diese Entscheidung nie akzeptiert.“ Das ist ein völlig anderes Problem und muss völlig anders gelöst werden.

Ergebnisse

Ein Architektur-Review sollte nicht nur Erkenntnisse produzieren. Stattdessen ergeben diese Reviews eine konkrete Liste mit nach Dringlichkeit und Wichtigkeit priorisierten Empfehlungen für Handlungen.

Manchmal beginnt die Veränderung sogar schon während der Interviews. Menschen merken, dass ihre Perspektive ernst genommen wird, Probleme ausgesprochen werden und andere ähnliche Schwierigkeiten sehen. Dadurch entsteht häufig bereits eine Änderung. Oft geht das Review dann in eine Beratung über. Die Basis für den Erfolg der Beratung hat dabei die offene Kommunikation bei den Interviews und das daraus entstehende Vertrauen gelegt.

Wenn also wie in dem bereits genannten Beispiel eine Entscheidung nicht akzeptiert worden ist, dann kann die vertrauensvolle Kommunikation helfen, die Zusammenarbeit zu verbessern. Weil alle ihre Meinung einbringen und Alternativen vorschlagen konnten, können sich die Beteiligten vielleicht eher mit der Realität abfinden oder nach echten Alternativen suchen, die den Rahmenbedingungen tatsächlich gerecht werden.

Auch in einem anderen Fall ging das Review in eine Beratung mit der Arbeit an den identifizierten Herausforderungen über, die tatsächlich das Vorgehen in dem Projekt geändert haben. Eine andere Beratung hatte vorher mit einem viel größeren Team ein Review vorgenommen und einen Foliensatz erstellt. Sicher hat der Foliensatz interessante und relevante Erkenntnisse enthalten – sie nützen nur nichts, wenn sie das Projekt nicht verbessern. Bei der Effektivität ist ein soziotechnisches Review daher oft überlegen.

Fazit

Klassische Architektur-Reviews fokussieren häufig auf technische Artefakte. Aber Software entsteht durch Menschen.

Viele Architekturprobleme sind letztlich soziale Probleme. Deshalb lohnt es sich, Architektur als soziotechnisches System zu betrachten. Dadurch dringt man schneller zu den zentralen Herausforderungen vor, weil man sich durch die Expertise der Teams leiten lassen kann, statt ungesteuert das gesamte System im Detail zu bewerten. Gleichzeitig verbessern die Interviews die Kommunikation und führen oft auch zu mehr Vertrauen – eine wichtige Voraussetzung, um zu echter Verbesserung zu gelangen. Es gibt zu soziotechnischen Architektur-Reviews auch eine Episode bei Software-Architektur im Stream und eine Webseite.

Interviews mit offenen Fragen können auch in anderen Kontexten hilfreich sein: Wenn in einem Projekt eine Situation unklar ist, helfen vertrauliche Gespräche mit offenen Fragen oft weiter. Genauso kann man den Ansatz nutzen, um in einem unbekannten Kontext wie einem neuen Projekt die beteiligten Personen besser zu verstehen und mit ihnen eine gemeinsame Basis zu finden. Um solche Gespräche durchzuführen, kann das Cheat Sheet helfen. Regeln können tatsächlich dabei helfen, besser zu kommunizieren – und das Cheat Sheet enthält dazu einige Ideen, die aus den Interviews verschiedener Reviews entstanden sind und sich dabei bewährt haben.

(rme)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Supreme Court überprüft Apples Missachtung des Epic-Gerichts

2026-06-30T22:01:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Im Streit um App-Gebühren hat Apple einem US-Gericht eine lange Nase gezeigt. Das hatte Folgen. Diese Folgen werden allerdings vom US Supreme Court überprüft.

Jeden Tag bescheren App-Gebühren Apple Millionen. Gerichtsverfahren sind vergleichsweise günstig.

(Bild: Steve Buissinne, gemeinfrei (Creative Commons CC0))

01.07.2026, 00:01 Uhr

Lesezeit: 5 Min.

Von

Daniel AJ Sokolov

Apple hat in seinem Spiel auf Zeit einen neuerlichen Etappensieg erzielt: Das US-Höchstgericht (Supreme Court of the United States, SCOTUS) nimmt einen Teilaspekt des Komplexes Epic v Apple zu Überprüfung an. Grundsätzlich geht es in dem seit fast sechs Jahren laufenden Rechtsstreit um wettbewerbsfeindliche Praktiken in Apples App Store für iOS und iPadOS. Der vom SCOTUS angenommene Teil dreht sich darum, dass Apple eine Entscheidung eines Bundesbezirksgerichts dem Geiste nach umgangen hat, indem es App-Anbietern prohibitive Gebühren verrechnet und andere nachteilige Auflagen macht.

Das hat das Bundesbezirksgericht für den Norden Kaliforniens als Missachtung des Gerichts eingestuft, was vom zuständigen Bundesberufungsgericht auch bestätigt worden ist. Doch Apple argumentiert, Missachtung sei nur bei Umgehung sehr konkreter Gerichtsbefehle möglich, nicht bei Umgehung des grundsätzlichen Tenors einer Gerichtsentscheidung. Mit diesem Vorbringen hat der Konzern das Interesse von mindestens vier der neun SCOTUS-Richter geweckt. Sie haben beschlossen, die Sache zu prüfen.

Delay, Deny, Defend

Damit gewinnt Apple weiter Zeit und kann seine Geschäftspraktiken fortführen. Frühester Termin für die mündliche Verhandlung wäre Oktober; bis zur Entscheidung könnte ein ganzes Jahr vergehen. Und dann geht die Sache womöglich zurück an ein untergeordnetes Gericht.

Apple hat in seinem App Store für iOS und iPadOS seit jeher hohe Gebühren verrechnet, typischerweise 30 Prozent aller Kundenzahlungen. Gleichzeitig untersagte Apple Umsätze außerhalb des App Store, direkte Kommunikation mit Kunden über andere Kanäle, und den Betrieb alternativer Appstores für die mobilen Apple-Betriebssysteme. Als Epic Games in seinem Spiel Fortnite Apples teures Bezahlsystem zu umgehen suchte, sperrte Apple Fortnite aus.

Daraufhin zog Epic im August 2020 vor das US-Bundesbezirksgericht für den Norden Kaliforniens. Dieses entschied im September 2021, dass Apples Bestimmungen zwar nicht gegen Monopolrecht des Bundes, wohl aber gegen ein kalifornisches Gesetz gegen Unlauteren Wettbewerb verstoßen. Das Gericht trug Apple auf, Hyperlinks aus Apps auf externe Webseiten mit unabhängigen Bezahlsystemen zu erlauben.

Videos by heise

Apple berief erfolglos, und konnte auch den Supreme Court nicht zu einer weiteren Überprüfung gewinnen. Schließlich gelobte der Konzern, sich an die rechtskräftigen Auflagen zuhalten.

Extreme Gebühren und andere Fallen

Tatsächlich legte Apple sein neues System jedoch so an, dass niemand es nutzen würde: Erlaubt ist darin nur ein einzelner Hyperlink, der nicht als solcher erkennbar sein darf. Die aufgerufene Seite darf keine Informationen über den Kunden oder sein Konto übernehmen, sondern muss das neu abfragen. Dazu kommen abschreckende Einblendungen und eine Gebühr von 27 Prozent aller Umsätze. Weil der Betrieb eines externen Bezahlsystems auch etwas kostet, und Finanzdienstleister Gebühren erheben, wäre der Umsatz außerhalb des App Store noch teurer als die 30 Prozent direkt im App Store.

Die Sache war also prohibitiv, was, wie sich später vor Gericht herausgestellt hat, Absicht war. Nebenbei schloss Apple alle Teilnehmer seines Video Partner Program und seines News Partner Program generell von externen Umsätzen aus. Eine sachliche Grundlage dafür ist nicht erkennbar.

Epic musste wieder das Bundesbezirksgericht anrufen. Dieses prüfte Apples Vorgehen ausführlich und hörte mehrfach Zeugen, bis es schließlich auf Missachtung des Gerichts entschied. Apples Argument, die ursprüngliche Gerichtsentscheidung hätte die gesetzten Maßnahmen nicht konkret verboten, zog nicht.

Missachtung des Gerichts

Das Bezirksgericht erließ diesmal detailliertere Auflagen, darunter ein absolutes Verbot von Gebühren für außerhalb des App Store anfallende Umsätze – nicht nur gegenüber Epic, sondern gegenüber allen App-Anbietern im US App Store. Apple berief erneut. Bundesberufungsgericht befand Ende 2025 (Az. 25-2935), dass Teile der neuen Auflagen zu streng seien: Beispielsweise dürfe Apple sehr wohl Gebühren für externe Umsätze berechnen, bloß nicht in prohibitiver Höhe.

Grundsätzlich habe das Bezirksgericht jedoch zulässig festgestellt, dass Apple durch sein Vorgehen das Gericht missachtet habe. Zwei Gerichtsauflagen habe Apple dem Buchstaben nach verletzt, zwei weitere dem Geiste nach.

Von 2 Themen wird 1 verhandelt

Gegen diese Entscheidung des Bundesberufungsgerichts hat Apple den Supreme Court angerufen und ihm zwei Fragen zur Erörterung vorgeschlagen: Erstens, ob Missachtung des Gerichts überhaupt gegeben sein könne, wenn eine Entscheidung nur ihrem Geiste nach umgangen werden, nicht aber ihren Buchstaben nach. Diese Frage hat das Höchstgericht am Dienstag angenommen.

Zweitens wollte Apple diskutieren, ob das Bundesbezirksgericht überhaupt landesweite Verbote, gestützt auf das Recht eines US-Staates, aussprechen darf, die auch Personen betreffen, die am Verfahren gar nicht beteiligt sind (hier: alle Anbieter von Apps im App Store). Diese Frage hat das Höchstgericht nicht angenommen. Es begründet seine Entscheidungen über Annahme oder Nichtannahme generell nicht.

Das Verfahren vor dem Supreme Court heißt Apple v Epic Games und trägt das Az. 25-1311. Das US-Bundesbezirksgericht für den neunten US-Gerichtskreis führt Epic Games v Apple unter den Az. 21-16506 und 21-16695, während das Bundesbezirksgericht Epic Games v Apple unter 4:20-cv05640 veraktet.

Die angefochtene Berufungsentscheidung des Ninth Circuit , Az. 25-2935
Apples teilweise erfolgreicher Antrag an den Supreme Court , Az. 25-1311

Lesen Sie auch

Copyright: US Supreme Court hebt Milliarden-Urteil wegen Filesharing auf

US-Urteil erschüttert das Fundament des transatlantischen Datentransfers

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Amazons KI-ler machen Hausbesuche: Forward Deployed Engineering

2026-06-30T19:36:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Forward Deployed Engineers ist das neue Milliarden-Buzzword: Sie helfen Kunden vor Ort bei Erstellung und Integration von KI-Agenten.

(Bild: Shutterstock)

30.06.2026, 21:36 Uhr

Lesezeit: 2 Min.

iX Magazin

Von

Daniel AJ Sokolov

Amazon.com bietet nun die vorübergehende Einbettung eigener Mitarbeiter bei großen Kunden der Amazon Web Services (AWS) an. Sie sollen bei den Kunden KI-Agenten zusammenstellen und installieren, die dann AWS-Dienste nutzen. Diese Hausbesucher nennt Amazon Forward Deployed Engineers (FDE), eine von Palantir übernommene Marketingbezeichnung.

Ziel ist natürlich, den Absatz zu beschleunigen, aber auch Kunden an AWS zu binden. Sind die KI-Agenten erst einmal tief in der IT einer großen Organisation integriert, wird der Wechsel zu einem Mitbewerber aufwändig und damit teuer. Speziell in sensiblen Bereichen wie Behörden, Geldinstituten und streng regulierten Branchen wie dem Finanzwesen sollen die AWS-FDEs eingebettet werden.

Am Anfang steht regelmäßig der Aufbau sogenannter knowledge graphs; die beim jeweiligen Kunden vorhandenen Informationen werden so zusammengestellt, dass die AWS-Agenten sie leicht verarbeiten können. Nicht zuletzt soll das menschliche Mitarbeiter leichter ersetzbar machen: Die „Expertise lebt im Code des Kunden, nicht in Organisationswissen, das ausscheiden kann“, formuliert AWS-Vizepräsidentin Francessca Vasquez.

Amazon: „Kein traditionelles Consulting”

Amazon richtet bei AWS eine eigene FDE-Abteilung ein und nimmt dafür nach eigenen Angaben eine Milliarde US-Dollar in die Hand. Die FDEs sollen weltweit tätig werden, auch im deutschen Sprachraum, wie das Unternehmen gegenüber heise online bestätigt hat. Konkrete Angaben zur Gebührenstruktur macht Amazon bislang nicht. Sie soll sich jedoch auf „business outcomes and deliverables” konzentrieren, nicht auf verrechnete Mannstunden oder traditionelle Consulting-Vergütungen.

Videos by heise

AWS FDE richtet sich an große Kunden, die über KI-Experimente hinaus sind und KI für echte Geschäftsprozesse einsetzen möchten. Der Datenkonzern verspricht, dass das FDE-System nicht auf Abhängigkeit, sondern auf Selbstständigkeit der Kunden abstelle. Mit Fortschritt des jeweiligen Projekts würden die IT-Mitarbeiter des Kunden schrittweise von Beobachtern zu Teilnehmern und schließlich zu selbstständigen Betreibern der KI-Agenten.

Erstkunden des FDE-Angebots sind den Angaben zufolge Ricoh, eine amerikanische Fluggesellschaft, zwei amerikanische Sportligen, Cox Automotive und das Allen Institute. Letzteres ist eine von Microsoft-Mitgründer Paul Allen und seiner Frau Jody gegründete neurowissenschaftliche Forschungseinrichtung.

Lesen Sie auch

Nach Kündigungswelle: US-Behörden suchen dringend Tech-Experten

Oracle hat über 21.000 Stellen gestrichen

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

.NET-Grafiken: SkiaSharp 4 mit Engine-Upgrade erschienen

2026-06-30T11:01:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

SkiaSharp zur 2D-Grafikerstellung in .NET bietet im neuen Release Beschleunigungen durch eine aktualisierte Engine.

(Bild: Sergey Nivens / Shutterstock.com)

30.06.2026, 13:01 Uhr

Lesezeit: 2 Min.

Developer

Von

Maika Möbus

Zwei Jahre Arbeit sind in das neu erschienene SkiaSharp 4.148.0 geflossen. Dabei handelt es sich um die erste stabile 4.x-Version der Cross-Platform-2D-Grafik-API für .NET-Plattformen, die auf Googles Skia-Graphics-Bibliothek basiert. Sie bringt eine überarbeitete Engine für verbesserte Grafiken sowie erhöhte Performance.

SkiaSharp wird vom .NET-Team in Partnerschaft mit dem Uno-Platform-Team entwickelt und kommt in .NET MAUI, WebAssembly, WinUI 3 und Frameworks wie Uno Platform zum Einsatz.

(Bild: King / stock.adobe.com)

Das ist neu in .NET: Die Online-Konferenz betterCode() .NET 11.0 präsentiert am 17. November 2026 die zentralen Änderungen für Entwicklerinnen und Entwickler. Bis zur Veröffentlichung des Programms sind vergünstigte Blind-Bird-Tickets verfügbar.

Upgrade für die Engine

Die in SkiaSharp 4 auf den Chrome-Meilenstein m148 aktualisierte native Skia-Engine soll sich positiv auf bestehende Apps auswirken, ohne Codeänderungen zu erfordern. Unter anderem soll sie die Performance verbessern sowie für schärfere herunterskalierte Grafiken, automatische Fotoausrichtung und akkuratere Farben sorgen. Wie Microsoft in der Ankündigung betont, zeigen erste Tests im Vergleich zur vorherigen SkiaSharp-Version 3.119 ein um bis zu 24 Prozent schnelleres Rendering zentraler App-UI-Bestandteile, wie Schlagschatten und mehrschichtige Oberflächen. Dabei treten laut den Tests an anderen Stellen keine Regressionen auf.

Videos by heise

Aufgeräumt und mit neuen Fähigkeiten

SkiaSharp 4 räumt darüber hinaus mit Legacy-APIs auf und behebt unter der Haube die Ursache für eine Klasse von Use-After-Free-Abstürzen durch einen neuen Umgang mit Singleton-Objektlebenszyklen. Daneben hat das Entwicklungsteam die Test-Suite auf xUnit 3 aktualisiert und jede gebundelte native Dependency mit den neuesten Security-Fixes versehen. Als ein neues Feature ist nun vollständige Kontrolle über OpenType-Variablen-Schriftachsen enthalten, ebenso wie animiertes WebP-Encoding mit SKWebpEncoder sowie Farbpaletten für Emoji- und Icon-Schriftarten.

Die interaktive SkiaSharp-Galerie zeigt die Möglichkeiten mit Blazor WebAssembly und Uno Platform. Beispiele mit .NET MAUI und weiteren Technologien sollen folgen.

SkiaSharp 4.148.0 steht beim .NET-Paketmanager NuGet unter MIT-Lizenz zum Download bereit. Weitere Informationen zur neuen stabilen Version

(mai)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Software Testing: Positives Führen – Was dahinter steckt und was nicht

2026-06-30T06:30:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Was positives Führen bedeutet und mit welchen konkreten Maßnahmen man es umsetzen kann, besprechen Richard Seidl und Christian Thiele.

(Bild: Richard Seidl)

30.06.2026, 08:30 Uhr

Lesezeit: 2 Min.

Developer

Von

Richard Seidl
Christian Thiele

Positives Führen hat nichts mit Ponyhof zu tun – das ist einer der ersten Sätze, die Christian Thiele im Gespräch mit Richard Seidl sagt, und bringt damit das Thema direkt auf den Punkt. Die beiden sprechen darüber, was hinter dem PERMA-Modell steckt: fünf konkrete Stellschrauben, mit denen Führung im Alltag greifbar wird, von positiven Emotionen über psychologische Sicherheit bis hin zum bewussten Feiern von Erfolgen. Es kommt auch zur Sprache, warum Leadership keine Frage der Rolle ist und was passiert, wenn man den besten Entwickler zum Projektleiter macht, nur weil Karriere bisher immer über Führung lief.

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.

„Niemand weiß so richtig, wer eigentlich wirklich wem was zu sagen hat und welche Konsequenzen das hat.“ – Christian Thiele

Empfohlener redaktioneller Inhalt

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

Christian Thiele ist Experte für Positive Leadership und unterstützt Führungskräfte, Teams und Organisationen mit Coachings, Trainings, Vorträgen, Teamentwicklungen und Konfliktklärungen. Zunehmend ist er auch im Hochschulkontext tätig, unter anderem als Standortleiter München-Ismaning im Studiengang „Positive Psychologie und Coaching“ an der Deutschen Hochschule für Sport und Gesundheit. Mit Haltung und Methoden der Positiven Psychologie möchte er dazu beitragen, dass Einzelne und Gruppen mehr Erfolg, mehr Kreativität, mehr Sinnhaftigkeit und mehr Freude in der Arbeit erleben. Gleichzeitig unterstützt er Menschen und Organisationen dabei, weniger Frust zu erleben, Stress besser zu bewältigen und leichter vom Krach zur Kooperation zu kommen.

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, die die Qualität in der Softwareentwicklung steigern.

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

(mai)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Chinas GLM-5.2 erreicht Anthropics Opus 4.8 bei der Schwachstellensuche

2026-06-29T15:46:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Zhipu AIs offenes Modell GLM-5.2 erreicht laut Sicherheitsexperten die Fähigkeiten von Anthropics Opus 4.8 bei der Bug-Erkennung.

Internationales Wettrennen um KI-Hackingfähigkeiten

(Bild: Herr Loeffler / Shutterstock.com)

29.06.2026, 17:46 Uhr

Lesezeit: 2 Min.

Security

Von

Carolin Riethmüller

Der chinesische KI-Anbieter Z.ai hat mit GLM-5.2 ein Open-Weight-Modell veröffentlicht, das sich bei der Erkennung von Sicherheitslücken offenbar mit Anthropics Opus 4.8 messen kann.

Das haben IDOR-Benchmark-Tests der Cybersicherheitsfirma Semgrep ergeben. Da es sich um ein Open-Weight-Modell handelt, kann jeder GLM-5.2 herunterladen, lokal betreiben und modifizieren. Das eröffnet für Hacker weitere Möglichkeiten für kriminelle Einsätze.

Open Weight als Chance und Risiko

Die offene Verfügbarkeit von GLM-5.2 ist ein zweischneidiges Schwert. Sicherheitsfirmen, CERTs und interne Red Teams können das Modell in abgeschotteten Umgebungen für Code-Reviews und Penetrationstests nutzen, ohne sensible Daten an US-Clouds zu übermitteln. Für DSGVO-konforme Umgebungen in Europa ist das ein Vorteil.

Gleichzeitig können auch Angreifer GLM-5.2 ohne jede Aufsicht betreiben. Diese Eigenschaft macht das Modell attraktiv für Akteure, die nach Schwachstellen in kritischen Systemen suchen wollen. Lior Div, Chef der Cybersicherheitsfirma 7AI, fasste die Lage gegenüber dem Wall Street Journal zusammen: China sorge dafür, dass der Abstand zu den US-KIs "immer kleiner" werde.

Zhipu AI selbst räumt in den Release Notes ein, dass GLM-5.2 während des Reinforcement-Learning-Trainings verstärkt sogenanntes Reward Hacking zeigte. Das Unternehmen habe daraufhin spezielle Anti-Hacking-Sicherungen für das Training und die Evalution des Modells integriert.

Geopolitische Dimension: USA unter Zugzwang

Die Entwicklung trifft die US-Regierung in einem heiklen Moment. Eines von Anthropics Modellen war kurzzeitig komplett gesperrt, weil die Trump-Administration den Zugriff durch ausländische Nutzer untersagte. Auch OpenAI bekommt von der US-Regierung Auflagen „aus Sicherheitsgründen“.

Für europäische Unternehmen und Behörden stellt sich mit der wachsenden Leistungsfähigkeit der KI-Modelle die Governance-Frage: Wie lässt sich der Einsatz solcher Werkzeuge in sicherheitskritischen Bereichen mit dem EU AI Act und nationalen Sicherheitsvorgaben vereinbaren – und wie geht man mit einem Modell um, das beim Schwachstellen-Finden brilliert, aber keiner Aufsicht unterliegt?

(rie)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

So würde eine KI als Start-up-Chef abschneiden

2026-06-29T14:52:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Princeton-Forscher lassen KI-Modelle 500 Tage ein Start-up führen. Nur drei schaffen es ins Plus – eine simple Wirtschafts-Weisheit ist besser als fast alle.

(Bild: kung_tom/Shutterstock.com)

29.06.2026, 16:52 Uhr

Lesezeit: 5 Min.

Von

Carolin Riethmüller

Forscher der Princeton University haben mit CEO-Bench einen neuen Langzeit-Benchmark vorgelegt, der KI-Agenten vor eine ungewöhnliche Aufgabe stellt: Sie sollten 500 Tage lang ein fiktives Software-Start-up führen. Das Ergebnis fällt für die aktuellen Modelle ernüchternd aus. Von zehn getesteten KI-Modellen schafften es lediglich drei, am Ende mehr Geld auf dem Konto zu haben als das Startkapital von einer Million US-Dollar. Zum Vergleich: Daten zu menschengeführten Start-ups in den USA legen nahe, dass ein Fünftel aller Start-ups im ersten Jahr und bis zu 65 Prozent der Start-ups innerhalb von zehn Jahren nach ihrer Gründung scheitern.

Als Vergleich im Benchmark-Test ließen die Forscher auch einen handkodierten, regelbasierten Agenten ganz ohne maschinelles Lernen die gleiche Aufgabe absolvieren. Abgesehen von den drei Gewinnern performte er besser als die KI-Modelle.

Die in der auf arXiv veröffentlichten Studie mit der beschriebenen Simulation dreht sich um ein Start-up namens „NovaMind“. Die KI-Agenten starten ohne Kunden und mit einer Million Dollar. Fällt der Kontostand unter null, ist die Firma insolvent – und das Spiel vorbei. Um ihr Start-up zu führen, stehen den Agenten 34 Werkzeuge zur Verfügung: von Preisfestlegung über Produktgestaltung bis hin zu Marketing. Als Input bekommen sie unter anderem „unternehmensinterne“ Datenbanken, Informationen zu Kundengruppen mit Präferenzen, die erst entschlüsselt werden müssen, und einen Markt, der sich laufend verändert. Konjunkturzyklen, Druck durch Wettbewerber und Änderung der Marktlage inklusive. Die Modelle müssen unübersichtliche, miteinander vernetzte Unternehmensdatenbanken analysieren, Daten und Ereignisse in fundierte Strategien übersetzen und zahlreiche Entscheidungen aufeinander abstimmen. Wie die Autoren der Studie betonen, messen sie damit nicht die Fähigkeit, isolierte Aufgaben abzuarbeiten, sondern das, was sie „Steering Intelligence“ nennen: die Kompetenz, ein komplexes System über längere Zeit trotz Unsicherheiten zu steuern.

Nur Claude Opus 4.8 und GPT-5.5 schaffen den Sprung

In der Hauptauswertung absolvierten alle Modelle jeweils drei Durchläufe. Als Leistungsmaß dient der beste Run pro Modell. Claude Opus 4.8 erzielte dabei ein End-Guthaben von rund 27,8 Millionen US-Dollar nach 500 Tagen, GPT-5.5 kam auf etwa 21,3 Millionen. Beide Modelle landeten damit in ihrer besten Runde deutlich oberhalb des Startkapitals – in den anderen beiden Runden lagen sie darunter und „bestanden“ den Test ebenfalls nicht. Claude Fable 5 schaffte laut der CEO-Bench-Projektseite in einem Lauf rund 47 Millionen Dollar; hier lief der Test jedoch zwischenzeitlich mit Opus, da Fable sich aufgrund seiner starken Sicherheitseinschränkungen immer mal wieder Aufgaben verweigerte.

Die übrigen Modelle blieben entweder unter dem Startkapital oder gingen bankrott. Claude Opus 4.7 überlebte zwar in allen Läufen die kompletten 500 Tage, endete aber mit nur rund 390.000 Dollar. Grok 4.20 hielt es im besten Fall gerade einmal 37 Tage durch, DeepSeek V4 Pro maximal 176 Tage.

Videos by heise

Unterschiedliche Strategien, hohe Varianz

Die erfolgreichen Modelle gingen für ihren Erfolg sehr unterschiedlich vor. Claude Opus 4.8 verfolgte in einem Run eine radikale Harvesting-Strategie: zunächst aggressiver Kundenaufbau, dann drastische Kostenschnitte – am Ende stand eine hohe Cash-Bilanz bei null aktiven Kunden. Ziel erreicht, im echten Leben wäre das jedoch nichts wert gewesen. GPT-5.5 setzte hingegen auf einen dauerhaften Kundenstamm und investierte rund 89 Prozent seines Entwicklungsbudgets in gruppenspezifische Verbesserungen. Beide Modelle schrieben eigenständig Code-Dateien: Opus 4.8 baute eine kohortenbasierte Cash-Prognose, GPT-5.5 analysierte Verhandlungshistorien, um Kundenpräferenzen abzuleiten.

Die Varianz zwischen den Läufen desselben Modells ist ebenfalls groß. GPT-5.5 zum Beispiel schwankte zwischen frühen Bankrotten nach 77 Tagen und einem vollständigen 500-Tage-Lauf. Einzelne Runs liefern daher kein stabiles Leistungsbild. Selbst in einer auf 50 Tage verkürzten Variante scheiterten die meisten Agenten – was nahelegt, dass nicht nur der lange Horizont, sondern die grundsätzliche Entscheidungskoordination unter Unsicherheit ein Problem für sie darstellt.

Abstand zum theoretischen Optimum bleibt gewaltig

Das Ergebnis passt ins Bild aktueller Forschung zur Langzeit-Kompetenz von KI-Modellen. Im Projekt „Emergence World“ durften Modelle wie ChatGPT, Grok, Claude und Gemini simulierte Städte regieren – mit teils bizarren Resultaten: Gemini 3 Flash schuf eine Hochkriminalitäts-Welt, Claude Sonnet 4.6 baute einen nahezu konfliktfreien „Ponyhof“. Auch dort zeigte sich, dass die Modelle in offenen Langzeit-Szenarien zu unvorhersehbarem Verhalten neigen. Man muss allerdings bei beiden Simulationen anfügen: Die getesteten KIs waren keine Weltmodelle, sondern überwiegend Reasoning-Modelle, die mutmaßlich nicht ideal für solche Aufgaben sind.

(rie)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Git grafisch mit KI sortieren und verwalten – GitBrowser

2026-06-29T11:39:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit GitBrowser lassen sich Git-Repos mit KI-Hilfe grafisch sortieren und partiell, anhand der Einteilung committen – auch nur mit Teilen von Dateien.

(Bild: Wolf Hosbach / KI / iX)

29.06.2026, 13:39 Uhr

Lesezeit: 2 Min.

Developer

Von

Wolf Hosbach

Die neue Version der grafischen Git-Verwaltung GitBrowser analysiert alle Dateiänderungen in einem Repo, sortiert sie in zusammenpassende Gruppen und benennt diese. So bekommen Anwenderinnen und Anwender einen schnellen Überblick über alle Änderungen, die sie oder ein Trupp von KI-Agenten gemacht haben. Die nach Themen sortierten Änderungsgruppen können sie dann separat stagen und commiten.

Partielles Committen von Diff-Inhalten

Für diese Funktion, Change Set Analysis, verwendet GitBrowser den hauseigenen Coding-Assistenten CodeBot, der sich an Claude, Gemini oder OpenAI anbinden lässt. Eine Besonderheit der Funktion ist, dass sie Themen auch innerhalb einer Datei erkennt und nur diesen Teil der Bühne übergibt, wenn der Anwender diesen Gliederungspunkt commiten will. Anwenderinnen und Anwender klicken in der Dateiliste auf „Analyze Changesets with CodeBot“ und erhalten die gegliederte Übersicht.

GitBrowser gliedert mit KI-Hilfe die anstehenden Änderungen nach Themen.

(Bild: GitBrowser)

Einzelne Dateien lassen sich anklicken und dann mit Diff untersuchen, wobei nur die zum Thema passenden Abschnitte zu sehen sind. Auch beim manuellen Commiten, ohne KI-Hilfe, können Anwender einzelne Teile einer Diff-Ansicht zum Stagen wählen.

Auch in der manuellen Diff-Ansicht lassen sich auch nur einzelne Abschnitte stagen und committen.

(Bild: GitBrowser)

Neu ist ferner eine umfassende Unterstützung für Worktrees, die sich im Tool wie normale Checkouts verwenden lassen, inklusive Commit, Push oder Merge. Auch hier funktioniert die Change Set Analyse mit CodeBot zwischen zwei Worktrees.

Videos by heise

Das im November 2025 vorgestellte Tool ist kostenlos, aber für die KI-Funktionen benötigen Anwender ihre eigenen Modell-Keys. Neben der Mac-Version ist in Kürze eine Beta für Windows angekündigt.

(who)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Neue Allianz für mehr Open-Source-Schutz

2026-06-29T10:37:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Linux Foundation und Tech-Giganten starten Akrites, um Open-Source-Sicherheitslücken zentral und vertraulich zu beheben.

(Bild: heise medien)

29.06.2026, 12:37 Uhr

Lesezeit: 3 Min.

iX Magazin

Von

Moritz Förster

Die Linux Foundation hat gemeinsam mit zahlreichen Tech-Unternehmen und Finanzinstituten die Initiative Akrites gestartet. Ziel ist es, den Umgang mit Sicherheitslücken in wichtiger Open-Source-Software zentral zu koordinieren, sie vertraulich mit den jeweiligen Projektverantwortlichen zu beheben und erst anschließend offenzulegen. Hintergrund ist die wachsende Sorge, dass moderne KI-Modelle Schwachstellen deutlich schneller finden als bisher und damit den Zeitdruck für Verteidiger erheblich erhöhen.

Zu den Gründungsmitgliedern gehören unter anderem Amazon Web Services, Anthropic, Cisco, Google, IBM, Microsoft, GitHub, Nvidia, OpenAI, Red Hat sowie JPMorganChase, Citi und Vodafone. Die beteiligten Unternehmen wollen Personal, Sicherheitswissen und finanzielle Mittel bereitstellen.

Reaktion auf KI-gestützte Schwachstellenanalyse

Nach Angaben in der Ankündigung der Linux Foundation verändert generative KI die Sicherheitslandschaft grundlegend. Während die Suche nach schwerwiegenden Sicherheitslücken bislang viel Fachwissen und oft Wochen an Analyse erforderte, könnten leistungsfähige KI-Modelle große Open-Source-Projekte inzwischen innerhalb weniger Minuten auf potenzielle Schwachstellen untersuchen. Dadurch verkürze sich die Zeit zwischen dem Auffinden einer Lücke und ihrer möglichen Ausnutzung erheblich.

Akrites soll diese Entwicklung mit einem gemeinsamen Sicherheitsprozess beantworten. Statt dass mehrere Unternehmen dieselbe Schwachstelle unabhängig voneinander melden oder unterschiedliche Patches entwickeln, bündelt die Initiative die Koordination. Kern des Projekts sind ein gemeinsames Security Incident Response Team (SIRT) sowie ein einheitlicher Prozess zur koordinierten Offenlegung von Sicherheitslücken (Coordinated Vulnerability Disclosure, CVD). Die beteiligten Organisationen wollen bestätigte Schwachstellen gemeinsam mit den Upstream-Maintainern beheben, bevor Details veröffentlicht werden.

Maintainer sollen entlastet werden

Ein Schwerpunkt liegt auf der Zusammenarbeit mit den Entwicklern der betroffenen Open-Source-Projekte. Laut Linux Foundation sollen Fehlerbehebungen grundsätzlich in die Originalprojekte zurückfließen. Maintainer behalten die Kontrolle über ihre Projekte und sollen nicht mit mehrfachen oder widersprüchlichen Sicherheitsmeldungen belastet werden.

Für Pakete, die nicht mehr aktiv gepflegt werden, sieht Akrites zudem eine Rolle als „Maintainer of Last Resort“ vor. In solchen Fällen soll die Initiative Korrekturen für aktuelle Versionen bereitstellen, damit kritische Sicherheitslücken auch dann geschlossen werden können, wenn ursprüngliche Entwickler nicht mehr verfügbar sind.

Videos by heise

Aufbau auf bestehenden Sicherheitsstandards

Technisch setzt Akrites auf etablierte Verfahren und Standards der IT-Sicherheitsbranche. Dazu zählen unter anderem CVE zur Identifikation von Schwachstellen, CVSS zur Bewertung ihrer Schwere sowie CWE zur Klassifizierung von Schwachstellentypen. Dadurch soll sich die Initiative in bestehende Prozesse von Softwareherstellern, Sicherheitsforschern und Betreibern kritischer Infrastruktur einfügen.

Die Anschubfinanzierung übernimmt Alpha-Omega, ein Förderfonds der Linux Foundation für Open-Source-Sicherheit. Weitere Unternehmen und Organisationen können sich beteiligen, indem sie Entwicklerkapazitäten oder finanzielle Mittel bereitstellen. Parallel zum Start hat die Initiative einen offenen Brief veröffentlicht, in dem die Gründungsmitglieder zu einer gemeinsamen Absicherung der Open-Source-Infrastruktur aufrufen.

(fo)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

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

2026-06-27T07:18:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kleine, aber interessante Meldungshäppchen vom News-Buffet zu Slint, VS Code, Spring Boot, Next.js, Vaadin, curl, Stack Overflow, Drupal und Rust.

(Bild: Natalia Klenova / Shutterstock.com)

27.06.2026, 09:18 Uhr

Lesezeit: 3 Min.

Developer

Von

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

Slint 1.17 nähert sich der Produktionsreife, was die Entwicklung von Desktopanwendungen betrifft. Das in Rust geschriebene UI-Toolkit bietet nun unter anderem Unterstützung für Drag-and-Drop-Interaktionen, ebenso wie für System-Tray-Icons.
In Visual Studio Code 1.126 erhalten Developer eine bessere Kostenkontrolle: Sie können nun die Kosten für eine gesamte Chat-Session einsehen. Im Agents Window, das sich weiterhin in der Preview-Phase befindet, kann eine Copilot-Session im neuen Release mehrere Chats mit getrennten Konversationen enthalten.
Version 3.5.16 von Spring Boot bringt neben Bugfixes auch Dependency-Updates für AMQP, Data BOM und Spring Integration. Gleichzeitig ist es die letzte 3.5.x-Version des Java-Frameworks, die noch OSS-Support erhält.

(Bild: ipopba / stock.adobe.com)

KI in der Produktentwicklung: Der Product Owner AI Day am 9. Juli 2026 zeigt Produktverantwortlichen, wie künstliche Intelligenz Prozesse automatisiert und zu besseren Produktentscheidungen verhilft. Tickets für Konferenz und Workshop im Onlineshop verfügbar.

Next.js 16.3 (Preview) bietet Neuerungen wie Instant Navigations für sofortige, SPA‑ähnliche Seitenwechsel sowie ein effizienteres Partial Prefetching. Die stabile Version des React‑Frameworks soll in den kommenden Wochen erscheinen. Next.js 16 ist seit Oktober 2025 als stabile Version verfügbar.
Drei Hauptneuheiten zeichnen das Java‑Framework Vaadin 25.2 aus: KI-Werkzeuge lassen sich in Datenansichten einsetzen, native Browserfunktionen aus Java aufrufen und bestehende End‑to‑End‑Tests in Lasttests umwandeln.
Mit mehr als 250 Bugfixes legt curl 8.21.0 den Fokus auf Sicherheit und Stabilität. Dennoch sind auch neue Features enthalten, etwa Named Globs, neue HTTP/3-Funktionen sowie die Entfernung des Stream-Dependency-Trackings bei HTTP/2.

Lesen Sie auch

KI-Basis entwickeln: Die Architektur smarter Systeme

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

KI-Hype vs. Realität: Warum Technologie allein nicht reicht

2026-06-27T07:05:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Warum der Erfolg von KI in der Praxis vom Zusammenspiel zwischen Mensch und Technik abhängt, erklärt Michael Zimmer in seiner Keynote von der data2day 2025.

(Bild: sdecoret / shutterstock.com)

27.06.2026, 09:05 Uhr

Lesezeit: 3 Min.

Developer

Von

Matthias Parbel

In seiner Keynote auf der data2day 2025 stellt Dr. Michael Zimmer den Menschen ins Zentrum der KI-Transformation – nicht die Technologie. Unter dem Leitgedanken „V³ – Verständnis, Vertrauen und Verantwortung“ zeigt er auf, dass KI in der Unternehmenspraxis weit mehr erfordert als technische Implementierung. Am Beispiel Klarna illustriert er, wie Unternehmen zunächst massiv auf KI-gestützte Automatisierung setzten und Personal abbauten, nur um später festzustellen, dass menschlicher Kundenkontakt unersetzlich ist. Eine MIT-Sloan-Studie untermauert zwar Produktivitätssteigerungen von bis zu 42 % bei Einzelaufgaben – in der Gesamtbetrachtung sei jedoch keine signifikante Veränderung messbar. Zimmer warnt vor dem Reflex, KI als Universallösung für strukturelle Probleme wie unübersichtliche Dokumentenablagen oder fehlerhafte Prozesse einzusetzen, und bringt es auf den Punkt: „Shit in, shit out“ – ohne saubere Daten und Prozesse liefert auch KI keine brauchbaren Ergebnisse.

Befähigung statt Angstmache: Der Mensch als Erfolgsfaktor

Für Data Teams besonders relevant ist Zimmers Analyse der unterschiedlichen Mitarbeitertypen im KI-Kontext: von der erfahrenen Fachkraft, die KI-Trainings konzipiert, über das „Spielkind“, das ohne Governance eigene Lösungen baut, bis zum ängstlichen Kollegen, der erst „abgeholt“ werden muss. Die W&W-Gruppe begegnet dem mit einem breit angelegten Enablement-Programm: 500 Mitarbeitende wurden in Präsenz geschult, eine Konzernbetriebsvereinbarung (KBV) erarbeitet, und Betriebsrat und Vorstand ziehen bewusst an einem Strang. Das konkrete Praxisbeispiel „Reggi“ – ein KI-Assistent zur Regresserkennung in der Kfz-Schadenbearbeitung – zeigt, wie ein gelungenes Zusammenspiel aussieht: Die KI übernimmt die zeitaufwendige Dokumentenprüfung, die finale Bewertung bleibt beim Menschen.

Governance, Regulierung und die Rolle von Data Teams

Zimmer betont in seinem Vortrag, dass erfolgreiche KI-Einführung Domänenwissen, Nähe zwischen IT und Fachbereich, klare Standards für Plattformen und Integrationsmuster sowie eingespielte Entwicklungs- und Deployment-Prozesse benötigt. Hinzu kommen die regulatorischen Anforderungen: Der EU AI Act (in Kraft seit August 2024, für die meisten Regelungen gültig ab August 2026, für bestimmte Hochrisiko-KI-Bereiche erst ab August 2027) verlangt von Finanzkonzernen einen risikobasierten Ansatz mit konkreten Prüfschemata. Sein Fazit für Data Scientists und Engineers: „Wir übernehmen das Denken, die KI erledigt die Ausführung, wir kümmern uns um die Validierung und Interpretation.“ Im aktuellen LLM-Hype sei Expertenwissen wichtiger denn je – und duale/integrierte Studienmodelle bekämen eine entscheidende Rolle, um diese Kompetenzbrücke zwischen Fachlichkeit und Technologie zu schlagen.

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.

Dr. Michael Zimmer ist Chief Data & AI Officer und Leiter des Kompetenzzentrums für KI in der W&W-Gruppe. Er hat über Agilität von Datenarchitekturen promoviert und war unter anderem als CDO der Zurich Gruppe Deutschland und mehr als 13 Jahre in der Beratung tätig. Er ist Herausgeber und Autor diverser Bücher und unter anderem TDWI Fellow, männlicher Alliierter der Women Leaders in Data and AI (WLDA) sowie Mitglied der Arbeitsgruppe Ethical AI der deutschen Aktuarsvereinigung.

Vom 7. bis 8. Oktober 2026 bietet die data2day in Köln ein umfassendes Programm zu Data Science, Data Engineering und Data Analytics. Ein besonderer Fokus liegt auf Agentic AI und Analytics, modernen Datenarchitekturen, rechtlichen Aspekten und Einblicken in die Unternehmenspraxis.

Ab sofort sind Tickets zum Frühbucherpreis verfügbar.

(map)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Xcode 26.6: Google Gemini zieht als Programmierassistent in Apples IDE ein

2026-06-26T15:08:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit Xcode 26.6 bringt Apple Google Gemini direkt in die Entwicklungsumgebung. Die Integration war bereits in Xcode 27 beta aufgetaucht, das noch weiter geht.

In Xcode 27 wird neben Claude Agent und OpenAI Codex auch Google Gemini direkt in der IDE verankert. Doch Entwickler müssen nicht bis Herbst warten. Gemini wurde jetzt auch in Xcode 26.6 eingebaut.

(Bild: Apple)

26.06.2026, 17:08 Uhr

Lesezeit: 4 Min.

Mac & i

Von

Malte Kirchner

Apples Entwicklungsumgebung Xcode bietet jetzt auch Google Gemini als Programmierassistent direkt in der IDE an. Mit der frisch erschienenen Version 26.6 müssen Entwickler dafür nicht bis zum Herbst warten. Zuvor war Gemini nach der Entwicklerkonferenz WWDC bereits in der Beta von Xcode 27 eingeführt worden, die Mitte Juni herauskam. Apple und Google arbeiten bekanntlich zusammen. Die Gemini-KI-Modelle kommen zum Einsatz, um zusammen mit Apples eigener KI-Arbeit eine verbesserte Sprachassistenz, Siri AI, zu ermöglichen. Jetzt kommt diese Kooperation auch Entwicklern zugute: Googles KI gesellt sich in der Xcode-IDE zu den bereits integrierten Anthropic Claude Agent und OpenAI Codex.

Mit der direkten Integration des agentischen Codings bietet Apple seit Xcode 26 eine niedrigschwellige Möglichkeit an, beliebte KI-Modelle für das Entwickeln von Apps einzusetzen. In Xcode 26.3 wurde dies erweitert. Wie Claude Code und GitHub Copilot dabei im direkten Vergleich abschneiden, zeigt unser Praxistest zum Prompten statt Coden in Xcode. Deren Integration soll mit Xcode 27 weiter vertieft werden. Auf der WWDC zeigte Apple in Demos für Entwickler, wie diese künftig zum Beispiel mehrere Anfragen parallel bearbeiten können. Auch wurde weiter an der optischen Aufbereitung gefeilt. Vor zwei Jahren hatte Apple noch einen eigenen Ansatz verfolgt, den Swift Assist, der es allerdings niemals in die Beta schaffte.

Version 26.6 von Xcode ist ansonsten ein kleines Update, das einfach nur die SDKs fortschreibt und Bugs behebt. Es umfasst Swift 6.3 sowie SDKs für iOS 26.5, iPadOS 26.5, tvOS 26.5, visionOS 26.5 und macOS 26.5.

Xcode 27: Viele neue Funktionen und Veränderungen

Mit Xcode 27, das für registrierte Entwickler jetzt schon als Testversion bereitsteht, stehen größere Veränderungen ins Haus. So soll die Software zunächst durch die Entfernung der Intel-Mac-Kompatibilität 30 Prozent kleiner im Umfang und schneller sein. Entwickler, die mit mehreren Computern arbeiten, dürften sich über die Synchronisation von Einstellungen über die iCloud freuen. So werden individuelle Änderungen der Benutzeroberfläche und Anzeigeeinstellungen automatisch auf andere Macs übertragen. Dies ist besonders nützlich, da Apple die Personalisierung in Xcode 27 ausbaut. So können pro Projekt verschiedene Themes eingestellt werden, um das Aussehen des Editors anzupassen, und die Toolbars können auch nach eigenen Bedürfnissen gestaltet werden.

Auf gemischte Reaktionen stößt der neue Device Hub. Er soll den Simulator ablösen, mit dem Apps auf dem Mac ausprobiert werden konnten. Der Device Hub ist im Vergleich dazu ein mächtigeres Werkzeug, das neben dem Management der Simulatoren auch das physischer Testgeräte in sich vereint. Auch können Simulatoren in der Größe dynamisch angepasst werden, was manche als Hinweis auf ein faltbares iPhone im Herbst werten. Insgesamt stößt das neue Konzept in ersten Reaktionen auf breite Zustimmung. Im Detail gibt es aber noch Nachbesserungsbedarf: So waren zum Beispiel Stimmen von Entwicklern zu hören, die zum Beispiel die pixel- und punktgenaue Darstellung des bisherigen Simulators vermissen. Gut möglich, dass Apple dies aber im weiteren Beta-Verlauf noch nachliefert.

Videos by heise

Apple führt in Xcode 27 außerdem mit dem Agent Client Protocol (ACP) ein offenes Protokoll ein, das die KI-Schnittstellen erweitert. Das Model Context Protocol (MCP) wird nativ unterstützt und öffnet die Tür zu Partnern, die ihre Anwendungen direkt integrieren. Die KI-gestützte Code-Vervollständigung soll dank lokaler KI-Modelle schneller als vorher laufen. Die fertige Version von Xcode 27 wird im Herbst erwartet, wenn auch iOS 27 und die weiteren großen Software-Updates erscheinen.

Lesen Sie auch

Foldable-Hinweise: iOS 27 bringt passende Features mit

Prompten statt Coden: So geht das mit Apples Xcode

Apple blockiert Updates für Vibe-Coding-Apps

Apple vollendet KI-Kurskorrektur: Agentisches Coding in Xcode 26.3

GPT-5.3-Codex: OpenAI stellt neues Coding-Modell vor

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Databricks will ETL zwischen Datenbanken und Analytics überflüssig machen

2026-06-26T14:45:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

LTAP heißt die neue Architektur von Databricks, mit der operative Datenbanken und analytische Systeme nur noch eine gemeinsame Datenbasis benötigen sollen.

(Bild: Jonas Härtfelder / iX)

26.06.2026, 16:45 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Prof. Jonas Härtfelder

Mit LTAP (Lake Transactional/Analytical Processing) stellt Databricks eine Architektur vor, die operative Datenbanken und analytische Systeme enger zusammenführen soll. Statt Daten per ETL- oder CDC-Prozessen zwischen beiden Welten zu kopieren, sollen künftig beide auf derselben Datenbasis arbeiten. Databricks sieht darin eine Antwort auf den zunehmenden Einsatz von KI-Agenten, die jederzeit auf aktuelle Unternehmensdaten zugreifen müssen.

In vielen Unternehmen existieren heute zwei getrennte Datenwelten. Operative Anwendungen speichern ihre Daten für den laufenden Geschäftsbetrieb in Transaktionsdatenbanken wie PostgreSQL oder Oracle. Für Berichte, Analysen oder KI-Anwendungen werden diese Daten anschließend in ein Data Warehouse oder Lakehouse kopiert. Dazwischen liegen ETL-Prozesse oder sogenannte Change-Data-Capture-Pipelines (CDC), die Änderungen laufend zwischen beiden Systemen synchronisieren. Diese Architektur gilt seit Jahren als Standard, verursacht jedoch zusätzlichen Betriebsaufwand, Datenkopien und zeitliche Verzögerungen.

Nach Ansicht von Databricks stößt dieses Modell zunehmend an seine Grenzen. KI-Agenten und moderne Anwendungen benötigten aktuelle operative Daten und könnten nicht mit Minuten oder Stunden alten Replikaten arbeiten. Mit LTAP will der Hersteller deshalb transaktionale und analytische Workloads enger zusammenführen.

Zwei Engines statt einer

Neu ist die Idee allerdings nicht. Bereits vor rund 15 Jahren versuchten HTAP-Systeme (Hybrid Transactional/Analytical Processing), Transaktionen und Analysen in einer gemeinsamen Datenbank-Engine auszuführen. Der Nachteil: Dieselbe Engine musste gleichzeitig schnelle Schreibzugriffe und komplexe analytische Abfragen bewältigen, was häufig zulasten der jeweiligen Optimierung ging.

Genau darin sieht Databricks den entscheidenden Unterschied zu früheren HTAP-Ansätzen. Eine einzelne Engine sei für beide Aufgaben zwangsläufig kompromissbehaftet, erläutert Rich Radley, Vice President Field Engineering EMEA bei Databricks. LTAP setzt stattdessen auf zwei spezialisierte Engines: Lakebase übernimmt die transaktionale Verarbeitung auf Basis von PostgreSQL, das Lakehouse die analytischen Abfragen. Beide greifen jedoch auf dieselbe Datenbasis zu.

Videos by heise

Grundlage dafür ist Lakebase, ein serverloses PostgreSQL-System, das Daten direkt im Objektspeicher des Lakehouse ablegt. Nach Angaben des Herstellers werden die für Transaktionsdaten typischen zeilenorientierten Daten beim Schreiben automatisch in ein für analytische Abfragen optimiertes spaltenorientiertes Format überführt.

Erst dadurch können beide Engines dieselbe Datenbasis nutzen, obwohl sie unterschiedliche Anforderungen an die Datenorganisation stellen. Radley bezeichnet diese Echtzeit-Transcodierung als eigentlichen technischen Durchbruch der Architektur. Dadurch können zwei spezialisierte Engines parallel auf denselben Daten arbeiten, ohne dass Daten zwischen operativen und analytischen Systemen repliziert werden müssen.

Gemeinsame Datenbasis statt Datenkopien

Lakebase legt die Daten auf derselben Speicherschicht wie das Lakehouse in offenen Tabellenformaten wie Delta oder Iceberg ab. Über den Unity Catalog werden sie gemeinsam verwaltet; dieser übernimmt Berechtigungen, Metadaten und Governance. Dadurch können sowohl die transaktionale Datenbank als auch das Lakehouse auf dieselbe Datenbasis zugreifen, ohne dass zusätzliche Datenkopien entstehen.

Lakebase ergänzt Databricks zudem um cloud- und regionenübergreifende Disaster Recovery, Git-ähnliche Branches und Snapshots sowie autonome Datenbankfunktionen, bei denen Agenten den Zustand überwachen und Optimierungsvorschläge liefern.

Architektur statt Revolution

Mit seinem Ansatz, transaktionale und analytische Workloads enger zusammenzuführen, will sich Databricks sowohl von den HTAP-Systemen (Hybrid Transactional/Analytical Processing) als auch von den neueren Zero-ETL-Konzepten absetzen. Während HTAP beide Workloads in einer gemeinsamen Engine vereinen wollte, argumentiert Databricks, dass Zero ETL vor allem den Integrationsaufwand zwischen bestehenden Systemen reduziere, die zugrunde liegenden Datenkopien jedoch bestehen blieben. LTAP setzt dagegen auf zwei spezialisierte Engines, die auf einer gemeinsamen Datenbasis arbeiten und Datenkopien vollständig vermeiden sollen.

Ob dieser Architekturansatz ETL- und Replikationsprozesse tatsächlich in größerem Umfang ersetzen kann, muss sich allerdings erst im produktiven Einsatz zeigen. LTAP ist bislang nicht allgemein verfügbar, unabhängige Benchmarks oder belastbare Erfahrungen aus Produktivumgebungen liegen ebenfalls nicht vor.

Zusammen mit Lakehouse//RT zeigt LTAP die strategische Richtung von Databricks: Analyse-, Transaktions- und KI-Workloads sollen künftig nicht mehr über zahlreiche Datenkopien und spezialisierte Zwischensysteme verbunden werden, sondern auf einer gemeinsamen Datenbasis zusammenlaufen. Sollte sich dieser Architekturansatz im produktiven Einsatz bewähren, könnte er den Aufbau datenintensiver KI-Anwendungen und Agentensysteme vereinfachen.

Lesen Sie auch

Databricks: Lakehouse//RT soll separate Echtzeitdatenbanken überflüssig machen

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

0,7 Nanometer: IBM zeigt die ersten Chips mit CFET-Transistoren

2026-06-26T11:49:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

IBM zeigt, wie Chips der Zukunft aussehen könnten. Leistung, Effizienz und Transistordichte steigen enorm.

(Bild: IBM)

26.06.2026, 13:49 Uhr

Lesezeit: 4 Min.

Von

Mark Mantel

IBMs Forschungsabteilung hat einen neuartigen Fertigungsprozess entworfen, den die Firma der 0,7-Nanometer-Generation alias 7 Ångström (7A) zuordnet. Die Versprechen sind enorm: Verglichen mit dem selbst entworfenen 2-nm-Prozess von 2021 soll sich die Transistordichte verdoppeln. Die Performance bei gleicher elektrischer Leistungsaufnahme steigt um bis zu 50 Prozent, alternativ sinkt der Energiebedarf bei gleicher Performance um bis zu 70 Prozent.

Damit ist nicht Schluss: Laut Mitteilung soll sich auch der in Prozessoren, Grafikchips und anderen Chiptypen integrierte SRAM-Cache um 40 Prozent verkleinern lassen. Das wäre ein enormer Sprung, nachdem sich die SRAM-Skalierung in den vergangenen Fertigungsgenerationen einer Wand genähert hatte.

Wie üblich haben Nanometer- beziehungsweise Ångström-Namen nichts mit den tatsächlichen Dimensionen zu tun. Ein einzelner Chip hat zahlreiche Metriken, anhand derer sich die Größen messen lassen. Die Mitten zweier Transistoren etwa sollen bei IBMs 7A 42 bis 45 nm voneinander entfernt sein (Contacted Poly Pitch, CPP).

Lesen Sie auch

Intels Chipfertigung: Weg von Nanometer, hin zu Angström mit HighNA-EUV

Chipfertigung: Das sind die Pläne des Weltmarktführers TSMC bis 2029

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Im Test: Elixirs 1.20 neues intelligentes Typsystem

2026-06-26T11:25:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Das Typsystem von Elixir 1.20 analysiert jedes Sprachkonstrukt, erkennt fehlerhafte Argumente und verfolgt sie auch.

(Bild: Wolf Hosbach / KI / iX)

26.06.2026, 13:25 Uhr

Lesezeit: 24 Min.

Developer

Von

Stefan Wintermeyer

Eine Funktion erwartet eine Zahl, aber irgendwo im Projekt wird stattdessen eine Zeichenkette übergeben. Der Compiler sagt nichts, die Tests decken den Fall nicht ab, und der Fehler tritt erst auf, wenn ein Kunde in der Produktion genau diesen Codepfad auslöst. Wer mit dynamisch getypten Sprachen arbeitet, kennt diese Klasse von Bugs: Typen werden erst zur Laufzeit geprüft, der Compiler trifft über sie von sich aus keine Annahmen.

Python, Ruby und JavaScript funktionieren nach diesem Prinzip, die funktionale Programmiersprache Elixir ebenfalls. Der Komfort: Code bleibt knapp und lässt sich leicht umbauen. Der Preis: Fehler werden erst sichtbar, wenn das Programm auf den unerwarteten Wert trifft.

Ein Beispiel zeigt, was sich bei Elixir mit dem am 3. Juni 2026 erschienenen Release 1.20 ändert. Die folgende Funktion nimmt eine Map entgegen, Elixirs Schlüssel-Wert-Struktur (geschrieben %{schlüssel: wert}, vergleichbar einem Dictionary in Python oder einem Hash in Ruby), und wandelt das darin enthaltene Feld age in eine Zeichenkette um:

defmodule Report do
  def user_age_to_string(user) do
    Integer.to_string(user.age)
  end
end

# An anderer Stelle im Projekt:
Report.user_age_to_string(%{age: "42"})

Integer.to_string/1 ist dabei Elixirs übliche Schreibweise für eine Funktion: Modul, Funktionsname und nach dem Schrägstrich die Stelligkeit (Arity), also die Zahl der Argumente. Bis einschließlich Version 1.19 schwieg der Compiler zu diesem Code; dass age eine Zeichenkette statt einer Zahl enthält, fiel erst zur Laufzeit auf. Ab 1.20 erscheint eine Warnung beim Übersetzen:

warning: incompatible types given to Report.user_age_to_string/1:

    Report.user_age_to_string(%{age: "42"})

given types:

    %{age: binary()}

but expected one of:

    %{..., age: integer()}

Zwei Notationen darin sind erklärungsbedürftig (Typnamen tragen in Elixir stets leere Klammern). binary() ist Elixirs Typ für Zeichenketten, denn Strings sind in Elixir intern UTF-8-kodierte Binärdaten. Und die Ellipse in %{..., age: integer()} steht für beliebige weitere Schlüssel: Gemeint ist jede Map, die mindestens den Schlüssel age mit einem integer(), einer ganzen Zahl, enthält.

Niemand hat dem Compiler mitgeteilt, welchen Typ user.age haben soll. Er hat es selbst erschlossen: Integer.to_string/1 verlangt eine ganze Zahl, also muss das Feld age eine ganze Zahl enthalten, also muss jeder Aufrufer eine Map mit genau diesem Merkmal übergeben. Die Schlussfolgerung klingt trivial, aber sie steckt in keiner Typannotation, also keinem expliziten Typhinweis im Quelltext, wie ihn typisierte Sprachen verlangen (name: string in TypeScript, String name in Java). In Elixir 1.20 übernimmt der Compiler diese Arbeit von selbst.

Das dahinterstehende Typsystem, das seit Version 1.17 schrittweise in die Sprache einzog, analysiert inzwischen jedes Sprachkonstrukt. Es erkennt nicht nur fehlerhafte Argumente wie im Beispiel oben, sondern verfolgt auch, wie sich das Wissen über einen Wert durch mehrere Fallunterscheidungen hindurch verfeinert, und deckt dabei toten Code und widersprüchliche Zugriffe auf. Was abstrakt klingt, markiert einen Wendepunkt in der Geschichte von Elixir.

Sämtliche Vorteile des neuen Typsystems gibt es automatisch und ohne eigenes Zutun. An der Arbeitsweise muss sich nichts ändern, bestehender Code kompiliert unverändert weiter, niemand muss Typannotationen schreiben oder neue Syntax lernen; die zusätzliche Fehlersuche läuft bei jedem Übersetzen einfach mit.

Erste Version: 2012
Autor: José Valim
Laufzeit: BEAM (Erlang/OTP)
Paradigma: funktional, dynamisch, ab 1.17 gradual typisiert (typisierter und untypisierter Code koexistieren)
Typische Einsatzfelder: Web-Backends (Phoenix, LiveView), Embedded (Nerves), maschinelles Lernen (Nx), verteilte Systeme
Paketverwaltung: Hex, Build-Tool Mix
Version zum Artikel: 1.20.0, Release 3. Juni 2026, benötigt OTP 27+, kompatibel bis OTP 29

Elixir kurz erklärt

Elixir ist eine funktionale, dynamisch getypte Sprache, die der Brasilianer José Valim 2012 veröffentlichte. Sie läuft auf der BEAM, der virtuellen Maschine von Erlang, und erbt von dort leichtgewichtige Prozesse im Millionenbereich (von der VM verwaltet, keine Betriebssystemprozesse) sowie eine ausfallsichere Laufzeit durch Supervisoren: überwachende Prozesse, die abgestürzte Teile des Systems automatisch neu starten.

Bekannt ist Elixir vor allem durch das Web-Framework Phoenix, das Embedded-Framework Nerves (Firmware-Images für Geräte vom Raspberry Pi bis zur Industriesteuerung) und Nx, das Elixir in die Welt des maschinellen Lernens bringt. Allen gemein ist ein Programmierstil, den eine kleine Funktion illustriert; sie übersetzt das Ergebnis einer Operation in einen lesbaren Satz:

defmodule Ergebnis do
  def beschreibe({:ok, wert}),        do: "Erfolg: #{wert}"
  def beschreibe({:error, :timeout}), do: "Zeitüberschreitung"
  def beschreibe({:error, grund}),    do: "Fehler: #{grund}"
  def beschreibe(:pending),           do: "läuft noch"
end

Vier Klauseln, vier Fälle. Eine Funktion darf in Elixir aus mehreren Definitionen gleichen Namens bestehen, den Klauseln; welche läuft, entscheidet kein if oder switch, sondern die Form des Arguments. Diesen Musterabgleich nennt man Pattern Matching. Die erste Klausel greift für einen Tupel, eine geordnete Sammlung fester Länge in geschweiften Klammern, dessen erstes Element das Atom :ok ist; den zweiten Wert bindet sie an die Variable wert und fügt ihn per #{...} in den Antwortsatz ein, Elixirs String-Interpolation, vergleichbar mit f-Strings in Python. Atome wie :ok oder :pending sind benannte Konstanten, deren Wert ihr eigener Name ist, vergleichbar mit Symbols in Ruby. Die zweite Klausel fängt den speziellen Fehlerfall :timeout ab, die dritte jeden anderen Fehler, die vierte das schlichte Atom :pending. Das do: ist die einzeilige Kurzform des do ... end-Blocks aus dem ersten Beispiel.

Videos by heise

Zwei Bausteine gehören noch zum Rüstzeug. Erstens: Tupel wie {:ok, wert} und {:error, grund} heißen Result-Tupel; fast jede Elixir-Bibliothek meldet Erfolg oder Misserfolg in dieser Form. Zweitens lassen sich Klauseln durch Guards verfeineren, Prüfbedingungen hinter dem Schlüsselwort when: def halbiere(x) when is_integer(x) greift nur für ganze Zahlen. Patterns, Klauseln und Guards ersetzen in Elixir einen großen Teil des klassischen Kontrollflusses. Und genau dieser Stil galt lange als Hindernis für ein klassisches Typsystem.

Vom dynamischen Liebling zum typisierten Werkzeug

Die Idee, Elixir ein Typsystem zu verpassen, ist alt. Bereits der aus der Erlang-Welt stammende Dialyzer, den Kostis Sagonas an der Universität Uppsala mitentwickelt hat, kann Elixir-Code analysieren. Seine Stärke, das sogenannte Success Typing, liegt darin, nur solche Fehler zu melden, die sich aus dem Code unzweifelhaft ergeben. Sein Potenzial entfaltet er allerdings erst, wenn Entwicklerinnen und Entwickler ihre Funktionen mit @spec-Annotationen versehen: von Hand geschriebene Typsignaturen, die zusätzlich zum eigentlichen Code gepflegt werden wollen und mit ihm auseinanderdriften können. Dazu kommen langsame Analysen, sperrige Integration und schwer entzifferbare Meldungen. In die breite Masse der Elixir-Entwickler hat es Dialyzer deshalb nie geschafft.

José Valim kündigte 2022 in seiner Keynote auf der ElixirConf EU an, dass die Sprache ein eigenes Typsystem bekommen werde, finanziert über ein Promotionsstipendium des französischen Forschungszentrums CNRS und des Unternehmens Remote. Die wissenschaftliche Grundlage lieferte der Informatiker Giuseppe Castagna (CNRS, Paris) mit seiner Arbeit zu set-theoretischen Typen, einem Formalismus, der Typen als Mengen begreift. Castagnas Doktorand Guillaume Duboc übernahm den Großteil der Implementierung, unterstützt durch Valim selbst; die Designprinzipien dokumentieren die drei in einem gemeinsamen Paper. Für eine Sprache, in der Pattern Matching ohnehin um die Form von Werten kreist, passte dieser Ansatz besser als klassische Typsysteme nach dem Vorbild von ML oder Haskell.

Die Entwicklung verlief in vier Etappen (Abbildung 1). Elixir 1.17 legte im Juni 2024 den Grundstein: erste Typen, abgeleitet aus den Patterns einer Funktion, erste Warnungen bei offensichtlichen Widersprüchen. Elixir 1.18 brachte im Dezember 2024 das Typchecking von Funktionsaufrufen, dazu eingebaute JSON-Unterstützung und Schnittstellen für die offizielle Language-Server-Initiative. Elixir 1.19 dehnte die Prüfungen im Oktober 2025 auf Protokolle und anonyme Funktionen aus und machte das Übersetzen großer Projekte bis zu viermal schneller. Version 1.20 schließt den Kreis: Der Compiler inferiert jetzt die Typen sämtlicher Sprachkonstrukte.

Zeitstrahl des Elixir-Typsystems (1.17 bis 1.20): Vier Minor-Versionen, ein roter Faden: Typinformation fließt in immer mehr Sprachkonstrukte ein. Mit 1.20 erreicht die Inferenz den Alltag (Abb. 1).

Den Rollout hat das Kernteam in einem öffentlichen Phasenplan organisiert, der die Inferenz in drei Phasen durch die Release Candidates trug (siehe Kasten). Alle drei stecken im stabilen Release, das Anfang Juni kurz nach dem ursprünglich angepeilten Mai-Termin erschien.

Lesen Sie auch

Bildklassifikation ohne Cloud mit überschaubarem Programmieraufwand

Funktionale Programmierung und mehr: Das Programm der BOB-Konferenz liegt vor

Open Source Security: GitHub Advisory Database kennt Erlang und Elixir

Tensorbibliothek Nx 0.1.0 macht Elixir fit für ML

Programmiersprache: Elixir 1.13 führt semantische Neukompilierung ein

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Neu in .NET 10.0 [29]: IP-Adressen prüfen mit IPAddress.IsValid()

2026-06-26T07:18:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die neue Methode IsValid() prüft schneller als ältere Methoden in .NET, ob eine IP-Adresse einen gültigen Aufbau hat.

(Bild: Pincasso / Shutterstock.com)

26.06.2026, 09:18 Uhr

Lesezeit: 1 Min.

Developer

Von

Dr. Holger Schwichtenberg

Zur Prüfung von IP-Adressen gibt es in der Klasse System.Net.IPAddress schon seit .NET Framework 2.0 die statische Methode TryParse(), die eine IP-Adresse aus einer Zeichenkette extrahiert.

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.

Seit .NET Core 2.1 ist die Extraktion auch aus dem Typ ReadOnlySpan<char> möglich. Der Rückgabewert ist ein bool-Wert und die extrahierte IP-Adresse wird in Form einer Instanz der Klasse IPAddress als out-Parameter geliefert. Wenn man nur prüfen will, ob die IP-Adresse stimmt, schreibt man IPAddress.TryParse(eingabe, out _).

In .NET 10.0 bietet Microsoft nun in der statischen Methode IsValid() eine weitere Prüfungsvariante mit weniger internem Aufwand. Folgender Code vergleicht IsValid() mit TryParse():

/// <summary>
/// IsValid mit ReadOnlySpan<char> oder ReadOnlySpan<byte> als Alternative zu IPAddress.TryParse(span, out _)
/// </summary>
public void Run()
{
 CUI.Demo("IPAddress.IsValid()");

 string IP1 = "192.168.1.0"; // gültige IPv4-Adresse
 CUI.H2(IP1);

 // --- Alt
 var valid1 = IPAddress.TryParse(IP1, out _);
 Console.WriteLine("TryParse: " + valid1); // true

 // --- Neu
 System.Console.WriteLine("IsValid: " + System.Net.IPAddress.IsValid(IP1)); // true

 string IP2 = "192.168.256.1"; // ungültige IPv4-Adresse
 CUI.H2(IP2);

 // --- Alt
 var valid2 = IPAddress.TryParse(IP2, out _);
 Console.WriteLine("TryParse: " + valid2); // false

 // --- Neu
 System.Console.WriteLine("IsValid: " + System.Net.IPAddress.IsValid(IP2)); // false
}

Videos by heise

Der Code nutzt die alte und die neue Methode, um IP-Adressen auf Gültigkeit zu prüfen (Abb. 1).

Dafür kehrt Microsoft nun einfach eine bisher interne Methode TargetHostNameHelper.IsValidAddress() nach außen, wie sich dem Issue auf GitHub entnehmen lässt.

IsValid() ist performanter als TryParse() und benötigt keinen Speicher (Abb. 2).

(Bild: Microsoft)

(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. Bis zur Veröffentlichung des Programms sind vergünstigte Blind-Bird-Tickets verfügbar.

(rme)

Top 10: Das beste City-E-Bike

Top 10: Speicher für Balkonkraftwerk im Test

Top 10: Bestes Smartphone bis 400 Euro im Test

Prognose: 2028 wird KI-Coding teurer als Entwicklergehälter

2026-06-25T13:23:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Von der Produktivitätsrevolution zur Kostenfalle: KI-Coding könnte Unternehmen bald teurer kommen als das Entwicklergehalt, prognostizieren Marktforscher.

171

(Bild: TierneyMJ/Shutterstock.com)

25.06.2026, 15:23 Uhr

Lesezeit: 3 Min.

iX Magazin

Von

Axel Kannenberg

Zunehmender Tokenverbrauch und die Umstellung auf verbrauchsbasierte Abrechnungsmodelle werden laut Prognose der Marktforscher von Gartner Coding mit generativer KI zunehmend verteuern. 2028 dürften die Tokenkosten pro Entwickler dann laut Gartner den globalen Durchschnittslohn eines Entwicklers übersteigen. Die Prognose basiert auf einem weltweiten Mittelwert von rund 2.000 US-Dollar pro Monat – also deutlich unter dem, was man in Deutschland in der Branche verdient.

Gartner-Analyst Nitish Tyagi betonte auch, dass die Kosten natürlich nicht jedes Entwicklergehalt auf der Welt übersteigen würden – in den USA werde etwa deutlich besser bezahlt als in Indien. Laut Gartnerdaten würden aber schon sechs Prozent der Unternehmen Token-Kosten von über 2000 US-Dollar pro Entwickler pro Monat erreichen, was über dem typischen Gehalt indischer Entwickler mittlerer und höherer Erfahrungsstufen liege.

„Unternehmen gehen rasch von der Testphase zur groß angelegten Einführung von KI-Codingsagenten über, doch viele unterschätzen die finanziellen Auswirkungen des steigenden Token-Verbrauchs“, führte Tyagi weiter aus. Mehr Disziplin beim Tokenverbrauch werde aber nicht allein aus den Entscheidungen der Entwickler erwachsen. Die neigten Tyagis Ansicht nach eher zu Komfort und Schnelligkeit als zu Kosteneffizienz. Ohne ein geregeltes Betriebsmodell für die Entwicklung könnten die Kosten in den Unternehmen schneller steigen als die Produktivitätsgewinne, die KI-Tools erreichen sollen.

Kein ROI, nirgends?

„Führungskräfte im Bereich Softwareentwicklung sind zunehmend besorgt, da sich tokenbasierte KI-Ausgaben immer schwerer rechtfertigen lassen und Budgets oft früher als erwartet aufgebraucht sind“, sagte Tyagi. Unter anderem hatte im April der Uber-CTO Praveen Neppalli Naga mit der Aussage für Aufsehen gesorgt, dass das jährliche Token-Budget der Firma bereits aufgebraucht sei. Darauf legte Uber-Präsident Andrew Macdonald im Mai in einem Podcast nach, dass der Nutzen des KI-Einsatzes auch nicht klar sei. Ein Zuwachs an nützlichen Funktionen für Verbraucher habe sich nicht abgezeichnet. Ein ähnliches Bild zeigt sich auch in Deutschland, wo laut einer Bitkom-Umfrage rund ein Drittel der befragten Unternehmen von den Kosten ihres KI-Einsatzes überrascht worden ist.

Lesen Sie auch

Was Entwickeln mit KI wirklich kostet

Tokenbudget und Kosten für Vibe Coding schätzen

Testsieger: Die beste mobile Klimaanlage

Top 10: Der beste Ventilator im Test

Top 8: Die beste Kompressor-Kühlbox

software-architektur.tv: Wie fährst du dein Projekt zuverlässig an die Wand?

2026-06-25T10:03:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

In der Episode diskutieren Ralf D. Müller und Andreas Monschau über „wohlbekannte“ Anti-Pattern, die jedes Softwareprojekt zum Scheitern bringen.

(Bild: software-architektur.tv)

25.06.2026, 12:03 Uhr

Lesezeit: 2 Min.

Developer

Von

Matthias Parbel

Softwareprojekte sind chaotisch, anstrengend und voller Überraschungen. Und ganz ehrlich: So soll es auch bleiben. Ordnung würde ja nur den Spaß verderben. Trotzdem gibt es immer wieder Menschen, die glauben, man könnte Projekte wirklich zum Erfolg führen … unglaublich, oder?

Ein paar goldene Regeln

In dieser Folge werfen Andreas Monschau und Ralf Müller einen Blick auf goldene Anti-Pattern, mit denen sich Softwareprojekte besonders zuverlässig ruinieren lassen. Nicht alle, aber einige besonders wirkungsvolle Regeln kommen auf den Tisch, welche genau, verraten die beiden vorab aber nicht. Nur so viel: Die Muster sind nicht ausgedacht. Sie begegnen Entwicklerinnen und Softwarearchitekten in echten Projekten immer wieder – oft gut getarnt als Pragmatismus, Zeitdruck oder „das haben wir schon immer so gemacht“. Manche entfalten ihre volle Zerstörungskraft sofort, andere erst Monate später.

Am Ende bleibt die Frage: Wenden wir alle diese Anti-Pattern weiterhin mit beeindruckender Konsequenz an – oder verändern wir vielleicht doch etwas?

Andreas Monschau spricht bei den IT-Tagen 2026 am 12. Juli in Frankfurt. Mit dem Code ITT26-SIS-352 erhalten Interessierte 100 Euro Rabatt auf ein Ticket.

Empfohlener redaktioneller Inhalt

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

Livestream am 26. Juni

Die Ausstrahlung findet am Freitag, 26. Juni 2026, live ab 13:00 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

(map)