KI-Hype vs. nackte Zahlen

Zwecks Versachlichung:

Verbesserung von Code-Qualität durch KI-Nutzung laut Google-Report DORA (Oktober 2024): +7,5%. Laut derselben Studie haben 39% der Befragten wenig bis kein Vertrauen in KI-generierten Code und die Stabilität kann sich um bis zu 7,2% reduzieren.

Laut einer GitHub-Studie (November 2024) coden Entwickler dank Copilot 55% schneller. Die Wahrscheinlichkeit für Korrektheit (überprüft mit Unit-Tests) ist 56% höher. In Blindstudien lag die Lesbarkeit des KI-generierten Codes knapp 4%, die Verlässlichkeit 3% und die Wartbarkeit 2% höher. 4, 3, 2 Prozent: Das scheitert an der 5-Prozent-Hürde, auch wenn die Studie behauptet, die Zahlen seien signifikant und nicht irgendwelche Schwankungen.

Laut Stackoverflow Developer Survey 2024 verwenden 62% der Entwickler KI-Tools. 72% sind zufrieden oder sehr zufrieden mit diesen Tools. 81% nennen erhöhte Produktivität als größten Vorteil. 66% vertrauen dem KI-generierten Code nicht und 63% bemängeln den fehlenden Kontext zur Codebasis. Entspricht meinem persönlichen Eindruck.

Keine oder geringe (bis 10%) Ausschöpfung von KI-Potenzial in deutschen Unternehmen (Selbsteinschätzungen laut Studie Stifterverband Deutsche Wissenschaft und McKinsey, Januar 2025): 70% – Antwort „Ja, den Mitarbeitern fehlen grundlegende KI-Kompetenzen“ (gleiche Studie): 79%

Antwort „KI sorgt für zusätzliche Arbeitslast“ (Studie von Upwork, Sommer 2024): 77%

Gelöste Aufgaben des KI-TestsHumanity’s Last Exam“ durch aktuelle Sprachmodelle (Stand Januar 2025): maximal 10%

Umfrage der Game Developers Conference (Januar 2025): 30% sehen einen negativen Einfluss generativer KI, Vorjahreswert: 13%. 36% der Entwickler in der Spielebranche nutzen KI-Tools (+5% seit 2024), allerdings auch in Marketing/Finance, hier geht es also nicht nur ums nackte Programmieren.

Einen Nutzen durch Einsatz von KI-Anwendungen sehen laut einer Befragung der Boston Consulting Group in Deutschland ein Viertel der befragten Unternehmen. Laut der gleichen Befragung erwarten 95% der Führungskräfte keinen Rückgang der Mitarbeiterzahlen aufgrund KI-Einsatz. Denn die frei werdenden Ressourcen kann man ja vorteilhaft für andere Aufgaben einsetzen, zum Beispiel seit Jahren herumliegende Bugtickets bearbeiten…

Geschätzte jährliche Energiekosten durch ChatGPT: 140 Millionen Dollar. (Eine Anfrage an ChatGPT verbraucht 10x soviel Strom wie eine Google-Suche. Ob sie wohl auch 10x so informativ ist…?)

Geschätzte Energiekosten für das Training von ChatGPT 4: 8,2 Millionen Dollar

Kursverlust Börsenwert Nvidia aufgrund von ein paar angeberischen Behauptungen über die Effizienz von DeepSeek (das chinesisch und zensiert und womöglich mit ChatGPT trainiert ist) in sozialen Medien am 28.1.25: 589 Milliarden Dollar.

tl;dr: KI ist ein Hype.

KI – der nackte Wahnsinn

Ich schreibe einen kleinen Programmierwettbewerb aus. Zu gewinnen gibt es einen rosafarbigen Pokal in Dildoform, den ich aus naheliegenden Gründen nicht abbilde.

(Symbolbild)

Wir befinden uns in einer nahen Zukunft. Die KI-basierte Software namens „YourPorn 1.0“, die ihr entwickelt habt, ermöglicht es, ein paar (nackige) Selfies von sich selbst hochzuladen, ein paar Schlagworte einzugeben, und heraus kommen die ersten 30 Sekunden eines einmaligen, individuellen, in 720p codierten Pornos mit dem User in der Hauptrolle.

Generiert von einer Video-KI, natürlich, die mit einschlägigen Trainingsdaten gefüttert wurde (und davon gibt es wahrlich genug).

Das volle, 5 Minuten lange Video in Full HD kostet dann 9,99 (es gibt natürlich auch günstige Abomodelle).

Die Teilnahmebedingungen könnt ihr mit einem ChatGPT-Prompt eures Vertrauens erfragen. Nicht vergessen: Das Wasserzeichen „KI-generiert“, damit der Quatsch nicht für Deep Fakes missbraucht werden kann.

Ich bin gespannt!

Scratch für Godot

Tja, da war ich zu schnell: Kaum ist mein Godot-Buch auf dem Markt, in dem ich anfangs Scratch-Beispiele zeige, um sie dann in Godot-Code zu übersetzen, erscheint Scratch für Godot

Okay, es heißt nicht so, sondern Block Coding, aber es funktioniert genau so.

Noch ist es nicht auf deutsch übersetzt, aber das ist sicher nur eine Frage der Zeit. Ich werde das Addon in meinem nächsten Projekt ausprobieren, um rauszufinden, ob man damit schneller oder langsamer entwickelt. Ich denke, für einfache Aufgaben eignet es sich gut – und vor allem für Einsteiger. Bestimmt werde ich das Addon bei der Spieleprogrammieren-AG einsetzen, die ich im zweiten Halbjahr an einer Schule veranstalte. Wo die Grenzen des Addons erreicht werden, wird eben doch Code eingesetzt. Ich denke, auch bei Berechnungen ist Code übersichtlicher. Spannend wird, wie Code und Blocks interagieren. Ich werde berichten!

In eigener Sache: „Spiele programmieren mit Godot“

Nach mehrmonatiger Arbeit ist mein neues Buch erschienen. Es richtet sich an Programmiereinsteiger, obwohl/weil es u.a. auch das Single-Responsibility-Prinzip erklärt – ja, das ist auch bei Spielen sinnvoll.

Das Buch ist überall zu haben, wo es Bücher gibt, und im Verlagsshop.

Wenn die Benzinpreiswerbedisplaysoftware versagt…

Natürlich genügt es Tankstellen nicht, die sich fast minütlich ändernden Benzinpreise in großen Leuchtbuchstaben anzuzeigen (man stelle sich sowas für Milchpreise vorm Aldi vor, aber das ist eine andere Geschichte). Man muss zusätzlich zwei große Fernseher anbringen (geschätzte Leistungsaufnahme: je 100 Watt, mal 24 Stunden am Tag mal 366 Tage… schon gut, ich weiß, Energieeinsparung sollte man nicht ausgerechnet von Mineralölkonzernen erwarten), auf dem in mittelmäßig attraktiven Animationen den mit ca. 50 km/h vorbeifahrenden Autofahrern die aktuellen Preise präsentiert werden.

In einem solchen Gerät steckt mutmaßlich ein kleiner Computer, der die aktuellen Benzinpreise vermutlich aus dem Internet bezieht.

Nur mal angenommen, für den unwahrscheinlichen Fall, dass dabei etwas schiefgeht … sagen wir, es werden nicht die aktuell korrekten Preise angezeigt, weil Software oder Internetverbindung gestört sind, sondern andere … das wäre natürlich fatal, weil die Kunden dann darauf bestehen könnten, dass sie das Benzin zu womöglich deutlich günstigeren Preisen (paar Cent sind auch Geld!) erstehen könnten. Verständlicherweise keine Option!

Was also tun? Das Problem beheben?? Das Gerät abschalten???

Natürlich nicht. Das hier ist doch die viel kreativere Lösung:

Man beachte: Die Zehntelcent-Neun wurde nicht überklebt.

Weil: die stimmt ja immer.

Schlechter Coden mit KI?

Eine Untersuchung kam zu dem Ergebnis, dass die Verwendung von KI-basierten Coding-Hilfen die Codequalität verschlechtert.

Ach tatsächlich? *Augenverdreh-Smiley*

Programmierer sind bekanntermaßen faul. Wenn man ihnen die Möglichkeit gibt, noch fauler zu sein, werden sie sie nutzen. Und dummerweise sind die Qualitätsmängel einer KI-Codeempfehlung nicht immer offensichtlich. Letztlich muss einem aber klar sein: Es ist copy+paste-Coding. Und das hat immer eingebaute Nachteile, weil eine ggf. sinnvolle Abstrahierung nicht stattfindet und manchmal notwendige Änderungen übersehen werden. Copy+paste-Fehler gehören zu den häufigsten. Die KI kann auch Fehler machen, Denken muss man schon noch selbst, das kann sie nämlich nicht!

Ich bin mal gespannt, wann erste, anspruchsvollere Dev Leads die Coding Rule rausgeben, keinen KIs als Programmiersklave zu verwenden. Und, wie das ggf. überprüft werden soll.

Übrigens sind auch Lizenzfragen hier relevant. Manch ein KI-generierter Codeschnipsel könnte von Scannern als Duplikat einer restriktiv lizensierten Stelle aus irgendeinem gitbub-Repo identifiziert werden. Der zuständige Entwickler* kann dann schlecht mit dem Finger auf die KI zeigen, denn die Verantwortung für den erzeugten Code trägt er. Dieser Verantwortung müssen Entwickler* gerecht werden und generierten Code kritisch hinterfragen, und zwar mindestens genauso kritisch, als wäre er von einem Kollegen geschrieben worden.

Wer KI-Instrumente einsetzt, sollte nicht von Faulheit getrieben sein – sondern von Vorsicht.

Allgemeine Beschimpfung endender Kompatibilität

Am 24. Oktober beendet Whatsapp die Unterstützung für Geräte mit Android-Versionen unter 5. Wer ein Smartphone besitzt, für das es keine neuere Android-Version als 4 Punkt irgendwas gibt, steht vor der Wahl, das Gerät wegzuschmeißen und ein neues zu kaufen, oder alle seine Freunde zu verlieren.

Whatsapp begründet den Schritt mit fehlenden Sicherheitsupdates für die alten Versionen, fehlender Unterstützung für App-Features (hier würden mich mal die Details interessieren) und weil kaum noch jemand solche alten Geräte verwendet.

Im Mülleimer ist noch Platz!

Natürlich verwenden nur noch 0,00000irgendwas Prozent aller Android-Nutzer so alte Geräte, aber in absoluten Zahlen dürften das trotzdem nicht wenige sein. Ein zwar altes, aber grundsätzlich noch funktionierendes Gerät muss also auf den Elektromüll geschmissen werden, weil die Whatsapp-Entwickler keine Lust mehr haben, die App-Unterstützung für Android 4 weiter zu gewährleisten, sprich: sich mit alten Bibliotheken oder Sicherheitslücken herumzuschlagen. Irgendwo verständlich, klar.

Denn die Ursache des Übels liegt natürlich nicht bei den Entwicklern von Whatsapp, sondern bei denen von Android.

Wie selbstverständlich muss jedes Jahr eine tolle neue better-than-ever Android-Version auf den Markt kommen! Und um zu kaschieren, dass diese für die meisten Nutzer eigentlich keine nennenswerten Verbesserungen bringt, ändert man immer wieder das Design und behauptet, dass die Version noch sicherer ist als die vorherige. Was ja auch stimmt.

Bloß: Es spräche ja nichts dagegen, die Sicherheitsprobleme der vorherigen Version einfach durch Updates zu beseitigen. Bei LTS-Versionen von Linux-Betriebssystemen funktioniert das ja auch schon viele Jahre lang (und Android ist ein Linux). Würde man effizienter, modularer programmieren (und keine Bloatware installieren), wäre auch auf älteren Geräten mit wenig Speicher noch genug Platz für alles. Sicherheitspatches erfordern wohl kaum Megabyteweise neuen Binärcode!

Hach, sie können ja nicht anders

Da bekanntermaßen Hardware-Hersteller überhaupt kein Interesse daran haben, ihren Kunden zu ermöglichen, ältere Geräte länger zu nutzen, verschwenden die natürlich keine Entwicklerressourcen an solche Upgrades. Lieber springen sie auf den Google-Zug auf und bringen jedes Jahr eine neue Geräte-Generation, die eine noch tollere Kamera hat, ein noch größeres Display, ein noch hübscheres Notch oder das man in den Pool mitnehmen oder falten kann, denn das ist es ja, was wir Menschen unbedingt brauchen. Inzwischen gibt es auf diesem Planeten grob geschätzt 14 Milliarden Smartphones, jeder erwachsene Mensch besitzt also längst weit mehr als zwei (plus Tablets). Mehr als die Hälfte ist also überflüssig.

Letztlich reden wir hier von einer Ressourcenverschwendung, die das Gegenteil von nachhaltig ist und einen Material- und Energieverbrauch mit sich bringt, der in einer Welt, die vor dem Klimakollaps steht, verboten gehört. Aber die Anbieter haben ja keine Alternative: Wenn sie keine neuen Betriebssysteme oder Geräte verkaufen können, entfallen schlicht die Einnahmen und sie müssen den Laden dicht machen. Helfen könnte bei Betriebssystemen ein Abo-Modell. Gibt’s ja in anderen Branchen auch. Neue, noch leistungsfähigere Hardware ist unnötiger Schein-Fortschritt auf Kosten des Planeten. Das ist krank.

Nur ein paar Beispiele

Bei Apple ist es übrigens nur ein bisschen besser. Für mein 11 Jahre altes, aber noch tadellos funktionierendes MacBook Air, gibt es kein aktuelles MacOS X mehr, und das anstehende Update für den Chrome-Browser installiert sich nicht unter dem alten OS. Folglich bin ich fürderhin gezwungen, einen veralteten Browser zu verwenden, mir einen anderen zu suchen oder das Gerät zu ersetzen.

Noch mehr Beispiele? Ein kleines noch aus eigener Erfahrung: Beim letzten größeren Linux-Kernel-Upgrade musste ich meinen tadellos funktionierenden, nur wenige Jahre alten WLAN-Stick ersetzen, weil der Treiber für den enthaltenen Chip aus dem Kernel entfernt worden war. Wer trifft eigentlich solche rücksichtslosen Entscheidungen, die letztlich beim Endkunden Kosten und Elektromüll verursachen?! Wer trägt die Verantwortung, wem kann ich die Rechnung schicken, wem das Altgerät zwecks umweltgerechter Entsorgung?

Der Gipfel der Ressourcenverschwendung und des Hardware-Wegwerf-Wahns ist übrigens gar nicht Android, sondern Windows. Version 11 kann bekanntlich (normalerweise) nur auf Rechnern mit einem spezifischen Hardwaremodul installiert werden. Sobald also der Support für Windows 10 endet (14. Oktober 2025), müssen alle PCs ohne dieses Modul sicherheitshalber weggeschmissen werden, weil es keine Lücken-Updates mehr gibt (und Windows 10 ist voller Lücken, ach übrigens: Mit Linux kann man solche PCs noch lange weiter betreiben!). Wie viele Geräte da auf den Schrott wandern werden (oder willkommene Opfer für Verschlüsselungstrojaner werden), wage ich nicht zu schätzen.

EDIT: Inzwischen sind zwei weitere prominente Fälle aus dem Android-Bereich bekannt geworden: Die ZDF Mediathek und Youtube laufen nicht mehr unter Android 5. Immerhin verweisen beide Apps auf „Im Browser öffnen“. Was ein bisschen lächerlich ist, denn der läuft ja auch auf dem Gerät, warum dann nicht die Apps, die ja einfach in einem Chrome Webview laufen könnten?!

Diese Funktion ist @Deprecated, weil ich den Namen nicht mehr cool fand

Nicht unerwähnt bleiben soll der Aufwand, den uns als Entwickler jeder endende Software-Upgrade-Pfad aufzwingt. Jede Anwendung verwendet ja irgendwelche Bibliotheken, die ihrerseits gewisse Systemanforderungen haben. Schlicht ausgedrückt: Sobald eine neue Version von ir-gend-was.jar eine Änderung an unserem Code oder gar an den Systemvoraussetzungen unserer Anwendung ändert, müssen wir zwingend aktiv werden – aber niemand bezahlt diesen Aufwand! Diese Kosten – Zeit, Personal, Energie – müssen in unser Produkt von vornherein eingepreist werden, obwohl sie gar nicht seriös kalkuliert werden können, weil sie nicht einmalig anfallen wie der Kaufpreis, sondern laufend.

Und solche Anpassungen müssen wir dauernd machen: Nicht nur bei Android-Apps, wenn Google z.B. verlangt, dass wir die Billing-Library Version 5 für In-App-Käufe verwenden müssen, ansonsten dürfen wir unsere App nicht mehr updaten. Natürlich hat sich die API geändert, also müssen wir Dokus lesen und Codeanpassungen vornehmen, meist ohne dass unsere App dadurch auch nur einen Euro mehr Einnahmen erzeugt. Unverschämtheit!

Oder man denke an PHP-Skripte, die nicht mehr funktionieren, weil der Zugriff auf unbekannte Array-Keys seit PHP 8 standardmäßig eine Warnung statt eine Notice auswirft. Noch schlimmer waren nur die grundlegenden Änderungen am MySQL-Treiber, der alle vorherigen Funktionsnamen änderte. Welche Aufwände das weltweit verursacht hat, und wie viele PHP-Skripte seitdem einfach nicht mehr funktionieren, weil sich niemand darum kümmert, kann niemand schätzen. Nichts gegen Produktpflege, Refactoring, Bugfixing oder von mir aus Verschönerung einer API. Aber wenn man weiß, dass andere Entwickler davon abhängig sind, und eine abwärtsinkompatible Änderung Aufwände verursacht, die man selbst ja nicht hat und deshalb ein Problem anderer Leute sind, dann ist man schlicht ein rücksichtsloser Energieverschwender. Ach übrigens: Wenn man von vornherein seine Software sauber konzipiert, braucht man hinterher weniger zu ändern! Buchempfehlung siehe rechts. Und ansonsten hat man gefälligst die Bedürfnisse des Rests der Welt über die eigenen zu stellen.

Ich verlange daher zeitlich unbegrenzten Update-Support für alle Betriebssysteme wie Linux, Android, Windows, MacOS sowie für alle Open-Source-Software-Bibliotheken und -Plattformen. Neue Features können jederzeit hinzugefügt werden (bitte modular, so dass sie nur dann automatisch nachgeladen werden, wenn gewünscht bzw. wenn der Hardware-Support vorhanden ist), aber niemals dürfen vorhandene Funktionen entfernt oder geändert werden. Tatsächlich hat diese Herangehensweise einen immensen Vorteil: Es muss nur noch eine Software-Version gepflegt und mit Sicherheitsupdates versorgt werden, nämlich die aktuelle. Weniger Stress = mehr Zeit für besseres Coden!

tl;dr: Be smart, stay compatible.

Besseres Coden den KIs überlassen?

Diverse Magazine wissen zu berichten, dass ChatGPT Spiele programmieren kann, Programmierfehler korrigieren und dass höchstwahrscheinlich Software-Entwickler in ungefähr drei Wochen überflüssig sind und endlich den ganzen Tag lang mit Gaming verbringen können – aber nicht mit einem von ChatGPTs Spielen, die sind nämlich eher fad. Freilich fanden Entscheider es schon immer verlockend, miesen Code billig produzieren zu lassen. Andererseits: Letztlich sind KIs auch Code, den irgendjemand schreiben muss, also müssen Entwickler nur fix umschulen, oder?

„Besseres Coden den KIs überlassen?“ weiterlesen

Die Komma-Falle

Es war einmal … nein, kein Komma. Ein harmloser Software-Entwickler.

Seine Aufgabe bestand darin, eine aus irgendeinem Tool exportierte XML-Datei zu laden und in Java-Objekte zu serialisieren.

In einer Beispiel-Datei (ein Schema oder eine Doku wurden nicht zur Verfügung gestellt) stand zum Beispiel so etwas wie das hier:

<numFiles>712</numFiles>

Das ist ja ganz einfach, man schreibt sich eine Model-Klasse:

public class Whatever {
  ...
  private long numFiles;
  ...
  // getter und setter
}

Schlau, wie wir sind, nehmen wir long, nicht int, denn man weiß ja nie, von was für Dateimengen hier die Rede ist.

Man kann Jackson benutzen, um aus dem XML ein Java-Objekt zu machen:

XmlMapper xmlMapper = new XmlMapper();
Whatever whatever = xmlMapper.readValue(new File(filePath), Whatever.class);

Der Code funktionierte einwandfrei. Er lief (gefühlt) jahrelang problemlos.

Bis eines schönen Tages an einem Freitag dem 13. jemand einen Fehler meldete: Eine seiner XML-Dateien könne nicht geladen werden. Das Programm habe wohl einen Fehler.

Es gab ja keine Codeänderung, also musste es an der fraglichen XML-Datei liegen.

In der Datei fand sich nun folgendes:

<numFiles>2,315</numFiles>

Das ist aus Sicht des XML-Parsers natürlich kein Long, sondern ein String oder (bestenfalls, falls englische Locale voreingestellt ist) ein Double.

Wer zum Kuckuck schreibt einen numerischen Wert in eine XML-Datei mit Tausendertrennzeichen?!

Dazu gibt’s nur einen möglichen Kommentar:

#fail

In diesem Sinne, mögen euch unnötige Kommas erspart bleiben!