Wenn Software-Updates mehr kaputt machen als sie reparieren: Ein persönlicher Erfahrungsbericht mit GIMP 3.0.4

Mit GIMP 3.0.4 wurde aus einem stabilen Werkzeug ein Bug-Monster: blockierte Shortcuts, verwaiste Dialoge, kaputte Export- und Font-Funktionen. Der Release wirkt wie KI-generierter Code ohne echte Tests – ein Beispiel dafür, dass KI, CI/CD und Automatisierung keine menschliche Qualitätskontrolle ersetzen können.

Vor wenigen Minuten habe ich über 1 Stunde 30 Minuten damit verloren, der GIMP-Community auf GitLab mehrere Bugs zu melden. Normalerweise mache ich das gerne, wenn ich auf Fehler stoße – schließlich lebt Open-Source-Software davon, dass Nutzer:innen Rückmeldung geben. Aber diesmal war es anders: Die Anzahl, Art und Systematik der Bugs in GIMP 3.0.4 geben mir ein sehr ungutes Gefühl.

Vor dem Update lief alles perfekt

Mit der Version vor 3.0.4 war ich rundum zufrieden. Alles funktionierte reibungslos, die Bedienung war konsistent, und es gab keine Stolperfallen im Workflow. Eigentlich hätte es kein Update gebraucht. Doch aufgrund des Splashscreens mit der neuen Versionsbenachrichtigung habe ich das Update trotzdem eingespielt – und plötzlich ging nichts mehr wie zuvor.

Ein Update voller Stolperfallen

Die Liste der Fehler ist lang, hier nur ein Auszug:

  • GIMP hat plötzlich einen globalen Keyboard Hook, der selbst außerhalb von GIMP alle Shortcuts wie Ctrl+C, Ctrl+V oder Ctrl+S blockiert (VS Code, VS 2022, Android Studio, Linqpad, Notepad++ usw.)
  • Mehrere Dialogfenster verlieren ihren Kontext und werden zu „verwaisten“ Fenstern, die sich unkontrolliert vervielfachen.
  • Im Export-Dialog wächst Text nicht nach rechts, sondern nach links aus dem Fenster hinaus – und die restliche UI reagiert nicht mehr.
  • Die Font-Auswahl und Größenänderung verhält sich grotesk: Statt den Wert im Feld zu ändern, landet meine Eingabe im eigentlichen Bildtext. (Mein Verdacht: die Beschreibung für Code-generierender KI war nicht eindeutig und missverständlich und dadurch hat der KI die Textfelder von Font-Eigenschaften mit dem Text im Bild (Layer) verwechselt. Das passiert oft und ist typisch für Coder mit sehr wenig Erfahrung in Coding und Software-Engineering)
  • Nach dem Rotieren oder Einfärben von Ebenen entstehen nach dem Zuschneiden plötzlich verschobene Layer-Kopien.

Das sind keine Kleinigkeiten, sondern fundamentale Fehler, die das Arbeiten massiv behindern.

Mein Verdacht: KI-Code ohne echte Tests

Die Häufung und Art dieser Bugs weckt bei mir einen starken Verdacht:

  • Es wirkt, als wären viele Code-Änderungen automatisiert entstanden, möglicherweise mit Hilfe von KI-generiertem Code. Z.B. durch unzureichende, nicht-eindeutige und missverständliche Beschreibung für KI, wurde ein Code generiert der zwar mit kein(e) einzige(r) Compiler-Fehler/Warnung übersetzt werden (und laufen) kann, aber sich bei der Nutzung völlig falsch verhält.
  • Darauf aufbauend hat man sich blind auf CI/CD-Pipelines verlassen, ohne dass echte Menschen die Software in Alltagsszenarien getestet haben.
  • Das Ergebnis: ein Release, das wie ein Krebs-Geschwür über die Community ausgerollt wurde.

Natürlich ist das nur mein Eindruck als Nutzer (mit 17+ Jahren Erfahrung in Software-Engineering und Entwicklung). Aber die Systematik der Fehler lässt kaum an Einzelfälle glauben.

KI ersetzt weder Menschen noch Tests durch Menschen

Ich möchte hier einen Punkt betonen: KI kann helfen, Code schneller zu schreiben oder Vorschläge zu liefern. Aber ohne menschliche Qualitätskontrolle, manuelles Testen und kritisches Hinterfragen wird jede Software zur Zumutung. Continuous Delivery (CD) und Continuous Integration (CI) sind mächtige Werkzeuge – aber sie ersetzen nicht das Verständnis für Usability und händisches Durchklicken, das echte Fehler sichtbar macht.

Fazit

Software-Updates sollten Verbesserungen bringen, nicht Regressionen. Im Fall von GIMP 3.0.4 war das Gegenteil der Fall. Ich musste auf die vorherige Version zurückrollen, weil grundlegende Dinge nicht mehr funktionierten.

Mein Appell an alle Entwickler:innen (egal ob Open Source oder kommerziell):

  • Nutzt KI, aber lasst sie nicht allein entscheiden.
  • Vertraut auf CI/CD, aber ergänzt sie mit echten Tests durch Menschen.
  • Denkt an eure Nutzer:innen – sie verlieren sonst Stunden ihrer Lebenszeit für Dinge, die gar nicht hätten passieren dürfen.

Wenn dein Code „Blinde Kuh“ spielt: Eine Reise durch das Labyrinth des digitalen Spaghetti-Chaos!

Ich betrat zum ersten Mal ein mir unbekanntes Haus und war auf der verzweifelten Suche nach einem Kugelschreiber und einem Blatt Papier.

Das Arbeitszimmer!“, dachte ich, „Ein Schriftsteller wohnt hier, dort wird sicherlich ein Schreibutensil zu finden sein.“

Die Türschilder leiteten mich durch die Räume, und ich machte mich auf den Weg zum beschrifteten „Arbeitszimmer“. Dort erwartete ich den klassischen Anblick eines Schreibtisches, Buchregale und ein paar Notizbücher. Doch was mich hinter der Tür erwartete, war der duftende Innenraum eines gut bestückten Kühlschranks, umgeben von Kochutensilien. Verblüfft verließ ich das vermeintliche Arbeitszimmer und folgte meiner Intuition zur Tür mit dem Schild „Küche“. Doch anstelle eines Herds fand ich ein farbenfrohes Kinderzimmer vor.

Nach einigen weiteren, eher komischen Zimmern und einer kleinen, skurrilen Reise durch das Haus, stolperte ich schließlich im „Gästezimmer“ über den lange gesuchten Schreibtisch. Mit einem erleichterten „Endlich!“ auf den Lippen schreckte ich hoch. Es war nur ein Albtraum gewesen, aber wenigstens mit einem glücklichen Ausgang.

Und die Moral der Geschichte lautet: Die Bezeichnung einer Klasse in der Programmierung sollte präzise widerspiegeln, was sich darin befindet. Ein „Converter“ ist dafür da, zu konvertieren und nicht zu formatieren. Ein „Formatter“ sollte keine Serialisierungsmethoden anbieten, genauso wie ein „DatabaseManager“ sich nicht um die Serialisierung von Daten in XML oder JSON kümmern sollte.

Die Analogien in dieser Kurzgeschichte, in der Reihenfolge ihres Auftretens:

  • Unbekanntes Haus: fremder Code
  • Schriftsteller: Datei- oder Klassen-Name
  • Kugelschreiber und Blatt Papier: spezifische, aber festgelegte Methode(n) mit klar definierten Funktionen
  • Türschilder: Namensräume, Klassen-, Methoden- und Property-Namen
  • Albtraum: Albtraum für den Code-Autor, seine Kollegen, die Nachwelt, die Firma und die Kunden
  • Nachwelt: alle, die nach dem Ausscheiden des Autors aus der Firma in irgendeiner Weise mit dem Code in Berührung kommen.