In der US-Softwarebranche wird Python-Code inzwischen zu fast 30 Prozent von KI geschrieben. Zu diesem Ergebnis kommt eine Analyse des Complexity Science Hub (CSH) in Wien in Zusammenarbeit mit der Universität Utrecht. Sie berücksichtigt den Zeitraum von Anfang 2019 bis Ende 2024. Europa folgt bei der Nutzung auf dem zweiten Platz.

Die in der Fachzeitschrift Science veröffentlichte Studie zeigt, dass es regional große Unterschiede bei der Akzeptanz von KI-geschriebenem Python-Code gibt. Am höchsten ist sie in den USA mit einem Anteil von 29 Prozent. Im Jahr 2022 lag der Wert dort noch bei rund fünf Prozent. Frankreich erreicht einen Anteil von 24 Prozent, gefolgt von Deutschland mit 23 Prozent und Indien mit 20 Prozent. Russland (15 %) und China (12 %) lagen am Ende der Studie hingegen noch deutlich zurück.

Die Datenbasis für die Studie wurde ebenfalls mithilfe von KI ermittelt. Dazu kam ein speziell trainiertes KI-Modell zum Einsatz, das mehr als 30 Millionen Python-Codeblöcke von rund 160.000 Entwicklern auf GitHub analysierte. Dabei prüfte das KI-Modell, ob die Python-Beiträge beispielsweise über ChatGPT oder GitHub Copilot erstellt wurden.

Je unerfahrener, desto mehr KI

Zwischen Frauen und Männern ließen sich in der Studie keine Unterschiede hinsichtlich der KI-Nutzung feststellen. Eine große Rolle spielt dagegen die Erfahrung. Während weniger erfahrene Programmiererinnen und Programmierer generative KI in 37 Prozent ihres Codes nutzten, betrug der Anteil bei der erfahrenen Klientel nur 27 Prozent. Geholfen hat es ersteren kaum, denn Produktivitätssteigerungen ließen sich nur bei letzteren feststellen. Die genaue Einordnung ist allerdings schwierig, weil Entwicklerinnen und Entwickler KI-Tools auf sehr unterschiedliche Weise verwenden.

Laut dem CSH hat der Einsatz generativer KI die Produktivität von Programmierern bis Ende 2024 um 3,6 Prozent gesteigert. Was nach wenig klingt, bedeute aber eine erhebliche Wertschöpfung. So würden in den USA jährlich schätzungsweise 637 Milliarden bis 1,06 Billionen US-Dollar in Programmieraufgaben investiert. Eine Produktivitätssteigerung von 3,6 Prozent entspreche daher einem zusätzlichen Wert zwischen 23 und 38 Milliarden US-Dollar pro Jahr. Die Studie schränkt jedoch ein, dass dieser Wert die Messungen von Python-Code verallgemeinert.

(who)

Der schlanke Xfce-Desktop hat bereits zaghaft die Fühler Richtung Wayland ausgestreckt, allerdings bislang nur experimentell und eingeschränkt. Jetzt soll Xfce jedoch mit Anlauf zügig bessere Wayland-Unterstützung durch einen eigenen Compositor – xfwl4 – bekommen.

Das hat das Xfce-Team jetzt in einem Blog-Beitrag angekündigt. Offenbar konnte das Projekt nennenswerte Spenden aus der Community einsammeln und hat sich entschieden, daraus den bereits seit langer Zeit als Xfce-Kernentwickler aktiven Brian Tarricone zu finanzieren. Tarricone soll xfwl4 erstellen, „einen brandneuen Wayland-Compositor für Xfce“. Dafür werde ein signifikanter Teil der Projektspenden draufgehen, jedoch glaubt das Xfce-Team, dass das eine wichtige Investition in die Zukunft der Xfce-Desktop-Umgebung ist.

Xfce: Ziele für Wayland-Compositor

Xfwl4 soll dieselben Funktionen und Verhaltensweise wie xfwm4 liefern – so weit wie möglich, in Anbetracht der Unterschiede von X11 und Wayland. Als Ziel setzen sich die Entwickler, dass sich das Benutzen von xfwl4 genauso anfühlt wie xfwm4 unter X11. „Wir planen sogar, bestehende xfwm4-Konfigurationsdialoge und xfconf-Einstellungen wiederzuverwenden, um einen nahtlosen Übergang zu gewährleisten“, schreiben die Entwickler. Xfwl4 soll nicht auf bestehendem xfwm4-Code aufsetzen, sondern von Grund auf neu in Rust programmiert werden. Die Entwickler haben sich entschieden, den Compositor auf Basis der Bausteine von smithay zu programmieren.

Der erste Versuch, einen Wayland-Compositor für Xfce durch Anpassungen im vorhandenen xfwm4-Code umzusetzen, was in gleichzeitiger Unterstützung für X11 und Wayland münden würde, erwies sich als der falsche Weg. Der Aufbau von xfwm4 mache es schwierig, Window-Management-Verhalten in generische Schnittstellen zu gießen, die keine X11-Spezifikationen enthalten. Die Refaktorierung des Codes sei riskant, da dadurch neue Fehler in X11 einschleichen können – mit zwei parallelen Code-Basen zu arbeiten, erlaube schnellere Entwicklung und Experimentieren mit dem Wayland-Compositor, ohne Risiko, dabei xfwm4 kaputtzumachen. Außerdem würde die bestehende Codebasis die Entwickler dazu nötigen, C und wlroots zu nutzen, wo es doch bessere Alternativen gibt.

Brian Tarricone hat wlroots und smithay evaluiert und sich für letzteres als Basis für xfwl4 entschieden, da es den Großteil der offiziellen Wayland-Protokollerweiterungen sowie das wlroots- und einige KDE-Protokolle unterstützt. Außerdem bevorzugt Tarricone Rust vor C, das vereinfacht zudem, speicherbasierte Fehler zu vermeiden und damit die Wahrscheinlichkeit etwa für Abstürze zu verringern.

Weitere Aufgaben fällig

Es fallen einige Aufgaben an. Zunächst muss xfwl4 erst einmal funktional zu xfwm4 aufrücken. Dazu sind größere Änderungen am Session-Start-up nötig, da der Wayland-Compositor die Wurzel einer Session ist, anstatt xfce4-Session. Auch soll Unterstützung für das xdg-Session-Management kommen, zudem steht auch Support für XWayland auf der Roadmap. Ferner muss das Build-System dafür angepasst und aktualisiert werden. Tarricone hat bereits mit dem Projekt losgelegt. Erste Entwicklungs-Releases könnten bereits in der Jahresmitte erscheinen, hofft das Xfce-Team.

(dmk)

Dokumentation hat bei vielen keinen guten Ruf: zu aufwendig, zu trocken, zu weit weg vom eigentlichen Entwickeln. Häufig entsteht sie losgelöst vom Entwicklungsprozess, wird einmal geschrieben und danach kaum noch gelesen oder gepflegt. Statt ein lebendiger Teil des Produkts zu sein, veraltet sie stillschweigend.

Im agilen Manifest heißt es: „Working software over comprehensive documentation“, also „Funktionierende Software mehr als umfassende Dokumentation.“ Diese Aussage wird oft als Aufruf verstanden, Dokumentation zu vernachlässigen oder ganz wegzulassen. Doch war das wirklich die Intention? Oder geht es vielmehr um eine neue Art von Dokumentation – zur richtigen Zeit, mit dem richtigen Fokus?

In diesem Stream mit Ralf D. Müller und Liam Bergh geht es darum, wie Dokumentation im agilen Umfeld sinnvoll funktionieren kann: leichtgewichtig statt schwerfällig, integriert statt nachgelagert, hilfreich statt Pflichtübung. Es geht um Praxis, Haltung und konkrete Ansätze, um Teams durch Doku zu unterstützen, statt sie auszubremsen.

Livestream am 30. Januar

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

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zu den Folgen finden sich auf der Videocast-Seite.

(mdo)