Die neueste Ausgabe der jährlichen Umfrage State of JavaScript präsentiert die Antworten von mehr als 10.000 Entwicklerinnen und Entwicklern weltweit, die ihre beliebtesten sowie am häufigsten genutzten JavaScript-Tools mitteilen. React ist erneut das meistgenutzte Frontend-Framework und Vite wieder das beliebteste Tool insgesamt.

Das meistgenutzte Tool webpack kann dagegen wenig Begeisterung wecken, denn der Bundler gilt als schwerfällig, mühsam und veraltet – und Vite ist ihm in der Nutzungshäufigkeit eng auf den Fersen. Unter den Texteditoren sticht der neuere KI-Editor Cursor besonders hervor, kann es jedoch nicht mit Visual Studio Code aufnehmen.

(Bild: jaboy/123rf.com)

Tools und Trends in der JavaScript-Welt: Die enterJS 2026 wird am 16. und 17. Juni in Mannheim stattfinden. Das Programm dreht sich rund um JavaScript und TypeScript, Frameworks, Tools und Bibliotheken, Security, UX und mehr. Frühbuchertickets sind im Online-Ticketshop erhältlich.

Vite sägt rasant an webpacks Thron

Die Studie hat erneut nicht nur nach der Nutzung von JavaScript-Libraries gefragt, sondern auch nach den positiven, negativen oder neutralen Einstellungen, die Entwickler ihnen gegenüber hegen. Die Libraries sind in verschiedene Kategorien gruppiert, darunter Frontend- oder Backend-Frameworks sowie Build-Tools. Gesamtsieger in der Nutzungshäufigkeit ist der Bundler webpack, doch das Build-Tool Vite ist ihm auf Rang 2 eng auf den Fersen und hat in diesem Jahr React überholt.

Ein Blick auf die meistgenutzten Build-Tools zeigt, wie eng dieses Mal das Rennen um den ersten Platz war: webpack nutzen 86,4 Prozent der Teilnehmenden im Jahr 2025, während Vite mit 84,4 Prozent knapp dahinter liegt. Die Betrachtung über die letzten Jahre hinweg zeigt, dass sich die Schere zwischen webpack und Vite immer weiter schließt. In der Umfrage 2023 betrug der Unterschied zwischen den Tools noch 17 Prozent, 2024 nur noch acht Prozent.

Meistgenutzte Build-Tools laut dem State of JavaScript 2025: webpack und Vite belegen – mit großem Abstand zu anderen wie esbuild oder Rollup – die ersten beiden Plätze.

(Bild: State of JavaScript 2025)

Auf der Beliebtheitsskala steht Vite ganz oben: Unter denjenigen, die das Tool bereits verwendet haben, stehen ihm 56 Prozent positiv gegenüber, dagegen nur ein Prozent negativ. In den Freitext-Kommentaren zu Vite überschlagen sich die Lobeshymnen. Es sei einfach zu nutzen, die beste Technologie in seinem Bereich oder gar „die einzige Wahl im Jahr 2025“.

Lesen Sie auch

programmier.bar: Vite – das universale Build Tool für JavaScript und TypeScript

Webentwicklung: Vite+ als einheitliche JavaScript-Toolchain geplant

Top 10: Die beste Mini-Powerbank fürs Handy im Test

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

Top 10: Die beste Soundbar ohne Subwoofer im Test

OpenAI Realtime API bietet günstigeres Mini-Modell für Echtzeitkommunikation

2026-02-10T08:23:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Das öffentliche Release verbessert Audio, Sprache, Debugging und die Developer Experience. Daneben lässt sich eine kostengünstigere Mini-Variante nutzen.

(Bild: pncha.me/Shutterstock.com)

10.02.2026, 09:23 Uhr

Lesezeit: 13 Min.

Developer

Von

Marius Obert

Knapp ein Jahr nach der Vorstellung der Developer Preview hat OpenAI im August 2025 die GA-Version (General Availability) der Realtime API veröffentlicht. Die Realtime API ist eine multimodale Schnittstelle, über die Audio- und Textdaten mit sehr geringer Latenz direkt mit einem Sprachmodell ausgetauscht werden können. Der Developer Day im Oktober 2025, einige Monate nach dem GA-Launch, brachte zusätzliche Neuerungen, darunter neue Tools, Preisänderungen und eine kleinere, schnellere Modellvariante.

Marius Obert baut gerne Prototypen mit den neuesten Cloud-Technologien und spricht noch lieber darüber. Seine Karriere startete in der UI-Entwicklung im sonnigen Kalifornien. Während dieser Zeit lernte er Webtechnologien wie JavaScript im Allgemeinen und das gesamte Node.js-Ökosystem im Speziellen zu lieben.

Mit der GA-Version erweitert OpenAI die Möglichkeiten der Interaktion mit KI-Agenten deutlich. In einem Blogbeitrag stellt das Unternehmen Anwendungsbeispiele von Partnern wie Zillow, T-Mobile, StubHub, Oscar Health und Lemonade vor, die die Vielfalt der Einsatzszenarien verdeutlichen. Die Anwendungsfelder reichen über klassische Sprachdialoge hinaus und ermöglichen sogenannte „hands-free Interaktionen“, bei denen Anwenderinnen und Anwender Text-, Sprach- und visuelle Eingaben flexibel kombinieren können. Die Realtime API ist dabei nicht ausschließlich als Voice-to-Voice-Lösung konzipiert, sondern als multimodales System, das Text, Audio und Bilder gleichermaßen als Eingaben akzeptiert. Sprachinteraktion stellt somit einen ergänzenden Kommunikationskanal neben weiteren Nutzungsformen dar.

Anwendungen werden zunehmend interaktiver und Nutzer erwarten ein unmittelbares, natürliches Reaktionsverhalten. Die Realtime API erfüllt diesen Bedarf, indem sie eine kontinuierliche, bidirektionale Kommunikation mit sehr geringer Latenz ermöglicht – etwa für Sprachassistenz im Kundensupport, automatische Protokollführer im Büro oder Anwendungen, die Live-Visualisierungen und Sprache kombinieren.

Durch den Wegfall traditioneller Zwischenschritte wie separater Speech-to-Text- und Text-to-Speech-Prozesse entsteht ein direktes Modell, das Sprache versteht und beantwortet, ohne spürbare Verzögerung oder Verlust von Nuancen.

Technische Neuerungen im allgemeinen Release

Im Vergleich zur Developer Preview enthält die GA-Version der Realtime API zahlreiche technische Erweiterungen und Verbesserungen in den Bereichen Modellarchitektur, Integration und Nutzbarkeit. Eine zentrale Änderung ist die Einführung einer Mini-Variante des Modells, die kosteneffizientere und schnellere Anwendungen ermöglicht. Die OpenAI-Website zeigt die Unterschiede zwischen gpt-realtime und gpt-realtime-mini.

Wann ist Voice AI in Webanwendungen sinnvoll, und wann nicht? Marius Oberts Vortrag auf dem Online-Thementag enterJS Integrate AI am 28. April 2026. Frühbuchertickets und Gruppenrabatte im Online-Ticketshop.

Die Audioqualität wurde deutlich überarbeitet: Die erzeugte Sprache klingt natürlicher und ausdrucksstärker, mit feineren Betonungen, flüssigeren Pausen und einer besseren Anpassung an Gesprächsverläufe. OpenAI hat hierfür zwei neue Stimmen eingeführt: „Cedar“ und „Marin“.

Auch die Fähigkeit zur Befolgung komplexer Anweisungen hat der Anbieter verbessert. Das Modell reagiert präziser auf System- und Entwickler-Prompts, und es kann Texte exakt vorlesen, alphanumerische Sequenzen korrekt wiedergeben und fließend zwischen Sprachen wechseln. Benchmark-Tests wie die Big Bench Audio Evaluation weisen eine Steigerung der Genauigkeit (Accuracy) von rund 65 Prozent in der Beta-Version auf über 82 Prozent in der GA-Version aus:

OpenAI Realtime API: Ergebnisse des Benchmarks Big Bench Audio Intelligence

(Bild: OpenAI)

Eine wesentliche Verbesserung betrifft die erweiterten rhetorischen Fähigkeiten des Modells. Die Realtime API kann Gesprächsverläufe nun flüssiger, natürlicher und kontextbewusster gestalten, indem sie Pausen, Betonungen und Gesprächsdynamik besser interpretiert. In diesem Zusammenhang führt OpenAI die Funktion der Conversation Idle Timeouts ein. Erkennt das Modell über einen definierten Zeitraum keine Eingabe, kann es automatisch Folgesätze wie „Sind Sie noch da?“ ausgeben, um den Gesprächsfluss aufrechtzuerhalten und dem Nutzer oder der Nutzerin ein aktives Gespräch zu signalisieren.

Darüber hinaus reagiert das Modell während längerer oder asynchroner Funktionsaufrufe mit Zwischentexten, beispielsweise „Ich warte noch auf das Ergebnis“, um Wartezeiten kommunikativ zu überbrücken und den Dialog lebendig zu halten. Diese Ergänzungen tragen dazu bei, die Interaktion natürlicher und konsistenter zu gestalten – insbesondere in Anwendungsfällen, in denen Echtzeit-Feedback und gesprochene Zwischenausgaben entscheidend für die Nutzererfahrung sind.

Zudem unterstützt die OpenAI Realtime API nun neben WebSocket und WebRTC auch das Session Initiation Protocol (SIP), was die direkte Integration in Telefonie- und Contact-Center-Systeme erleichtert.

Für Entwicklerinnen und Entwickler hat der Anbieter die Strukturen der Ereignis- („Event“-) und Nachrichten-Items überarbeitet, um Debugging und Fehlerbehandlung zu vereinfachen. Dieses Modell verfügt zudem inzwischen über EU-Datenresidenz, um europäischen Datenschutzanforderungen Rechnung zu tragen.

Vorgefertigte Werkzeuge wie Web-Search oder Code Interpreter sind derzeit noch nicht integriert, sodass Anwender sie selbst nachbauen müssen. Über die Implementierung des MCP-Servers (Model Context Protocol) ist es möglich, externe Tools in die Agentenlogik einzubinden. Damit lassen sich die Fähigkeiten eines Agenten relativ einfach erweitern und in bestehende Tools größerer Anwendungen integrieren. Diese Änderungen erhöhen insgesamt die Robustheit, Flexibilität und Praxistauglichkeit der API.

Modellübersicht

Die folgende Tabelle gibt einen Überblick über die wichtigsten Modellparameter und Preisstrukturen von gpt-realtime und gpt-realtime-mini.

Modell	Kontextfenster (Token)	Maximale Ausgabe (Token)	Wissensgrenze	Eingabetypen	Ausgabetypen	Preis pro 1 Million Input-Token (Audio)	Preis pro 1 Million Output-Token (Audio)
gpt-realtime	32.000	4.096	Okt. 2023	Text, Bild, Audio	Text, Audio	$ 32,00 (Cached: $ 0,40)	$ 64,00
gpt-realtime-mini	32.000	4.096	Okt. 2023	Text, Bild, Audio	Text, Audio	$ 10,00 (Cached: $ 0,30)	$ 20,00

Tabelle 1: Vergleich der Kernparameter beider Modelle; Kosten pro Million Token in US-Dollar ($)

Top 10: Die beste Mini-Powerbank fürs Handy im Test

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

Top 10: Die beste Soundbar ohne Subwoofer im Test

Wie motiviere ich meinen Boss?

2026-02-10T08:21:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Motivation von Mitarbeitern ist ein gängiges Thema. Doch wie ist es eigentlich um die Motivation der Manager und Team-Leads bestellt?

(Bild: Charles-Edouard Cote/Shutterstock.com)

10.02.2026, 09:21 Uhr

Lesezeit: 5 Min.

Developer

Von

Stefan Mintert

Die Frage „Wie motiviere ich meine Mitarbeiter?“ wurde mir unzählige Male von Vorgesetzten gestellt. Überraschenderweise ist mir die Frage „Wie motiviere ich meinen Boss?“ nie begegnet. Da der Begriff nicht einheitlich verwendet wird, sei kurz erwähnt, dass ich unter Boss jede Person mit Führungsverantwortung für einen Bereich verstehe.

(Bild:

Stefan Mintert

)

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potenzial sieht er in der Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potenzial zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Sind Vorgesetzte immer motiviert?

Wenn man bedenkt, dass ein Vorgesetzter A selbst Mitarbeiter seines Vorgesetzten B ist, müsste das angebliche Motivationsproblem ja auch für Person A gelten. Also dürfte es aus der Perspektive von B auch bei A mal an Motivation fehlen.

Aber auch aus Sicht eines Teams von Person A zweifle ich den Zustand von „permanenter Motivation“ an. Denn von Teams höre ich nicht selten, dass es ihnen an Führung fehlt. Teammitglieder erkennen sehr wohl Defizite bei Vorgesetzten, nur bringen sie das nie mit Motivation in Verbindung.

Geht es hier eigentlich um Motivation oder um etwas anderes?

Videos by heise

Ein Beispiel: Ein Entwickler, mit dem ich gearbeitet habe, hat seinen Bereichsleiter um ein Mitarbeitergespräch gebeten. Es hatte schon lange keines mehr stattgefunden und so hatten sich beim Mitarbeiter einige Themen aufgestaut. Acht Monate, nachdem der Mitarbeiter erstmals um das Gespräch gebeten hatte, hatte es immer noch nicht stattgefunden. Augenscheinlich war der Manager nicht sonderlich motiviert, das Gespräch zu führen. Als ich das Thema bei ihm ansprach, gab er offen zu, dass er sich lieber um technische Fragen kümmere. Es machte den Eindruck, dass alles, was an seiner Position mit Personalführung zu tun hatte, nicht „sein Ding“ war.

Nun kann man eine solche Situation (mit einigem Recht) grundsätzlich beklagen, das hilft aber nicht weiter und beantwortet die wichtigste Frage nicht: Was soll der Mitarbeiter in dem Fall tun?

Im Allgemeinen rate ich dazu, herauszubekommen, was den Vorgesetzten interessiert; anders gesagt, was ihn motiviert. Möchte er bei seinem eigenen Vorgesetzten gut dastehen? Möchte er sich um bestimmte Themen möglichst wenig kümmern? Möchte er, dass die Aufgaben, die man erledigt, möglichst geräuschlos und im Zeitplan erledigt werden? Und so weiter.

Im zweiten Schritt geht es darum, das eigene Anliegen mit der vermuteten Motivation des Vorgesetzten in Verbindung zu bringen.

Unterschiedliche Strategien

Im obigen Beispiel des Vorgesetzten, der „seine Ruhe“ haben möchte, gibt es verschiedene Strategien – von entgegenkommend bis konfrontativ. Entgegenkommend wäre es zum Beispiel, die Planung des Gesprächs in die eigene Hand zu nehmen, eine Agenda mit den eigenen Themen aufzustellen und das alles in einen Kalendereintrag zu schreiben. Wenn man im Kalender die freien Slots des Vorgesetzten sehen kann, wählt man einen Termin und lädt ihn ein.

Konfrontativ wäre der Ansatz, seinen Boss in allen anderen stattfindenden Meetings an den Gesprächswunsch zu erinnern. Also auch in Besprechungen, in denen das Thema nichts zu suchen hat. Irgendwann – so die Hoffnung – hat man genug genervt und bekommt einen Termin. Ob diese konfrontative Ansprache eine gute Idee ist, dürfte sehr stark vom persönlichen Verhältnis zum Vorgesetzten abhängen. Und es ist wichtig, den richtigen Ton zu treffen. Keinesfalls sollte man das eigentliche Thema des Meetings behindern. Wenn aber der Vorgesetzte zum Abschluss eher floskelhaft fragt: „Sind wir durch oder habt Ihr noch ein Thema?“ kann eine beiläufige Erwähnung der Art „Wir wollten ja noch unser Mitarbeitergespräch führen. Wann passt es denn?“ funktionieren.

Ein dritter Weg, den ich sehr erfolgreich anwenden konnte, besteht darin, für die Themen, die der Vorgesetzte bearbeiten soll, eigene Tickets im Teamboard (sic!) zu schreiben. Das funktioniert besonders gut, wenn sich die Führungskraft als Teil des Teams sieht. Falls man es irgendwie rechtfertigen kann, dass diese Tickets als Blocker für andere Arbeiten des Teams herhalten können, steht das Team früher oder später still, wenn der Chef nicht liefert.

Bei Teams, die ihre Arbeit mit Metriken beobachten, kann so eine Vorgehensweise die Auswertungen ziemlich verschlechtern. Bleiben die fraglichen Tickets lange unbearbeitet, erhöht sich die Cycle Time. Im obigen Beispiel wäre das Ticket „Mitarbeitergespräch führen“ mindestens 8 Monate alt geworden. Das ist in den Umgebungen, die ich kenne, eine sehr schlechte Cycle Time. Falls das ein KPI ist, der im Unternehmen sichtbar gemacht wird, möchte der Vorgesetzte bestimmt nicht, dass dieser Sachverhalt an die große Glocke gehängt wird. Bei diesem Weg macht man sich also die Motivation zunutze, dass der Vorgesetzte Wert auf sein Ansehen in der Firma legt.

Letztlich läuft es in all diesen Fällen darauf hinaus, im Falle eines (unmotiviert wirkenden) Vorgesetzten, die Führung im jeweiligen Einzelfall selbst zu übernehmen.

Erst lesen, dann hören

Nach dem Schreiben des Artikels ist die Idee entstanden, die Frage „Wie motiviere ich meinen Boss?“ im Gespräch mit Führungskräften zu diskutieren. Die Gespräche finden live und online und – bei entsprechender Nachfrage – regelmäßig statt. Die Anmeldung ist kostenlos.

(rme)

Top 10: Die beste Mini-Powerbank fürs Handy im Test

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

Top 10: Die beste Soundbar ohne Subwoofer im Test

PHPUnit 13: Neue Array-Assertions und strengere Mock-Prüfungen

2026-02-10T08:11:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit Version 13 zieht das PHP‑Testwerkzeug die Regeln an und bringt neue Array‑Vergleiche, strengere Mocks sowie eine klare Mindestanforderung an PHP.

(Bild: Smileus/Shutterstock.com)

10.02.2026, 09:11 Uhr

Lesezeit: 4 Min.

Developer

Von

Madeleine Domogalla

Mit PHPUnit 13 hat Maintainer Sebastian Bergmann eine neue Major-Version des verbreiteten Test-Frameworks für PHP vorgelegt. Das Release bringt funktionale Neuerungen, entfernt länger veraltete APIs und zieht die technischen Anforderungen an. Ziel ist es laut dem Projekt, Tests klarer zu formulieren und Missverständnisse zu reduzieren.

Aktuelle PHP-Version erforderlich

PHPUnit 13 setzt PHP 8.4 oder neuer voraus und schließt ältere PHP-Versionen aus. Zur Begründung verweist PHPUnit auf den aktuellen Stand der PHP-Entwicklung: Derzeit entwickeln die PHP-Verantwortlichen nur noch PHP 8.4 und 8.5 aktiv weiter.

Gleichzeitig rät PHPUnit zu einem überlegten Upgrade. Der Wechsel auf eine neue Major-Version soll bewusst erfolgen. Wer mit PHPUnit 12.5 noch Deprecation-Warnungen erhält, sollte diese zuerst beheben, bevor ein Umstieg auf Version 13 erfolgt.

Neue Assertions für Arrays

PHPUnit 13 ergänzt das bestehende Angebot um neue Assertions für Arrays. Sie richten sich an Anwendungsfälle, in denen die bisherigen Methoden assertSame() und assertEquals() nicht fein genug zwischen Vergleichsanforderungen unterscheiden.

Die neuen Assertions erlauben es, Array-Vergleiche genauer zu spezifizieren. Dabei lässt sich festlegen, ob Werte strikt inklusive Typen oder lediglich inhaltlich verglichen werden, ob Array-Schlüssel berücksichtigt werden sollen und ob die Reihenfolge der Elemente relevant ist.

Damit stellt PHPUnit zusätzliche Werkzeuge bereit, um bestimmte Vergleichsszenarien expliziter auszudrücken, etwa bei Vergleichen unabhängig von Sortierung oder bei strikt identischen assoziativen Arrays.

Änderungen bei Mock-Objekten

Bei Mock-Objekten ändert PHPUnit 13 die Prüfung von Übergabeparametern und verabschiedet sich von der Methode withConsecutive(), die bislang dazu diente, unterschiedliche Parameter für aufeinanderfolgende Methodenaufrufe zu prüfen. An ihre Stelle treten zwei spezielle Regeln, mit denen sich Parameterfolgen über mehrere Aufrufe hinweg überprüfen lassen.

Der bisherige Ansatz stieß auf bekannte Grenzen, etwa durch die enge Bindung an eine feste Aufrufreihenfolge und eine zunehmende Unübersichtlichkeit bei komplexeren Szenarien. Gerade seit PHPUnit 10 waren daher häufig zusätzliche Konstruktionen nötig, um entsprechende Aufrufsequenzen abzubilden. Ziel der Neuerung ist es, Erwartungen an Mock-Objekte klarer zu formulieren und die zugehörigen Prüfungen übersichtlicher zu halten.

Videos by heise

Versiegelte Test-Doubles als neue Option

Neu hinzugekommen sind sogenannte sealed test doubles. Mit ihnen schließt PHPUnit die Konfiguration von Mock- oder Stub-Objekten bewusst ab. Ein Stub dient dabei als einfacher Platzhalter für eine Abhängigkeit und liefert festgelegte Rückgabewerte, ohne Aufrufe zu überprüfen. Nach dem Aufruf von seal() lassen sich weder weitere Erwartungen noch zusätzliche Methoden definieren. Bei Mock-Objekten sorgt das zudem dafür, dass nicht ausdrücklich erwartete Methodenaufrufe zurückgewiesen werden.

PHPUnit führt diese Funktion als optionale Ergänzung ein. Bestehende Tests bleiben unverändert lauffähig, lassen sich aber gezielt strenger einstellen, wenn unerwartete Interaktionen frühzeitig auffallen sollen.

any()-Matcher kurz vor dem endgültigen Rausschmiss

Der Matcher any() ist in PHPUnit 13 als „hart veraltet“ (hard-deprecated) markiert. Gemäß Ankündigungsbeitrag liegt das daran, dass Mock-Objekte primär zur Überprüfung konkreter Interaktionen gedacht sind. Wer keine Aufrufe verifizieren möchte, soll stattdessen Stubs verwenden.

Support-Zeiträume und Ausblick

PHPUnit 13 wird gemäß Übersichtsplan der Versionen bis Februar 2028 mit Bugfixes versorgt. PHPUnit 12 bleibt noch bis Februar 2027 im Support, ältere Versionen erhalten keine Fehlerkorrekturen mehr.

Für 2026 sind mehrere Minor Releases der 13er-Reihe geplant. PHPUnit 14 ist derzeit für Februar 2027 angekündigt. Nähere Informationen zu PHPUnit 13 finden sich im Ankündigungsbeitrag sowie im Changelog.

(mdo)

Top 10: Die beste Mini-Powerbank fürs Handy im Test

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

Top 10: Die beste Soundbar ohne Subwoofer im Test

Software Testing: Software-Engineering von morgen

2026-02-10T07:02:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Richard Seidl und Ina Schieferdecker sprechen in dieser Podcast-Episode über Next-Gen Software Engineering und Qualität im KI-Zeitalter.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externer Podcast (Podigee GmbH) geladen.

Podcasts immer laden

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

10.02.2026, 08:02 Uhr

Lesezeit: 1 Min.

Developer

Von

Richard Seidl
Ina Schieferdecker

In dieser Episode sprechen Richard Seidl und Ina Schieferdecker über Next-Gen Software Engineering und Qualität im KI-Zeitalter. Schieferdecker plädiert für Shift-left und klare Testspezifikationen. Das Duo diskutiert, wie Low-Code und No-Code das modellbasierte Arbeiten stärken. Ina Schieferdecker warnt vor durchgewunkenem Code und stellt die Idee eines Model-Bus vor, der Anforderungen, Architektur, Tests und Ausführung über Werkzeuge synchron hält.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externer Podcast (Podigee GmbH) geladen.

Podcasts immer laden

Über Ina Schieferdecker

Prof. Dr.-Ing. Ina Schieferdecker ist unabhängige Forscherin und Honorarprofessorin für Softwarebasierte Innovationen an der Technischen Universität Berlin. Sie ist Mitglied der Deutschen Akademie der Technikwissenschaften (acatech) und Ehrenmitglied des German Testing Board e. V. (GTB) sowie aktiv im International Software Testing Qualifications Board. Darüber hinaus ist sie Präsidiumsmitglied der Gesellschaft für Informatik sowie Vorstandsmitglied von Informatics Europe. Ihre Forschungsinteressen umfassen Software Quality Engineering, offene Datenplattformen und die Twin-Transformation von Digitalisierung und Nachhaltigkeit. Sie ist u.a. Preisträgerin des Deutschen Preises für Software-Qualität des ASQF, der GI-TAV und des GTB.

(Bild: TechSolution)

Der betterCode() GenAI Summit zeigt alle Aspekte der KI-gestützten Softwareentwicklung von geeigneten Tools über praktische Anwendungen bis zu den Auswirkungen auf Entwicklungsteams.

Das Programm des betterCode() GenAI Summit behandelt aktuelle Tools, Best Practices und Möglichkeiten, aber auch die Risiken und rechtlichen Rahmenbedingungen KI-gestützter Softwareentwicklung. Unter anderem gibt es Vorträge zu folgenden Themen:

Coding Agents im Praxiseinsatz: Auswahl und Orchestrierung
KI in der Praxis: Strategien zur Modernisierung komplexer Legacy-Systeme
Spec-Driven Development: Das Ende des Vibe Coding
Sicherheitsnetze für den sicheren Einsatz von Coding-Agenten
KI-generierter Code zwischen Effizienzgewinn und Rechtsrisiko
Design Patterns für das Zeitalter der Agenten

Bis zum 21. April sind die Tickets zum vergünstigten Frühbuchertarif von 999 Euro (zzgl. 19 % MwSt.) verfügbar.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Videos by heise

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Software-Engineering von morgen – Ina Schieferdecker“ und steht auf YouTube bereit.

(mdo)

Top 10: Die beste Mini-Powerbank fürs Handy im Test

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

Top 10: Die beste Soundbar ohne Subwoofer im Test

Die Produktwerker: Detailgrad und Darstellungsform einer Product Roadmap

2026-02-09T09:44:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Wie viel Detail braucht eine Product Roadmap? Oliver Winter und Tim Klein zeigen, wie Darstellung und Fokus Orientierung schaffen statt Scheinsicherheit.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externer Podcast (Podigee GmbH) geladen.

Podcasts immer laden

09.02.2026, 10:44 Uhr

Lesezeit: 3 Min.

Developer

Von

Tim Klein
Oliver Winter

Im Podcast sprechen Oliver Winter und Tim Klein dieses Mal darüber, wie eine Product Roadmap gestaltet sein kann, ohne ihre eigentliche Aufgabe zu verlieren. Beide bringen ihre Erfahrungen aus Trainings und der täglichen Arbeit mit Produktteams ein und nehmen sich bewusst Zeit für die Frage, welchen Detailgrad eine Product Roadmap wirklich braucht und in welcher Darstellungsform sie hilfreich ist.

Eine Product Roadmap entsteht nicht als Lieferplan und auch nicht als Versprechen auf Termine. Sie beschreibt eine Richtung und schafft Orientierung darüber, welche Wirkung mit einem Produkt in welcher Reihenfolge erreicht werden soll. Genau hier liegt der Kern der Diskussion. Eine Product Roadmap hilft dann, wenn sie Klarheit über Ziele und Wirkungen erzeugt und nicht versucht, zukünftige Entwicklungen bis ins letzte Detail vorwegzunehmen. Sie ist keine Vorhersage der Zukunft. Zu viel Genauigkeit erzeugt Scheinsicherheit und lenkt den Blick schnell auf Output statt auf Wirkung.

(Bild: deagreez/123rf.com)

Konferenz in Köln: Die Product Owner Days am 5. und 6. Mai 2026 befassen sich in über 20 Talks mit aktuellen Themen rund um Product Ownership, KI im Produktmanagement, User Research und mehr. Frühbuchertickets sind im Online-Ticketshop verfügbar.

Passende Detailgrade und Darstellungsformen

Der Detailgrad einer Product Roadmap hängt stark vom Kontext ab. In stabilen Umfeldern kann eine längere Vorschau sinnvoll erscheinen, während in einem volatilen Produktumfeld kurze Zeithorizonte und bewusst grobe Darstellungen besser funktionieren. Entscheidend ist, dass die Product Roadmap Raum für Lernen lässt und Veränderungen nicht als Störung wahrgenommen werden. Sie bleibt ein lebendiges Arbeitsinstrument und kein statisches Dokument.

Auch die Darstellungsform spielt dabei eine wichtige Rolle. Eine Product Roadmap darf einfach sein und muss nicht jedes Element erklären, solange sie ihre Richtung klar vermittelt. Wirkungsziele, übergeordnete Themen und zeitliche Orientierung reichen oft aus, um Gespräche zu ermöglichen und Entscheidungen zu unterstützen. Zusätzliche Details entstehen dort, wo sie gebraucht werden, etwa im Backlog oder in der täglichen Arbeit mit dem Team.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmung wird hier ein externer Podcast (Podigee GmbH) geladen.

Podcasts immer laden

Eine gute Product Roadmap macht also sichtbar, was gerade wichtig ist und was bewusst später oder gar nicht verfolgt wird. Sie hilft dabei, Erwartungen zu managen und Diskussionen auf einer sachlichen Ebene zu führen. Gleichzeitig zeigt sie, dass Produktentwicklung kein Abarbeiten von Listen ist, sondern ein kontinuierlicher Prozess aus Entscheiden, Lernen und Anpassen.

Am Ende geht es bei der Product Roadmap um Verantwortung. Wer sie nutzt, übernimmt Verantwortung für Richtung, Fokus und Wirkung des Produkts. Genau dafür ist sie gedacht, und genau dann entfaltet sie ihren Wert im Alltag von Product Ownern, Produktmanagern und Führungskräften.

Videos by heise

Weitere Informationen

Im Gespräch empfehlen Tim Klein und Oliver Winter diese Bücher, Videos und Websites:

Passende frühere Folgen des Podcasts:

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Detailgrad & Darstellungsform einer Product Roadmap“.

(mai)

Top 10: Die beste Mini-Powerbank fürs Handy im Test

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

Top 10: Die beste Soundbar ohne Subwoofer im Test

Nutzungsbasiert statt Festpreis: X ändert Kosten seiner Entwicklerschnittstelle

2026-02-09T09:38:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

X reformiert erneut seine Gebührentabelle für die Entwicklerschnittstelle. Die Einstiegshürde sinkt zwar, die Kosten bleiben aber wohl ähnlich.

API-Zugriffe werden bei X ab sofort nutzungsbasiert abgerechnet.

(Bild: X)

09.02.2026, 10:38 Uhr

Lesezeit: 3 Min.

Von

Malte Kirchner

Das soziale Netzwerk X ändert sein Preismodell für die Nutzung seiner Entwicklerschnittstellen. Der früher Twitter genannte Dienst von Elon Musk stellt dabei von pauschalen Abozahlungen auf nutzungsbasierte Entgelte um. Damit dürfte die Einstiegshürde sinken, die X-API zu verwenden. Berechnungen zeigen allerdings, dass bei moderater Nutzung rasch das bisherige Preisniveau erreicht wird.

„Der Kern der X-Entwickler besteht aus unabhängigen Entwicklern, Produkten in der Frühphase, Start-ups und Hobbyentwicklern“, verkündete der offizielle Entwickler-Account von X im Netzwerk. „Es ist an der Zeit, unser X-API-Ökosystem zu öffnen und eine neue Welle von X-Apps der nächsten Generation zu schaffen. Wir sind wieder da.“

Keine Rückkehr zu alten Twitter-Zeiten

Die neuen Preise bewegen sich zwischen 0,005 und 0,015 US-Dollar pro Abruf. Unterschieden wird unter anderem zwischen API-Abfragen für Posts, Benutzer, Direktnachrichten und Inhalten.

Von den Zeiten vor dem Kauf Twitters durch Musk im Jahr 2022 ist der API-Zugang freilich immer noch weit entfernt. Die Anfangsjahre des Netzwerks galten unter Entwicklern als „goldene Ära“. Bis etwa zum Jahr 2010 war die Twitter-API weit offen. Drittanbieter-Apps wie Twitterific oder Tweetbot trugen massiv zum Wachstum des Netzwerks bei. Es gab kaum Einschränkungen und die API konnte kostenlos genutzt werden.

Videos by heise

Wechselvolle Geschichte der API

Doch schon bevor Twitter den Besitzer wechselte, waren die sonnigen Zeiten für Entwickler vorbei. Im Zuge seines Monetarisierungskurses zog Twitter die Zügel bei der API straffer. Es wurden Obergrenzen bei der Nutzung eingeführt und der Fokus bei der Nutzung der Schnittstellen auf Analyse- und Unternehmens-Tools verlegt. Mit dem Kauf durch Musk folgte ein strikter Monetarisierungskurs und die Aussperrung populärer Apps über Nacht.

Später wurde die bis zum jetzigen Wechsel gültige Bepreisung eingeführt: Entwickler mussten nach anfänglichen 100 US-Dollar später mindestens 200 US-Dollar pro Monat zahlen – hierfür gab es eine Basic Tier, die für kleine Tools und Bots genügte. Problem war allerdings, dass nach Erreichen der Obergrenze der Zugang für den Rest des Monats automatisch gekappt wurde. Start-ups und skalierende Apps griffen deshalb gleich zur Pro-Tier, die mit 5000 US-Dollar pro Monat eine hohe Einstiegshürde setzte.

Mitbewerber bieten kostenlosen Zugang

Mitbewerber von X bieten die Nutzung ihrer Entwicklerschnittstellen kostenlos an – allerdings teilweise mit eingeschränkten Möglichkeiten: So sieht Threads von Meta etwa nur API-Zugriffe vor, die für Analyse- und Posting-Tools interessant sind. Das quelloffene Mastodon gewährt Entwicklern volle Freiheit, hat allerdings eine im Vergleich zu den großen Mitbewerbern nur kleine Nutzerschaft. Bluesky knüpft indessen an alte Twitter-Zeiten an, ist aber im Vergleich auch sehr klein.

(mki)

Top 10: Die beste Mini-Powerbank fürs Handy im Test

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

Top 10: Die beste Soundbar ohne Subwoofer im Test

Software ist ein Werkzeug, kein Selbstzweck: Plädoyer für mehr Fachlichkeit

2026-02-07T08:07:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Zu viele Teams diskutieren über Technologien statt über Probleme. Es ist an der Zeit, den Fokus wieder auf die Fachlichkeit zu richten.

(Bild: LanKS/Shutterstock.com)

09:07 Uhr

Lesezeit: 11 Min.

Developer

Von

Golo Roden

Wir entwickeln Software nicht, weil es so schön ist. Wir entwickeln sie, um fachliche Probleme zu lösen. Diese Unterscheidung klingt banal, aber sie geht in der täglichen Arbeit vieler Teams verloren. Ich beobachte seit Jahren, wie Diskussionen in Entwicklungsteams ablaufen: Es geht um Frameworks, um Architekturstile, um die neueste Technologie. Es geht darum, ob man besser auf Microservices oder auf einen Modulithen setzt, ob man dieses oder jenes Tool verwendet, ob die Code-Coverage hoch genug ist. Worüber erstaunlich selten gesprochen wird: das fachliche Problem, das die Software eigentlich lösen soll.

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.

Das ist kein Zufall und keine Nachlässigkeit. Es ist ein strukturelles Problem unserer Branche. Wir haben uns so sehr an technische Debatten gewöhnt, dass wir gar nicht mehr merken, wie weit wir uns von der eigentlichen Aufgabe entfernt haben. Dieser Artikel ist ein Versuch, das sichtbar zu machen – und ein Plädoyer dafür, den Blick wieder auf das Wesentliche zu richten.

Der Technologie-Tunnelblick

Warum reden wir lieber über Technologie als über Fachlichkeit? Die Antwort ist unbequem, aber nachvollziehbar: Technologie ist greifbar. Sie lässt sich vergleichen, messen, bewerten. Man kann Benchmarks lesen, Dokumentationen studieren, Tutorials durcharbeiten. All das passiert in einer Welt, die Entwicklerinnen und Entwickler kennen und kontrollieren.

Fachliche Probleme sind anders. Sie sind oft vage formuliert, widersprüchlich, und sie erfordern Gespräche mit Menschen, die eine andere Sprache sprechen – nicht im linguistischen Sinne, sondern im Sinne von Denkweisen und Prioritäten. Eine Fachexpertin interessiert sich nicht dafür, ob das System auf Kubernetes läuft. Sie will wissen, ob es ihre Arbeit erleichtert. Das sind verschiedene Welten, und die Brücke zwischen ihnen zu bauen, ist anstrengend.

Hinzu kommt ein strukturelles Problem: Die Branche belohnt technische Expertise stärker als Domänenwissen. Wer sich mit der neuesten Technologie auskennt, gilt als kompetent. Wer die Fachdomäne einer Versicherung oder eines Logistikunternehmens versteht, wird selten auf Konferenzen eingeladen. Das prägt, worauf Entwicklerinnen und Entwickler ihre Energie richten. Und so entstehen Teams, die technisch auf der Höhe der Zeit sind, aber nicht wirklich verstehen, welches Problem sie lösen.

Architekturstile als Glaubensfragen

Nirgends zeigt sich der Technologie-Tunnelblick deutlicher als in der Debatte um Architekturstile. Nehmen Sie die Diskussion um Microservices versus Monolith. In den 2010er-Jahren galt es fast als Naturgesetz, dass Microservices die bessere Wahl sind. Wer einen Monolithen baute, musste sich rechtfertigen. Wer Microservices einsetzte, galt als modern.

Aber was ist eigentlich die fachliche Begründung für Microservices? Im Kern geht es darum, Teile eines Systems unabhängig voneinander entwickeln, deployen und skalieren zu können. Das ist sinnvoll, wenn unterschiedliche Teams an verschiedenen Teilen arbeiten, wenn diese Teile unterschiedliche Lebenszyklen haben, wenn sie unterschiedlich stark genutzt werden. Es ist weniger sinnvoll, wenn ein kleines Team ein überschaubares System baut, bei dem alles zusammenhängt.

Trotzdem entscheiden sich Teams für Microservices, ohne diese Fragen zu stellen. Die Entscheidung fällt nicht auf Basis der Domäne, sondern auf Basis dessen, was gerade als Best Practice gilt. Das Ergebnis sind verteilte Systeme mit all ihrer Komplexität (Netzwerkkommunikation, Eventual-Consistency, Debugging über Servicegrenzen hinweg, …), ohne dass diese Komplexität durch einen fachlichen Nutzen gerechtfertigt wäre.

Die Architektur sollte aus der Domäne folgen, nicht umgekehrt. Wenn das fachliche Problem eine klare Trennung von Verantwortlichkeiten nahelegt, können Microservices die richtige Antwort sein. Wenn das Problem überschaubar ist und die Teile eng zusammenhängen, ist ein gut strukturierter Monolith oft die bessere Wahl. Aber diese Abwägung findet zu selten statt. Stattdessen wird der Architekturstil zur Glaubensfrage, losgelöst von der Realität des Problems.

Prinzipien ohne Kontext

Ähnlich verhält es sich mit Design-Prinzipien. DRY, SOLID, Clean-Code: Diese Begriffe kennt jede Entwicklerin und jeder Entwickler. Sie werden in Büchern gelehrt, in Code-Reviews eingefordert, in Vorstellungsgesprächen abgefragt. Aber sie werden oft so behandelt, als wären sie universelle Gesetze, die immer und überall gelten.

Nehmen Sie DRY (Don't Repeat Yourself). Das Prinzip besagt, dass jede Information im System nur einmal repräsentiert sein sollte. Das klingt einleuchtend. Duplikation führt zu Inkonsistenzen, erschwert Änderungen, erhöht die Fehleranfälligkeit. Soweit die Theorie.

In der Praxis führt die dogmatische Anwendung von DRY oft zu einem anderen Problem: falschen Abstraktionen. Zwei Stellen im Code sehen ähnlich aus, also werden sie zusammengefasst. Aber allzu oft sehen sie nur zufällig ähnlich aus, fachlich haben sie nichts miteinander zu tun. Doch nun sind sie gekoppelt, und wenn sich eine Stelle ändern muss, muss die Abstraktion angepasst werden, die auch die andere Stelle betrifft. Die vermeintliche Vereinfachung wird zur Komplexitätsfalle.

Die Frage, ob Duplikation akzeptabel ist, lässt sich nicht ohne fachlichen Kontext beantworten. Wenn zwei Codestellen dasselbe fachliche Konzept repräsentieren, sollten sie zusammengeführt werden. Wenn sie verschiedene Konzepte repräsentieren, die nur zufällig gleich implementiert sind, sollten sie getrennt bleiben. Aber diese Unterscheidung erfordert ein Verständnis der Domäne – und genau das fehlt oft.

Dasselbe gilt für SOLID, für Clean-Code-Regeln, für jedes Prinzip. Sie sind Heuristiken, keine Gesetze. Ihr Nutzen hängt vom Kontext ab. Eine Klasse mit mehr als 200 Zeilen ist nicht automatisch schlecht. Eine Methode mit drei Parametern ist nicht automatisch besser als eine mit fünf. Es kommt darauf an, was die Klasse oder Methode tut, welches fachliche Konzept sie repräsentiert, wie sie verwendet wird. Wer Prinzipien ohne Kontext anwendet, optimiert für technische Metriken statt für fachliche Klarheit.

Falscher Maßstab für Qualität

Apropos Metriken: Auch bei der Qualitätsmessung zeigt sich der Technologie-Tunnelblick. Test-Coverage ist das prominenteste Beispiel. Eine hohe Coverage gilt als Zeichen guter Qualität. Teams setzen sich Ziele: 80 Prozent, 90 Prozent, manchmal 100 Prozent. Tools visualisieren die Abdeckung, Dashboards zeigen Trends, Code-Reviews fordern Tests für jede neue Zeile.

Aber was misst Test-Coverage eigentlich? Sie misst, wie viel Code von Tests ausgeführt wird. Sie misst nicht, ob die richtigen Dinge getestet werden. Sie misst nicht, ob die Tests sinnvolle Szenarien abdecken. Und sie misst schon gar nicht, ob die Software das fachliche Problem löst.

Es ist möglich, 100 Prozent Coverage zu erreichen und trotzdem eine Software zu haben, die am Bedarf vorbeigeht. Die Tests prüfen, dass der Code macht, was er macht, aber niemand hat jemals geprüft, ob das, was er macht, auch das Richtige ist. Die Anforderungen waren missverstanden, die Domäne war nicht durchdrungen, die Gespräche mit den Fachexpertinnen und Fachexperten haben nicht stattgefunden. Der Code ist technisch einwandfrei und fachlich wertlos.

Ähnlich verhält es sich mit statischen Analysen, Linting-Regeln, Komplexitätsmetriken. Sie alle messen technische Eigenschaften des Codes. Sie können helfen, bestimmte Probleme zu vermeiden. Aber sie können nicht messen, was wirklich zählt: ob die Software das richtige Problem auf die richtige Weise löst. Wer sich auf diese Metriken verlässt, verwechselt technische Sauberkeit mit fachlicher Qualität.

Die Fachlichkeit zurückholen

Wie lässt sich der Fokus verschieben? Es gibt Ansätze, die dabei helfen können: Domain-Driven Design (DDD), Event-Storming, Domain-Storytelling & Co. Sie alle haben gemeinsam, dass sie die Fachlichkeit in den Mittelpunkt stellen. Sie fordern, dass Entwicklerinnen und Entwickler mit Fachexpertinnen und Fachexperten sprechen, dass der Code die Sprache der Domäne spricht, dass Architekturentscheidungen aus dem fachlichen Kontext abgeleitet werden.

Aber hier lauert eine Falle: Auch diese Ansätze können zum Selbstzweck werden. Ich habe kürzlich darüber geschrieben, wie Domain-Driven Design dieses Schicksal ereilt hat. Die Kernbeobachtung: DDD wurde akademisiert. Was als einfache Idee begann („verstehe die Domäne und sprich die Sprache des Business“) ist zu einem Katalog von Patterns geworden, über den Entwicklerinnen und Entwickler diskutieren, statt mit Fachexpertinnen und Fachexperten zu reden.

Das ist bezeichnend. Selbst ein Ansatz, der explizit den Fachfokus propagiert, wurde von uns als Branche in etwas Technisches verwandelt. Wir diskutieren, ob etwas ein Aggregat oder eine Entity ist, statt zu fragen, wie die Fachleute das Konzept nennen. Wir zeichnen Bounded-Context-Diagramme, statt die Grenzen aus der Domäne abzuleiten. Wir lernen die Patterns auswendig, statt die Domäne zu verstehen. Der Sog der Technologie ist so stark, dass er selbst Ansätze vereinnahmt, die gegen ihn gerichtet sind.

Die Lösung liegt nicht in neuen Methoden oder besseren Tools. Sie liegt in einer Haltungsänderung. Wir müssen akzeptieren, dass die schwierige Arbeit, also die Gespräche mit Fachexpertinnen und Fachexperten, das Ringen um Verständnis, das Aushalten von Unsicherheit, nicht durch Technik ersetzt werden kann. Wir müssen den Mut aufbringen, weniger über Frameworks zu reden und mehr über Probleme. Wir müssen uns eingestehen, dass technische Eleganz kein Wert an sich ist, wenn sie nicht im Dienst der Fachlichkeit steht.

Software als Werkzeug, nicht als Kunstwerk

Softwareentwicklung ist angewandte Problemlösung. Wir werden nicht dafür bezahlt, schönen Code zu schreiben. Wir werden dafür bezahlt, Probleme zu lösen. Das klingt banal, aber es hat weitreichende Konsequenzen.

Es bedeutet, dass die beste Architektur nicht die eleganteste ist, sondern die, die das fachliche Problem am besten adressiert. Es bedeutet, dass Prinzipien und Patterns Werkzeuge sind, keine Ziele. Es bedeutet, dass technische Schulden manchmal akzeptabel sind, wenn sie die schnellere Lösung eines dringenden fachlichen Problems ermöglichen. Es bedeutet, dass wir unseren Erfolg nicht an Coverage-Zahlen oder Clean-Code-Metriken messen sollten, sondern daran, ob die Software ihren Zweck erfüllt.

Das erfordert ein Umdenken. Es erfordert, dass wir unsere Komfortzone verlassen und uns auf das einlassen, was unbequem ist: die Kommunikation mit Menschen, die anders denken als wir. Es erfordert Demut, also die Einsicht, dass wir als Entwicklerinnen und Entwickler nicht die Expertinnen und Experten für die Domäne sind, auch wenn wir gerne so tun. Es erfordert Pragmatismus, also die Bereitschaft, technisch suboptimale Lösungen zu akzeptieren, wenn sie fachlich besser passen.

Ich plädiere nicht dafür, technische Qualität zu ignorieren. Guter Code ist wichtig. Saubere Architektur ist wichtig. Tests sind wichtig. Aber all das ist Mittel zum Zweck, nicht Selbstzweck. Wenn wir das vergessen, bauen wir technisch ausgefeilte Systeme, die niemand benötigt. Wir optimieren für Metriken, die nichts aussagen. Wir führen Debatten, die nichts bringen.

Die Frage, die wir uns in jedem Projekt, bei jeder Entscheidung stellen sollten, ist einfach: Hilft das, das fachliche Problem besser zu lösen? Wenn ja, machen wir weiter. Wenn nein, sollten wir innehalten und uns fragen, ob wir gerade der Technologie dienen oder der Fachlichkeit. Die Antwort darauf bestimmt, ob wir Softwareentwicklung als Handwerk betreiben oder als Selbstzweck. (rme)

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

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

2026-02-07T08:04:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Kleine, aber interessante Meldungshäppchen vom News-Buffet zu Elastic, KubeLB, JetBrains, Neos, GitHub, Slint, OpenMP, Google und Accessibility.

(Bild: Natalia Klenova/Shutterstock.com)

09:04 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:

Das Motto des neuen Release Elastic 9.3 lautet „Automate everything“. Dafür bringt das Update der Elasticsearch-Plattform eine Reihe von Neuerungen, durch die Entwicklerinnen und Entwickler mit ihren Daten chatten und maßgeschneiderte KI-Agenten konfigurieren können. Während der Elastic Agent Builder als generell verfügbar gilt, starten die auf Automatisierung ausgelegten Elastic Workflows als Technical Preview.
Kubermatic rüstet KubeLB 1.3 für die im Kubernetes-Ökosystem anstehende Migration von Ingress zur Gateway API. Das Load-Balancing-Tool erhält dazu ein automatisiertes Konvertierungstool als Beta-Funktion. In das neue Release fließen darüber hinaus einige Verbesserungen für die Supply Chain Security ein. KubeLB wartet zudem erstmals mit einer Web Application Firewall (WAF) auf, die zunächst aber noch im Alpha-Status Kunden der Enterprise Edition vorbehalten bleibt.
JetBrains Console ist nun für JetBrains-Kunden mit einem kommerziellen Abo mitsamt KI-Lizenz verfügbar. Die Konsole ermöglicht eine erweiterte KI-Verwaltung und KI-Analytics für Unternehmen. Diese können damit beispielsweise die KI-Kosten auf Unternehmens- oder Teamebene verwalten.
Mit verschiedenen Verbesserungen im Bereich User Experience und Editing hat die Neos Foundation ihr Open-Source-CMS Neos 9.1 veröffentlicht. Der CKEditor ist nun nativ integriert, und es gibt neue Toolbars und Formatierungsoptionen. Die nächste große LTS-Version Neos 9.3 soll ebenfalls noch in diesem Jahr erscheinen.

(Bild: AtemisDiana/Shutterstock)

Die Online-Konferenz Mastering Observability von iX und dpunkt.verlag am 16. April 2026 widmet sich unter anderem den Herausforderungen automatisierter Observability für KI- und agentenbasierte Systeme. Bis zum 18. März sind noch Frühbuchertickets verfügbar.

GitHub hat die generelle Verfügbarkeit von GPT-5.2-Codex für Copilot Enterprise, Copilot Business, Copilot Pro und Copilot Pro+ bekannt gegeben. Developer können das Modell über den Copilot-Chat auch aus den Entwicklungsumgebungen Visual Studio Code, Visual Studio, JetBrains, Xcode und Eclipse heraus nutzen.
Das UI-Framework Slint liegt in Version 1.15 vor. Das Entwicklungsteam hat Layouts mit dynamischen Rastern eingeführt und ermöglicht Zwei-Wege-Bindings für Structs. Über den Slint-Compiler lassen sich zudem Typ-Hinweise für Python hinzufügen.

Lesen Sie auch

Cross-Plattform-Applikationen mit Rust 2: Crux-Architektur in der Praxis

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

Studie: Designer-Wissen macht KI-generierte UIs deutlich besser

2026-02-06T15:55:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Wer KI-Modelle um Designvorschläge bittet, wird häufig enttäuscht. Apple zeigt in einer Studie auf, wie die KI besser werden kann.

(Bild: Redpixel.pl / Shutterstock.com)

06.02.2026, 16:55 Uhr

Lesezeit: 2 Min.

Mac & i

Von

Malte Kirchner

Wer schon mal eine KI gebeten hat, ihm ein User-Interface für eine App vorzuschlagen, dürfte vielfach die Hände über dem Kopf zusammengeschlagen haben. Obwohl es gewiss nicht an Trainingsmaterial mangelt, beweisen Large Language Models kein gutes Händchen dafür, daraus etwas Ästhetisches und zugleich gut Nutzbares zu generieren. Speist man aber das Feedback professioneller Designer ein, sieht der Fall schon ganz anders aus. Dies hat Apple in einer Studie untersucht und die Ergebnisse in seinem Machine-Learning-Blog veröffentlicht.

Das Problem mit den User-Interfaces ist demnach, dass das klassische Anlernen der KI offenbar für Design-Belange völlig unzureichend ist. Bei der herkömmlichen Methode, dem verstärkenden Lernen aus menschlichen Rückmeldungen, vergibt ein Mensch Noten für die Erzeugnisse der KI. Mit dieser Methode, die während des Finetunings in der Trainingsphase eines neuen Modells angewendet wird, soll die KI gut von schlecht unterscheiden können. Doch in der Realität funktioniert das bei Designs dann trotzdem nicht so gut.

Lesen Sie auch

Apple Intelligence braucht Gemini-Hilfe: Google freut sich über Apple-Deal

Vom KI-Modell zur App: So geht das mit Apples Machine-Learning-Workflow

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

Neu in .NET 10.0 [9]: Null-Conditional Assignment in C# 14.0

2026-02-06T14:35:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Entwicklerinnen und Entwickler können nun eine Zuweisung an eine Eigenschaft vornehmen, ohne vorher zu prüfen, ob das Objekt null ist.

(Bild: Pincasso / Shutterstock.com)

06.02.2026, 15:35 Uhr

Lesezeit: 1 Min.

Developer

Von

Dr. Holger Schwichtenberg

Neben den bisher in dieser Blogserie aufgeführten Sprachelementen gibt es ein weiteres sehr hilfreiches neues Sprachkonstrukt in C# 14.0, das Microsoft „Null-Conditional Assignment“ nennt. Damit können Entwicklerinnen und Entwickler eine Zuweisung an eine Eigenschaft vornehmen, ohne vorher zu prüfen, ob das Objekt null ist.

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.

Anstelle von

if (meineWebsite != null)
{
  meineWebsite.Url = "https://www.IT-Visions.de";
  meineWebsite.Url = meineWebsite.Url.ToLower();
  meineWebsite.Counter += 1;
}

darf man nun verkürzt mit dem Fragezeichen vor dem Punkt (?.) ohne if schreiben:

meineWebsite?.Url = "https://www.IT-Visions.de";
meineWebsite?.Url = meineWebsite.Url.ToLower();
meineWebsite?.Counter += 1;

Das führt zur Laufzeit zu keinem Fehler. Allerdings passiert auch rein gar nichts, falls die Variable meineWebsite den Wert null besitzt.

Die Variante

meineWebsite?.Owner.Name = "IT-Visions";
Console.WriteLine("Owner: " + meineWebsite?.Owner.Name);

funktioniert, wenn Website null ist. Aber nicht, wenn Website != null und Owner = null. Dann braucht man:

meineWebsite?.Owner?.Name = "IT-Visions";
Console.WriteLine("Owner: " + meineWebsite?.Owner?.Name);

Das Null-Conditional Assignment ist auch bei einem Indexer erlaubt:

Website[] websites = …;
websites?[0]?.Url = "https://www.IT-Visions.de";

(rme)

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

Microsoft löst .NET Framework 3.5 aus Windows heraus

2026-02-06T11:23:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Das klassische .NET Framework 3.5 wird in Zukunft keine optionale Windows-Komponente mehr sein, sondern ein eigenständiges Setup.

(Bild: Pincasso/Shutterstock.com)

06.02.2026, 12:23 Uhr

Lesezeit: 3 Min.

Developer

Von

Dr. Holger Schwichtenberg

Microsoft hat bekannt gegeben, dass das klassische .NET Framework in der Version 3.5 ab 2026 in Windows 11 nicht mehr Teil des Betriebssystem-Setups sein wird. Bisher war .NET Framework 3.5 eine optionale Komponente bei der Betriebssysteminstallation.

Demnächst eigenständige Installation

Künftig muss man das Installationsprogramm für .NET Framework 3.5 von der Microsoft-Website herunterladen und getrennt ausführen. Diese Änderung betrifft erst einmal nur Windows 11 ab Insider Preview Build 27965 und wird dann aber voraussichtlich schon mit dem Feature-Release 26H1 in den stabilen Windows-Kanal eingehen.

Videos by heise

Für Windows 10 ist diese Änderung nicht geplant. Details zu der Änderung erläutert Microsoft in einer kurzen FAQ.

Support für .NET Framework 3.5 endet 2029

Das .NET Framework 3.5 ist am 19. November 2007 erschienen. Der Support für diese Version endet am 9. Januar 2029, siehe Microsoft .NET Framework Lifecycle Policy. Die Version 3.5 ist eine ältere Version des klassischen .NET Framework, das zahlreiche Nachfolger in den Versionen 4.0, 4.5, 4.6.x, 4.7.x und 4.8.x hatte.

Der Support für die Versionen 4.0, 4.5 und 4.5.1 endete schon im Jahr 2016. Die Versionen 4.5.2, 4.6 und 4.6.1 liefen 2022 aus dem Support. Der Version 4.6.2 geht es am 12. Januar 2027 an den Kragen.

Kein Support-Ende für .NET Framework 4.7 bis 4.8.1

Für die Versionen 4.7 bis 4.8.1 des klassischen .NET Framework wurde noch kein Support-Ende verkündet. Microsoft hatte bei der Einführung der modernen .NET-Versionen (im Jahr 2016 zunächst als .NET Core in den Versionen 1.0 bis 3.1, dann seit Version 5.0 nur noch .NET genannt) zwar offiziell erklärt, dass es keine signifikante Weiterentwicklung des .NET Framework mehr geben wird. Nach dieser Aussage im Jahr 2019 erschien aber im August 2022 noch die Version 4.8.1 für das klassische .NET Framework.

Microsoft hatte auch erklärt, dass man weiterhin an Fehlerbehebungen, Zuverlässigkeit und Sicherheit der klassischen .NET-Framework-Versionen arbeitet und dass das .NET Framework weiterhin mit Windows ausgeliefert werde. Wie die Änderung an der Auslieferungsart von .NET Framework 3.5 jetzt zeigt, bezieht sich diese Aussage „Teil von Windows“ aber offenbar nicht auf alle Versionen.

Aktuelle Version .NET 10.0

Die aktuelle Version des modernen .NET ist die Version 10.0, die am 11. November 2025 erschienen ist – zusammen mit C# 14.0. Im heise-Blog Der Dotnet-Doktor erscheint jede Woche ein Beitrag, der neue Funktionen in C# 14.0 und .NET 10.0 vorstellt.

Details zu der Umstellung von .NET Framework 3.5 finden sich im Microsoft-Blog.

(rme)

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

Interview: So arbeiten die Entwickler bei OpenAI

2026-02-06T10:31:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Programmierassistenten sind allgegenwärtig. iX hat bei OpenAI nachgefragt, wie man den Überblick behält und mit großen Code-Mengen umgeht.

(Bild: Shutterstock/ioda)

06.02.2026, 11:31 Uhr

Lesezeit: 13 Min.

iX Magazin

Von

Philipp Steevens

Für viele Entwickler sind Programmierassistenten auf Basis großer Sprachmodelle (LLMs) nicht mehr wegzudenken. Da Kompetenz in diesem Feld für neue Modelle besonders relevant ist, nennen Entwickler Coding-Kapazitäten oft neben Mathe-Fähigkeiten, wenn sie die nächste Generation ihrer Produkte hypen wollen. Derzeit nutzen Entwickler oft nicht das Eine Modell, sondern greifen für verschiedene Anforderungen auf die Klassenbesten verschiedener Anbieter zu - wenn nicht sogar kleinere Modelle simplere Aufgaben abwickeln.

Unter dem Namen Codex bündelt OpenAI die Programmierfähigkeiten seines Angebots, auf die sich über eine CLI-Variante, als IDE-Extension oder auf dem Mac neuerdings per App zugreifen lässt. Im Gespräch mit iX erzählt Dominik Kundel, Developer Experience Lead bei OpenAI, über Softwareentwicklung mit Codex bei OpenAI und den Zielen, die das Unternehmen mit dem Tool verfolgt.

Dominik Kundel ist Developer Experience Lead für Codex bei OpenAI in San Francisco. Er sitzt bei OpenAI zwischen dem Produkt- und dem Go-to-Market-Team, programmiert am Tooling und an der Dokumentation und Lehrmaterialien, um dafür zu sorgen, dass Leute das Meiste aus Codex herausholen können.

iX: OpenAI hat zwischen 2021 und 2025 drei Werkzeuge vorgestellt, die Codex heißen. Was ist der aktuellste Ableger der Reihe denn jetzt genau?

Dominik: Grundsätzlich verstehen wir Codex als eine Einheit. Codex ist ein Software Engineer, der da sein soll, wo Entwickler arbeiten. Das ist einmal die Terminal-Oberfläche Codex CLI. Außerdem gibt es Codex für Code Reviews in GitHub und IDE Extensions, um Codex in Cursor oder in VS Code zu benutzen. Darunter liegen die Codex-Modelle, aktuell GPT-5.2 Codex. Das sind auf Programmieren trainierte Modelle und der Codex Harness, in dem die Agenten interagieren. Diese Teile geben wir auch in der API raus, worüber Cursor oder Open Code ebenfalls mit Codex interagieren können.

Wie helft ihr euren Nutzern dabei, den Überblick über ihren generierten Code zu behalten?

Einerseits mit der Funktion Codex Code Review, die automatisch mit der ChatGPT-Subscription kommt. Codex ist gut darin, selbst komplexe Codebases zu navigieren und zu verstehen. Wir haben sehr große Codebases bei OpenAI und testen das Ganze damit selber. Andererseits ist Codex gut darin, Rückfragen zu stellen, um den Code zu verbessern. Wir benutzen Codex selbst viel, um sozusagen aufzuräumen. Wir schicken Codex die Aufgabe, Sachen zu refactorn oder Bugs zu finden. Ich hab letztes Jahr am Agents SDK gearbeitet und hatte dabei konstant mehrere Codex-Instanzen laufen, die noch nach Bugs gesucht haben oder Sachen verbessert haben.

Videos by heise

Fast alle bei OpenAI nutzen Codex

Das heißt, ihr entwickelt bei OpenAI selbst mit Codex?

Grundsätzlich sieht es bei uns so aus, wie bei vielen Silicon Valley Softwarefirmen, wir benutzen also Git und PR-Reviews. Allerdings haben wir durch den ganzen Prozess Codex verteilt. Das heißt, Entwickler, aber auch Product Manager, Designer, Data Scientists, andere, eigentlich mittlerweile fast die komplette Firma benutzt Codex, um Code zu schreiben. Der Code geht dann aber noch durch die traditionellen Pull Requests Reviews und den ganzen Prozess. Wir nutzen Codex aber auch für einen zusätzliches Review, durch das aller Code läuft. Wir haben das Modell explizit auf Code Reviews trainiert.

Mich überrascht häufig, wenn Codex Sachen findet, die ich selbst nicht gefunden hätte. Vor allem, da ich zum Teil an Dokumentation arbeite und dann etwa einen Pull Request hochschicke und auf einmal dann ein Kommentar kommt, dass auf der aktuellen Seite die Dokumentation und der Source Code nicht übereinstimmen. Etwa, weil es eine Logikproblem gibt. Trotzdem wird jeder PR noch von Menschen durchschaut. Häufig ist es so, dass die Leute als Erstes Codex benutzen, um den PR zu reviewen und dann eventuell irgendwelche CI/CD Probleme von Codex reparieren lassen, bevor ein Kollege den Pull Request dann durchschaut.

Hast du das Gefühl, du hast dann noch die Kontrolle über die ganzen Agenten oder bist du eigentlich nur noch ein Mensch, der Sachen abnickt?

Nee, ich habe noch Kontrolle. Vor allem bei komplexeren Problemen bitte ich Codex, erstmal einen Plan zu schreiben. Wir haben einen Kollegen, Aaron Friel, der nennt seine Pläne „Exec Plans“. Er lässt das Modell ein komplettes Dokument schreiben, wo es dokumentiert, welche Entscheidungen es getroffen hat und was der Fortschritt ist. Da hat man ein Log, durch das man nochmal durchgehen kann und die Richtigkeit der Entscheidungen bestätigen kann. Das lässt sich auch noch weiter aufteilen, um weiterhin mehrere PR-Reviews zum Durchgehen zu haben.

Was wir generell vorschlagen ist, die gleichen Systeme aufzusetzen, wie wenn man mit einem großen Team an denselben Sachen arbeitet. Das heißt, CI ist eine der ersten Sachen, die ich normalerweise aufsetze, um sicherzustellen, dass ich dann auch Test Coverage habe. Das hilft dann auch Codex. Codex ist generell darauf trainiert, zu verifizieren, ob die Aufgaben fertig sind. Wenn man also nach einem neuen Feature fragt und bereits Tests hat, schreibt Codex automatisch neue Tests. Sowas hilft dann bei der Maintenance. Genauso wie weiterhin Code Reviews zu machen und Dokumentation zu behalten. Ich habe das Gefühl, dass die Codebases besser aussehen, weil Codex hilft Features zu dokumentieren und auch bei anderen Aufgaben hilft, die in der Realität oft hinten anstehen.

Benutzt ihr nur Codex oder benutzt ihr auch Modelle von anderen Anbietern?

Wir benutzen nur OpenAI-Modelle. Bei der Wahl des Editors sind wir nicht festgelegt, da kann jeder Kollege die IDE of Choice einsetzen, die eventuell noch weitere KI-Features hat. Wenn ich mal Code schreiben muss, dann benutze ich Cursor, wo ich dann das Cursor Tab Modell benutze. Cursor ist allerdings auch ein großer OpenAI-Kunde.

Kann Codex mit Claude mithalten?

Viele Entwickler schwören aktuell auf Claude Code mit Opus 4.5. Wie wollt ihr da mit Codex aufholen?

Ich glaube, dass es da zwei Perspektiven gibt. Auf der einen Seite sind die Leute, die Claude Code sehr mögen, mit den Features, die es gibt und auch das Terminal Interface, was die Modelle haben. Die Leute mögen es, mit Opus zu schreiben. Wir hören häufig, dass Codex zu langsam ist. Da arbeiten wir auch dran. Auf der anderen Seite gibt es viele Leute, die mittlerweile auf Codex schwören. Die Anwender loben, dass sie Codex ein Problem geben und das Tool einfach daran arbeitet. Wenn sie dann später wiederkommen, ist Codex komplett fertig.

Anders als bei Claude Code, wo man sich dran gewöhnt hat, hin und her zu schreiben, ist Codex gut darin, ein Problem zu nehmen und wenn es das Ziel verstanden hat, einfach für mehrere Stunden an diesem Problem arbeiten. Peter Steinberger, der im Moment auf X und LinkedIn sehr viral geht, schreibt darüber, dass er Codex bevorzugt und wie er das meiste aus Codex rausholt.

Wie wollt ihr Codex denn schneller machen?

Ich kann da keine Details nennen, aber wir haben zum Beispiel vor Kurzem eine Cerebras-Partnerschaft angekündigt.

Umgang mit großen Codebasen

Du hast über große Codebasen gesprochen, wie ihr sie ja selber habt. Gibt es besondere Strategien für den Umgang damit?

Mono-Repos helfen sehr, um dem Modell Kontext zu geben. Also, in der Lage zu sein, Codex etwa auf das Backend zu verweisen, wenn man gerade zum Beispiel an einer Android-App arbeitet. Ein gutes Beispiel dafür ist unser Browser Atlas. Da gibt es das Agent Panel, über das ein Agent in einem logged-in oder logged-out State dann selbst mit dem Browser umgehen kann. Das Feature und den Wechsel zwischen den Zuständen hat größtenteils Codex geschrieben. Dafür musste es die Codebase mit vier verschiedenen Sprachen durchgehen. Diesen Kontext zu geben ist sehr hilfreich.

Außerdem schlagen wir vor, CI/CD zu haben und generell Validation Tools. Wenn man also Frontend-Produkte baut, auch die Tools zu haben, die sicherstellen, dass die Frontend-Komponenten richtig gerendert werden. Man kann dann die Screenshots wieder als Image-Input in Codex reingeben und Codex kann sich dann quasi selbst validieren. Ein weiterer Punkt ist Naming. Wir empfehlen, Namen zu benutzen, die sehr einfach zu finden sind. Codex benutzt nämlich Tools wie grep und ripgrep, um sich in der Codebase zurechtzufinden. Wenn es die Sachen schnell finden kann, ist Codex wesentlich schneller.

Einer der Gründe, warum Codex den Leuten langsam vorkommt, ist, dass es häufig erstmal auf eine Tour geht, um sich zurechtzufinden. Codex springt nicht direkt rein und schreibt irgendeinen Code, sondern es geht erstmal rum und versucht, zu verstehen. Genauso wie das ein Software-Entwickler machen würde: Wie sieht die Codebase hier aus, wo sind die Daten oder die Dateien, mit denen ich umgehen möchte. Das Modell versucht zu verstehen, wie das Ganze aufgebaut ist, bevor es dann anfängt. Naming Conventions, die dem Modell erlauben einfacher herumzuspringen, helfen.

Das kann die Codex App

Was hebt die neue Codex App vom CLI oder dem Plug-in-Einsatz ab?

Die App ist gezielt entwickelt, um Leuten beim Multitasking zu helfen. Viele Leute nutzen mehrere Codex-Instanzen parallel, die dann mehrere CLI-Tabs nebeneinander aufbauen. Die Codex-App ist als Command Center gedacht. Man kann den Überblick über alle Projekte behalten und schnell zwischen den Projekten wechseln. Dabei hat die App ein ähnliches User-Interface wie die IDE-Extension, man hat also Zugriff auf Features wie Worktrees. Wenn man an mehrere Features in der gleichen Codebase arbeiten will, kann man mehrere Worktrees aufbauen, um dann Aufgaben im Hintergrund laufen zu lassen und dann schnell dazwischen zu wechseln. Außerdem heben wir in der App Agent Skills hervor, also die Möglichkeit, dem Agenten neue Capabilities wie bestimmte APIs oder bestimmte Tools beizubringen.

Also generell Tool-Use-Funktionen?

Das ist ähnlich wie Tool Use, nur, dass der Agent das Ganze „progressively discovered“. Man kann jetzt bestimmte Prozesse einbauen. Ich habe letztens ein Screenshot-Skill gebaut, der auch in der App enthalten ist. Damit kann man Codex anweisen, Screenshots der App zu machen, die Codex dann benutzen kann, um selber zu verifizieren, ob es den Job richtig gemacht hat. Als ich diesen Skill gebaut habe, habe ich dann meinen PR zu GitHub geschickt, der Codex Code Review auf GitHub hat dann ein Problem gefunden. Ich habe dann den GitHub „address code review“-Skill benutzt, um Codex auf GitHub zu schicken und das Problem zu analysieren, zu fixen und ein Update zu dem PR zu schicken.

Man kann in diese Skills Prozesse einarbeiten und dann mit dem kombinieren, was wir Automations nennen. Automations sind dann Aufgaben, die entweder jede Stunde oder zu einer bestimmten Uhrzeit am Tag laufen. Die Automations laufen im Hintergrund auf einem Worktree. Wenn sie irgendein Problem finden, können sie das Ganze an dich weiterleiten. Ein Kollege hat beispielsweise jede Stunde eine Automation laufen, die alle seine Pull Requests durchgeht und guckt, ob CI bei denen grün ist oder ob es irgendwelche Probleme gibt und fixt die dann automatisch selber. Oder die Automation läuft einmal am Tag durch Sentry durch und guckt sich die Error-Logs an. Dann sucht sich das Programm ein besonders großes Problem aus und versucht es selber zu fixen und öffnet einen PR.

Mit Codex und den Automations in der App kann man als Entwickler dann auch die Aufgaben neben der Feature-Entwicklung im Blick behalten. Also die Aufgaben, die so an der Seite hängen oder nicht-technische Aufgaben sind, wie etwa bei der Codebase auf dem Laufenden zu bleiben. Da kann man sich zum Beispiel einmal am Tag ein automatisiertes Update mit den Änderungen an der Codebase schicken lassen und dazu, was in dem Fall an der Dokumentation aktualisiert werden muss.

Codex - nur ein Tool für Experten?

Du hast berichtet, dass ihr am Ende immer die Ergebnisse von Codex kontrolliert. Wie vibe-coding-freundlich ist euer Tool?

Wir wollen, dass Codex eine Stütze für professionelle Entwickler ist. Codex kann an sehr komplexen Problemen arbeiten, weswegen es auch etwas langsamer ist. Das heißt, es kommt darauf an, was man aus dem Vibe Coding herausholen will. Ich habe zum Beispiel schonmal eine komplette Demo-App während eines Meetings gebaut, was viele so Vibe Coding nennen würden. Es funktioniert, aber es ist nicht die gleiche Erfahrung, als wenn man sich beispielsweise was mit Lovable bauen lassen würde.

Dominik, vielen Dank für das Interview.

(pst)

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

Debian: Projektleiter warnt vor stillem Rückzug von Entwicklern

2026-02-06T10:22:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Debian-Projektleiter Andreas Tille prangert ein strukturelles Problem an: Entwickler verschwinden ohne Rückmeldung – mit Folgen für Sicherheit und Wartung.

(Bild: heise medien)

06.02.2026, 11:22 Uhr

Lesezeit: 4 Min.

iX Magazin

Von

Moritz Förster

Das Debian-Projekt hat ein Kommunikationsproblem. Entwickler, die keine Zeit oder kein Interesse mehr haben, ziehen sich still zurück – ohne ihre Verantwortung offiziell zu übertragen. Ein solches Verhalten gefährdet die Wartung von Paketen, die Sicherheit von Accounts und die Kontinuität wichtiger Teams. Debian-Projektleiter Andreas Tille hat das Problem in seiner Februar-Mitteilung an die Entwickler-Community detailliert beschrieben.

Das Kernproblem ist laut Tille nicht, dass Freiwillige aufhören zu arbeiten – das sei völlig normal. Problematisch sei vielmehr, dass sie dies nicht kommunizieren. „Debian existiert, weil Menschen sich freiwillig dafür entscheiden, ihre Zeit dafür aufzuwenden“, schreibt Tille. Doch die meisten seien mit Enthusiasmus beigetreten, ohne eine explizite Vereinbarung zu einer späteren Ankündigung, falls sich ihre verfügbare Zeit, Energie oder Interessen ändern.

Die Konsequenzen dieser stillen Abwanderung sind erheblich: Bugs bleiben unbearbeitet, sicherheitsrelevante Accounts ohne aktive Überwachung, delegierte Rollen existieren nur noch auf dem Papier. Besonders deutlich wurde das Problem bei der Reorganisation des FTPmaster-Teams, das über zwei Jahrzehnte für die Debian-Archive verantwortlich war. Im Oktober 2025 musste es aufgelöst und in zwei neue Teams aufgeteilt werden, weil wesentliche Arbeit von zu wenigen Menschen getragen wurde – mit negativen Auswirkungen auf Transparenz und Kommunikation.

Videos by heise

MIA-Team soll automatisiert nach Inaktiven fahnden

Als Lösung schlägt Tille einen sechsstufigen automatisierten Prozess vor: Das MIA-Team (Missing In Action) soll mithilfe von Heuristiken inaktive Entwickler identifizieren und nach sechs Monaten ohne Aktivität automatisierte E-Mails versenden. Diese bieten einfache Optionen: Bestätigung der aktiven Präsenz, Übergang zum Emeritus-Status (ehrenhalber zurückgezogener Entwickler ohne aktive Pflichten) oder Kontaktaufnahme mit dem MIA-Team.

Bleibt eine Antwort aus, folgen sechs Monate lang monatliche Erinnerungen. Danach versucht das MIA-Team, die Person manuell zu erreichen, und warnt vor der Verwaisung ihrer Pakete. Erfolgt auch dann keine Reaktion, werden die Pakete nach einem weiteren Monat verwaist und der Account wird schließlich den Debian Account Managers zur möglichen Entfernung gemeldet.

Der Vorteil dieses automatisierten Systems: Es vermeidet direkte Fragen, die für manche Menschen sozial schwierig seien. Viele Entwickler empfinden es als unangenehm, von Freunden oder Kollegen direkt auf ihre Inaktivität angesprochen zu werden. „Aus gegenseitiger Rücksicht vermeiden wir es oft, zu fragen. Aus derselben Rücksicht vermeiden wir es auch, proaktiv zu sagen, dass wir zurückgetreten sind“, beschreibt Tille das Dilemma.

Delegation mit Ablaufdatum als weiterer Ansatz

Für delegierte Rollen schlägt Tille zusätzlich einen leichten Erneuerungsmechanismus vor. Delegierte sollen sechs Monate vor Ablauf ihrer Delegation einen kurzen Bericht mit Erneuerungsantrag einreichen. Bleibt dieser aus, läuft die Delegation automatisch ab. Dieser Ansatz normalisiere die Rotation und mache sie zu einem regulären Prozess statt einer konfliktbeladenen Ausnahmesituation.

Ein Beispiel für die Folgen fehlender Kommunikation ist das Data Protection Team: Alle bisherigen Delegierten sind zurückgetreten, die Delegation wurde widerrufen. Debian hat derzeit kein aktives Datenschutz-Team, obwohl die Aufgabe im DSGVO-Kontext wichtig ist. Der Workload war dabei gering – nur vier Anfragen im Jahr 2025.

Tille betont, dass bessere Sichtbarkeit von Inaktivität auch Chancen für neue Freiwillige schafft. Über eineinhalb Jahre hat er täglich ein langfristig inaktives Paket zur Zusammenarbeitsplattform Salsa migriert. Dies senke die Barriere für Beiträge erheblich und sende ein klares Signal, dass Hilfe willkommen ist. Bei aktiven Maintainern seien die Antworten meist konstruktiv gewesen – bei Paketen ohne Aktivität seit Jahren blieb die Reaktion dagegen meist aus.

Unklar ist derzeit, wie viel vom vorgeschlagenen MIA-Prozess bereits implementiert wurde. Tille fordert die Community auf, den aktuellen Status sichtbar zu machen, und lädt Interessierte explizit ein, sich einzubringen. Das Problem betreffe nicht nur Debian: „Dies ist eine wichtige Initiative für die Gesundheit des Debian-Projekts – und tatsächlich für jedes Open-Source-Projekt“, schreibt der Projektleiter.

Lesen Sie auch

Partitionierungs-Tool GParted aktualisiert: stabiler und zuverlässiger

Collabora portiert Debian auf OpenWrt One

Die Rückkehr von Windows Phone: NexPhone mit Android, Linux und Windows 11

Nach Aufgabe des bisherigen Teams: Debian sucht Datenschützer

MX Linux 25: Umstieg auf Debian-Trixie-Basis

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

Wegen Vibe Coding: Open Source nur noch gegen Geld?

2026-02-06T08:37:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Angesichts des Vibe-Coding-Booms empfiehlt eine Studie einen drastischen Schritt: Open-Source-Software soll es nur noch gegen Bezahlung geben.

(Bild: SizeSquares/Shutterstock.com)

06.02.2026, 09:37 Uhr

Lesezeit: 3 Min.

Developer

Von

Manuel Masiero

Die immer stärkere Nutzung von Vibe Coding gefährdet das Open-Source-Prinzip (OSS). Viele OSS-Entwicklerinnen und -Entwickler ziehen ihre Motivation nur aus dem direkten Umgang mit der Community und dem Feedback von ihr. Was Open Source groß gemacht hat, bleibt durch Vibe Coding nun aber zunehmend aus.

Zu diesem Ergebnis kommt die Studie „Vibe Coding Kills Open Source“ der Central European University (CEU), der Universität Bielefeld und des Kieler Instituts für Weltwirtschaft. „Unser wichtigstes Ergebnis ist, dass unter traditionellen OSS-Geschäftsmodellen, bei denen die Verantwortlichen in erster Linie das direkte Nutzerengagement monetarisieren (höhere Sichtbarkeit, die zu bezahlten Gelegenheiten oder anderen Formen der Anerkennung führt), eine stärkere Verbreitung von Vibe Coding das OSS-Angebot reduziert und das Wohlergehen senkt.“

Ihre Urheber verstehen dies als Aufruf zum Handeln und schlagen Lösungen vor. Eine besteht darin, auf ein kostenpflichtiges Open-Source-Modell umzuschwenken, das Erträge an die Maintainer und Kontributoren ausschüttet.

Videos by heise

Viel Traffic, wenig Engagement

Die von vier Ökonomen durchgeführte Studie nennt das CSS-Framework Tailwind CSS als Beispiel für eines von vielen Projekten, dem der Vibe-Coding-Boom zu schaffen macht. Sie zitiert dessen Anbieter mit den Worten, dass Tailwind zwar populärer sei als jemals zuvor, was die Download-Zahlen angeht. Der Traffic bei den Tailwind-Docs sei gegenüber 2023 aber um 40 Prozent gesunken, der Umsatz sogar um fast 80 Prozent.

Stillschweigen: Durch den zunehmenden Einsatz von KI verzeichnen Tailwind (links) und Stack Overflow (rechts) immer weniger Interaktionen.

(Bild: arxiv.org/abs/2601.15494)

Um die Auswirkungen von Vibe Coding auf OSS zu untersuchen, erstellten die Forscher ein Modell des Open-Source-Ökosystems, das auf den zugrundeliegenden ökonomischen Prinzipien basiert. Das Ergebnis: Vibe Coding senkt zwar einerseits die Kosten für die Softwareentwicklung und steigert die Produktivität. Andererseits schwächt es aber die Nachfrage, im Sinne von User-Engagement, und damit den Gemeinwohlgedanken hinter Open Source. „Das zentrale Ergebnis des Modells ist ein Wettrennen zwischen diesen beiden Kanälen.“

Da es nicht mehr hauptsächlich der Mensch ist, sondern die KI, die mit den OSS-Repositories interagiert, entfällt die Mitmach-Komponente weitgehend. Bei OSS-Maintainern, die sich ausschließlich darüber motivieren, verschlechtere sich dadurch die Qualität und die Verfügbarkeit des OSS-Codes.

Lesen Sie auch

Nextcloud schaltet den ADA-Turbo: Deutliche Performance-Verbesserungen kommen

iX-Workshop Keycloak: Die Grundlagen für effizientes IAM und SSO

Smart Home: Alles, was Einsteiger über Home Assistant wissen müssen

LibreOffice 26.2: Schneller, Markdown-Support und bessere Office-Kompatibilität

München macht digitale Souveränität mit eigenem Score messbar

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

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

2026-02-06T08:27:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

OpenAI hat mit GPT-5.3-Codex ein neues Coding-Modell veröffentlicht, das laut Entwickler-Team maßgeblich an seiner eigenen Entwicklung beteiligt war.

(Bild: Tada Images/Shutterstock.com)

06.02.2026, 09:27 Uhr

Lesezeit: 2 Min.

Von

Andreas Floemer

OpenAIs GPT-5.3-Codex erscheint nur knapp zwei Monate nach Veröffentlichung von GPT-5.2-Codex, das Mitte Dezember veröffentlicht wurde. Laut Entwickler vereint die neue Version die Coding-Fähigkeiten von GPT-5.2-Codex mit den Denk- und Wissensfähigkeiten von GPT-5.2. Dabei sei es um 25 Prozent schneller als sein Vorgänger.

Bei der eigenen Entwicklung geholfen

Weiter sagt OpenAI in der Ankündigung, dass GPT-5.3-Codex in vier Leistungstests für Programmierung und praktische Anwendungen auf zwei der vier Benchmarks neue Bestwerte erreiche (SWE-Bench Pro, Terminal-Bench) und bei den anderen beiden (OSWorld, GDPval) starke Leistung zeige.

Laut OpenAI ist GPT‑5.3‑Codex das erste Modell des Unternehmens, „das maßgeblich an seiner eigenen Entwicklung beteiligt war“. Dafür nutzte das Codex-Team frühe Versionen, „um sein eigenes Training zu debuggen, seine eigene Bereitstellung zu verwalten und Testergebnisse und Bewertungen zu diagnostizieren“ – es habe damit dazu beigetragen, seine eigene Entwicklung zu beschleunigen, heißt es.

Videos by heise

Ferner erläutert OpenAI, dass GPT-5.3-Codex im agentischen Coding-Benchmark Terminal-Bench 2.0 seinen Vorgänger als auch das neu erschienene Claude Opus 4.6 (65,4 Prozent) um etwa zwölf Prozent übertreffe – OpenAIs neues Tool erreichte in dem Benchmark 77,3 Prozent. Dabei verbrauche das Modell weniger Token als die Codex-Vorgänger.

GPT-Codex-5.3 im Benchmark-Vergleich mit dem Vorgänger und GPT 5.2.

(Bild: OpenAI)

OpenAI will GPT-5.3-Codex für zahlende ChatGPT-Nutzer in allen Codex-Umgebungen bereitstellen: in der App, über die CLI, in der IDE und im Web. Zudem arbeite OpenAI daran, „bald einen sicheren API-Zugriff zu ermöglichen“. Zudem hatte Apple vor wenigen Tagen angekündigt, KI-Coding-Agenten wie Claude und Codex direkt in die Entwicklungsumgebung Xcode ab Version 26.3 einzubinden.

Die Entwicklungsumgebung nutzt dafür das quelloffene Model Context Protocol (MCP), das den KI-Agenten Zugriff auf Projektstruktur, Build-Logs und Apples Dokumentation ermöglicht. Die neuen Funktionen knüpfen an die Integration von externen Large Language Models (LLMs) in Xcode 26 an, die es schon ermöglichte, Quelltexte automatisch ohne Copy & Paste an GPT und Claude weiterzugeben. Auch GitHub kündigte die Integration der beiden Coding-Agenten an.

(afl)

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

Large Language Models: Die Mathematik hinter Transformers

2026-02-06T07:30:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Die Transformer-Architektur findet sich heute in allen Large Language Models. Aber wie genau funktioniert sie? Der Artikel klärt die mathematischen Hintergründe

Die Mathematik hinter den Transformers

(Bild: DALL-E)

06.02.2026, 08:30 Uhr

Lesezeit: 45 Min.

Developer

Von

Dr. Michael Stal

Im Jahr 2017 veröffentlichte ein Team bei Google ein Paper mit einem gewagten Titel: „Attention Is All You Need.“ Das war nicht nur akademische Prahlerei. Die vorgestellte Transformer-Architektur veränderte grundlegend, wie wir KI-Systeme bauen. Heute basiert jedes große Sprachmodell von GPT über Claude bis Gemini auf diesem Fundament. Wenn Sie ein modernes KI-Tool nutzen, haben Sie bereits mit einem Transformer interagiert.

Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz. Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.

Als Software Engineer haben Sie vielleicht gehört, dass Transformers „nur aus Matrixmultiplikationen“ bestehen oder dass sie „Aufmerksamkeitsmechanismen verwenden“. Diese Beschreibungen sind zwar technisch korrekt, verfehlen aber die elegante mathematische Argumentation, die Transformers funktionieren lässt. Dieser Artikel nimmt Sie mit auf eine Reise zu den Problemen, die Transformers motivierten, bis zu den hochmodernen Optimierungen in Produktionssystemen. Am Ende verstehen Sie nicht nur, was die Mathematik hinter Transformers bedeutet, sondern warum sie genau so sein muss. Damit erlangen Sie das Wissen, um einen Transformer von Grund auf zu implementieren.

Wir folgen einem roten Faden: Wie bauen wir ein System, das Beziehungen zwischen Elementen in einer Sequenz verstehen kann, unabhängig davon, wie weit diese Elemente auseinanderliegen, und dies effizient genug, um auf Milliarden von Beispielen zu trainieren? Jede Formel, jede architektonische Entscheidung resultiert aus der Beantwortung dieser Frage.

Das Problem: Warum Recurrent Networks uns im Stich ließen

Vor Transformers dominierte der Ansatz der Recurrent Neural Networks (RNN) die Sequenzverarbeitung. Um zu verstehen, warum Transformers existieren, müssen wir verstehen, warum wir RNNs trotz ihrer Eleganz nicht auf die Probleme skalieren können, die wir lösen wollen.

Stellen Sie sich vor, Sie bauen ein Übersetzungssystem. Sie erhalten den englischen Satz „The cat sat on the mat“ und müssen die französische Übersetzung produzieren. Ein RNN verarbeitet dies sequenziell. Es liest „The“, aktualisiert seinen internen Zustand, liest dann „cat“, aktualisiert seinen Zustand erneut, und so weiter. Die Idee: Wenn das Übersetzungssystem den Satz zu Ende gelesen hat, enthält sein versteckter Zustand eine komprimierte Repräsentation von allem, was es gesehen hat.

(Bild: Golden Sikorka/Shutterstock)

Die Online-Konferenz LLMs im Unternehmen zeigt am 19. März, wie KI-Agenten Arbeitsprozesse übernehmen können, wie LLMs beim Extrahieren der Daten helfen und wie man Modelle effizient im eigenen Rechenzentrum betreibt.

So aktualisiert ein RNN seinen versteckten Zustand bei jedem Zeitschritt:

h_t = tanh(W_hh * h_{t-1} + W_xh * x_t + b_h)

In dieser Formel repräsentiert h_t den versteckten Zustand zum Zeitpunkt t, x_t ist die Eingabe zum Zeitpunkt t, W_hh ist eine Gewichtsmatrix, die den vorherigen versteckten Zustand transformiert, W_xh transformiert die aktuelle Eingabe, und b_h ist ein Bias-Term. Die tanh-Funktion beschränkt das Ergebnis, um die Werte begrenzt zu halten.

Das Problem zeigt sich, wenn Sie das Ganze aus der Perspektive vieler Zeitschritte betrachten. Angenommen, Sie übersetzen ein langes Dokument, und eine kritische Information erscheint im ersten Satz, aber Sie benötigen diese Information, um den hundertsten Satz korrekt zu übersetzen. Diese Information muss somit eine hundertfache Multiplikation mit W_HH überleben.

Videos by heise

In der Praxis führt dies zu zwei katastrophalen Problemen:

Erstens das Problem verschwindender Gradienten. Beim Training neuronaler Netzwerke berechnen wir Gradienten, die uns sagen, wie wir Gewichte anpassen sollen. Diese Gradienten müssen rückwärts durch die Zeit fließen. Wenn der Gradient bei Schritt 100 die Gewichte beeinflussen muss, die wir im Schritt 1 verarbeitet haben, muss er hundertmal mit der Ableitung der tanh-Funktion multipliziert werden. Da die Ableitung von tanh immer kleiner als eins ist, schrumpft der Gradient exponentiell. Wenn er die frühen Schritte erreicht, bleibt er im Wesentlichen bei null und die Gewichte somit unverändert, ohne dazuzulernen.

Zweitens gibt es, selbst wenn wir verschwindende Gradienten mit Techniken wie LSTMs oder GRUs lösen, ein fundamentaleres Problem: Sequenzielle Verarbeitung ist langsam. Moderne GPUs zeichnen sich durch parallele Berechnung aus. Sie können massive Matrizen unglaublich schnell multiplizieren. Aber RNNs zwingen uns, Sequenzen Schritt für Schritt zu verarbeiten, weil jeder Schritt vom vorherigen abhängt. Sie können h_100 nicht berechnen, bis Sie h_99 berechnet haben, was h_98 erfordert, und so weiter, bis wir schlussendlich h_1 erreichen. Diese sequenzielle Abhängigkeit macht das Training auf den massiven Datensätzen, die wir für moderne KI benötigen, unerträglich langsam.

Die Transformer-Architektur löst beide Probleme mit einer radikalen Idee: Was, wenn wir alle Positionen in der Sequenz gleichzeitig betrachten und das Modell lernen lassen könnten, welche Positionen füreinander relevant sind? Hier kommt Attention ins Spiel.

Die Kernidee: Attention als differenzierbare Lookup-Tabelle

Bevor wir in mathematische Formeln eintauchen, bauen wir Intuition darüber auf, was Attention tatsächlich macht. Stellen Sie sich vor, Sie lesen diesen Satz: „Die Trophäe passte nicht in die Truhe, weil sie zu groß war.“ Worauf bezieht sich „sie“? Ihr Gehirn verarbeitet dies nicht Wort für Wort unter Beibehaltung eines versteckten Zustands. Stattdessen schauen Sie, wenn Sie auf „sie“ stoßen, durch den Satz zurück, finden relevanten Kontext (Trophäe und Truhe) und bestimmen, was angesichts von „zu groß“ sinnvoll ist.

Aufmerksamkeitsmechanismen formalisieren diesen intuitiven Prozess. Im Kern ist Attention ein differenzierbarer Nachschlagemechanismus (Lookup-Mechanismus). In einer traditionellen Lookup-Tabelle oder Hash-Map geben Sie einen Schlüssel an und erhalten einen Wert zurück. Attention macht etwas Ähnliches, aber mit einem entscheidenden Unterschied: Statt exakter Übereinstimmungen berechnet es einen gewichteten Durchschnitt aller Werte, wobei die Gewichte davon abhängen, wie gut jeder Schlüssel zu Ihrer Abfrage passt.

Konkretisieren wir dies mit einem einfachen Beispiel. Angenommen, Sie haben drei Wörter in einem Satz, und jedes Wort repräsentiert sich als Vektor. Sie möchten eine neue Repräsentation für das zweite Wort berechnen, die Informationen von den anderen Wörtern basierend auf ihrer Relevanz einbezieht.

# Einfaches Beispiel mit drei Wortvektoren

wort1 = [1.0, 0.0] # "Die"

wort2 = [0.5, 0.5] # "Katze"

wort3 = [0.0, 1.0] # "saß"

Um nun eine attention-erweiterte Repräsentation für wort2 zu berechnen, müssen wir beantworten: Wie relevant ist jedes andere Wort im Textfragment für wort2? Wir könnten diese Relevanz als Skalarprodukt berechnen, das Ähnlichkeit misst:

relevanz_1_zu_2 = skalarprodukt(wort1, wort2) = 1.0 * 0.5 + 0.0 * 0.5 = 0.5

relevanz_2_zu_2 = skalarprodukt(wort2, wort2) = 0.5 * 0.5 + 0.5 * 0.5 = 0.5

relevanz_3_zu_2 = skalarprodukt(wort3, wort2) = 0.0 * 0.5 + 1.0 * 0.5 = 0.5

Diese rohen Relevanzwerte sind nicht sehr nützlich, weil sie sich nicht zu eins summieren lassen. Wir wollen Gewichte, die wir für einen gewichteten Durchschnitt nutzen können. Hier kommt die Softmax-Funktion ins Spiel. Softmax konvertiert beliebige Werte in eine Wahrscheinlichkeitsverteilung:

def softmax(werte):

exp_werte = [exp(w) for w in werte]

summe_exp = sum(exp_werte)

return [e / summe_exp for e in exp_werte]

Die Softmax-Funktion besitzt eine schöne Eigenschaft: Sie ist differenzierbar, sodass wir sie mit Backpropagation trainieren können, und sie produziert immer Ausgaben, die zu eins summieren und allesamt positive Werte besitzen. Die Exponentialfunktion stellt sicher, dass größere Werte exponentiell mehr Gewicht erhalten, was einen weichen Auswahlmechanismus schafft.

Wenden wir Softmax auf unsere Relevanzwerte an, …

gewichte = softmax([0.5, 0.5, 0.5]) = [0.33, 0.33, 0.33]

…, können wir die Attention-erweiterte Repräsentation als gewichtete Summe berechnen:

erweitertes_wort2 = 0.33 * wort1 + 0.33 * wort2 + 0.33 * wort3

= 0.33 * [1.0, 0.0] + 0.33 * [0.5, 0.5] + 0.33 * [0.0, 1.0]

= [0.495, 0.495]

Dies ist die Essenz von Attention: Wir berechnen, wie relevant jede Position für die aktuelle Position ist, normalisieren diese Relevanzen zu Gewichten und nehmen einen gewichteten Durchschnitt. Das Genie der Transformer liegt darin, diesen Prozess lernbar und effizient zu machen.

Scaled Dot-Product Attention: Das mathematische Fundament

Jetzt sind wir bereit, die tatsächliche Attention-Formel abzuleiten, die Transformers nutzen. Wir bauen sie Schritt für Schritt auf und bekommen Einblick, warum jede Komponente existiert.

Unser Ziel: Einen Mechanismus schaffen, bei dem wir für jede Position in einer Sequenz eine Repräsentation berechnen können, die Informationen von allen anderen Positionen basierend auf gelernter Relevanz einbezieht. Wir benötigen drei Dinge:

eine Möglichkeit auszudrücken, "wonach ich suche" und das an jeder Position. Wir nennen dies die Query (Q). Denken Sie zum Beispiel an eine Suchanfrage in einer Datenbank.
eine Möglichkeit auszudrücken, "was ich anzubieten habe" an jeder Position. Wir nennen dies den Key (K). Denken Sie an den Index in einer Datenbank, gegen den wir abgleichen.
die tatsächliche Information, die wir abrufen möchten. Wir nennen dies den Value (V). Denken Sie an die in der Datenbank gespeicherten Daten.

Warum Keys und Values trennen? Weil das, was wir zur Bestimmung der Relevanz verwenden (der Key), sich von dem unterscheiden kann, was wir tatsächlich abrufen möchten (der Value). Zum Beispiel könnte beim Übersetzen von „Die Katze saß“ das Wort „Katze“ relevant sein, weil es ein Substantiv ist (das erfasst der Key), aber was wir tatsächlich abrufen möchten, ist seine volle semantische Bedeutung (das erfasst der Value).

Wir erzeugen Q, K und V, indem wir unsere Eingabe mit gelernten Gewichtsmatrizen multiplizieren:

Q = X * W_Q

K = X * W_K

V = X * W_V

Hier ist X unsere Eingabematrix, wobei jede Zeile ein Wort-Embedding ist, und W_Q, W_K, W_V lernbare Gewichtsmatrizen. Diese Matrizen lernen während des Trainings, die richtige Art von Informationen für Queries, Keys und Values zu extrahieren.

Um nun Attention zu berechnen, müssen wir messen, wie gut jede Query zu jedem Key passt. Die natürliche Wahl ist das Skalarprodukt, weil es Ähnlichkeit misst: Wenn zwei Vektoren in die gleiche Richtung zeigen, ist ihr Skalarprodukt groß; wenn sie orthogonal sind, ist es Null; wenn sie in entgegengesetzte Richtungen zeigen, ist es negativ.

Wir berechnen alle Query-Key-Ähnlichkeiten auf einmal, indem wir Q und K transponiert multiplizieren:

scores = Q * K^T

Dies gibt uns eine Matrix, bei der Eintrag (i,j) beschreibt, wie intensiv Position i (die Query) auf Position j (den Key) achten sollte. Die Dimensionen ergeben sich daraus wie folgt: Wenn wir n Positionen betrachten und jede Query/jeder Key d-dimensional ist, dann erhalten wir eine Matrix Q mit der Größe n mal d, K^T mit der Größe d mal n, und ihr Produkt mit der Größe n mal n.

Hier stoßen wir auf unser erstes Problem. Erhöht sich die Dimension d wachsen die Skalarprodukte ebenfalls. Um zu sehen, warum, bedenken Sie, dass ein Skalarprodukt eine Summe von d Termen ist. Wenn jeder Term die Varianz sigma zum Quadrat hat, hat die Summe die Varianz d mal sigma zum Quadrat aufgrund der Eigenschaften der Varianz. Dies bedeutet, das Skalarprodukt wächst mit der Quadratwurzel von d.

Warum ist dies ein Problem? Weil wir Softmax auf diese Werte anwenden. Softmax mit sehr großen Eingaben führt allerdings zu extrem „spitzen Werten“. Um dies zu sehen, betrachten Sie:

softmax([10, 9, 8]) = [0.665, 0.245, 0.090]

softmax([100, 90, 80]) = [0.9999, 0.0001, 0.0000]

Wenn die Eingaben für Softmax riesengroß sind, ergibt sich im Wesentlichen eine harte Auswahl, die nur den größten Wert auswählt und alles andere ignoriert. Dies löscht Gradienten während des Trainings aus, weil die Ableitung von Softmax fast überall Null erreicht, außer am Maximum.

Die Lösung besteht darin, die Skalarprodukte durch die Quadratwurzel der Dimension zu skalieren:

skalierte_scores = (Q * K^T) / sqrt(d_k)

Diese Skalierung stellt sicher, dass unabhängig von der Dimension die Varianz der Werte ungefähr konstant bleibt. Die Quadratwurzel wirkt speziell dem Quadratwurzelwachstum entgegen, das wir früher identifiziert haben.

Jetzt wenden wir Softmax an, um Attention-Gewichte zu erhalten:

attention_gewichte = softmax(skalierte_scores)

Schließlich verwenden wir diese Gewichte, um einen gewichteten Durchschnitt der Values zu berechnen:

ausgabe = attention_gewichte * V

Alles zusammengesetzt erhalten wir die Scaled Dot-Product Attention-Formel:

Attention(Q, K, V) = softmax((Q * K^T) / sqrt(d_k)) * V

Implementieren wir das in Code, um es zu veranschaulichen:

import numpy as np

def scaled_dot_product_attention(Q, K, V):
    """
    Berechnet Scaled Dot-Product Attention.
    
    Args:
        Q: Query-Matrix der Form (n, d_k), wobei n die Sequenzlänge ist
        K: Key-Matrix der Form (n, d_k)
        V: Value-Matrix der Form (n, d_v)
        
    Returns:
        ausgabe: Attention-Ausgabe der Form (n, d_v)
        attention_gewichte: Attention-Gewichtsmatrix der Form (n, n)
    """
    # Holt die Dimension der Keys für die Skalierung
    d_k = Q.shape[-1]
    
    # Berechnet Attention-Scores durch Skalarprodukt von Queries und Keys
    # Form: (n, d_k) @ (d_k, n) = (n, n)
    scores = np.matmul(Q, K.transpose(-2, -1))
    
    # Skaliert Scores durch Quadratwurzel der Key-Dimension
    # Dies verhindert, dass Softmax zu spitz wird
    skalierte_scores = scores / np.sqrt(d_k)
    
    # Wendet Softmax an, um Attention-Gewichte zu erhalten
    # Jede Zeile summiert zu 1, repräsentiert eine Wahrscheinlichkeitsverteilung
    attention_gewichte = softmax(skalierte_scores)
    
    # Berechnet gewichtete Summe der Values
    # Form: (n, n) @ (n, d_v) = (n, d_v)
    ausgabe = np.matmul(attention_gewichte, V)
    
    return ausgabe, attention_gewichte

def softmax(x):
    """
    Berechnet Softmax-Werte für jede Zeile der Matrix x.
    Numerisch stabile Implementierung, die den Maximalwert subtrahiert.
    """
    # Subtrahiert Maximum für numerische Stabilität
    # Dies verhindert Overflow durch exp von großen Zahlen
    exp_x = np.exp(x - np.max(x, axis=-1, keepdims=True))
    return exp_x / np.sum(exp_x, axis=-1, keepdims=True)

Dies ist der Kern des Transformers. Alles andere baut auf diesem Fundament auf. Beachten Sie, wie die Formel aus ersten Prinzipien entstand: Wir wollten einen differenzierbaren Lookup-Mechanismus, wir wählten Skalarprodukte für Ähnlichkeit, wir skalierten, um Sättigung zu verhindern, und wir verwendeten Softmax, um normalisierte Gewichte zu erhalten.

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

Cross-Plattform-Applikationen mit Rust 2: Crux-Architektur in der Praxis

2026-02-06T07:04:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Mit Rust und dem Crux-Framework lassen sich Cross-Plattform-Apps mit klarem Core, UI-Trennung und plattformspezifischen Effekten umsetzen.

(Bild: iX)

06.02.2026, 08:04 Uhr

Lesezeit: 9 Min.

Developer

Von

Marcel Koch

Marcel Koch berät mit seinem siebenköpfigen Team kleine und mittelständische Unternehmen und entwickelt branchenübergreifend Cross-Platform-Apps für Desktop und Mobile sowie Webapplikationen – bevorzugt mit TypeScript, Rust, Flutter oder Java, gestützt auf CI/CD und IaC. Dabei setzt er auf pragmatische, passgenaue Lösungen, denn Software ist kein Selbstzweck. Neben soliden technischen Kenntnissen schult er in Gewaltfreier Kommunikation, Transaktionsanalyse sowie Agilität und fördert einen kritischen Blick auf Cloud Hypes. Marcel ist Speaker, Autor von Fachartikeln und Büchern und regelmäßig in Podcasts zu hören.

Die Programmiersprache Rust eignet sich gut für die Umsetzung von Cross-Plattformprojekten. Der erste Teil der Artikelserie hat die grundlegenden Konzepte einer langlebigen Cross-Plattform-Architektur vorgestellt: Ein herausgelöster Core in Rust bildet das Fundament für nachhaltige Apps. Die Implementierung eines einfachen MVVM-Patterns mit ViewModel, Actions und State zeigte eine einfache konkrete Umsetzung dieses Ansatzes. Wie sich die Architektur verfeinern lässt, zeigt sich, wenn man sie um Validierungen erweitert.

Cross-Plattform mit Crux

Das in Rust geschriebene Framework Crux für die plattformübergreifende Entwicklung implementiert die im ersten Artikelteil vorgestellten Konzepte. Was Aktion hieß, nennt Crux Event. Der Zustand(State) heißt Model. Durch den ähnlichen Namen ist die Grenze zum ViewModel leider nicht mehr ganz so deutlich. Das ViewModel heißt nämlich auch bei Crux ViewModel. Umso wichtiger ist es, die Abgrenzung bei der Umsetzung im Hinterkopf zu behalten.

Zudem bringt Crux mit Effect und Command noch weitere wichtige Konzepte mit.

Videos by heise

Ein Effect bildet einen Seiteneffekt der hexagonalen Architektur ab. In diesem Kontext sind Seiteneffekte gleichbedeutend mit Plattformspezifika und dem Rendern des User Interface (UI). Dabei ist ein Effect keine Einbahnstraße. Durch ein Command lässt es sich mit einem Event verknüpfen, sodass der verarbeitete Effekt beantwortet und die Antwort in der App auf ein weiteres Event angewendet werden kann. Auf diese Art lässt sich der Zugriff auf das jeweilige Dateisystem und auf native APIs abstrahieren und umsetzen.

Crux definiert außerdem die Begriffe App, Core und Shell.

Die App ist das zentrale Trait und ein Pendant zum Core aus Teil 1
Core umhüllt die App und sorgt dafür, dass ein Event in die App hinein- und nur eine Liste von Effect oder das ViewModel aus der App hinausgeht
Shell bezeichnetet den Konsumenten des Cores (bepackt mit der App), wie eine native App auf Basis von Swift, Kotlin oder C#

Die Architektur von Crux unterscheidet App, Core und Shell und Effekte (Abb. 1)

(Bild: Marcel Koch)

Beispiel: E-Mail-App

Das zuvor in Teil 1 implementierte Beispiel wird erneut aufgegriffen und auf Crux übertragen. Als Erstes die einfachen Typen (Listing 1):

Listing 1: Crux: Event/Model/ViewModel-Definitionen

#[derive(Deserialize, Serialize)]
pub enum Event {
    ChangeName(String),
    ChangeEmail(String),
    ApplyChanges,
}

#[derive(Default)]
pub struct Model {
    name: String,
    email: String,
}

#[derive(Deserialize, Serialize)]
pub struct ViewModel {
    pub name: String,
    pub email: String,
}

Hierbei gibt es keine Überraschungen. Actions werden zu Event (Einzahl), State wird zu Model und das ViewModel bleibt bestehen.

Als Nächstes die neuen Typen (Listing 2):

Listing 2: Crux: Effect-Enum und App-Struct

#[effect]
pub enum Effect {
    Render(RenderOperation),
}

#[derive(Default)]
pub struct EmailApp;

Das Enum Effect definiert alle möglichen Kommunikationen aus dem Core hinaus. Das Struct EmailApp bleibt leer. Es implementiert im nächsten Schritt das Trait App von Crux.

Die Implementierung von App ist in drei Blöcke (siehe Kommentare in Listing 3) unterteilt.

Listing 3: Crux: App-Trait-Implementierung

impl App for EmailApp {
    // 1
    type Event = Event;
    type Model = Model;
    type ViewModel = ViewModel;
    type Capabilities = (); // deprecated
    type Effect = Effect;

    // 2
    fn update(
        &self,
        event: Self::Event,
        model: &mut Self::Model,
        _caps: &Self::Capabilities,
    ) -> Command<Self::Effect, Self::Event> {
        match event {
            Event::ChangeEmail(email) => {
                model.email = email.clone();
            }
            Event::ChangeName(name) => {
                model.name = name.clone();
            }
            Event::ApplyChanges => {}
        }
        render()
    }

    // 3
    fn view(&self, model: &Self::Model) -> Self::ViewModel {
        ViewModel {
            name: model.name.clone(),
            email: model.email.clone(),
        }
    }
}

Der erste Block legt die grundlegenden assoziierten Typen fest, die App vorsieht. Diese Typen sind aus Listing 1 und 2 bekannt. Der Typ Capabilities ist ein Relikt und gilt als veraltet (deprecated). Dieses Konzept wurde vor der Einführung von Command genutzt. Daher ist es lediglich aus Gründen der Rückwärtskompatibilität vorhanden und lässt sich ignorieren.

Die update-Methode nimmt eingehende Events entgegen und passt daraufhin den Zustand (Model) an. Änderungen am Namen oder der E-Mail-Adresse werden auch hier direkt im Model gespeichert. Nach der Verarbeitung eines Events wird ein Render- Effect ausgelöst. Dieser kann in der Shell aufgegriffen, das ViewModel angefragt und das Re-Rendering angestoßen werden.

Die view-Methode in Abschnitt 3 bietet die Schnittstelle, um das ViewModel zu erstellen. Wie zuvor erzeugt das ViewModel das aktuelle Model (Zustand) und bereitet die relevanten Informationen für die UI so auf, dass die Benutzeroberfläche sie direkt anzeigen kann.

App im Core einwickeln

Um die App zu verwenden, gilt es diese im Core zu umhüllen (zu wrappen):

let core: Arc<Core<EmailApp>> = Arc::new(Core::new());

Dieser Core-Instanz lässt sich ein Event übergeben und die zurückkommenden Effekte können verarbeitet werden (Listing 4).

Listing 4: Crux: Effect-Verarbeitung

let effects: Vec<Effect> =
    core.process_event(ChangeEmail("marcel.koch@example.org".into()));

for effect in effects {
  match effect {
    Effect::Render(_) => {
      let view_model = core.view();
      
      assert_eq!(view_model.email, "marcel.koch@example.org")
    }
  }
}

process_event nimmt das Event entgegen und gibt eine Liste von Effekten zurück. Das Beispiel behandelt nur eine Art von Effect: Render. Es wird geprüft, ob das ViewModel die eben übergebene E-Mail-Adresse enthält.

Ist das UI verbunden, tritt es bei jeder Änderung der E-Mail-Adresse auf.

Core in Bridge wrappen

Geht es nicht um einen reinen Aufruf innerhalb von Rust, ist die Integration in andere Technologien abhängig von Serialisierung. Diese Aufgabe übernimmt auf der Rust-Seite die Bridge. Ein einfacher Einsatz sähe in Rust wie folgt aus:

Listing 5: Crux: Bridge-Integration

let serialized = 
    bincode::serialize(&ChangeEmail("marcel.koch@example.org".into())).unwrap();

let effects: Vec<u8> = bridge.process_event(&serialized).unwrap();

let effects: Vec<Request<EffectFfi>> =
bincode::deserialize(effects.as_slice()).unwrap();

for request in effects {
  let effect = request.effect;
  
  match effect {
    EffectFfi::Render(_) => {
    let view_model = bridge.view().unwrap();
    let view_model: ViewModel =
    bincode::deserialize(&view_model).unwrap();
    
    assert_eq!(view_model.email, "marcel.koch@example.org")
    }
  }
}

Es ist der gleiche Ablauf wie zuvor mit dem reinen Core. Die einzigen Unterschiede sind die Serialisierung des Events und die Deserialisierung der Effekte und des ViewModel. Diese Serialisierungen werden in einem realistischen Einsatz in den jeweiligen Fremdtechnologien (.NET, Swift etc.) durchgeführt. Diese Umsetzung zeigt der nächste Teil dieser Artikelserie.

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

Anthropic stellt Claude Opus 4.6 mit Agent Teams vor

2026-02-05T19:17:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Das neue KI-Modell Claude Opus 4.6 bringt verbesserte Coding-Fähigkeiten, ein größeres Kontextfenster und erstmals eine „Agent-Teams“-Funktion.

(Bild: Anthropic)

Update 20:17 Uhr

Lesezeit: 4 Min.

Von

Dr. Volker Zota

Anthropic hat das neue KI-Modell Opus 4.6 vorgestellt, das primär beim Programmieren deutlich besser abschneiden soll als der Vorgänger. Opus 4.6 ist die erste Version der Opus-Klasse mit einem Kontextfenster von einer Million Token – allerdings noch als Beta-Funktion. Weitere Neuerungen: Agentische Coding-Teams sollen komplexe Aufgaben parallel bearbeiten, Claude passt die Nachdenkzeit automatisch der Fragestellung an und die maximale Ausgabelänge verdoppelt sich. Leistungsfähiger wird die neue Opus-Version obendrein.

Mehrere KI-Instanzen koordinieren

Eine zentrale Neuerung ist die Agent-Teams-Funktion in Claude Code, die sich aktuell in einer Research Preview befindet. Damit lassen sich mehrere Claude-Code-Instanzen parallel ausführen und koordinieren – ähnlich wie bei der kürzlich vorgestellten Codex-App von OpenAI. Eine federführende Session koordiniert dabei die Arbeit, weist Tasks zu und fasst Ergebnisse zusammen. Kurz nach der Veröffentlichung von Opus 4.6 hat OpenAI eine aktualisierte Version GPT-5.3 Codex veröffentlicht. Sie soll GPT-5.2 und GPT-5.2 Codex zusammenführen sowie 25 Prozent schneller sein als die Vorversion.

Die einzelnen Team-Mitglieder sind unabhängige Sessions mit eigenem Kontextfenster. Sie können direkt miteinander kommunizieren und greifen auf eine gemeinsame Task-Liste zu. Die Team-Mitglieder können sich Tasks selbst zuweisen oder zugewiesen bekommen und arbeiten parallel an verschiedenen Problemen. Aktiviert wird die Funktion über die Umgebungsvariable CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Agent Teams verursachen höhere Token-Kosten, weil jede Instanz separat abgerechnet wird. Sie sind für komplexe Zusammenarbeit gedacht, bei der mehrere Perspektiven oder parallele Lösungsansätze gefragt sind.

Im Gegensatz zu den agentischen Teams arbeiten Subagents innerhalb einer einzelnen Session und liefern ihre Ergebnisse nur an den beauftragenden Agenten zurück. Anthropic sieht diese Unteragenten eher für fokussierte Einzelaufgaben vor.

Lesen Sie auch

ChatGPT und Gemini im Vergleich: Duell der KI-Titanen

GPT-5.2: Neues KI-Modell von OpenAI soll Büroarbeiten besser unterstützen

Top 10: Die beste Powerbank ab 20.000 mAh im Test

Top 10: Die beste Android-Box fürs Auto im Test

Top 10: Der beste höhenverstellbare Schreibtisch

Visual Studio Code 1.109: KI-Modelle erstellen Mermaid-Diagramme im Chat

2026-02-05T11:44:00.000Z

${intro} ${title}

${lead}

${intro} ${title}

${lead}

Im VS-Code-Chat können KI-Agenten nun Rückfragen stellen sowie Mermaid-Diagramme erzeugen, und Anthropic-Claude-Modelle zeigen ihren detaillierten Gedankengang.

(Bild: Ground Picture/Shutterstock.com)

12:44 Uhr

Lesezeit: 2 Min.

Developer

Von

Maika Möbus

Visual Studio Code 1.109 ist erschienen und bringt in erster Linie neue Features für den Umgang mit KI-Agenten. So können Entwicklerinnen und Entwickler im Chat die Antwortgenerierung von Anthropic-Claude-Modellen in Echtzeit mitverfolgen und KI-Agenten auf Rückfrage zusätzliche Informationen liefern. Doch auch für die Optik des Source-Code-Editors gibt es im Januar-Update Neuerungen.

Videos by heise

Experimentelle Light und Dark Themes

Als experimentelle neue Themes stehen „VS Code Light“ und „VS Code Dark“ bereit. Sie befinden sich noch in aktiver Entwicklung, lassen sich aber bereits ausprobieren. Entwicklerinnen und Entwickler sind dazu aufgerufen, im VS-Code-Repository auf GitHub ihr Feedback dazu abzugeben.

VS Code 1.109 im experimentellen Dark Theme

(Bild: Microsoft)

VS Code 1.109 im experimentellen Light Theme

(Bild: Microsoft)

Claude-Modellen beim Denken zuschauen

Wer Anthropic-Claude-Modelle in Visual Studio Code nutzt, kann ihren „Denkprozess“ nun dank ihrer Thinking-Token im Chat live mitverfolgen. Das Denken lässt sich entweder detailliert oder kompakt anzeigen, was sich mit der Einstellung chat.thinking.style festlegen lässt, und auch Tool-Aufrufe werden während des Prozesses dargestellt (chat.agent.thinking.terminalTools). Dabei erscheinen fehlgeschlagene Tool-Aufrufe automatisch ausgeklappt (chat.tools.autoExpandFailures).

heise developer News

JavaScript: webpack ist unbeliebt – doch wird am häufigsten genutzt

Vite sägt rasant an webpacks Thron

OpenAI Realtime API bietet günstigeres Mini-Modell für Echtzeitkommunikation

Technische Neuerungen im allgemeinen Release

Modellübersicht

Wie motiviere ich meinen Boss?

Sind Vorgesetzte immer motiviert?

Unterschiedliche Strategien

Erst lesen, dann hören

PHPUnit 13: Neue Array-Assertions und strengere Mock-Prüfungen

Aktuelle PHP-Version erforderlich

Neue Assertions für Arrays

Änderungen bei Mock-Objekten

Versiegelte Test-Doubles als neue Option

any()-Matcher kurz vor dem endgültigen Rausschmiss

Support-Zeiträume und Ausblick

Software Testing: Software-Engineering von morgen

Empfohlener redaktioneller Inhalt

Über Ina Schieferdecker

Die Produktwerker: Detailgrad und Darstellungsform einer Product Roadmap

Passende Detailgrade und Darstellungsformen

Empfohlener redaktioneller Inhalt

Weitere Informationen

Nutzungsbasiert statt Festpreis: X ändert Kosten seiner Entwicklerschnittstelle

Keine Rückkehr zu alten Twitter-Zeiten

Wechselvolle Geschichte der API

Mitbewerber bieten kostenlosen Zugang

Software ist ein Werkzeug, kein Selbstzweck: Plädoyer für mehr Fachlichkeit

Der Technologie-Tunnelblick

Architekturstile als Glaubensfragen

Prinzipien ohne Kontext

Falscher Maßstab für Qualität

Die Fachlichkeit zurückholen

Software als Werkzeug, nicht als Kunstwerk

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

Studie: Designer-Wissen macht KI-generierte UIs deutlich besser

Neu in .NET 10.0 [9]: Null-Conditional Assignment in C# 14.0

Microsoft löst .NET Framework 3.5 aus Windows heraus

Demnächst eigenständige Installation

Support für .NET Framework 3.5 endet 2029

Kein Support-Ende für .NET Framework 4.7 bis 4.8.1

Aktuelle Version .NET 10.0

Interview: So arbeiten die Entwickler bei OpenAI

Fast alle bei OpenAI nutzen Codex

Kann Codex mit Claude mithalten?

Umgang mit großen Codebasen

Das kann die Codex App

Codex - nur ein Tool für Experten?

Debian: Projektleiter warnt vor stillem Rückzug von Entwicklern

MIA-Team soll automatisiert nach Inaktiven fahnden

Delegation mit Ablaufdatum als weiterer Ansatz

Wegen Vibe Coding: Open Source nur noch gegen Geld?

Viel Traffic, wenig Engagement